Re: Native PPPoE broken (4.6-STABLE), RP-PPPoE working?!
On Sun, 23 Jun 2002 22:54:32 -0700 (PDT), in sentex.lists.freebsd.net you wrote: On Sun, 23 Jun 2002, Mike Tancsa wrote: On Sun, 23 Jun 2002 18:53:32 -0700 (PDT), in sentex.lists.freebsd.net you wrote: After spending a couple of hours getting it to compile, I got Roaring Penguin (latest release) and pppd-3.11 compiled and installed on my 4.6-STABLE (June 17) box, and connected it just fine. Speeds are exactly as expected, and there's *no* slowness at all. define slowness? Hi, about 300 or 400 bytes per second (yes, bytes per second, not kBytes or kbits) Does RP attach to 'ppp' or does it supply it's own? I think Damian had to compile an update PPPd (3.11) to make it work It seems hard to understand how the pppoe node in the kernel can slow things down. Here is an example iscar% fetch ftp://ftp.sentex.net/netscape95.exe Receiving netscape95.exe (3512832 bytes): 100% 3512832 bytes transferred in 28.0 seconds (122.50 kBps) iscar% But to iscar% fetch ftp://ftp.isc.org/isc/bind9/9.2.1/bind-9.2.1.tar.gz Receiving bind-9.2.1.tar.gz (5021044 bytes): 0%^C 24684 bytes transferred in 153.6 seconds (160.71 Bps) fetch: transfer interrupted This was after about 2.5 minutes. This same machine connected to an SMS works fine. e.g. from my home (farther away from the CO) cage# fetch ftp://ftp.isc.org/isc/bind9/9.2.1/bind-9.2.1.tar.gz Receiving bind-9.2.1.tar.gz (5021044 bytes): 9%^C 480612 bytes transferred in 4.9 seconds (95.12 kBps) fetch: transfer interrupted No problems. Before deploying the machine connected to the ERX, it worked great against the SMS as did/does all our other deployed FreeBSD boxes. But with Roaring Penguin installed, no problems. With a machine behind a ciso 827, no problem. Running LINUX, no problem. Any thoughts on what to try next ? ---Mike Mike Tancsa ([EMAIL PROTECTED]) Sentex Communications Corp, Waterloo, Ontario, Canada Given enough time, 100 monkeys on 100 routers could setup a national IP network. (KDW2) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Native PPPoE broken (4.6-STABLE), RP-PPPoE working?!
On Sun, 23 Jun 2002 18:53:32 -0700 (PDT), in sentex.lists.freebsd.net you wrote: After spending a couple of hours getting it to compile, I got Roaring Penguin (latest release) and pppd-3.11 compiled and installed on my 4.6-STABLE (June 17) box, and connected it just fine. Speeds are exactly as expected, and there's *no* slowness at all. define slowness? Hi, about 300 or 400 bytes per second (yes, bytes per second, not kBytes or kbits) Does RP attach to 'ppp' or does it supply it's own? I think Damian had to compile an update PPPd (3.11) to make it work So it appears that the in-kernel PPPoE implementation is broken, and Roaring Pengiun's is working? (Or that the new concentrator is breaking from the spec, and causing problems with the in-kernel implementation...) This is my guess, I've seen this before.. some manufacturers asssume that if it works with W95 they can stop testing and often thay make assumptions about the parts of the spec that they shouldn't Quite possibly. The hard part to explain to the manufacture is that it works with Windows 95,98, XP, 2000, Linux and a Cisco 827. It does not work with FreeBSD ---Mike Mike Tancsa ([EMAIL PROTECTED]) Sentex Communications Corp, Waterloo, Ontario, Canada Given enough time, 100 monkeys on 100 routers could setup a national IP network. (KDW2) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: zero copy code checkin in 2 days, new snapshot
On Sun, 23 Jun 2002, Kenneth D. Merry wrote: I'm planning on checking in the zero copy sockets code Tuesday evening, MDT. If there are any concerns, I'm more than willing to delay it. Out of curiousity, what happens when the page being write()n is a mmap'd page shared by multiple processes? Will the page be shared? That could be a big reduction in mbuf cluster usage on some http/ftp systems, I'd guess. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: How cwnd is set after a loss in FreeBSD TCP?
On Tue, 18 Jun 2002, ef90b7323131bdf05e wrote: My explanation to this is that the ssthresh is not exactly half of the cwnd after detecting the loss. However, the explanation seems contradicts with RFC2581, which say ssthresh must be no more than max( FlightSize /2, 2*SMSS). The behavior puzzled me for a while. Is it a bug or just the right behavior? Can anyone help to explain it? I have dump file the the figure of this behavior, if anyone want, I will email it. ** Lu Guohan It's certainly possible that there's a bug. To explain the behavior, you'll probably have to wander around tcp_output.c a bit. When doing so, also take into consideration new reno (rfc 2582, I think.) If you find something that you believe is a definite problem, please post back to this list. I'd love to help, but I'm busy with other matters at the moment. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
tracking down strange MTU issues with PPPoE)
The DSL whole supplier we use (Bell Canada) has been turfing their Redback SMSes and moving to an ERX from unisphere networks. With the Redback, all was great... I had a FreeBSD box acting as a NAT gateway for a number of Windows boxes and all was great. Then, the customer got moved over to one of these ERXes and there is now some strange MTU problem. Couple of things. Supposedly the default MTU on the ERX is 1472 (or 1452) depending on who you talk to and not 1492. e.g. when doing a fetch to lynx2.8.4rel.1.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/. Attempting to fetch from http://lynx.isc.org/current/. Receiving lynx2.8.4rel.1.tar.bz2 (1940531 bytes): 0%^C 16682 bytes transferred in 89.5 seconds (186.41 Bps) fetch: transfer interrupted Notice the speed... Its totally brutal. yet, a transfer from just a few hops away is fine. My question is, how can I track this problem down ? There seems to be some strange interaction with FreeBSD because if I put a Windows box on the other end, it does not suffer from this same problem. I can easily repeat the problem, but the question is, how can I track down the issue and then explain it to my telco. (Note, I have tried various MTU and MRU settings. Thanks for any pointers. 4.6-STABLE FreeBSD 4.6-STABLE #0: Tue Jun 18 default: set log Phase Chat LCP IPCP CCP tun command ident user-ppp VERSION (built COMPILATIONDATE) # Ensure that device references the correct serial port # for your modem. (cuaa0 = COM1, cuaa1 = COM2) # set device /dev/cuaa1 set speed 115200 set dial ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \ \\ AT OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT set timeout 180# 3 minute idle timer (the default) enable dns # request DNS info (for resolv.conf) pppoe: set device PPPoE:fxp1 #set mtu 1452 #set mru 1452 set speed sync enable lqr set lqrperiod 5 set cd 5 set dial set login set timeout 0 disable deflate pred1 mppe deny deflate pred1 mppe set authname [EMAIL PROTECTED] set authkey thepassword set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 add default HISADDR ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: tracking down strange MTU issues with PPPoE)
Hi, the mss fixup is enabled by default and is part of the stock PPP from what I understand. Also, this was all working just great when the other end was a redback. The problems only started when the telco moved the termination to the ERX. ---Mike At 04:34 PM 18/06/2002 -0500, Nick Rogness wrote: On Tue, 18 Jun 2002, Mike Tancsa wrote: The DSL whole supplier we use (Bell Canada) has been turfing their Redback SMSes and moving to an ERX from unisphere networks. There was, at one time, MTU problems with PPPoE. See the tcpmssd port or other online documentation. I don't know if anything has changed recently concerning this. Nick Rogness [EMAIL PROTECTED] - Don't mind me...I'm just sniffing your packets To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: tracking down strange MTU issues with PPPoE)
Hi, In terms of the MTU, I can set that in my router as I am the ISP :-) Not sure how it works with Telus on the west coast, but with Bell, PPPoE is done between the client and the DSL concentrator. Then the session is handed off to the ISP via an L2TP tunnel. I can control that part on my router (a cisco) e.g. vpdn-group 72 description info describing the particular DSL concentrator - redback or ERX accept-dialin protocol any virtual-template 3 terminate-from hostname our-l2tp-tunnel-endpoint local name my-local-auth-name-to-the-telco lcp renegotiation always l2tp tunnel password the-big-pass-to-that-concentrator source-ip 1.2.3.4 ! Then with the virt-template, I can control what the other end negotiates as the MTU size. In the past, 1492 and all was happy on the planet. interface Virtual-Template3 description ERX-Only-Virtual-Template mtu 1492 ip unnumbered Loopback0 peer default ip address pool -our-pool-names ppp authentication pap chap callin ! I have tried adjusting the MTU to various sizes but with no luck. In case someone reading this has been down the same boat, yes, I do clear vpdn lt2p tun our-l2tp-tunnel-endpoint and then connect again with the client... ifconfig tun0 on the client side does indeed show the MTU specified in the virt-template. ---Mike At 03:09 PM 6/18/2002 -0700, Tom Samplonius wrote: Well, if you need to find the MTU, the ppp logs should tell you what the remote end is telling you to use. Usually, if you are having a MTU problem, it relates to fragmentation, MTU detection and ICMP filters. FreeBSD uses MTU detection by default. However, MTU detection requires that ICMP can't fragment messages be received, and some broken sites filter all ICMP. I know that the Redback has an ignore don't fragment feature. If this is enabled, it will fragment packets, it would normally throw away. This feature will break MTU detection too, but at least the end user won't notice, and packets will flow. Tom On Tue, 18 Jun 2002, Mike Tancsa wrote: The DSL whole supplier we use (Bell Canada) has been turfing their Redback SMSes and moving to an ERX from unisphere networks. With the Redback, all was great... I had a FreeBSD box acting as a NAT gateway for a number of Windows boxes and all was great. Then, the customer got moved over to one of these ERXes and there is now some strange MTU problem. Couple of things. Supposedly the default MTU on the ERX is 1472 (or 1452) depending on who you talk to and not 1492. e.g. when doing a fetch to lynx2.8.4rel.1.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/. Attempting to fetch from http://lynx.isc.org/current/. Receiving lynx2.8.4rel.1.tar.bz2 (1940531 bytes): 0%^C 16682 bytes transferred in 89.5 seconds (186.41 Bps) fetch: transfer interrupted Notice the speed... Its totally brutal. yet, a transfer from just a few hops away is fine. My question is, how can I track this problem down ? There seems to be some strange interaction with FreeBSD because if I put a Windows box on the other end, it does not suffer from this same problem. I can easily repeat the problem, but the question is, how can I track down the issue and then explain it to my telco. (Note, I have tried various MTU and MRU settings. Thanks for any pointers. 4.6-STABLE FreeBSD 4.6-STABLE #0: Tue Jun 18 default: set log Phase Chat LCP IPCP CCP tun command ident user-ppp VERSION (built COMPILATIONDATE) # Ensure that device references the correct serial port # for your modem. (cuaa0 = COM1, cuaa1 = COM2) # set device /dev/cuaa1 set speed 115200 set dial ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \ \\ AT OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT set timeout 180# 3 minute idle timer (the default) enable dns # request DNS info (for resolv.conf) pppoe: set device PPPoE:fxp1 #set mtu 1452 #set mru 1452 set speed sync enable lqr set lqrperiod 5 set cd 5 set dial set login set timeout 0 disable deflate pred1 mppe deny deflate pred1 mppe set authname [EMAIL PROTECTED] set authkey thepassword set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 add default HISADDR ---Mike Mike Tancsa,tel +1 519 651 3400 Sentex Communications, [EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-isp in the body of the message Mike Tancsa
Re: tracking down strange MTU issues with PPPoE)
Yes, that did it! Thanks very much! What is different about that, and me setting it on the other end as part of the virt-template ? ---Mike At 12:33 AM 6/19/2002 +0100, Brian Somers wrote: Perhaps adding set mtu max 1452 will help ? On Tue, 18 Jun 2002 16:54:49 -0400, Mike Tancsa [EMAIL PROTECTED] wrote: The DSL whole supplier we use (Bell Canada) has been turfing their Redback SMSes and moving to an ERX from unisphere networks. With the Redback, all was great... I had a FreeBSD box acting as a NAT gateway for a number of Windows boxes and all was great. Then, the customer got moved over to one of these ERXes and there is now some strange MTU problem. Couple of things. Supposedly the default MTU on the ERX is 1472 (or 1452) depending on who you talk to and not 1492. e.g. when doing a fetch to lynx2.8.4rel.1.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/. Attempting to fetch from http://lynx.isc.org/current/. Receiving lynx2.8.4rel.1.tar.bz2 (1940531 bytes): 0%^C 16682 bytes transferred in 89.5 seconds (186.41 Bps) fetch: transfer interrupted Notice the speed... Its totally brutal. yet, a transfer from just a few hops away is fine. My question is, how can I track this problem down ? There seems to be some strange interaction with FreeBSD because if I put a Windows box on the other end, it does not suffer from this same problem. I can easily repeat the problem, but the question is, how can I track down the issue and then explain it to my telco. (Note, I have tried various MTU and MRU settings. Thanks for any pointers. 4.6-STABLE FreeBSD 4.6-STABLE #0: Tue Jun 18 default: set log Phase Chat LCP IPCP CCP tun command ident user-ppp VERSION (built COMPILATIONDATE) # Ensure that device references the correct serial port # for your modem. (cuaa0 = COM1, cuaa1 = COM2) # set device /dev/cuaa1 set speed 115200 set dial ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \ \\ AT OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT set timeout 180# 3 minute idle timer (the default) enable dns # request DNS info (for resolv.conf) pppoe: set device PPPoE:fxp1 #set mtu 1452 #set mru 1452 set speed sync enable lqr set lqrperiod 5 set cd 5 set dial set login set timeout 0 disable deflate pred1 mppe deny deflate pred1 mppe set authname [EMAIL PROTECTED] set authkey thepassword set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 add default HISADDR ---Mike Mike Tancsa,tel +1 519 651 3400 Sentex Communications, [EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike -- Brian [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.Awfulhak.orgbrian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: tracking down strange MTU issues with PPPoE)
At 05:16 PM 6/18/2002 -0700, Tom Samplonius wrote: Possibly. There is a PPPoE session to the Redback (or ERX), then usually a L2TP session to the ISP. A PPPoE client connecting to the Redback (or ERX) should be told a valid MTU. PPP tunel to L2TP tunnel raises some interesting possiblities. I wonder how much mucking about the SMS does to the protocol. Obviously it is doing something, since the Redback works, but the ERX does not. Or the Bell network is broken :) b) is always a possibility. Actually, there is some bug in the ERX where the setting IP TUNNEL REASSEMBLY gets turned off when doing unrelated configs. The first time we encountered this, we had no end of trouble for 2 days and tracking down the right people to talk to was insane. There are groups in Bell who look after the DSL concentrators, groups who look after the DSLAMS, groups who look after the ATM network, but it seems not one individual knows how all the components work together, or at least they are not reachable. At one point one of the ATM guys said something to the effect that this was a known bug and I had to set the MTU on my terminating router's ethernet to 1450. I asked why and where the document was to which he responded that he was not allowed to share such information. whatever Its ironic that the old kids game of broken telephone comes into play with the telco :-( ... But, [EMAIL PROTECTED]'s suggestion of set max mtu did the trick. I am curious to know why this is necessary on the ERX and not on the SMSes. ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: tracking down strange MTU issues with PPPoE)
Actually, in your documentation you mention that its broken for the situation where the FreeBSD box acts as a gateway. In my case, its broken right from the FreeBSD box. But the same machine connected with Windows 98 does not have the problem. ---Mike At 04:18 PM 6/18/2002 -0700, Renaud Waldura wrote: Section 6.3 of the following document describes this issue in detail and may help you solve it. http://renaud.waldura.com/doc/freebsd/pppoe/ - Original Message - From: Tom Samplonius [EMAIL PROTECTED] To: Mike Tancsa [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, June 18, 2002 3:09 PM Subject: Re: tracking down strange MTU issues with PPPoE) Well, if you need to find the MTU, the ppp logs should tell you what the remote end is telling you to use. Usually, if you are having a MTU problem, it relates to fragmentation, MTU detection and ICMP filters. FreeBSD uses MTU detection by default. However, MTU detection requires that ICMP can't fragment messages be received, and some broken sites filter all ICMP. I know that the Redback has an ignore don't fragment feature. If this is enabled, it will fragment packets, it would normally throw away. This feature will break MTU detection too, but at least the end user won't notice, and packets will flow. Tom On Tue, 18 Jun 2002, Mike Tancsa wrote: The DSL whole supplier we use (Bell Canada) has been turfing their Redback SMSes and moving to an ERX from unisphere networks. With the Redback, all was great... I had a FreeBSD box acting as a NAT gateway for a number of Windows boxes and all was great. Then, the customer got moved over to one of these ERXes and there is now some strange MTU problem. Couple of things. Supposedly the default MTU on the ERX is 1472 (or 1452) depending on who you talk to and not 1492. e.g. when doing a fetch to lynx2.8.4rel.1.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/. Attempting to fetch from http://lynx.isc.org/current/. Receiving lynx2.8.4rel.1.tar.bz2 (1940531 bytes): 0%^C 16682 bytes transferred in 89.5 seconds (186.41 Bps) fetch: transfer interrupted Notice the speed... Its totally brutal. yet, a transfer from just a few hops away is fine. My question is, how can I track this problem down ? There seems to be some strange interaction with FreeBSD because if I put a Windows box on the other end, it does not suffer from this same problem. I can easily repeat the problem, but the question is, how can I track down the issue and then explain it to my telco. Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: tracking down strange MTU issues with PPPoE)
Looking at the TCPDump, to a host that works, I see iscar# tcpdump -n -i tun0 'tcp[13] 2 != 0' tcpdump: listening on tun0 23:21:37.506516 64.7.134.131.1029 199.212.134.1.80: S 3285534554:3285534554(0) win 57344 mss 1452,nop,wscale 0,nop,nop,timestamp 59058 0 (DF) 23:21:37.528294 199.212.134.1.80 64.7.134.131.1029: S 2139469875:2139469875(0) ack 3285534555 win 65535 mss 1452,nop,wscale 1,nop,nop,timestamp 67282456 59058 If I let this transfer go, I will see a good megabit + speeds. But to the host below (and from a non pppoe connection on the other side, I get a good 5Mb/s), I see the following 23:21:45.400445 64.7.134.131.1030 204.152.184.112.80: S 1898183196:1898183196(0) win 57344 mss 1452,nop,wscale 0,nop,nop,timestamp 59847 0 (DF) 23:21:45.498440 204.152.184.112.80 64.7.134.131.1030: S 1924929184:1924929184(0) ack 1898183197 win 61440 mss 1452,nop,wscale 0 and the speed is a few hundred bytes /s But, when I do the same from my connection at home, I see the same sorts of flags and speeds are as expected ---Mike At 04:18 PM 6/18/2002 -0700, Renaud Waldura wrote: Section 6.3 of the following document describes this issue in detail and may help you solve it. http://renaud.waldura.com/doc/freebsd/pppoe/ - Original Message - From: Tom Samplonius [EMAIL PROTECTED] To: Mike Tancsa [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, June 18, 2002 3:09 PM Subject: Re: tracking down strange MTU issues with PPPoE) Well, if you need to find the MTU, the ppp logs should tell you what the remote end is telling you to use. Usually, if you are having a MTU problem, it relates to fragmentation, MTU detection and ICMP filters. FreeBSD uses MTU detection by default. However, MTU detection requires that ICMP can't fragment messages be received, and some broken sites filter all ICMP. I know that the Redback has an ignore don't fragment feature. If this is enabled, it will fragment packets, it would normally throw away. This feature will break MTU detection too, but at least the end user won't notice, and packets will flow. Tom On Tue, 18 Jun 2002, Mike Tancsa wrote: The DSL whole supplier we use (Bell Canada) has been turfing their Redback SMSes and moving to an ERX from unisphere networks. With the Redback, all was great... I had a FreeBSD box acting as a NAT gateway for a number of Windows boxes and all was great. Then, the customer got moved over to one of these ERXes and there is now some strange MTU problem. Couple of things. Supposedly the default MTU on the ERX is 1472 (or 1452) depending on who you talk to and not 1492. e.g. when doing a fetch to lynx2.8.4rel.1.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/. Attempting to fetch from http://lynx.isc.org/current/. Receiving lynx2.8.4rel.1.tar.bz2 (1940531 bytes): 0%^C 16682 bytes transferred in 89.5 seconds (186.41 Bps) fetch: transfer interrupted Notice the speed... Its totally brutal. yet, a transfer from just a few hops away is fine. My question is, how can I track this problem down ? There seems to be some strange interaction with FreeBSD because if I put a Windows box on the other end, it does not suffer from this same problem. I can easily repeat the problem, but the question is, how can I track down the issue and then explain it to my telco. Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Broken PMTUD in FreeBSD?
On Fri, 14 Jun 2002, Jonathan Lemon wrote: It is a DoS. Suppose that for some reason, we send out a SYN,ACK of 80 octets, which hits a router with the minimum MTU of 68 octets. Unlikely, yes, but still legal. If IP_DF is set, the packet gets dropped, and a ICMP PMTU response is sent back, but the syncache will still resend the 80 octet datagram. If IP_DF is clear, the datagram will get through. In theory, I guess that could happen. Give me a few days to examine the PMTU code to see if there's an easy way to handle that case. If the DF bit is removed on the resend, would that be acceptable? /me has this bad feeling that he just roped himself into auditing the PTMU code. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Broken PMTUD in FreeBSD?
On Tue, 11 Jun 2002, Phil Dibowitz wrote: Glad it's fixed, and thanks for the info. Phil Well, it's not fixed yet, but it will be. (Probably a week at least, I don't have the time to devote to it right now, despite it being a simple change.) Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Broken PMTUD in FreeBSD?
On Tue, 11 Jun 2002, Phil Dibowitz wrote: Ahhh. Sounds like many of the bugs I've found in my own software. Yep, just an oversight. There have been larger, more serious ones. :) Phil: In the future, please try a bit harder to notify someone if you believe that a bug is serious enough for posting to bugtraq. freebsd-net is a relatively busy list, and things do get missed. Certainly. I appologize if I caused the FreeBSD developers any grief over my post. I'm not a FreeBSD user myself and wasn't aware of the http://www.freebsd.org/send-pr.html page until yesterday. I did submit a bug report there yesterday, which got assigned an ID of kern/39141, so when you commit the fix, you can update/close that case as well. Thanks again for your quick response. Phil Dibowitz I don't think you caused any grief; releasing this information didn't hurt anyone. Had it been some remotely exploitable bug which was not yet patched, then I would be annoyed. For the record, filing a PR isn't always enough, either. There are a lot filed, and we often get very behind on them. :) So, if you do find a security issue in the future, please directly e-mail [EMAIL PROTECTED] so that it gets handled properly. If you find less serious bugs, feel free to drop me an e-mail if mail to the -net list falls on deaf ears. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Problem with SYN cache in FreeBSD 4.5
On Tue, 4 Jun 2002, jayanth wrote: Can you dump the output of netstat -s -p tcp ? Checking for listen queue overflows and syncache bucket overflows. jayanth And netstat -La too, please. I'm interested in if you're accepting sockets fast enough. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Problem with SYN cache in FreeBSD 4.5
On Tue, 4 Jun 2002, Nguyen-Tuong Long Le wrote: Here is the output of netstat -La Current listen queue sizes (qlen/incqlen/maxqlen) Proto Listen Local Address tcp4 3/0/8192 *.6789 I wonder why the listen queue overflows when there are so few connections in the queue. The number of listen queue overflows is equal to the number of syncache aborts. Is it a coincidence or are they related? Thanks, -- long It appears that the primary reason a syncache abort would occur is because the system has run out of sockets. Is kern.ipc.numopensockets approaching kern.ipc.maxsockets? Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Problem with SYN cache in FreeBSD 4.5
On Mon, 3 Jun 2002, Nguyen-Tuong Long Le wrote: Hi all, Our group has a proprietary web server that can handle 1 requests/s under FreeBSD 4.3 release. We recently upgraded our system to 4.5 and got very poor performance. While the web server runs, I see lots of messages similar to the following on the console Limiting open port RST response from 1068 to 200 packets per second. The problem seems to be related to the syncache implementation that drops incoming SYN segments. I've tried to increase the size of the hash table but that didn't seem to help much. Here is the output of sysctl net.inet.tcp.syncache. A few questions: 1. Is this 4.5-release, or 4.5-stable (aka 4.6-RC2)? 4.5-release had a few bugs in the syn cache which could cause crashes. 2. Are you using accept filters? Accept filters act oddly on 4.5-release, you'll have to upgrade to 4.5-stable/4.6. 3. Could you use tcpdump to determine what exactly is going wrong and post a url to the log so that we can investigate what is going wrong? Thanks, Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: MPLS
On Sat, 1 Jun 2002, Andre Oppermann wrote: I'm axing that right now and will provide a tcp_hostcache that will assume that role (tcp is the only consumer of rt_metrics, except for rmx_mtu and rmx_pksent). By moving this every node/leaf in the routing table shrinks by 48 bytes. On a default free view of the Internet this gives us a whopping 5.5 Mbytes in kernel memory savings (110k routes). -- Andre Hrm. Once you've cut the route metrics out of the route entries, is there anything preventing you from doing away with cloned routes alltogether? :) Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Bug in net/route.[ch] with rmx_pksent while cloning
On Fri, 31 May 2002, Andre Oppermann wrote: I think it will break. Isn't there a compiler warning in net/rtsocket.c on 64bit platforms about the u_long to int assignment? IMO the right solution would to simply axe this field from rt_msghdr. It serves no purpose. At least none of the base utilites look at it and I don't see neither gated nor Zebra using it. My vote would go to axe it in -CURRENT and bump the version number. Netstat and route need to be recompiled. Note in UPDATING. Even in -current, that's an annoying step to take. What I'm thinking of doing is renaming the field to rt_unused with a comment indicating that it should be axed if anyone else has a good reason to change the structure. I'll look over your latest round of patches tomorrow. They're a bit more in depth, I can't evaluate them in 5 minutes. :) Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Bug in net/route.[ch] with rmx_pksent while cloning
On Fri, 31 May 2002, Andre Oppermann wrote: Hi all, there is a bug in sys/route.[ch] with the rmx_pksent statistics (which counts how many times the route has been used to forward a ip packet). Silby, Bosko or Luigi, could you have a look at this? -- Andre Sure, I'll take a look at in the next day or two. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
zebra + gif
into firewall to see OSPF packets: router# ipfw add 10 allow log 89 from any to any router# tail -f /var/log/security Apr 21 17:20:34 relay /kernel: ipfw: 10 Accept P:89 10.1.10.4 224.0.0.5 out via gif6 Apr 21 17:20:44 relay /kernel: ipfw: 10 Accept P:89 10.1.10.4 224.0.0.5 out via gif6 Apr 21 17:20:54 relay /kernel: ipfw: 10 Accept P:89 10.1.10.4 224.0.0.5 out via gif6 Why zebra sends hello-packets via gif6? Concerning to the ospfd diagnostics (show ip ospf interface) OSPF is enabled only on gif1 interface, and (debug ospf packet hello) show that zebra sends hello-packets via gif1 (OSPF: Hello sent to [224.0.0.5] via [gif1:10.1.10.4].) Is it zebra or FreeBSD specific bug? Or maybe my misconfiguration? When I stop zebra, delete gif6 interface and start zebra again, OSPF packets start appears on gif5 interface, and so on... I could provide more useful information, if required. What is wrong with my zebra configuration? Thanks in advance for any help... Regards, Mike To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: ng_eiface hangs on 4.6RC
On Thu, 23 May 2002 08:32:35 -0400, in sentex.lists.freebsd.net you wrote: Hello! I updated to 4.6-RC on May 22. Posted to freebsd-stable (I also made /usr/sbin/ngctl; but I did not do a complete buildworld. Could that be a problem ?) Yes, it could very much be your problem. Do a complete buildworld first so you really do update to 4.6 and try again. ---Mike Mike Tancsa ([EMAIL PROTECTED]) Sentex Communications Corp, Waterloo, Ontario, Canada Given enough time, 100 monkeys on 100 routers could setup a national IP network. (KDW2) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: mpd: pptp server
GM GG ([EMAIL PROTECTED]) wrote: Can you suggest a config for mpd used like a pptp client ? It seems to me there is not such config sample in the provided mpd.conf default. Sure, I'll include some that I've used successfully - client configs are old and haven't been tested recently - they were last used with mpd 3.6. server configs work very well with W2K/XP clients, however, I think my IP calculations in .secrets may be incorrect. Perhaps this isn't even necessary with 3.7 - my goal was to have one user always get the same IP - this worked fine, except if that user disconnected and someone else connected on same interface, they ended up with the reserved IP. Eventually, I'd end up with a couple clients connected as 192.168.0.210. :( I find the same sort of thing happens if I log in twice with the same username unless I have the client request a specific IP. Probably just need to play with numbers in .secrets file. Any feedback/corrections would be appreciated! -Mike ** `client' mpd.conf ** default: load vpn vpn: new -i ng1 vpn vpn set iface disable on-demand # set iface addrs 192.168.1.1 192.168.2.1 set iface idle 0 set iface route 192.168.1.0/24 set bundle disable multilink set bundle authname login here set bundle password password here set link yes acfcomp protocomp set link no pap # set link yes chap set link enable no-orig-auth set link keep-alive 10 75 set ipcp yes vjcomp set ipcp ranges 0.0.0.0/0 192.168.1.0/24 set bundle enable compression set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e128 set bundle enable crypt-reqd set ccp yes mpp-stateless open ** `client' mpd.links ** vpn: set link type pptp set pptp self client internal ip address set pptp peer server external ip address set pptp enable originate incoming outcall ** `server' mpd.conf ** default: load client1 load client2 . . . load client9 pptp_common_settings: set iface disable on-demand set iface enable proxy-arp set iface idle 0 set bundle enable multilink set link yes acfcomp protocomp set link no pap chap set link enable chap set link keep-alive 25 60 set ipcp yes vjcomp set ipcp dns 192.168.0.102 set ipcp nbns 192.168.0.102 set bundle enable compression set ccp yes mppc # I've been trying mpp-compress every couple # months... it doesn't work for me. :) # set ccp yes mpp-compress set ccp yes mpp-e40 set ccp yes mpp-e128 set ccp yes mpp-stateless client1: new -i ng0 pptp1 pptp1 set ipcp ranges 192.168.0.101/32 192.168.0.201/32 load pptp_common_settings client2: new -i ng1 pptp2 pptp2 set ipcp ranges 192.168.0.101/32 192.168.0.202/32 load pptp_common_settings . . . client9: new -i ng8 pptp9 pptp9 set ipcp ranges 192.168.0.101/32 192.168.0.209/32 load pptp_common_settings ** `server' mpd.links ** pptp1: set link type pptp set pptp self 192.168.0.101 set pptp enable incoming set pptp disable originate pptp2: set link type pptp set pptp self 192.168.0.101 set pptp enable incoming set pptp disable originate . . . pptp9: set link type pptp set pptp self 192.168.0.101 set pptp enable incoming set pptp disable originate ** `server' mpd.secret ** user1 password 192.168.0.210/32 user2 password 192.168.0.216/29 user3 password 192.168.0.224/29 user4 password 192.168.0.232/29 user5 password 192.168.0.240/29 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Interface statistic
MTRG in conjunction with snmpd. It will gather the data you require. Also, you can safely run SNMPD as a non root user for this purpose and I strongly advise that. Both programs are in the ports tree. ---Mike On Tue, 21 May 2002 14:58:22 +0300, in sentex.lists.freebsd.net you wrote: Hi, Can you tell me a way to collect per network interface statistic on my FreeBSD box? At this moment I'm using IPFilter accounting to collect needed information, but I think this way I'm collecting only information related to tcp, udp and icmp traffic. My purpose is to visualize this data in MRTG. Thank you in advantage, Ivailo Tanusheff System Administrator and Security Advisor ProCredit Bank Mike Tancsa ([EMAIL PROTECTED]) Sentex Communications Corp, Waterloo, Ontario, Canada Given enough time, 100 monkeys on 100 routers could setup a national IP network. (KDW2) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: High volume proxy server configuration.
On Tue, 21 May 2002, Scott Hess wrote: Setup: 2x SMP server running FreeBSD4.5. Apache 1.3.x. 2Gig of memory. When stress-testing, I am able to cause the kernel messages: m_clalloc failed, consider increase NMBCLUSTERS value fxp0: cluster allocation failed, packet dropped! Here's my theory: When the amount of space used for user processes and kernel usage fills all of memory, and a burst of packets are received from the backend servers, the kernel isn't able to allocate pages and drops the packets, with the message. The sender resends, and things cascade away. Since this is a kernel vm issue, the console also locks up. [Well, it's the best I have.] I've tried upping vm.v_free_min, vm.v_free_target, and vm.v_free_reserved. It doesn't appear to have any impact. I think that your theory is probably close to what is happening. Unfortunately, there's no easy way to address this yet. Due to the extensive use of zone allocators in 4.x, it's hard to size all allocations correctly. For this reason, there may be other subtle issues with 2 gig+ machines. For now, I think your best option may be to run your mbuf allocation program so that you have a certain amount of mbufs allocated and ready for your application. Along those lines, you might consider writing a kernel patch which performs this function based on a configurable value; I would be happy to commit such a feature if it was implemented well; other people with busy servers might find it useful. I've been pondering various methods to handle out of mbuf cluster situations better, but handling your case seems especially difficult. I'll have to think more. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: HEADS UP: ALTQ integration developer preview
On Fri, 17 May 2002, Kenjiro Cho wrote: ECN support in TCP is independent from ALTQ, and it can be done separately. An ECN patch for 4.5 which doesn't require ALTQ is included in altq-3.1. It's been in KAME since December. If there are interests, I can make a patch for -current. Personally, I hope we keep ECN support out of the tree; it's unlikely to provide any benefit over the internet in general, and will just make integrating other TCP changes more difficult. I haven't looked over the ALTQ patches, but integration of those changes sounds like a good idea. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Junior network hacker tasks...
On Mon, 6 May 2002, Garrett Wollman wrote: 1) Change the RFC 1323 implementation to use ticks relative to the time the socket was created. This is fairly easy to do and requires changes to only a handful of lines of code. (Keep in mind that only timestamps we send over the network ought to be so treated -- the timestamps stored in the TCPCB are a separate issue.) For additional confusion value, consider adding a random bias when each connection is created. (TCP already bogusly depends on a maximum segment lifetime of 30 seconds, so segments dallying in the network for days are probably not a concern. The correct answer for the user who has set HZ to 100 is ``don't do that, then'' -- but this probably ought to be documented as a limitation.) Is doing this wise? I have this nagging feeling that randomizing (or zeroing on each new connection) the timestamp would degrade its usefulness for PAWS checks and the like. (Don't ask me how, I haven't thought it through fully.) How about this idea: - For inbound connections, use 0 as the start value for the timestamp, as you suggest above. - For outbound connections, generate the timestamp offset using a hash similar to the one used for ISN generation. This way, timestamps won't jump around when connections are broken and reestablished / etc. This is a slight information leak; one can tell that the machine hasn't been rebooted. However, you would have to poll the machine quite often to figure out what the uptime really is. I think that the solution to wrapround with ticks is to normalize the value using hz to some known amount. I could certainly code these changes up (I've been thinking along the same lines for a while), but I'd be more than happy to defer to some unknown lurker on the mailing list who wants to make a name for his/her self. :) Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Junior network hacker tasks...
On Mon, 6 May 2002, Garrett Wollman wrote: On Mon, 6 May 2002 17:26:20 -0500 (CDT), Mike Silbersack [EMAIL PROTECTED] said: Is doing this wise? I have this nagging feeling that randomizing (or zeroing on each new connection) the timestamp would degrade its usefulness for PAWS checks and the like. (Don't ask me how, I haven't thought it through fully.) I don't think so, because the timestamps, as currently specified, are only meaningful within the context of a single connection. See sections 1.2, 4.3, and 4.2 of RFC 1323. The PAWS mechanism requires only that timestamps used by each connection be monotone increasing with respect to Sequence Number Arithmetic. RFC 1323 does require (section 4.2.2) that the clock be between 1 ms and 1 s in period, which I think we already violate on some platforms, although not seriously; there probably should be a pre-computed (global) scaling factor as well. -GAWollman I looked over both our and Linux's tcp stack to double-check, and it appears that my memory was faulty. You are correct, no PAWS checks are done during TIME_WAIT recycling. Initializing to zero is probably the best idea; getting fancy with random starts doesn't really help anything. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Putting all PCBs into sysctl?
On Thu, 25 Apr 2002, Alfred Perlstein wrote: * George V. Neville-Neil [EMAIL PROTECTED] [020425 20:02] wrote: Hey Folks, I was just wondering if anyone had considered making it possible to control PCBs from the sysctl interface? I'm not completely familiar with sysctl yet, is it possible to add information to the database dynamically? It would be nice to be able to disconnect, or modify, long running connections, for instance on a machine under DOS attack or perhaps for debugging. Just an idea... A very good one in fact, see what you can do, I'd be interested in seeing patches to do this safely. -- -Alfred Perlstein [[EMAIL PROTECTED]] Agreed, that would be cool. The only problem I can see is how you would uniquely identify a socket. (It wouldn't be nice to kill the wrong socket because they switched out from under you.) Maybe a procfs like filesystem for sockets would be better. :) Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: What does FreeBSD do when listen queue is full ?
On Wed, 17 Apr 2002, Bill Fenner wrote: Boy, I hope not. Incoming SYNs should be ignored if the backlog is met, so that the client can retransmit them. I know Microsoft decided to use RST as a my queue is full indicator, but I hope we're not following in their footsteps!... Bill Actually, I read the code slightly wrong. We don't send a RST, we just silently drop the connection. However, at the point we're talking about, we're already past the 3-way handshake, so either way the connection has been lost. Heh, actually, I take that back. With a syncookie, a retransmitted ACK should end up reestablishing the connection. Clever... I think that you're referring to the case where we receive an initial SYN, and the listen queue is full. With the syncache/syncookies, this is no longer a problem; either a syn cookie is returned, or the syn is silently dropped (depending on whether or not syn cookies are enabled.) With the pre-syncache code, yes, a RST was sent at that time. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: What does FreeBSD do when listen queue is full ?
On Wed, 17 Apr 2002, Bill Fenner wrote: We don't send a RST, we just silently drop the connection. This is wrong too; it should silently drop the ACK and leave the connection in the pending queue. Hm, I suppose that could work. It still feels icky, though; if the problem is that the app is building up a backlog, I'd think that it should be handled by increasing the length of the backlog queue. OTOH, keeping a syncache socket around waiting for an ack to be retransmitted IS better than dropping the connection... Accept filters might interact badly with such a change, that'd have to be checked. Also, this would open up the potential that one bad app could fill the syncache. That would require a lot of work though; someone with a local account can already do much worse things. How do the apps which try to rate-limit connections (OpenSSH, sendmail) do it? Would that behavior be defeated with your proposed changes? I'm not opposed to your idea, I'd just like to fully understand the implications before any changes are made. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: What does FreeBSD do when listen queue is full ?
On 18 Apr 2002, Mark Delany wrote: It raises the question as to the purpose of backlog. Is it really only intended as a resource hint or does it represent a firm threshold beyond which the OS should act differently? If the latter, then the purpose of the threshold can only be of real benefit to the client as the server can trivially track its own resource usage, true? Well, the problem with being fast and free with RSTs is that I don't think many clients react well to them. Hence, in the standalone server case I suspect that Bill's idea of ignoring the ACK and waiting for it to be retransmitted is the better idea. After that is done, adding a sysctl which enables the RST functionality wouldn't be a problem if you think that it may be beneficial for those using load balancers. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: What does FreeBSD do when listen queue is full ?
On 15 Apr 2002, Yusuf Goolamabbas wrote: In 4.5-RELEASE, there seems to be no caller for sodropablereq, however the function is declared in sys/sys/socketvar.h and defined in sys/kern/uipc_socket2.c. Maybe it can be deleted from the source tree I'll go look into cleaning that up tomorrow. I have yet to read J.Lemon's Usenix paper on syncache and figure out how that affects tcp input processing Regards, Yusuf The syncache changes syn processing entirely, and seems to have a very positive effect. Rather than analyzing the old behavior, you're best off spending time upgrading to RELENG_4_5. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: What does FreeBSD do when listen queue is full ?
On 15 Apr 2002, Yusuf Goolamabbas wrote: Subsequently, we changed the listen backlog to 128 via DAEMON_OPTIONS(`Port=smtp, Name=MTA, Listen=128') and turned ConnectionRateThrottle back on with a value of 20. Now, the immediate reset is triggered but quite infrequently I thought that FreeBSD might be sending a RESET when the listen queue is full but that would be contrary to what the listen(2) man page says 'If a connection request arrives with the queue full the client may receive an error with an indication of ECONNREFUSED, or, if the underlying protocol supports retransmission, the request may be ignored so that retries may succeed.' There used to be two listen queues; one for completed connections and one for incomplete connections. (Complete referring to the TCP three-way handshake completing.) The syncache replaces the incomplete connection queue, meaning that the listen queue depth is no longer relevant there. I just did a quick look over the code, and it appears that the complete connection queue is still intact, and takes on 3/2*listen backlog as its length. Therefore, if sendmail is deciding to not accept() all connections ASAP, a backlog will build up, and RSTs will be sent to incoming connections. This should be true under 4.4 or 4.5. The listen manpage looks to be pretty accurate in its description. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: What does FreeBSD do when listen queue is full ?
On Mon, 15 Apr 2002, Yusuf Goolamabbas wrote: There used to be two listen queues; one for completed connections and one for incomplete connections. (Complete referring to the TCP three-way handshake completing.) The syncache replaces the incomplete connection queue, meaning that the listen queue depth is no longer relevant there. What is the maximum size of the queue for completed connections ? Is there a sysctl setting for this The listen backlog parameter should determine this. The listen manpage looks to be pretty accurate in its description. What about the statement 'or,if the underlying protocol supports retransmission, the request may be ignored so that retries may succeed' What does 'underlying protocol' refer to then since you are saying that even with TCP which supports retransmission, the stack sends a RST when the listen queue is full Regards, Yusuf -- Yusuf Goolamabbas That statement makes sense to me if the incomplete connection queue is being referred to. (Although that would be incorrect wrt the default behavior in 4.4, and the syncache isn't a queue.) Maybe I can word that better when I go through and make sure all the comments in the source are up to date. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: TCP Timestamp option?
On Wed, 10 Apr 2002, ipver4 wrote: Thanks for the explanation. It seems since version 4.4 that kernel net.inet.tcp.rfc1323 is set to 1 by default, thus causing all the TCP connections to use the RFC1323 extension. The effects are: 1. bigger TCP header. 2. more processing time at sending and receiving hosts. 3. VJ TCP/IP header compression algorithm does not compress most of the time. I am not sure turning on the RFC1323 support on by default is such a good idea. The added amount of time and data is insignificant with today's computers on today's networks. At the same time, the reality of 32 bit sequence numbers being relatively small and timestamps being needed to track wraparound is setting in. Although we don't use the various rfc 1323 options to their full extent yet, keeping them enabled is a good idea in the long run. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
RE: Unnumbered IP Interface
The driver is lmc. The version from the SBEI (formally LanMedia) web site does not support netgraph. Their support claims to have one (or will have one I forget). I want to hold off on NG at the moment. As for what I'm doing. In this case, I have 4 of these PCI cards. I eventually, I want to be dual homed to 2 different ISP's and run BGP4. The other two p2p lines will go to different remote sites (e.g. leased line). I'll need to run OSPF (or possibly RIP) on the leased lines and BGP4 to the ISP's. In one case, the box at the other end forces me to use unnumbered interfaces (hence my initial message). In the other cases I'm staging the BSD box here first. There are subnets at the other end of all these p2p connections. Route advertisements will need to be exchanged over the p2p links. I'm just getting to this part in the lab now and wanted to get some hints. For example, Archie's answer for unnumbered interfaces isn't in the route manpage. I'm glad I asked. MikeC -Original Message- From: Julian Elischer [mailto:[EMAIL PROTECTED]] Sent: Monday, March 25, 2002 9:49 PM To: Cambria, Mike Cc: 'Archie Cobbs'; '[EMAIL PROTECTED]' Subject:RE: Unnumbered IP Interface On Mon, 25 Mar 2002, Cambria, Mike wrote: Thanks. I have a few follow-up questions to your answer. I'm not using netgraph (at least at the moment). Will this matter? No it's a totally sepaate matter. I assume 'ifconfig lmc0 up' is all I need to do to bring the interface up prior to route add next hop -iface lmc0... yes, assuming it's a point-to-point interface. On FreeBSD, do I need to do anything special to run OSPF or BGP4 over an unnumbered interface? (If I remember correctly RIP doesn't support an unnumbered interface.) I have NO idea.. I've only used it with static routes. I have four of these lmc cards. Besides the leased line monthly charges ... am I crazy doing this on FreeBSD? They all work in one machine at the moment (4.5-Stable). I'm just starting to get the p2p routing setup (it has been a long time.) Are 4 unnumbered interfaces supported in one machine? Can they all point to the same next hop? 4 different next hops? A combination? It all depends on what you want to do. what is the driver called? does it have a netgraph interface? (if so you can GANG the cards by using the one2many netgraph node. otherwise I need more info on what you are trying to do Thanks, MikeC -Original Message- From: Archie Cobbs [mailto:[EMAIL PROTECTED]] Sent: Friday, March 22, 2002 1:19 AM To: Julian Elischer Cc: Cambria, Mike; '[EMAIL PROTECTED]' Subject: Re: Unnumbered IP Interface Julian Elischer writes: A while ago it was possible to use 'route' to add a rout eto a p2p interface by name and not assign it any addresses. Yes, this still works.. e.g., route add 1.2.3.4 -iface ng0. The interface has to be marked 'UP' of course. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
RE: Unnumbered IP Interface
Thanks. I have a few follow-up questions to your answer. I'm not using netgraph (at least at the moment). Will this matter? I assume 'ifconfig lmc0 up' is all I need to do to bring the interface up prior to route add next hop -iface lmc0... On FreeBSD, do I need to do anything special to run OSPF or BGP4 over an unnumbered interface? (If I remember correctly RIP doesn't support an unnumbered interface.) I have four of these lmc cards. Besides the leased line monthly charges ... am I crazy doing this on FreeBSD? They all work in one machine at the moment (4.5-Stable). I'm just starting to get the p2p routing setup (it has been a long time.) Are 4 unnumbered interfaces supported in one machine? Can they all point to the same next hop? 4 different next hops? A combination? Thanks, MikeC -Original Message- From: Archie Cobbs [mailto:[EMAIL PROTECTED]] Sent: Friday, March 22, 2002 1:19 AM To: Julian Elischer Cc: Cambria, Mike; '[EMAIL PROTECTED]' Subject:Re: Unnumbered IP Interface Julian Elischer writes: A while ago it was possible to use 'route' to add a rout eto a p2p interface by name and not assign it any addresses. Yes, this still works.. e.g., route add 1.2.3.4 -iface ng0. The interface has to be marked 'UP' of course. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Unnumbered IP Interface
Hi, Can an unnumbered IP interface be configured on FreeBSD (4.5-Stable)? Will Zebra and/or GateD (or RouteD) handle it properly? Thanks, MikeC To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
RE: Unnumbered IP Interface
Thanks. I'll check out route man page. I am running synchronous serial PCI cards. I have one FreeBSD 4.5-Stable machine routing Ethernet, PPP and Wireless just to see if it would all play together. I'm running a few LMC (now SBE) HSSI and T1/E1 cards in various FreeBSD boxes. One of the devices I need to test against (and work with in the field) doesn't seem to let me configure an IP address for both ends via ifconfig. For example: ifconfig lmc0 10.1.1.1 10.1.1.2 netmask 255.255.255.255 works just fine FreeBSD to FreeBSD. No such command exists on this one box I need to deal with. I configure a subnet (e.g. Ethernet) or unnumbered p2p, that's it as far as I can tell. The manual for this device does claim to support unnumbered, so I want to try that on our side if possible. If that works, the next trick is to find an OSPF that can deal with it. Thanks again, MikeC -Original Message- From: Julian Elischer [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 21, 2002 4:05 PM To: Cambria, Mike Cc: '[EMAIL PROTECTED]' Subject:Re: Unnumbered IP Interface Unnumbered interfaces are not supported officially, but it may still work.. A while ago it was possible to use 'route' to add a rout eto a p2p interface by name and not assign it any addresses. thus packets would still be passed across the link without it having any addresses. (this is great for not wasting adresses) I do not know it this still works, asd I have not tested it for a long time (several years) from memory the 'route' man page still specifies how to do the route end of thing. you might try it and get back to us to let us know it it still works. (it has to be a point-2-point interface, e.g. a sync serial card) On Thu, 21 Mar 2002, Cambria, Mike wrote: Hi, Can an unnumbered IP interface be configured on FreeBSD (4.5-Stable)? Will Zebra and/or GateD (or RouteD) handle it properly? Thanks, MikeC To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Getting rid of maxsockets.
On Wed, 20 Mar 2002, Garrett Wollman wrote: On Wed, 20 Mar 2002 15:01:01 -0600 (CST), Mike Silbersack [EMAIL PROTECTED] said: That would end up being a reduction below the current value; right now sockets maxfiles with large maxuser values. Whether or not this is a necessary differential, I'm not sure. (With TIME_WAIT and FIN_WAIT_2 sockets, I believe that maxsockets should exceed maxfiles.) My point was that it's not necessary to enforce a limit on sockets, specifically, because maxfiles (and user resource limits) will keep users from opening too many sockets. We should probably look to templating closed TCP connections, since they don't actually need a socket at all (or most of the PCB). -GAWollman A TIME_WAIT cache or similar would be great, I agree. In that case, I'd think that you would want fewer sockets than files so that apps would always have free files available, even once sockets were depleted. In short, I think that it's advantageous having seperate limits, given that doing so is easy. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Getting rid of maxsockets.
On Wed, 20 Mar 2002, Jeff Roberson wrote: Once everything's UMA'd, then we can develop new sizing parameters. Everything has been UMA'd other than MD code, so I'm working on making the system take advantage of it. Thanks! Jeff I've looked over vmstat -z with a UMA kernel, it's really nice to know that everything is coexisting together now. There's one big target, though: mbufs. I know that Bosko put a lot of work into his new mbuf allocator, but if you could find a way to merge mbufs into the slab allocator the benefits would be huge. Have you discussed doing this with Bosko yet? Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Getting rid of maxsockets.
On Thu, 21 Mar 2002, Bosko Milekic wrote: On Thu, Mar 21, 2002 at 11:35:52PM -0500, Jeff Roberson wrote: We have talked about it quite a bit. I'd love to remove the hard limit on mbufs. I may do this soon, but I have other uma related work that will probably come before it. I'm not so sure I like this idea. What would be better (and perhaps what you meant) is: be able to expand the size of the mbuf allocation `pool' at runtime. In any case, we should not jump to quick conclusions with all data structures right away. Instead, I propose that we first glue-in mbuf allocations to UMA (not too difficult, given that UMA provides an allocation routine stub). If this is done properly [without macro-performance loss] then it should be rather trivial to bring in new functionality. -- Bosko Milekic Expanding is good, contracting is better. :) Whatever rate you want to do the switchover at would be best; I don't see any urgent need to rush the work. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: ADD TO(NEW Info): Apache/TCP stack issues
On Wed, 13 Mar 2002, Dmitry Koltsov wrote: Hello, I'm running on 4.4-stable. Seems like my problem is (connection refused) caused by listen queue. I have 1-10 requsts in apache listen queue (port 80), queue len is 511 connections and have counter listen queue overflows growing in the same time (!) Current listen queue sizes (qlen/incqlen/maxqlen) Listen Local Address 11/11/511 216.65.107.31.80 How it may be? Is there solution? As I said before, the listen queue has been mostly replaced by the syn cache in 4.5. Therefore, it is very unlikely that anyone is going to go back and work on it. If you are concerned about listen queue overflows, upgrade to 4.5. Also I have tested queue with simple program (socket(), bind(), listen(sock,128), do nothing in the loop) and received this amazing stats: Current listen queue sizes (qlen/incqlen/maxqlen) Listen Local Address 193/0/128 216.65.107.31.81 (queue len queue maxlen) !!! That's entirely expected, and the reason why is visible in the source. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Getting rid of maxsockets.
On Wed, 20 Mar 2002, Jeff Roberson wrote: Would anyone be upset if I got rid of maxsockets and consequently the limits on the *pcb zones? This was previously used so that the zone allocator could allocate items at interrupt time. Now you can just supply M_NOWAIT/WAITOK and get the desired effect without a hard limit. Jeff We still need to cap the number of sockets somehow, as it would be bad for sockets to consume all memory. If you want to move the socket limit to someplace where it can be modified via a sysctl, that'd be great. As you're going through and UMAing everything, I think it'd be best if you kept the limits the same for now. Once everything's UMA'd, then we can develop new sizing parameters. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Getting rid of maxsockets.
On Wed, 20 Mar 2002, Garrett Wollman wrote: On Wed, 20 Mar 2002 14:18:31 -0600 (CST), Mike Silbersack [EMAIL PROTECTED] said: We still need to cap the number of sockets somehow, as it would be bad for sockets to consume all memory. There's already a cap: maxfiles. -GAWollman That would end up being a reduction below the current value; right now sockets maxfiles with large maxuser values. Whether or not this is a necessary differential, I'm not sure. (With TIME_WAIT and FIN_WAIT_2 sockets, I believe that maxsockets should exceed maxfiles.) Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Getting rid of maxsockets.
On Wed, 20 Mar 2002, Jeff Roberson wrote: I have kept the current limits in place, but I think that it's somewhat ugly to have this policy enforced in the allocator where it is hard to adjust with a sysctl. Perhaps maxsockets could stay but become run time adjustable. Is there any case where we will have lots of pcbs w/o sockets? If so, all of the limits checking can be done in the socket code and the pcb code can completely forget about it. I believe that the various pcb structures are tightly coupled to sockets, so checking only in the socket code should be safe. That would be a good change. Once everything's UMA'd, then we can develop new sizing parameters. Everything has been UMA'd other than MD code, so I'm working on making the system take advantage of it. Ah, neat. I haven't cvsup'd in the last two weeks, so I have yet to play around with UMA. I was going to ask some more questions here, but it's probably best that I actually look at the code first. :) Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Freebsd REL_ENG 4.3 p28 freezes every 30 minutes.
On Tue, 19 Mar 2002, Greg Black wrote: Josef Karthauser wrote: | 4.3 is two whole major releases ago. You should be running 4.5, which | you can get by cvsuping using the tag RELENG_4_5_0_RELEASE, or the tag | RELENG_4 if you wish to be at the head of developments on the -stable | branch. This is not wise advice. There are lots of circumstances where 4.3 is perfectly fine and can be shown to work while 4.4 and 4.5 are broken. I have had to revert to 4.3 on several machines after attempting unsuccessfully to run 4.4 and 4.5 (and current, for that matter). Greg Which PRs describe the problems encountered? Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Freebsd REL_ENG 4.3 p28 freezes every 30 minutes.
On Tue, 19 Mar 2002, Greg Black wrote: Mike Silbersack wrote: | Which PRs describe the problems encountered? I have not submitted a PR yet. I have raised the problems on the FreeBSD mailing lists several times since 4.4-RELEASE and have had some correspondence with Warner Losh and Greg Lehey in vain attempts to establish some basis for working towards a solution. In essence, I have laptops that work fine with PCMCIA cards under 4.3 but which don't recognise them at all under later releases (including 4.4, 4.5 and current as of a few weeks ago). The symptoms, as reported several times, are: Ah, PCMCIA... I can't help there. :) You weren't very specific in your earlier message, and I (incorrectly) assumed that you were talking about more general problems (which I could work on.) Good luck, I'm sure Warner will get it all working one of these days. He does commit to -current a lot, so there is the possibility that it is already fixed. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Apache/TCP stack issues
On Wed, 13 Mar 2002, Dmitry Koltsov wrote: Hello I have some issues with TCP stack and/or Apache. Issue: I'm getting Connection refused error when trying to connect to Apache over Internet when packet loss is 1-2%. Not all connection attempts fail but about 3% of attempts. When I'm trying to connect over local network(from another machine and localhost) in the same time, all is ok. In order to get this statistics, I've made 2 attempts from each place in the same time. I guess apache is ok because from local network and localhost it gives no errors. Is there solution? What release of FreeBSD are you running? From what you describe and the logs, it appears you're overloading the server and causing the listen queue to overflow. One piece of information you're omitting is how quickly you're sending those 2 connection attempts. If that's over 2 seconds, I wouldn't expect any listen queue overflows. If it's over 1 second, I'd expect a lot of listen queue overflows. The listen queue overflows indicate to me that you're running a version of FreeBSD that does not include Jonathan Lemon's syncache/syncookie implementation. This was added just shortly before 4.5-release, and should help your situation greatly. If you are running 4.5, then I'm stumped. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Apache/TCP stack issues
On Wed, 13 Mar 2002, Dmitry Koltsov wrote: I'm running on 4.4-stable I have 1-3 connections in queue and in the same time I have listen queue overflows counter growing. How it may be? Current listen queue sizes (qlen/incqlen/maxqlen) Listen Local Address 1/1/128216.65.107.31.80 Well, the listen queue may be occasionally spiking due to network latency. You're probably not going to be able to observe such an event via netstat because the bursts are probably quite short. You could increase the listen queue length (via a sysctl I've now forgotten), or update to 4.5-stable. If this is just a load test and not real usage, you could also ignore the problem for now; you'll have to make the determination. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
NFS odditiy
Right, first of all let me state that im somewhat of a unix newbie (having only been using it for 3 weeks or so) so i might be missing something obvoius here. Ok, first my netwrok setup, im running Freebsd 4.4 on a p90 with 48mb and a nice chunky 40gb hard drive, this is my file server (called bitch), now my client machines are a windows 2000 box and my amiga a4000. On Bitch there is a partition called /Store which im sharing with the network, my exports file reads /Store -alldirs -maproot=0 192.68.0.1 192.168.0.2 i can mount this share on both machines with no problem i can read/write into /Store/Mp3 and /Store/Filter... but, i cant read/write into /Store itself although i can browse /Store, thus far all the literature ive read seems to say i shouldnt be having this problem. Any ideas ? -- Mike Woods WoA SE Webmonkey General Dogsbody Amiga North Thames Webmaster Games Co-ordinator --- World Of Amiga SE - http://www.worldofamiga.com Amiga North Thames - Http://www.AmigaNorthThames.co.uk HomePage - Http://www.planetheck.co.uk/~damnation Micronik Busboards Support - Http://www.microniksupport.n3.net ICQ uin - 86410172 --- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: dc TX underrun message, again
On Tue, 26 Feb 2002, Yann GROSSEL wrote: But after a few minutes of activity : Feb 26 13:19:22 blade /kernel: dc3: TX underrun -- using store and forward mode Feb 26 13:24:33 blade /kernel: dc2: TX underrun -- using store and forward mode Are these new messages indicating a more serious problem ? Or is it harmless to ignore them ? Thanks for any answers Yann That means, I give up, I'm just going to wait until the whole packet gets sent to me from the PCI bus before I even try sending it over the network. So yes, your system is quite busy. However, it's still not anything to worry about. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: dc TX underrun message
On Mon, 25 Feb 2002, Yann GROSSEL wrote: Hi, We have a new machine that is about to become a firewall. For now this machine is running but idle, that is, it has no services running but sshd, and no default route. The machine has been up for about 20 days, wihtout doing anything. However 3 messages has been logged : Feb 5 14:30:18 blade /kernel: dc3: TX underrun -- increasing TX threshold Feb 5 14:58:33 blade /kernel: dc3: TX underrun -- increasing TX threshold Feb 19 09:38:39 blade /kernel: dc3: TX underrun -- increasing TX threshold What do these message mean ? Is there a hardware problem ? Don't worry too much about those messages; as far as I understand it, the default mode of the NIC is to start transmitting the packet as it is being DMA'd into the card. However, the default buffer size is too small, and the NIC gets ahead of the DMA transfer. Hence, the buffer is automatically being increased in size until the problem goes away. So, you've really only lost 4 packets to the problem, then it stabilized. You'll probably see the exact same behavior on every reboot. There have been patches to up the default buffer size and/or enable features to work around the problem on certain chipsets, but everything works well enough that I haven't been motivated to give them a serious look. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: SACK (and older TCP stack) availability?
On Thu, 21 Feb 2002, Luigi Rizzo wrote: I actually looked at the patches, and by visual inspection, they broke the flow for standard TCP connections when SACK was disabled. This was also verified with TBIT. So even if the SACK implementation was correct (which I haven't checked in detail) they are a no-go unless someone puts significant work on them. cheers luigi Whee! Ok, good to know. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: network buffer problem
On Mon, 18 Feb 2002, Marcel de Vries wrote: Hi all, I'm getting alot of buffer problems with my internet connection. I'm using a (Dutch) Mxstream ADSL for Broadband internet connection. The ISDN Alcatel ADSL modem is loaded with firmware: Active : GSV7AA3.270 Setting NMBClusters in the kernelconf doesn't help at all. Tracked the BSD hackers archive, there are some known bugs regarding the ep driver and 'No buffer space available' Still fresh yet unsolved bugs? correct? There is a fix for the No buffer space available problems due to the ep driver. It has been commmitted to -current, but not -stable as of yet. I suspect Warner will MFC the change in a few days. In the meantime, you could try manually applying this diff to your system: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ep/if_ep.c.diff?r1=1.107r2=1.108 Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: network buffer problem
On Mon, 18 Feb 2002, Marcel de Vries wrote: I really want to make a point, is it third party software ‘mpd-3.7 Multi-link PPP daemon based on netgraph(4)’ that is causing this or is it something in the TCP/IP stack of BSD that is changed or the driver support. We had these problems in 4.3, 4.4 and still in 4.5. From using mpd 3.1 to 3.7 nothing changed about our problem. I think it’s an important notice why this is happening, because what if this is a real TCP/IP stack issue this would be very wrong and bad for FreeBSD. But I’m still no expert so I have to leave this open for the Pro BSD users/developers. Bye, Marcel If your friend with a different network card is having similar problems, I'd guess that mpd-netgraph is where you should start investigating. However, as I have never used mpd-netgraph, I have no idea what you should be looking at. If by chance a mpd guru does not wander into this thread, I suggest that you look through the old mailing list archives, see who has had experience with it before, and drop them an e-mail. As far as your other question about natd slowing down... I believe that someone was looking into that. If he manages to find the bottleneck and fix it, I suspect you'll see the announcement here. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: ~40 DupAcks And No Fast Retransmit !!
On Tue, 12 Feb 2002, murthy kn wrote: Hello all, I am using 4.3 BSD and from the below capture, I feel that there is some problem with the Fast Retransmit (unless I am missing something). I also recall that there was a short thread about some problems with Fast Retransmit earlier in Nov 2001 - that sender was resorting to the costly Retransmission timeout even after receiving many DupAcks. Ok, I'll look at this in depth when I get some time. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Duplicate Acks and Fast Retransmit
On Wed, 6 Feb 2002, murthy kn wrote: Hello, Below is the netstat -p tcp output on a FreeBSD 4.3 Machine. (with a couple of arrows to indicate lines of interest) In order to understand the effect of reordering better, ... If you really wish to understand how the tcp stack works better and / or fix bugs in it, you really need to use tcpdump to log what is actually passing over the wire. The statistics from netstat -s are only meant as an overview, and are not detailed enough to make inferences about how things are actually working. If you can show specific behaviors in a tcpdump that you're interested in, I'm sure that many people would be willing to help answer your questions. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Netgraph Based Web Server?
Just curious but has anyone implemented a netgraph based web server? --- Mike Wade ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Netgraph Based Web Server?
Just curious but has anyone implemented a netgraph based web server? --- Mike Wade ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
[patch] removal of mbuf allocation failure messages from if_fxp
Luigi, does this patch look good? AFAIK, the code you added should handle
printing errors in these two cases; is that correct?
Thanks,
Mike Silby Silbersack
--- if_fxp.cSun Feb 3 19:01:14 2002
+++ if_fxp.c.oldSun Feb 3 18:59:55 2002
@@ -1836,6 +1836,8 @@
if (m != NULL) {
MCLGET(m, M_DONTWAIT);
if ((m-m_flags M_EXT) == 0) {
+ device_printf(sc-dev,
+ cluster allocation failed, packet dropped!\n);
m_freem(m);
if (oldm == NULL)
return 1;
@@ -1843,6 +1845,8 @@
m-m_data = m-m_ext.ext_buf;
}
} else {
+ device_printf(sc-dev,
+ mbuf allocation failed, packet dropped!\n);
if (oldm == NULL)
return 1;
m = oldm;
Re: [patch] removal of mbuf allocation failure messages from if_fxp
Heh, I tend to diff in the wrong order a lot. I'll go ahead and get it
committed then.
Mike Silby Silbersack
On Sun, 3 Feb 2002, Luigi Rizzo wrote:
looks correct (apart from having to use patch -r to apply it...)
cheers
luigi
On Sun, Feb 03, 2002 at 07:03:20PM +, Mike Silbersack wrote:
Luigi, does this patch look good? AFAIK, the code you added should handle
printing errors in these two cases; is that correct?
Thanks,
Mike Silby Silbersack
--- if_fxp.cSun Feb 3 19:01:14 2002
+++ if_fxp.c.oldSun Feb 3 18:59:55 2002
@@ -1836,6 +1836,8 @@
if (m != NULL) {
MCLGET(m, M_DONTWAIT);
if ((m-m_flags M_EXT) == 0) {
+ device_printf(sc-dev,
+ cluster allocation failed, packet dropped!\n);
m_freem(m);
if (oldm == NULL)
return 1;
@@ -1843,6 +1845,8 @@
m-m_data = m-m_ext.ext_buf;
}
} else {
+ device_printf(sc-dev,
+ mbuf allocation failed, packet dropped!\n);
if (oldm == NULL)
return 1;
m = oldm;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-net in the body of the message
Workaround (RE: TCP connection via IPsec machine also running natd)
I'm able to workaround the problem posted earlier by doing the following: Since the machine which eats the received esp packets after natd is a router for the subnet making natd necessary, I'm able to connect to this machine by establishing sessions to any of the IP addresses on the other side of natd. It works just fine. This will suffice until I can figure out how to connect to a socket via a tunnel endpoint which is also doing natd. MikeC -Original Message- From: Cambria, Mike Sent: Friday, January 04, 2002 4:09 PM To: '[EMAIL PROTECTED]' Cc: Cambria, Mike Subject:TCP connection via IPsec machine also running natd I'm having problems connecting (e.g. telnet, ssh, ftp etc.) to a machine which is at the other end of an IPsec tunnel. Passing data with machines, via this tunnel, on subnets for which the tunnel endpoint is acting as a router work just fine. I'm using FreeBSD 4.4-Stable (cvsup'ed shortly after 4.4-Release) and have an IPsec tunnel from one subnet at home to a machine at a friends house. The subnet at home is behind ipfw/natd and uses a cable modem (i.e. one IP address) to access the Internet. I'm using ipfw simple with one addition to allow incoming TCP traffic from the friends machine (also FreeBSD 4.4). This _works_ fine for traffic to/from the subnet. Encrypted packets hit divert, get counted on the ipfw allow esp rule, are decrypted and are then routed to the destination machine and vice versa. Problems exist only with traffic from the remote (friends) machine that terminates at the ipfw/natd machine itself. The IKE (racoon) ISAKMP-SA is established just fine, an IPsec-SA is established for both directions and the remote machine sends the (e.g.) telnet traffic encrypted. The counters for ipfw show the packet hitting the divert rule and esp packet has been received. However, the connection never seems to make it to telnetd. Before setting up IPsec, this worked just fine. I tried again using the sock program (see Unix Network Programming, Vol. 1 2ed ) to have more control, rule out inted etc. with the same results. sock -s ip address port never returns form the listen call. As I said earlier, packets which route through ipfw/natd get unencrypted and make it to the remote subnet just fine. Looking at 'ipfw -a l' it seems that the ESP packets are being received _after_ being diverted to natd, but just not sent to the socket: [deleted] 01600 20 4384 divert 8668 ip from any to any via vx0 01700 00 deny ip from 10.0.0.0/8 to any via vx0 01800 00 deny ip from 172.16.0.0/12 to any via vx0 01900 00 deny ip from 192.168.0.0/16 to any via vx0 02000 00 deny ip from 0.0.0.0/8 to any via vx0 02100 00 deny ip from 169.254.0.0/16 to any via vx0 02200 00 deny ip from 192.0.2.0/24 to any via vx0 02300 00 deny ip from 224.0.0.0/4 to any via vx0 02400 00 deny ip from 240.0.0.0/4 to any via vx0 02500 19 4272 allow tcp from any to any established (an ssh session I have up to gather info on one PC) 02600 00 allow ip from any to any frag 02700 00 allow udp from any to any 500 02800 00 allow udp from any 500 to any 02900 1 112 allow esp from any to any (the encrypted packet) [deleted] 03500 0 0 allow tcp from friends ip address to my ip address setup [rest deleted] Any thoughts on where to look next? I don't see any counters for deny rules going up, so I'm guessing that the unencrypted packet isn't getting dropped due to one of my ipfw rules. I also notice that the counter on my firewall rule which explicitly allows session setup from my friends machine is not incrementing. Any help appreciated. Thanks, MikeC Michael C. Cambria Avaya Inc. Consulting Engineer Former Enterprise Networks Group voice: (978) 287 - 2807of Lucent Technologies fax: (978) 381 - 6415 300 Baker Avenue email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Concord, Massachusetts 01742 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
TCP connection via IPsec machine also running natd
I'm having problems connecting (e.g. telnet, ssh, ftp etc.) to a machine which is at the other end of an IPsec tunnel. Passing data with machines, via this tunnel, on subnets for which the tunnel endpoint is acting as a router work just fine. I'm using FreeBSD 4.4-Stable (cvsup'ed shortly after 4.4-Release) and have an IPsec tunnel from one subnet at home to a machine at a friends house. The subnet at home is behind ipfw/natd and uses a cable modem (i.e. one IP address) to access the Internet. I'm using ipfw simple with one addition to allow incoming TCP traffic from the friends machine (also FreeBSD 4.4). This _works_ fine for traffic to/from the subnet. Encrypted packets hit divert, get counted on the ipfw allow esp rule, are decrypted and are then routed to the destination machine and vice versa. Problems exist only with traffic from the remote (friends) machine that terminates at the ipfw/natd machine itself. The IKE (racoon) ISAKMP-SA is established just fine, an IPsec-SA is established for both directions and the remote machine sends the (e.g.) telnet traffic encrypted. The counters for ipfw show the packet hitting the divert rule and esp packet has been received. However, the connection never seems to make it to telnetd. Before setting up IPsec, this worked just fine. I tried again using the sock program (see Unix Network Programming, Vol. 1 2ed ) to have more control, rule out inted etc. with the same results. sock -s ip address port never returns form the listen call. As I said earlier, packets which route through ipfw/natd get unencrypted and make it to the remote subnet just fine. Looking at 'ipfw -a l' it seems that the ESP packets are being received _after_ being diverted to natd, but just not sent to the socket: [deleted] 01600 20 4384 divert 8668 ip from any to any via vx0 01700 00 deny ip from 10.0.0.0/8 to any via vx0 01800 00 deny ip from 172.16.0.0/12 to any via vx0 01900 00 deny ip from 192.168.0.0/16 to any via vx0 02000 00 deny ip from 0.0.0.0/8 to any via vx0 02100 00 deny ip from 169.254.0.0/16 to any via vx0 02200 00 deny ip from 192.0.2.0/24 to any via vx0 02300 00 deny ip from 224.0.0.0/4 to any via vx0 02400 00 deny ip from 240.0.0.0/4 to any via vx0 02500 19 4272 allow tcp from any to any established (an ssh session I have up to gather info on one PC) 02600 00 allow ip from any to any frag 02700 00 allow udp from any to any 500 02800 00 allow udp from any 500 to any 02900 1 112 allow esp from any to any (the encrypted packet) [deleted] 03500 0 0 allow tcp from ip address to 66.31.106.72 setup [rest deleted] Any thoughts on where to look next? I don't see any counters for deny rules going up, so I'm guessing that the unencrypted packet isn't getting dropped due to one of my ipfw rules. I also notice that the counter on my firewall rule which explicitly allows session setup from my friends machine is not incrementing. Any help appreciated. Thanks, MikeC Michael C. Cambria Avaya Inc. Consulting Engineer Former Enterprise Networks Group voice: (978) 287 - 2807of Lucent Technologies fax: (978) 381 - 6415 300 Baker Avenue email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Concord, Massachusetts 01742 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: USB ethernet problem
On Wed, 2 Jan 2002, Thomas Zenker wrote: Hi Mike, back from holidays... because this is now discussed in different threads, on -stable and on -net, I will try to recapitulate what has happened and keep this on -net USB ethernet problem. The performance problems apeared after updating my test system from 4.3 to 4.4 with Netgear EA101 USB/ethernet adaptor (kue driver). Performance dropped by a factor of 10 or more. The server in all cases was 4.4. After testing different slowstart flightsizes and send/recv buffer sizes with ttcp the findings were, that mostly the recvspace reduced to 16K (as in 4.3) recovered the performance. See also my message to -stable from 2001/12/14. The usb host controller on this system is a VIA 83C572 (UHCI). Now going to the final embedded hardware, the suprise was a hanging usb driver. The strange thing is, this does not happen while testing with ttcp, but only if the data is written to disk. The following kernel messages are printed: usb0: host controller process error usb0: host controller halted kue0: watchdog timeout kue0: usb error on tx: TIMEOUT this comes from uhci_intr() in dev/usb/uhci.c. Aparently the usb0-messages reflect a hw status register!? This happens very quickly with 4.4 (it is impossible to install over usb/ethernet), but I have seen it today for the first time with 4.3 also. The usb host controller is UHCI Intel 82371AB/EB (PIIX4). Well, since you've been able to isolate this as the cause, there's no need to run any more tcp tests with varying servers. Try changing hz, as I mentioned in the e-mail I just sent to you guys. Also, try running ttcp while seperately creating disk load (through a disk benchmark or something.) Meanwhile, watch systat -vm and see if the interrupt counts show you anything interesting. Thanks, Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: m_reclaim and a protocol drain
On Sun, 30 Dec 2001, Randall Stewart wrote: Heh, you nailed the reverse of the problem we've seen: Right now the easy way to cause exhaustion is to fill up _send_ buffers, via netkill. I guess if we solve that problem, out of order segments could be used for an attack too. Mike: Interesting problem.. but I was thinking in terms of a outside attacker.. not someone who has a login id on your machine. That leads down another path... i.e. local machine security. R Heh, you don't have to be local to cause a machine to send you something. Just find a service which exists to send data (http, pop3, ftp, irc), and you're in business. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: m_reclaim and a protocol drain
On Wed, 26 Dec 2001, Randall Stewart wrote: This comment facinates me. The reason we made SACK's in SCTP revokeable is due to the potential DOS attack that someone can supposedly lauch if you don't allow the stack to revoke. I can actually see the reason that Sally made the comments and had us change it so that SACK's are revokeable. However you argue to the contrary and I wonder which is correct. If you do not allow revoking it is the same as if a protocol does not hold a drain() fucntion. A attacker could easily stuff a lot of out-of-order segments at you and thus fill up all your mbuf's or clusters (in my current testing case). This would then yeild a DOS since you could no longer receive any segments and leave you high and dry Heh, you nailed the reverse of the problem we've seen: Right now the easy way to cause exhaustion is to fill up _send_ buffers, via netkill. I guess if we solve that problem, out of order segments could be used for an attack too. Just FWIW, Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: FreeBSD TCP/IP relation to Mac OS/X?
On Wed, 26 Dec 2001, Bill Vermillion wrote: I can't say one way or the other but in the past couple of weeks someone from Apple posted some fixes to the FreeBSD specifically in the TCP/IP area so I'm assuming it's the BSD stack. Otherwise the fixes would be going the other way. I think that you're confusing issues. Apple released a file system test program which helped Matt Dillon to find and fix a bunch of NFS / UFS / VM bugs, and Matt also fixed some TCP bugs, but there is no direct relation between Apple and the TCP changes. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: USB ethernet problem
On Fri, 21 Dec 2001, Thomas Zenker wrote: to follow up myself :-( the situation changed, I have tried to install the new release now on the final embedded hardware. It is to mention, that this hardware is working with fbsd 4.3 from july without any problems in about 50 equipments. Upgrade from the previous fbsd 4.3 works flawlessly (4.3 kernel is running during this procedure), however after rebooting the 4.4 kernel, another upgrade run doesn't terminate: kue0: usb error on tx: TIMEOUT kue0: watchdog timeout The difference in the run of sysinstall and ttcp is the heavy disk activity with sysinstall. There was no significant change in the USB driver since 2001-07-17. Might there be a run condition, interrupt problem or priority problem with the ata driver, which become visible now on the slower machine? May be I have to go back to fbsd 4.3 Hmm. I agree, it doesn't like like much of anything usb-related changed between 4.3 and now. If we examine the ata driver, one big thing changed between 4.3 and 4.4: Write caching was re-enabled. This caused a big change in disk throughput for some people, perhaps it's affecting you. Try turning it off (see the ata manpage for details) and see if that changes your results. Also, is your USB adapter sharing interrupts with anything else? Are interrupts being allocated the same way on 4.3 and 4.4? Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Bridging vlan0 with de0
On Wed, 19 Dec 2001 11:50:03 -0800 (PST), in sentex.lists.freebsd.net you wrote: I believe you can bridge a vlan interface if you use the new upcoming netgraph vlan node. It shuold be committed soon. (Vlans done the way it should have been done ;-) What advantage does this method have ? ---Mike Mike Tancsa ([EMAIL PROTECTED]) Sentex Communications Corp, Waterloo, Ontario, Canada Given enough time, 100 monkeys on 100 routers could setup a national IP network. (KDW2) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: USB ethernet problem
(Moving over to -net, please remove -stable from any cc's) On Mon, 17 Dec 2001, Thomas Zenker wrote: I allways wondered, why the initial slowstart window is set to one (well some years I didn't look into the tcp code though). 9 years ago I had to develope the firmware for a storeforeward radio network, where I applied a lot of the ideas from the then net/2 tcp stack. The rtt in such a network is really horrible and packetsizes have to be taken in account. Anyway the optimal initial window there was 2. With a window of two there much more probability to get a connection going, because you send two packets in the beginning, if the first is lost, the receiption of the second one gets the first one resent long before the timeout. Otherway round, if the second is lost... the third is on its way already. With a intital window of 1 the only recovery is by timeout. The argument against bigger than two was (at least in my case) not to defeat the intention of the slowstart. Anyway, in tcp probably something between 2 and 4 could be considered. Thomas RFC 2581 suggests that 4 is a good value (well, not exactly 4, they have a formula which comes out to about 4 in most cases.) I'm inclined to agree that something between 2-4 would be a good value for our non-local slowstart flightsize as well. Maybe after 4.5 is released we can go look into it. (It's too late to be changing stuff now.) Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Polling code at http://info.iet.unipi.it/~luigi/polling/
or two lines of MD code), and send feedback. thanks luigi --+- Luigi RIZZO, [EMAIL PROTECTED] . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 --+- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: mbuf / maxfiles / maxsockets / etc autoscaling patch
On Mon, 10 Dec 2001, Andre Oppermann wrote: - Only do autoscaling only if MAXUSERS=0 in kernel compile. Also change GENERIC to set MAXUSERS to null. (This is from Matt's patch) -- Andre Matt I are working on merging the two approaches, once we've finished throwing numbers together we'll commit the merged patch. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: What is TODO for SACK ?
On Mon, 10 Dec 2001, Daikichi Osuga wrote: Hello I hope SACK code comming into FreeBSD. What is TODO ? Can I help some work ? Our group is working to deploy useful TCP extensions for wireless networks. http://search.ietf.org/internet-drafts/draft-ietf-pilc-2.5g3g-05.txt We made Tom Henderson SACK code run on OPNET. (OPNET is commercial product network simulator. (www.opnet.com)) and fixed various bugs. so, I'm familiar with Tom Henderson SACK code. -- Daikichi Osuga Mobile Internet Laboratory NTT DoCoMo,Inc. There was a patch posted to -net a few months ago which imported the SACK support from OpenBSD. It needs a good looking over and testing, you should be able to find it if you look back through the archives. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
mbuf / maxfiles / maxsockets / etc autoscaling patch
Here's the autoscaling patch I was mumbling about earlier this week. With this patch applied, the necessity of tuning maxusers when one upgrades to a machine with more ram should be removed in most cases. (This patch is only to -current, the mbuf changes will make it not apply cleanly to -stable patch if there is sufficient demand right now.) Here's a quick look at the size of various memory allocations with various maxusers sizes and with the autoscaling patch: With maxusers: musers mproc mfiles msocket callout nmbcl nsfbuf tcp hash size 32 532 10641064161210241024512 64 104420882088314815361536512 128 206841364136622025602560512 256 41168232823212364 46084608512 With autoscaling: MB ram mproc mfiles msocket callout nmbcl nsfbuf tcp hash size 32 512 40962048462410241024512 64 102481924096923220481024512 128 204816384 819218448 409620481024 256 409632768 16384 36880 819240962048 384 614449152 24576 55312 12288 61443072 512 819265536 32767 73744 16384 81924096 (Values above this start to flatten out due to #defined maximums) Note that in general calculations are of the following form: value = max(maxusers-derived value, autoscale-derived value); value = loader tuned value if present As such, under no circumstances will people suddenly see a decrease in various parameters when they upgrade to an autoscaling kernel; only increases. I'm sure that there will be much commotion about what scaling factors are correct. To make changes to these easy, I have grouped all the mins, scaling factors, and maxes in param.h - tweaking them is quite simple. I included mins and maxes to make sure that autoscaling doesn't cause problems by creating low values on small memory machines and also so that it does not specify really high values on 2GB+ machines. The high case is what worries me; I have not heard much about how well maxsockets / nmbclusters 32767 really works. If people running high volume systems that actively use that many simultaneous sockets + clusters + files, I'd be glad to bump up the maxes. Oh, there's one more kicker thrown in; I changed maxfilesperproc to equal 9/10ths of maxfiles, and maxprocperuid to equal 9/10 maxproc; this'll help to prevent a single process or user from forkbombing the system or running it out of file handles with a default configuration. Please review. Thanks, Mike Silby Silbersack diff -u -r sys.old/alpha/alpha/machdep.c sys/alpha/alpha/machdep.c --- sys.old/alpha/alpha/machdep.c Sat Dec 8 16:05:15 2001 +++ sys/alpha/alpha/machdep.c Sat Dec 8 16:05:28 2001 @@ -556,7 +556,7 @@ kern_envp = bootinfo.envp; /* Do basic tuning, hz etc */ - init_param(); + init_hz(); /* * Initalize the (temporary) bootstrap console interface, so @@ -861,6 +861,9 @@ physmem -= (sz - nsz); } } + + /* Init basic tunables */ + init_param(alpha_ptob(physmem)); /* * Initialize error message buffer (at end of core). diff -u -r sys.old/i386/i386/machdep.c sys/i386/i386/machdep.c --- sys.old/i386/i386/machdep.c Sat Dec 8 16:04:54 2001 +++ sys/i386/i386/machdep.c Sat Dec 8 16:43:20 2001 @@ -1691,8 +1691,8 @@ else if (bootinfo.bi_envp) kern_envp = (caddr_t)bootinfo.bi_envp + KERNBASE; - /* Init basic tunables, hz etc */ - init_param(); + /* Init hz */ + init_hz(); /* * make gdt memory segments, the code segment goes up to end of the @@ -1871,6 +1871,9 @@ getmemsize(first); /* now running on new page tables, configured,and u/iom is accessible */ + + /* Init basic tunables */ + init_param(ptoa(Maxmem)); /* Map the message buffer. */ for (off = 0; off round_page(MSGBUF_SIZE); off += PAGE_SIZE) diff -u -r sys.old/ia64/ia64/machdep.c sys/ia64/ia64/machdep.c --- sys.old/ia64/ia64/machdep.c Sat Dec 8 16:04:52 2001 +++ sys/ia64/ia64/machdep.c Sat Dec 8 16:05:28 2001 @@ -522,8 +522,8 @@ /* get fpswa interface */ fpswa_interface = (FPSWA_INTERFACE*)IA64_PHYS_TO_RR7(bootinfo.bi_fpswa); - /* Init basic tunables, including hz */ - init_param(); + /* Init hz */ + init_hz(); p = getenv(kernelname); if (p) @@ -623,6 +623,9 @@ phys_avail[phys_avail_cnt] = 0; Maxmem = physmem; + + /* Init basic tunables */ + init_param(ia64_ptob(physmem)); /* * Initialize error message buffer (at end of core). diff -u -r sys.old/kern/subr_mbuf.c sys/kern/subr_mbuf.c --- sys.old/kern/subr_mbuf.cSat Dec 8 16:04:51
Re: Request to back out Luigis polled-net patch in -stable.
To: [EMAIL PROTECTED] Core isn't really the appropriate forum for asking for a back-out; arch and net are where this should have been discussed and reviewed in the first place. Subject: Request to back out Luigis polled-net patch in -stable. I'm entirely in agreement with this; the decision to commit this code was extremely ill-advised, and the best thing we can do now for everyone's sake is to pull it as quickly as possible. I would also like to point to the parallel piece of code: Jun-Itohs ALTQ for which he reliably has maintained a patch relative to the 4.X branch and which despite various peoples requests have not haphazardly been committed into -stable. And in that context one should not forget that ALTQ has a lot longer and better trackrecord of high quality than Luigis poll-code, or any of Luigis code for that matter. Yes; this is an excellent example of how it can be done better. Regards, Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
More Polling vs No Polling tests
OK, I think this time around I have fixed the duplex issues and the problem with the D-link not being initialized properly (reset PCI config data in the BIOS fixed a the problems). Using netperf I ran the basic snapshot script to see what affect the polling code had on network performance. In general it seems to work better for the most part, but the big bonus is the lowered load average. Next tests, I am going to see what effect it has purely on forwarding. For now, I have all the raw results available at http://www.tancsa.com/netperf-11-29-2001.tgz for anyone interested tar -tzf netperf-11-29-2001.tgz no-poll-dc-fxp no-poll-dc-fxp.no-hz no-poll-dc-rl no-poll-fxp-fxp no-poll-fxp-fxp-vlan no-poll-fxp-rl no-poll-fxp-rl.no-hz poll-dc-fxp poll-dc-fxp.no-hz poll-dc-rl poll-fxp-fxp poll-fxp-fxp-vlan poll-fxp-rl poll-fxp-rl.no-hz hardware.txt I did the following cross over cables connecting 2 boxes -- PIV with fxp and rl nics and and PIII with fxp and four port D-Link running the dc driver. netperf client on the PIII and the server on the PIV. I ran poll enabled vs no poll enabled on dc to fxp, dc to rl and fxp to fxp, and dc via switch port to a vlan interface on the PIV's fxp nic in 802.1q trunk mode connected to a compaq switch 10/100 switch. Much to my surprise and disappointment, the d-link was throughput wise quite an under-performer. I am not sure its the driver, it could very well be the card thats the problem. (Its a DFE-570TX 4 port). All the above tests were done with options HZ=1000 in the kernel. To see what difference it made, I re-ran the tests without the HZ option. These text files have the .no-hz extension One nice surprise (for me anyways) was the relatively good performance of the fxp card in 802.1q mode. With the prices of switches being so low (especially used), its almost cheaper to make a 24 port network card as opposed to something like the quad port D-link. ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Revised polling code (some stats)
Hi, just as an FYI, I did some simple tests using netperf of the polling code. On first blush, it does look quite nice. I am going to try and simulate what the effect is under network load while at the same time, trying to bring up a BGP peer with a full view. Machine A is a PIII 800 with a D-Link 4port NIC using the dc driver. Connected to it was a PIV 1.5 845 chipset board with integrated fxp running the server portion of netperf On the PIII with the Dlink card I ran the tests only varying net.xorp.polling: 0 vs net.xorp.polling: 1 The other nice thing of course of the polling code that does not show up in the figures below is the load average, which on the stream test at least shows . /0 /10 /20 /30 /40 /50 /60 /70 /80 /90 /100 idle XXX +POLLidle XX /usr/local/netperf/netperf -t TCP_STREAM -l 60 -H 10.1.1.1 -i 10,3 -I 99,5 -- -s 57344 -S 57344 -m 4096 Recv SendSend Socket Socket Message Elapsed Size SizeSize Time Throughput bytes bytes bytessecs.10^6bits/sec 57344 57344 409660.06 60.10 +POLL 57344 57344 409660.00 59.37 /usr/local/netperf/netperf -t TCP_STREAM -l 60 -H 10.1.1.1 -i 10,3 -I 99,5 -- -s 32768 -S 32768 -m 4096 Recv SendSend Socket Socket Message Elapsed Size SizeSize Time Throughput bytes bytes bytessecs.10^6bits/sec 32768 32768 409659.99 61.31 +POLL 32768 32768 409660.16 60.73 /usr/local/netperf/netperf -t TCP_RR -l 60 -H 10.1.1.1 -i 10,3 -I 99,5 -- -r 1,1 Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size SizeTime Rate bytes Bytes bytesbytes secs.per sec 16384 16384 11 59.998260.80 +POLL 16384 16384 11 59.996072.08 /usr/local/netperf/netperf -t UDP_RR -l 60 -H 10.1.1.1 -i 10,3 -I 99,5 -- -r 1,1 Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size SizeTime Rate bytes Bytes bytesbytes secs.per sec 9216 42080 11 59.9910398.39 +POLL 9216 42080 11 59.999248.39 /usr/local/netperf/netperf -t UDP_RR -l 60 -H 10.1.1.1 -i 10,3 -I 99,5 -- -r 516,4 UDP REQUEST/RESPONSE TEST to 10.1.1.1 : +/-2.5% @ 99% conf. : histogram Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size SizeTime Rate bytes Bytes bytesbytes secs.per sec 9216 42080 516 4 59.995857.40 +POLL 9216 42080 516 4 59.995482.58 /usr/local/netperf/netperf -t UDP_STREAM -l 60 -H 10.1.1.1 -i 10,3 -I 99,5 -- -s 32768 -S 32768 -m 4096 UDP UNIDIRECTIONAL SEND TEST to 10.1.1.1 : +/-2.5% @ 99% conf. : histogram Socket Message Elapsed Messages SizeSize Time Okay Errors Throughput bytes bytessecs# # 10^6bits/sec 327684096 59.99 115161 10324576 62.90 +POLL 32768 59.99 114009 62.27 +POLL 327684096 59.99 108361 7401883 59.19 32768 59.99 108342 59.18 327681024 59.99 478638 13513083 65.36 +POLL 32768 59.99 478475 65.34 +POLL 327681024 59.99 452463 8759390 61.79 32768 59.99 451930 61.71 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Revised polling code (some stats)
At 09:09 AM 11/27/01 -0800, Luigi Rizzo wrote: On Tue, Nov 27, 2001 at 11:56:45AM -0500, Mike Tancsa wrote: Hi, just as an FYI, I did some simple tests using netperf of the polling code. On first blush, it does look quite nice. I am going to try and well, the throughput numbers seems essentially unmodified, which is not surprising given that with large packet sizes your hardware should be able to bear the load. I have to say that 60Mbit/s for TCP seems a bit low given your hardware, i wonder if you are using half-duplex link (this would explain the huge number of errors in the udp test). If so, you should really re-run the test with full-duplex. Hmmm, I think you are right! fxp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet6 fe80::201:80ff:fe10:46a3%fxp0 prefixlen 64 scopeid 0x2 inet 10.1.1.1 netmask 0xff00 broadcast 10.1.1.255 ether 00:01:80:10:46:a3 media: Ethernet autoselect (100baseTX) status: active marble4# dc3: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet6 fe80::280:c8ff:fef8:51d4%dc3 prefixlen 64 scopeid 0x4 inet 10.1.1.2 netmask 0xff00 broadcast 10.1.1.255 ether 00:80:c8:f8:51:d4 media: Ethernet 100baseTX full-duplex status: active Name Mtu Network AddressIpkts IerrsOpkts Oerrs Coll fxp0 1500 Link#200:01:80:10:46:a3 42682189 4 27310290 0 338169 That is strange, the fxp _used_ to negotiate duplex settings just fine against this card. Perhaps its this poxy onboard variant! fxp0: Intel Pro/100 Ethernet port 0xc800-0xc83f mem 0xe7001000-0xe7001fff irq 10 at device 8.0 on pci2 fxp0: Ethernet address 00:01:80:10:46:a3 inphy0: i82562ET 10/100 media interface on miibus1 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto I will re-run them. ---Mike To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Revised polling code (some stats II)
At 09:09 AM 11/27/01 -0800, Luigi Rizzo wrote: On Tue, Nov 27, 2001 at 11:56:45AM -0500, Mike Tancsa wrote: Hi, just as an FYI, I did some simple tests using netperf of the polling code. On first blush, it does look quite nice. I am going to try and well, the throughput numbers seems essentially unmodified, which is not surprising given that with large packet sizes your hardware should be able to bear the load. I have to say that 60Mbit/s for TCP seems a bit low given your hardware, i wonder if you are using half-duplex link The strange thing is that its not much better having fixed the duplex issue. I notice in dmesg that dc3: TX underrun -- increasing TX threshold dc3: TX underrun -- increasing TX threshold dc3: TX underrun -- increasing TX threshold dc3: TX underrun -- using store and forward mode But I have found that to be normal for the card. Anyways, here are the stats going from dc2 (PIII 800) to an fxp card on a PIV. Testing with the following command line: /usr/local/netperf/netperf -t TCP_STREAM -l 60 -H 10.1.1.1 -i 10,3 -I 99,5 -- -s 57344 -S 57344 -m 4096 TCP STREAM TEST to 10.1.1.1 : +/-2.5% @ 99% conf. : histogram Recv SendSend Socket Socket Message Elapsed Size SizeSize Time Throughput bytes bytes bytessecs.10^6bits/sec 57344 57344 409660.00 62.52 57344 57344 409660.00 64.19 +POLL /usr/local/netperf/netperf -t TCP_STREAM -l 60 -H 10.1.1.1 -i 10,3 -I 99,5 -- -s 32768 -S 32768 -m 4096 TCP STREAM TEST to 10.1.1.1 : +/-2.5% @ 99% conf. : histogram Recv SendSend Socket Socket Message Elapsed Size SizeSize Time Throughput bytes bytes bytessecs.10^6bits/sec 32768 32768 409659.99 64.19 32768 32768 409659.99 65.23 +POLL /usr/local/netperf/netperf -t TCP_RR -l 60 -H 10.1.1.1 -i 10,3 -I 99,5 -- -r 1,1 TCP REQUEST/RESPONSE TEST to 10.1.1.1 : +/-2.5% @ 99% conf. : histogram Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size SizeTime Rate bytes Bytes bytesbytes secs.per sec 16384 16384 11 59.996072.04 16384 16384 11 59.998351.88 +POLL /usr/local/netperf/netperf -t UDP_RR -l 60 -H 10.1.1.1 -i 10,3 -I 99,5 -- -r 1,1 UDP REQUEST/RESPONSE TEST to 10.1.1.1 : +/-2.5% @ 99% conf. : histogram Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size SizeTime Rate bytes Bytes bytesbytes secs.per sec 9216 42080 11 59.999473.54 9216 42080 11 59.9910384.59 +POLL /usr/local/netperf/netperf -t UDP_RR -l 60 -H 10.1.1.1 -i 10,3 -I 99,5 -- -r 516,4 UDP REQUEST/RESPONSE TEST to 10.1.1.1 : +/-2.5% @ 99% conf. : histogram !!! WARNING !!! Desired confidence was not achieved within the specified iterations. !!! This implies that there was variability in the test environment that !!! must be investigated before going further. !!! Confidence intervals: Throughput : 8.5% !!! Local CPU util : 0.0% !!! Remote CPU util : 0.0% Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size SizeTime Rate bytes Bytes bytesbytes secs.per sec 9216 42080 516 4 59.995332.39 9216 42080 516 4 59.995752.03 +POLL /usr/local/netperf/netperf -t UDP_STREAM -l 60 -H 10.1.1.1 -i 10,3 -I 99,5 -- -s 32768 -S 32768 -m 4096 UDP UNIDIRECTIONAL SEND TEST to 10.1.1.1 : +/-2.5% @ 99% conf. : histogram Socket Message Elapsed Messages SizeSize Time Okay Errors Throughput bytes bytessecs# # 10^6bits/sec 327684096 59.99 108559 7379153 59.30 32768 59.99 108521 59.28 327684096 59.99 114246 10368207 62.40 +POLL 32768 59.99 114227 62.39+POLL Testing with the following command line: /usr/local/netperf/netperf -t UDP_STREAM -l 60 -H 10.1.1.1 -i 10,3 -I 99,5 -- -s 32768 -S 32768 -m 1024 UDP UNIDIRECTIONAL SEND TEST to 10.1.1.1 : +/-2.5% @ 99% conf. : histogram Socket Message Elapsed Messages SizeSize Time Okay Errors Throughput bytes bytessecs# # 10^6bits/sec 327681024 59.99 475626 9177882 64.95 32768 59.99 475467 64.93 327681024 59.99 461228 13567726 62.98 +POLL 32768 59.99 461151 62.97 +POLL The only problematic one is the last one. Still, I am surprised by the amount of errors and even the somewhat low throughput. I recall running this test some time ago and being able to pretty well get close to 100Mb/s on the fxp card. And, a UDP stream test /usr/local/netperf/netperf -t UDP_STREAM -l 60 -H 10.1.1.1 -i 10,3 -I 99,5 -- -s 32768 -S 32768
Re: RFC: MFC M_ZERO usage for bpf.c
On Tue, 27 Nov 2001, Bruce A. Mah wrote: Hi-- I've been reading through src/sys/net/bpf.c, and I noticed that the changes to make it use M_ZERO haven't been MFC-ed to RELENG_4 yet. Any objection if I do this? (Nothing broke in my quick testing.) Thanks, Bruce. Possibly a dumb question, but does 4.x actually have the M_ZERO functionality? If so, syncing these changes to 4.x seems like a good idea. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Revised polling code for STABLE
At 11:57 AM 11/26/01 -0800, Luigi Rizzo wrote: [Bcc to -stable in case someone is interested there] Attached you can find the latest version of the polling code for STABLE (which is useful to make boxes much more robust to attacks and have much better responsiveness under [over]load). Thanks for this code! Are there any particular compile time options one should use ? e.g. HZ=1000 etc ? The box in question would be running Zebra and BGPd and forwarding lots-o-packets with lots-o-routes (100k+) ---Mike To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Strange problem with PPP/Netgraph (PPPoE)
On Thu, 22 Nov 2001 14:36:37 + (UTC), in sentex.lists.freebsd.net you wrote: Thanks for all who replied to this thread, indicating that a bad cable was likely the culprit. In this case, changing the cable didn't help, but commenting out the ifconfig_rl0='up' line in /etc/rc.conf fixed the problem. Any ideas on why doing an 'ifconfig rl0 up' before starting PPP (using set device PPPoE:rl0) would cause this problem? (These machines are running 4.3-REL-p20) Not sure why. But, I have noticed that many of the realtek cards do not detect their speed / media type properly. On my DSL connection, I need to do ifconfig rl0 media 10baseT/UTP. Try in your /etc/rc.conf instead of just ifconfig_rl0='up' try ifconfig_rl0='media 10baseT/UTP up' Without doing this, ifconfig rl0 shows a media type of none and the connection does not function properly. ---Mike Mike Tancsa ([EMAIL PROTECTED]) Sentex Communications Corp, Waterloo, Ontario, Canada Given enough time, 100 monkeys on 100 routers could setup a national IP network. (KDW2) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: expiring cached routes on in_pcb entries.
On Wed, 21 Nov 2001, Ian West wrote: Hi, I have been looking at the code in ip_ouput in relation to a problem I have had with named using the wrong route for talking to forwarders after route changes occur. There is a check for cached routes, and a check for validity, but not as far as I can see a check for expiry. What revision of the code are you looking at? Some related behavior was changed relatively recently. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: expiring cached routes on in_pcb entries.
On Wed, 21 Nov 2001, Ian West wrote: I have seen the problem occur on two different machines, one is running code 4.3-STABLE FreeBSD 4.3-STABLE #0: Thu May 10 15:13:04 CST 2001 the other is 4.3-STABLE FreeBSD 4.3-STABLE #0: Mon May 28 16:10:27 CST 2001 Both machines showed named requests taking the wrong route. Both recovered by restarting named. The code I am actually looking at is the source on a 4.4 stable box. I will see if I can duplicate the problem with 4.4 stable. Are the recent changes a fix for this type of behaviour, or something that may have introduced it ? Hm, good question. I was going to suggest that rev 1.59.2.2 would fix your problem, but apparently it only fixes the problem with routes going away, not routes appearing. You're probably best contacting Ruslan ([EMAIL PROTECTED]) directly; he's been the one doing the work in that file, and could probably tell you if his more recent commits address your problem. As for the expiration of cloned routes: They're only timed out by a kernel process which runs minimally once every 10 minutes (more often under heavy route load.) This would explain why they're persisting longer than you expect them to. I wouldn't worry about the longer than expected expiration though; expiration of cloned routes isn't the issue here; the routing code should be invalidating the existing cloned routes when the new route appears. (Apparently this is not happening in your situation.) Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: t_dupacks to u_int?
On Sat, 17 Nov 2001, Alfred Perlstein wrote: Any problems with this? -static int tcprexmtthresh = 3; +static unsigned int tcprexmtthresh = 3; +SYSCTL_UINT(_net_inet_tcp, OID_AUTO, rexmtthresh, CTLFLAG_RW, +tcprexmtthresh, 0, Max duplicate acks before fast rexmit); + tcp_cc tcp_ccgen; While this may be useful for those doing testing, I'm wondering if such a sysctl should be implemented. I have this bad feeling about net.inet.tcp.tcprexmtthresh=1 being added to the bogus pile of sysctls that should be changed which is sent to every person who asks how to tune their system. (Just look back through mailing list archives to see how man tweaks people are making that shouldn't be made.) Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Intel nics (fxp, wx, gx) questions
On Sat, 10 Nov 2001 20:52:09 + (UTC), in sentex.lists.freebsd.net you wrote: Kyunghwan Kim wrote: Some questions related to intel nic drivers: 1. fxp microcode Marko has summited fxp interrupt bundling patch before. Is there any reference to write fxp microcode? No that I am aware of, as I just used the microcode supplied with Intel's Linux driver in binary form. After conducting a few TCP throughput tests with interrupt coalescing microcode, I found that depending of the specific environment, quite serious TCP perfomance degradation can follow as a result of additional delay Hi, Can you give some more details as to where this introduces performance problems, and if so, how is the best way to work around it? ---Mike Mike Tancsa ([EMAIL PROTECTED]) Sentex Communications Corp, Waterloo, Ontario, Canada Given enough time, 100 monkeys on 100 routers could setup a national IP network. (KDW2) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
SBEI wanADAPT drivers in BSD
Hi, According to this link at the SBE website ( http://www.sbei.net/linux_bsd.htm# http://www.sbei.net/linux_bsd.htm# ), OpenBSD v2.9 and NetBSD v1.6 now include SBEI drivers. I'm curious why FreeBSD isn't included. Is it simply an oversight or is there a reason (e.g. driver doesn't work on FreeBSD) Thanks, MikeC To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: your mail
On Tue, 30 Oct 2001, veedee wrote: [#] netstat -m 309/1232/6144 mbufs in use (current/peak/max): 194 mbufs allocated to data 115 mbufs allocated to packet headers 170/352/1536 mbuf clusters in use (current/peak/max) 1012 Kbytes allocated to network (21% of mb_map in use) ... what would be an appropriate value? I'm running FreeBSD 4.3 on this box and I have about 400 workstations on my neck. Thanks in advance, Radu Bogdan Rusu (aka veedee) C7 Campus Network System Administrator There's no exact science, but the tuning manpage seems to give a pretty good formula to calculate what you could use. It'd be easier to just pick an abritrary number like 6000, though. :) And if the problem does happen again, run a netstat -n to see if you can see a pattern to buffer usage; there is a DoS called netkill which can be used to suck up all network buffers and cause the problem you're seeing. If it's being used, you'll see that one IP is eating up all the buffers. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: NEW CODE: polling support for device drivers.
On Sat, 27 Oct 2001, Alfred Perlstein wrote: Is it possible to implement all the basic packet forwarding to run to completion at interrupt, ie, when a packet comes in, the interrupt code would run until the packet has been sent out on another interface, and then loop back to see if there's more incomming packets, in a polling fashion. That would give the advantage of the polling, but without the latency. I'm mostly a hardware guy, so bear over with me if it's not possible at all Actually your idea is sort of what Terry Lambert posted about a couple of weeks ago. I have no idea what happened in the end, the flameage went on and on and I lost interest. Can anyone summarize for the benefit of the list? -- -Alfred Perlstein [[EMAIL PROTECTED]] Summary: The patch Terry posted was to loop a few more times in the interrupt handler. I was going to commit it this weekend for the dc driver, but it looks like Luigi's work overshadows that. The idea proposed above is (similar to) LRP, which Terry implemented for clickarray. It is not in his patchset. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: fxp patch - bundling receive interrupts
On Wed, 24 Oct 2001, Marko Zec wrote: An updated fxp driver patch for bundling receive interrupts, thus saving a noticeable amount of CPU overhead for interrupt processing, can be found at http://www.tel.fer.hr/zec/BSD/fxp/. New features include: I haven't reviewed the code and don't have a fxp near, but your patch sounds impressive. I'm sure we'd all be proud of its inclusion in -stable once enough testing has been performed. That being said, I thought I should check on one thing: In your original post, you mentioned that these techniques came from the linux drive for these cards. In the process of writing this patch, did you copy any section of code from the Linux driver? If possible, it would be best to avoid any GPL entanglements. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: SYN flood and IP spoofing
On Sun, 21 Oct 2001, Fernando Gont wrote: That's an old explanation; basically any OS released in the last few years will throw old/random connections out of the queue when it fills up. Anyway, I wonder how the old implementations behaved, and why they behaved like that. I don't think it's worth worrying about how old implementations behaved at this point in time. They weren't designed for the hostile environment of today's internet, and have long since been replaced by newer stacks with better countermeasures. If you encounter an old system, it's probably better to start upgrading it to a newer version of whatever OS it runs than to analyze it. (I'm assuming that's how Mitnick did it; I'm not aware that he has revealed exactly how he did anything, He didn't do it. It was the owner of the attacked host that revealed it, in a post to comp.security.misc. Maybe I'll look for it some day. In either case, it doesn't matter anymore. We're using strong sequence numbers, and ip-based authentication has many better replacements now. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: SYN flood and IP spoofing
On Sat, 20 Oct 2001, Fernando Gont wrote: Hi! I've read some explanations about the SYN flood DoS attack. I understand that when the attacker fills the listening queue of the attacked host with incomplete connections, the attacked host will not reply to any SYN it receives after that. That's an old explanation; basically any OS released in the last few years will throw old/random connections out of the queue when it fills up. What you actually describe here is more spoofing than a syn flood; a syn flood just involves blasting large numbers of syn packets at someone, with no intent of actually spoofing a connection. When Mitnick / anyone else did spoofing, it was through weaknesses in the algorithm used to generate initial sequence numbers, not through simple brute force. (I'm assuming that's how Mitnick did it; I'm not aware that he has revealed exactly how he did anything, and I doubt I'd trust him even if he did explain.) However, I don't understand why it will not even reply with an RST when it receives a SYN-ACK from other machine. In the general case of spoofing, you could ensure that a syn-ack does not elicit a rst by spoofing the IP of a nonexistant host. I've also read that older tcp stacks could be caused to stop emitting packets by filling their SYN queue; I'm not sure when that stopped applying. These days, spoofing really isn't a concern; those looking to find a way into a system wouldn't gain anything by spoofing and would instead look for a buffer overflow to exploit. Syn floods are alive and well, though. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: fxp driver - receive interrupt bundling
At 03:16 AM 10/20/2001 +0200, Marko Zec wrote: It doesn't matter how many fxp cards you have installed - if your box acts as a server than most probably you can leave INT_DELAY at default value (Intel proposes 0x600, but I think 0x400 would be more appropriate). If you use your multi-fxp-card BSD box as a router, than the microcode will impose additional delay *twice* (once in each direction), so in that case the default value of 0x600 might be too high for achieving full 100 megE throughput, because of TCP windowing scheme having to wait for ACK frames, which will be held in fxp receive buffers too long. On the other hand, setting INT_DELAY too low minimizes the benefits of bundling interrupts, as fewer received frames get bundled on a single interrupt. To summarize: if you are doing any routing (or bridging as I do), find the best value for INT_DELAY for your specific environment experimentally, it should be definitely smaller than or equal to 0x400. If you don't do packet forwarding between fxp interfaces, use the defaults. Thanks! This is for a router pushing upwards of 20Mb/s with about 110K routes on 4 interfaces. I will try and experiment a bit on my test setup first to see what works best. ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: strange results with increased net.inet.ip.intr_queue_maxlen (solved)
On Mon, 15 Oct 2001 23:00:27 + (UTC), in sentex.lists.freebsd.net you wrote: Mike Tancsa writes: If the forwarding path is maxed out, then it is the application layer's responsibility to back off (think TCP). Is it better for the networking layer to deal with this (potentially introducing some latency) as opposed to letting the application ? Oops, can substitute transport for application.. But no, the network should just do best effort.. that is, unless you are a telco type in which case, go back to your X.25 :-) This is a religious issue to some degree, but in practice the war is over and the Internet won (vs. the telco way of doing things). There is probably a good paper somewhere outlining the best effort philosophy but I don't know what it is. Another way to look at it is intelligence in the leaf nodes rather than in the network. This is one of the central idea of the Internet dating back to a long time ago. I guess the other big idea is packets instead of dedicated circuits (which hog resources). Thanks for the info. Lugi Rizzo was kind enough to figure out what has been going on. I increased the queue size to 512 on both my OC-3 equipped machine (via the en device) as well as my pure FastE (via fxp) machines and the problems have gone away. As to why this solved the problem Lugi wrote, -- oh, did you see drops go to 0 when the queue size is 256 ? I missed this. Then it means another thing, you are receiving a very large burst of packet from the interface, larger than ipintrq, and this is why they get dropped. In fact, processing is done like this: in the interrupt driver, while you have packets you fetch them from the device and queue them in ipintrq. Once you are done with this (which could take very long and drain a lot of packets if either packets come in very fast, or the device queue is long and interrupts come late), you go up and process packets in ipintrq. Now, I am not 100% sure but the en device seems to have 512 slots in the receive queue, hence the problem... Normally, using fastforwarding would help because bypasses ipintrq and calls directly ip_input(), except that en calls atm_intr() which does not know anything about fastforwarding. I think the above should explain the problem, and then you can probably either set ipq_maxlen to a large enough value (like 512) or slightly modify the en driver to limit the burst of packets it produces to some more reasonable amount. Not my area though, you should contact the author of the device driver to see if this is possible. - ---Mike Mike Tancsa ([EMAIL PROTECTED]) Sentex Communications Corp, Waterloo, Ontario, Canada Given enough time, 100 monkeys on 100 routers could setup a national IP network. (KDW2) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: strange results with increased net.inet.ip.intr_queue_maxlen (solved)
At 08:44 PM 10/15/2001 -0700, Archie Cobbs wrote: This makes sense.. and that's is exactly what queues are for: absorbing bursts. If you have big bursts then you'll need big queues.. in general this is the only reason to have them. The only mystery I didnt solve in the end was what was generating the bursts. The only commonality is that The machines in question are all running bgpd and zebra with a full view in the kernel. The bursts would happen once every 10min. But I am not aware of any timers that would run at that long an interval. I think I will ask over on the zebra list to see if this interval rings a bell with anyone. ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: strange results with increased net.inet.ip.intr_queue_maxlen
At 06:30 PM 10/11/01 -0700, Luigi Rizzo wrote: from pinging the other side of the OC-3 or ethernet connection and measuring the response time, how can I see how much latency is added by increasing these buffers ? of course the latency increase depends on how full are the buffers, and the worst case is easier to determine by back-of-the-envelope calculations: queue_slots * max_pkt_size / bottleneck_link_speed e.g. if you have 100 slots and an MSS of 1500 and a 10Mbit bottleneck you are adding (100*1500*8 / 1000) = 120ms latency. Interesting! In my case, one of the machines is oc-3 and ther other, FastE. I guess now it becomes a choice of what is the best choice for my situation which I guess is not so easy to figure out. Is it better to drop packets when the queue is full and let the various applications behind me figure it out, or is it better to add some latency at the network layer so the apps dont have to deal with it. Forgive me if my questions are simplistic, I am just trying to get as much info to make a more informed decision as how to best configure my network given the resources I have. ---Mike To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: strange results with increased net.inet.ip.intr_queue_maxlen
At 11:42 AM 10/12/01 -0700, Luigi Rizzo wrote: If you find yourself hitting the queue limit I'd suggest using RED or GRED with ipfw to drop packets more intelligently before the hard limit we are talking about a different queue here, which is not managed by ipfw (now you are actually giving me an idea on adding this feature...) Speaking about ipfw, am I better off performance wise going to ipfilter ? Or do you think ipfw is more efficient ? Also, I am going to swap in an athlon 1.4G with DDR RAM in place of the celeron 866. I am curious to see how just changing the hardware will effect the rate of packet drops. If it is resource related I should see a difference. ---Mike To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: strange results with increased net.inet.ip.intr_queue_maxlen
At 06:16 PM 10/11/01 -0700, Archie Cobbs wrote: If the forwarding path is maxed out, then it is the application layer's responsibility to back off (think TCP). Is it better for the networking layer to deal with this (potentially introducing some latency) as opposed to letting the application ? Pinging is an excellent way to determine latency. I guess then its only at the worst case where I would see the added latency as I dont see any difference by adjusting the queue size. ---Mike To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
