Root/
1 | # |
2 | # IP configuration |
3 | # |
4 | config IP_MULTICAST |
5 | bool "IP: multicasting" |
6 | help |
7 | This is code for addressing several networked computers at once, |
8 | enlarging your kernel by about 2 KB. You need multicasting if you |
9 | intend to participate in the MBONE, a high bandwidth network on top |
10 | of the Internet which carries audio and video broadcasts. More |
11 | information about the MBONE is on the WWW at |
12 | <http://www.savetz.com/mbone/>. For most people, it's safe to say N. |
13 | |
14 | config IP_ADVANCED_ROUTER |
15 | bool "IP: advanced router" |
16 | ---help--- |
17 | If you intend to run your Linux box mostly as a router, i.e. as a |
18 | computer that forwards and redistributes network packets, say Y; you |
19 | will then be presented with several options that allow more precise |
20 | control about the routing process. |
21 | |
22 | The answer to this question won't directly affect the kernel: |
23 | answering N will just cause the configurator to skip all the |
24 | questions about advanced routing. |
25 | |
26 | Note that your box can only act as a router if you enable IP |
27 | forwarding in your kernel; you can do that by saying Y to "/proc |
28 | file system support" and "Sysctl support" below and executing the |
29 | line |
30 | |
31 | echo "1" > /proc/sys/net/ipv4/ip_forward |
32 | |
33 | at boot time after the /proc file system has been mounted. |
34 | |
35 | If you turn on IP forwarding, you should consider the rp_filter, which |
36 | automatically rejects incoming packets if the routing table entry |
37 | for their source address doesn't match the network interface they're |
38 | arriving on. This has security advantages because it prevents the |
39 | so-called IP spoofing, however it can pose problems if you use |
40 | asymmetric routing (packets from you to a host take a different path |
41 | than packets from that host to you) or if you operate a non-routing |
42 | host which has several IP addresses on different interfaces. To turn |
43 | rp_filter on use: |
44 | |
45 | echo 1 > /proc/sys/net/ipv4/conf/<device>/rp_filter |
46 | or |
47 | echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter |
48 | |
49 | Note that some distributions enable it in startup scripts. |
50 | For details about rp_filter strict and loose mode read |
51 | <file:Documentation/networking/ip-sysctl.txt>. |
52 | |
53 | If unsure, say N here. |
54 | |
55 | config IP_FIB_TRIE_STATS |
56 | bool "FIB TRIE statistics" |
57 | depends on IP_ADVANCED_ROUTER |
58 | ---help--- |
59 | Keep track of statistics on structure of FIB TRIE table. |
60 | Useful for testing and measuring TRIE performance. |
61 | |
62 | config IP_MULTIPLE_TABLES |
63 | bool "IP: policy routing" |
64 | depends on IP_ADVANCED_ROUTER |
65 | select FIB_RULES |
66 | ---help--- |
67 | Normally, a router decides what to do with a received packet based |
68 | solely on the packet's final destination address. If you say Y here, |
69 | the Linux router will also be able to take the packet's source |
70 | address into account. Furthermore, the TOS (Type-Of-Service) field |
71 | of the packet can be used for routing decisions as well. |
72 | |
73 | If you are interested in this, please see the preliminary |
74 | documentation at <http://www.compendium.com.ar/policy-routing.txt> |
75 | and <ftp://post.tepkom.ru/pub/vol2/Linux/docs/advanced-routing.tex>. |
76 | You will need supporting software from |
77 | <ftp://ftp.tux.org/pub/net/ip-routing/>. |
78 | |
79 | If unsure, say N. |
80 | |
81 | config IP_ROUTE_MULTIPATH |
82 | bool "IP: equal cost multipath" |
83 | depends on IP_ADVANCED_ROUTER |
84 | help |
85 | Normally, the routing tables specify a single action to be taken in |
86 | a deterministic manner for a given packet. If you say Y here |
87 | however, it becomes possible to attach several actions to a packet |
88 | pattern, in effect specifying several alternative paths to travel |
89 | for those packets. The router considers all these paths to be of |
90 | equal "cost" and chooses one of them in a non-deterministic fashion |
91 | if a matching packet arrives. |
92 | |
93 | config IP_ROUTE_VERBOSE |
94 | bool "IP: verbose route monitoring" |
95 | depends on IP_ADVANCED_ROUTER |
96 | help |
97 | If you say Y here, which is recommended, then the kernel will print |
98 | verbose messages regarding the routing, for example warnings about |
99 | received packets which look strange and could be evidence of an |
100 | attack or a misconfigured system somewhere. The information is |
101 | handled by the klogd daemon which is responsible for kernel messages |
102 | ("man klogd"). |
103 | |
104 | config IP_ROUTE_CLASSID |
105 | bool |
106 | |
107 | config IP_PNP |
108 | bool "IP: kernel level autoconfiguration" |
109 | help |
110 | This enables automatic configuration of IP addresses of devices and |
111 | of the routing table during kernel boot, based on either information |
112 | supplied on the kernel command line or by BOOTP or RARP protocols. |
113 | You need to say Y only for diskless machines requiring network |
114 | access to boot (in which case you want to say Y to "Root file system |
115 | on NFS" as well), because all other machines configure the network |
116 | in their startup scripts. |
117 | |
118 | config IP_PNP_DHCP |
119 | bool "IP: DHCP support" |
120 | depends on IP_PNP |
121 | ---help--- |
122 | If you want your Linux box to mount its whole root file system (the |
123 | one containing the directory /) from some other computer over the |
124 | net via NFS and you want the IP address of your computer to be |
125 | discovered automatically at boot time using the DHCP protocol (a |
126 | special protocol designed for doing this job), say Y here. In case |
127 | the boot ROM of your network card was designed for booting Linux and |
128 | does DHCP itself, providing all necessary information on the kernel |
129 | command line, you can say N here. |
130 | |
131 | If unsure, say Y. Note that if you want to use DHCP, a DHCP server |
132 | must be operating on your network. Read |
133 | <file:Documentation/filesystems/nfs/nfsroot.txt> for details. |
134 | |
135 | config IP_PNP_BOOTP |
136 | bool "IP: BOOTP support" |
137 | depends on IP_PNP |
138 | ---help--- |
139 | If you want your Linux box to mount its whole root file system (the |
140 | one containing the directory /) from some other computer over the |
141 | net via NFS and you want the IP address of your computer to be |
142 | discovered automatically at boot time using the BOOTP protocol (a |
143 | special protocol designed for doing this job), say Y here. In case |
144 | the boot ROM of your network card was designed for booting Linux and |
145 | does BOOTP itself, providing all necessary information on the kernel |
146 | command line, you can say N here. If unsure, say Y. Note that if you |
147 | want to use BOOTP, a BOOTP server must be operating on your network. |
148 | Read <file:Documentation/filesystems/nfs/nfsroot.txt> for details. |
149 | |
150 | config IP_PNP_RARP |
151 | bool "IP: RARP support" |
152 | depends on IP_PNP |
153 | help |
154 | If you want your Linux box to mount its whole root file system (the |
155 | one containing the directory /) from some other computer over the |
156 | net via NFS and you want the IP address of your computer to be |
157 | discovered automatically at boot time using the RARP protocol (an |
158 | older protocol which is being obsoleted by BOOTP and DHCP), say Y |
159 | here. Note that if you want to use RARP, a RARP server must be |
160 | operating on your network. Read |
161 | <file:Documentation/filesystems/nfs/nfsroot.txt> for details. |
162 | |
163 | config NET_IPIP |
164 | tristate "IP: tunneling" |
165 | select INET_TUNNEL |
166 | select NET_IP_TUNNEL |
167 | ---help--- |
168 | Tunneling means encapsulating data of one protocol type within |
169 | another protocol and sending it over a channel that understands the |
170 | encapsulating protocol. This particular tunneling driver implements |
171 | encapsulation of IP within IP, which sounds kind of pointless, but |
172 | can be useful if you want to make your (or some other) machine |
173 | appear on a different network than it physically is, or to use |
174 | mobile-IP facilities (allowing laptops to seamlessly move between |
175 | networks without changing their IP addresses). |
176 | |
177 | Saying Y to this option will produce two modules ( = code which can |
178 | be inserted in and removed from the running kernel whenever you |
179 | want). Most people won't need this and can say N. |
180 | |
181 | config NET_IPGRE_DEMUX |
182 | tristate "IP: GRE demultiplexer" |
183 | help |
184 | This is helper module to demultiplex GRE packets on GRE version field criteria. |
185 | Required by ip_gre and pptp modules. |
186 | |
187 | config NET_IP_TUNNEL |
188 | tristate |
189 | default n |
190 | |
191 | config NET_IPGRE |
192 | tristate "IP: GRE tunnels over IP" |
193 | depends on (IPV6 || IPV6=n) && NET_IPGRE_DEMUX |
194 | select NET_IP_TUNNEL |
195 | help |
196 | Tunneling means encapsulating data of one protocol type within |
197 | another protocol and sending it over a channel that understands the |
198 | encapsulating protocol. This particular tunneling driver implements |
199 | GRE (Generic Routing Encapsulation) and at this time allows |
200 | encapsulating of IPv4 or IPv6 over existing IPv4 infrastructure. |
201 | This driver is useful if the other endpoint is a Cisco router: Cisco |
202 | likes GRE much better than the other Linux tunneling driver ("IP |
203 | tunneling" above). In addition, GRE allows multicast redistribution |
204 | through the tunnel. |
205 | |
206 | config NET_IPGRE_BROADCAST |
207 | bool "IP: broadcast GRE over IP" |
208 | depends on IP_MULTICAST && NET_IPGRE |
209 | help |
210 | One application of GRE/IP is to construct a broadcast WAN (Wide Area |
211 | Network), which looks like a normal Ethernet LAN (Local Area |
212 | Network), but can be distributed all over the Internet. If you want |
213 | to do that, say Y here and to "IP multicast routing" below. |
214 | |
215 | config IP_MROUTE |
216 | bool "IP: multicast routing" |
217 | depends on IP_MULTICAST |
218 | help |
219 | This is used if you want your machine to act as a router for IP |
220 | packets that have several destination addresses. It is needed on the |
221 | MBONE, a high bandwidth network on top of the Internet which carries |
222 | audio and video broadcasts. In order to do that, you would most |
223 | likely run the program mrouted. If you haven't heard about it, you |
224 | don't need it. |
225 | |
226 | config IP_MROUTE_MULTIPLE_TABLES |
227 | bool "IP: multicast policy routing" |
228 | depends on IP_MROUTE && IP_ADVANCED_ROUTER |
229 | select FIB_RULES |
230 | help |
231 | Normally, a multicast router runs a userspace daemon and decides |
232 | what to do with a multicast packet based on the source and |
233 | destination addresses. If you say Y here, the multicast router |
234 | will also be able to take interfaces and packet marks into |
235 | account and run multiple instances of userspace daemons |
236 | simultaneously, each one handling a single table. |
237 | |
238 | If unsure, say N. |
239 | |
240 | config IP_PIMSM_V1 |
241 | bool "IP: PIM-SM version 1 support" |
242 | depends on IP_MROUTE |
243 | help |
244 | Kernel side support for Sparse Mode PIM (Protocol Independent |
245 | Multicast) version 1. This multicast routing protocol is used widely |
246 | because Cisco supports it. You need special software to use it |
247 | (pimd-v1). Please see <http://netweb.usc.edu/pim/> for more |
248 | information about PIM. |
249 | |
250 | Say Y if you want to use PIM-SM v1. Note that you can say N here if |
251 | you just want to use Dense Mode PIM. |
252 | |
253 | config IP_PIMSM_V2 |
254 | bool "IP: PIM-SM version 2 support" |
255 | depends on IP_MROUTE |
256 | help |
257 | Kernel side support for Sparse Mode PIM version 2. In order to use |
258 | this, you need an experimental routing daemon supporting it (pimd or |
259 | gated-5). This routing protocol is not used widely, so say N unless |
260 | you want to play with it. |
261 | |
262 | config SYN_COOKIES |
263 | bool "IP: TCP syncookie support" |
264 | ---help--- |
265 | Normal TCP/IP networking is open to an attack known as "SYN |
266 | flooding". This denial-of-service attack prevents legitimate remote |
267 | users from being able to connect to your computer during an ongoing |
268 | attack and requires very little work from the attacker, who can |
269 | operate from anywhere on the Internet. |
270 | |
271 | SYN cookies provide protection against this type of attack. If you |
272 | say Y here, the TCP/IP stack will use a cryptographic challenge |
273 | protocol known as "SYN cookies" to enable legitimate users to |
274 | continue to connect, even when your machine is under attack. There |
275 | is no need for the legitimate users to change their TCP/IP software; |
276 | SYN cookies work transparently to them. For technical information |
277 | about SYN cookies, check out <http://cr.yp.to/syncookies.html>. |
278 | |
279 | If you are SYN flooded, the source address reported by the kernel is |
280 | likely to have been forged by the attacker; it is only reported as |
281 | an aid in tracing the packets to their actual source and should not |
282 | be taken as absolute truth. |
283 | |
284 | SYN cookies may prevent correct error reporting on clients when the |
285 | server is really overloaded. If this happens frequently better turn |
286 | them off. |
287 | |
288 | If you say Y here, you can disable SYN cookies at run time by |
289 | saying Y to "/proc file system support" and |
290 | "Sysctl support" below and executing the command |
291 | |
292 | echo 0 > /proc/sys/net/ipv4/tcp_syncookies |
293 | |
294 | after the /proc file system has been mounted. |
295 | |
296 | If unsure, say N. |
297 | |
298 | config NET_IPVTI |
299 | tristate "Virtual (secure) IP: tunneling" |
300 | select INET_TUNNEL |
301 | select NET_IP_TUNNEL |
302 | depends on INET_XFRM_MODE_TUNNEL |
303 | ---help--- |
304 | Tunneling means encapsulating data of one protocol type within |
305 | another protocol and sending it over a channel that understands the |
306 | encapsulating protocol. This can be used with xfrm mode tunnel to give |
307 | the notion of a secure tunnel for IPSEC and then use routing protocol |
308 | on top. |
309 | |
310 | config INET_AH |
311 | tristate "IP: AH transformation" |
312 | select XFRM_ALGO |
313 | select CRYPTO |
314 | select CRYPTO_HMAC |
315 | select CRYPTO_MD5 |
316 | select CRYPTO_SHA1 |
317 | ---help--- |
318 | Support for IPsec AH. |
319 | |
320 | If unsure, say Y. |
321 | |
322 | config INET_ESP |
323 | tristate "IP: ESP transformation" |
324 | select XFRM_ALGO |
325 | select CRYPTO |
326 | select CRYPTO_AUTHENC |
327 | select CRYPTO_HMAC |
328 | select CRYPTO_MD5 |
329 | select CRYPTO_CBC |
330 | select CRYPTO_SHA1 |
331 | select CRYPTO_DES |
332 | ---help--- |
333 | Support for IPsec ESP. |
334 | |
335 | If unsure, say Y. |
336 | |
337 | config INET_IPCOMP |
338 | tristate "IP: IPComp transformation" |
339 | select INET_XFRM_TUNNEL |
340 | select XFRM_IPCOMP |
341 | ---help--- |
342 | Support for IP Payload Compression Protocol (IPComp) (RFC3173), |
343 | typically needed for IPsec. |
344 | |
345 | If unsure, say Y. |
346 | |
347 | config INET_XFRM_TUNNEL |
348 | tristate |
349 | select INET_TUNNEL |
350 | default n |
351 | |
352 | config INET_TUNNEL |
353 | tristate |
354 | default n |
355 | |
356 | config INET_XFRM_MODE_TRANSPORT |
357 | tristate "IP: IPsec transport mode" |
358 | default y |
359 | select XFRM |
360 | ---help--- |
361 | Support for IPsec transport mode. |
362 | |
363 | If unsure, say Y. |
364 | |
365 | config INET_XFRM_MODE_TUNNEL |
366 | tristate "IP: IPsec tunnel mode" |
367 | default y |
368 | select XFRM |
369 | ---help--- |
370 | Support for IPsec tunnel mode. |
371 | |
372 | If unsure, say Y. |
373 | |
374 | config INET_XFRM_MODE_BEET |
375 | tristate "IP: IPsec BEET mode" |
376 | default y |
377 | select XFRM |
378 | ---help--- |
379 | Support for IPsec BEET mode. |
380 | |
381 | If unsure, say Y. |
382 | |
383 | config INET_LRO |
384 | tristate "Large Receive Offload (ipv4/tcp)" |
385 | default y |
386 | ---help--- |
387 | Support for Large Receive Offload (ipv4/tcp). |
388 | |
389 | If unsure, say Y. |
390 | |
391 | config INET_DIAG |
392 | tristate "INET: socket monitoring interface" |
393 | default y |
394 | ---help--- |
395 | Support for INET (TCP, DCCP, etc) socket monitoring interface used by |
396 | native Linux tools such as ss. ss is included in iproute2, currently |
397 | downloadable at: |
398 | |
399 | http://www.linuxfoundation.org/collaborate/workgroups/networking/iproute2 |
400 | |
401 | If unsure, say Y. |
402 | |
403 | config INET_TCP_DIAG |
404 | depends on INET_DIAG |
405 | def_tristate INET_DIAG |
406 | |
407 | config INET_UDP_DIAG |
408 | tristate "UDP: socket monitoring interface" |
409 | depends on INET_DIAG && (IPV6 || IPV6=n) |
410 | default n |
411 | ---help--- |
412 | Support for UDP socket monitoring interface used by the ss tool. |
413 | If unsure, say Y. |
414 | |
415 | menuconfig TCP_CONG_ADVANCED |
416 | bool "TCP: advanced congestion control" |
417 | ---help--- |
418 | Support for selection of various TCP congestion control |
419 | modules. |
420 | |
421 | Nearly all users can safely say no here, and a safe default |
422 | selection will be made (CUBIC with new Reno as a fallback). |
423 | |
424 | If unsure, say N. |
425 | |
426 | if TCP_CONG_ADVANCED |
427 | |
428 | config TCP_CONG_BIC |
429 | tristate "Binary Increase Congestion (BIC) control" |
430 | default m |
431 | ---help--- |
432 | BIC-TCP is a sender-side only change that ensures a linear RTT |
433 | fairness under large windows while offering both scalability and |
434 | bounded TCP-friendliness. The protocol combines two schemes |
435 | called additive increase and binary search increase. When the |
436 | congestion window is large, additive increase with a large |
437 | increment ensures linear RTT fairness as well as good |
438 | scalability. Under small congestion windows, binary search |
439 | increase provides TCP friendliness. |
440 | See http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/ |
441 | |
442 | config TCP_CONG_CUBIC |
443 | tristate "CUBIC TCP" |
444 | default y |
445 | ---help--- |
446 | This is version 2.0 of BIC-TCP which uses a cubic growth function |
447 | among other techniques. |
448 | See http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/cubic-paper.pdf |
449 | |
450 | config TCP_CONG_WESTWOOD |
451 | tristate "TCP Westwood+" |
452 | default m |
453 | ---help--- |
454 | TCP Westwood+ is a sender-side only modification of the TCP Reno |
455 | protocol stack that optimizes the performance of TCP congestion |
456 | control. It is based on end-to-end bandwidth estimation to set |
457 | congestion window and slow start threshold after a congestion |
458 | episode. Using this estimation, TCP Westwood+ adaptively sets a |
459 | slow start threshold and a congestion window which takes into |
460 | account the bandwidth used at the time congestion is experienced. |
461 | TCP Westwood+ significantly increases fairness wrt TCP Reno in |
462 | wired networks and throughput over wireless links. |
463 | |
464 | config TCP_CONG_HTCP |
465 | tristate "H-TCP" |
466 | default m |
467 | ---help--- |
468 | H-TCP is a send-side only modifications of the TCP Reno |
469 | protocol stack that optimizes the performance of TCP |
470 | congestion control for high speed network links. It uses a |
471 | modeswitch to change the alpha and beta parameters of TCP Reno |
472 | based on network conditions and in a way so as to be fair with |
473 | other Reno and H-TCP flows. |
474 | |
475 | config TCP_CONG_HSTCP |
476 | tristate "High Speed TCP" |
477 | default n |
478 | ---help--- |
479 | Sally Floyd's High Speed TCP (RFC 3649) congestion control. |
480 | A modification to TCP's congestion control mechanism for use |
481 | with large congestion windows. A table indicates how much to |
482 | increase the congestion window by when an ACK is received. |
483 | For more detail see http://www.icir.org/floyd/hstcp.html |
484 | |
485 | config TCP_CONG_HYBLA |
486 | tristate "TCP-Hybla congestion control algorithm" |
487 | default n |
488 | ---help--- |
489 | TCP-Hybla is a sender-side only change that eliminates penalization of |
490 | long-RTT, large-bandwidth connections, like when satellite legs are |
491 | involved, especially when sharing a common bottleneck with normal |
492 | terrestrial connections. |
493 | |
494 | config TCP_CONG_VEGAS |
495 | tristate "TCP Vegas" |
496 | default n |
497 | ---help--- |
498 | TCP Vegas is a sender-side only change to TCP that anticipates |
499 | the onset of congestion by estimating the bandwidth. TCP Vegas |
500 | adjusts the sending rate by modifying the congestion |
501 | window. TCP Vegas should provide less packet loss, but it is |
502 | not as aggressive as TCP Reno. |
503 | |
504 | config TCP_CONG_SCALABLE |
505 | tristate "Scalable TCP" |
506 | default n |
507 | ---help--- |
508 | Scalable TCP is a sender-side only change to TCP which uses a |
509 | MIMD congestion control algorithm which has some nice scaling |
510 | properties, though is known to have fairness issues. |
511 | See http://www.deneholme.net/tom/scalable/ |
512 | |
513 | config TCP_CONG_LP |
514 | tristate "TCP Low Priority" |
515 | default n |
516 | ---help--- |
517 | TCP Low Priority (TCP-LP), a distributed algorithm whose goal is |
518 | to utilize only the excess network bandwidth as compared to the |
519 | ``fair share`` of bandwidth as targeted by TCP. |
520 | See http://www-ece.rice.edu/networks/TCP-LP/ |
521 | |
522 | config TCP_CONG_VENO |
523 | tristate "TCP Veno" |
524 | default n |
525 | ---help--- |
526 | TCP Veno is a sender-side only enhancement of TCP to obtain better |
527 | throughput over wireless networks. TCP Veno makes use of state |
528 | distinguishing to circumvent the difficult judgment of the packet loss |
529 | type. TCP Veno cuts down less congestion window in response to random |
530 | loss packets. |
531 | See <http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1177186> |
532 | |
533 | config TCP_CONG_YEAH |
534 | tristate "YeAH TCP" |
535 | select TCP_CONG_VEGAS |
536 | default n |
537 | ---help--- |
538 | YeAH-TCP is a sender-side high-speed enabled TCP congestion control |
539 | algorithm, which uses a mixed loss/delay approach to compute the |
540 | congestion window. It's design goals target high efficiency, |
541 | internal, RTT and Reno fairness, resilience to link loss while |
542 | keeping network elements load as low as possible. |
543 | |
544 | For further details look here: |
545 | http://wil.cs.caltech.edu/pfldnet2007/paper/YeAH_TCP.pdf |
546 | |
547 | config TCP_CONG_ILLINOIS |
548 | tristate "TCP Illinois" |
549 | default n |
550 | ---help--- |
551 | TCP-Illinois is a sender-side modification of TCP Reno for |
552 | high speed long delay links. It uses round-trip-time to |
553 | adjust the alpha and beta parameters to achieve a higher average |
554 | throughput and maintain fairness. |
555 | |
556 | For further details see: |
557 | http://www.ews.uiuc.edu/~shaoliu/tcpillinois/index.html |
558 | |
559 | choice |
560 | prompt "Default TCP congestion control" |
561 | default DEFAULT_CUBIC |
562 | help |
563 | Select the TCP congestion control that will be used by default |
564 | for all connections. |
565 | |
566 | config DEFAULT_BIC |
567 | bool "Bic" if TCP_CONG_BIC=y |
568 | |
569 | config DEFAULT_CUBIC |
570 | bool "Cubic" if TCP_CONG_CUBIC=y |
571 | |
572 | config DEFAULT_HTCP |
573 | bool "Htcp" if TCP_CONG_HTCP=y |
574 | |
575 | config DEFAULT_HYBLA |
576 | bool "Hybla" if TCP_CONG_HYBLA=y |
577 | |
578 | config DEFAULT_VEGAS |
579 | bool "Vegas" if TCP_CONG_VEGAS=y |
580 | |
581 | config DEFAULT_VENO |
582 | bool "Veno" if TCP_CONG_VENO=y |
583 | |
584 | config DEFAULT_WESTWOOD |
585 | bool "Westwood" if TCP_CONG_WESTWOOD=y |
586 | |
587 | config DEFAULT_RENO |
588 | bool "Reno" |
589 | |
590 | endchoice |
591 | |
592 | endif |
593 | |
594 | config TCP_CONG_CUBIC |
595 | tristate |
596 | depends on !TCP_CONG_ADVANCED |
597 | default y |
598 | |
599 | config DEFAULT_TCP_CONG |
600 | string |
601 | default "bic" if DEFAULT_BIC |
602 | default "cubic" if DEFAULT_CUBIC |
603 | default "htcp" if DEFAULT_HTCP |
604 | default "hybla" if DEFAULT_HYBLA |
605 | default "vegas" if DEFAULT_VEGAS |
606 | default "westwood" if DEFAULT_WESTWOOD |
607 | default "veno" if DEFAULT_VENO |
608 | default "reno" if DEFAULT_RENO |
609 | default "cubic" |
610 | |
611 | config TCP_MD5SIG |
612 | bool "TCP: MD5 Signature Option support (RFC2385)" |
613 | select CRYPTO |
614 | select CRYPTO_MD5 |
615 | ---help--- |
616 | RFC2385 specifies a method of giving MD5 protection to TCP sessions. |
617 | Its main (only?) use is to protect BGP sessions between core routers |
618 | on the Internet. |
619 | |
620 | If unsure, say N. |
621 |
Branches:
ben-wpan
ben-wpan-stefan
javiroman/ks7010
jz-2.6.34
jz-2.6.34-rc5
jz-2.6.34-rc6
jz-2.6.34-rc7
jz-2.6.35
jz-2.6.36
jz-2.6.37
jz-2.6.38
jz-2.6.39
jz-3.0
jz-3.1
jz-3.11
jz-3.12
jz-3.13
jz-3.15
jz-3.16
jz-3.18-dt
jz-3.2
jz-3.3
jz-3.4
jz-3.5
jz-3.6
jz-3.6-rc2-pwm
jz-3.9
jz-3.9-clk
jz-3.9-rc8
jz47xx
jz47xx-2.6.38
master
Tags:
od-2011-09-04
od-2011-09-18
v2.6.34-rc5
v2.6.34-rc6
v2.6.34-rc7
v3.9