From pyunyh at gmail.com Sun Jun 1 07:48:41 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Sun Jun 1 07:48:46 2008 Subject: Intel embedded NICs not working with FreeBSD 6.2, 6.3 and 7.0 In-Reply-To: References: <20080528003526.GB63696@cdnetworks.co.kr> Message-ID: <20080601074832.GA80963@cdnetworks.co.kr> On Sat, May 31, 2008 at 01:40:47PM +0200, Fuchs, Martin wrote: > Ok, back again... sorry for letting you wait so long, but i had a lot to do... > > Since there's no possibility to copy via putty i'm copying by hand... hopefully there are not too many errors :-) > > ----- > pciconf -lcv > > ... > fxp0@pci0:1:4:0: class=0x020000 card=0x00708086 chip=0x12298086 rev=x010 > hdr=0x00 > class = network > subclass = ethernet > cap01[dc] = powerspec 2 supports D0 D1 D2 D3 current D0 > > fxp1@pci0:1:5:0: class=0x020000 card=0x00708086 chip=0x12298086 rev=x010 > hdr=0x00 > class = network > subclass = ethernet > cap01[dc] = powerspec 2 supports D0 D1 D2 D3 current D0 > > fxp2@pci0:1:8:0: class=0x020000 card=0x30118086 chip=0x103a8086 rev=x010 > hdr=0x00 > class = network > subclass = ethernet > cap01[dc] = powerspec 2 supports D0 D1 D2 D3 current D0 > It looks like fxp0/fxp1 is 82551 Pro and fxp2 is 82801 DB(ICH4). > ----- > dmesg shows for example: > > fxp0: link state changed to down > fxp1: link state changed to down > fxp2: link state changed to down > fxp1: link state changed to up <- when I attach a network cable to a switch That's normal. All ethernet drivers should detect link up event. > > ----- > devinfo does not work... does not find the command (it's the freebsd under pfSense) > Hmm, I don't know layout of pfSense but I guess it's not good idea to remove such a small/good program. > ----- > vmstat -i > > interrupt total rate > irq0: clk 1348688 999 > irq5: ehci0 9043 6 > irq8: rtc 172621 127 > irq10: fxp1 91 0 > irq12: fxp0 86 0 > irq14: uhci0 ata0 792 0 > irq15: ata1 2738 2 > Total 1534059 1137 > > ----- > > Hope you can use this information ? > This looks odd, where is fxp2? Therere is no '+' mark in vmstat output so I think there should be at least an entry for fxp2. Because you have two differnet kinds of NICs would you let me know which one is not working? Also full dmesg output would be helpful, I guess. -- Regards, Pyun YongHyeon From imp at bsdimp.com Sun Jun 1 18:25:33 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Sun Jun 1 18:25:37 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled In-Reply-To: <20080526162427.X26343@fledge.watson.org> References: <5D4AF8D7-88A7-4197-A0FE-7CA992EE5F96@FreeBSD.org> <483AD498.6070207@FreeBSD.org> <20080526162427.X26343@fledge.watson.org> Message-ID: <20080601.122524.114765121.imp@bsdimp.com> In message: <20080526162427.X26343@fledge.watson.org> Robert Watson writes: : : On Mon, 26 May 2008, Bruce M. Simpson wrote: : : >> Given that this is (a) 2008 and (b) 8.x we're talking about, are there : >> really that many consumers of SLIP to warrant it being carried forward at : >> all? : > : > It's kind of a basic. [C]SLIP has been historically handy to have around for : > situations which warrant it. Mind you, given that we have had tun(4) in the : > tree for years now, a userland implementation of SLIP is possible. : > : > As with all of these things it's down to someone sitting down and doing it. : > : > I'm not volunteering to support any of this as I don't use it myself (got : > enough on my plate), merely pointing out that support for SLIP in a system : > is something many people have taken for granted over the years, and for : > prototyping something or providing IP over a simple serial link without the : > configuration overhead of PPP, SLIP is something someone might be using. : > : > P.S. ahc(4) is commodity hardware, I think it can stay right where it is : > thank-you. : : My suspicion is that getting SLIP basically working in userspace is fairly : straight forward, SLiRP and friends have been doing this for years. I made my living for about a year working on TIA, which was a portable, userland implementation of PPP and SLIP/CSLIP. This was in about 1995 or so. It isn't that hard... : SLIP has its subtleties, but the current implementation is relatively : straight-forward, well-documented, etc. Yes, especially CSLIP. But frankly, they are a whole lot easier than PPP to get up and going... Warner From imp at bsdimp.com Sun Jun 1 18:34:45 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Sun Jun 1 18:34:49 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled In-Reply-To: <483C2666.7010608@FreeBSD.org> References: <45633.1211870269@critter.freebsd.dk> <20080527064253.GG64397@hoeg.nl> <483C2666.7010608@FreeBSD.org> Message-ID: <20080601.123351.-950433793.imp@bsdimp.com> In message: <483C2666.7010608@FreeBSD.org> "Bruce M. Simpson" writes: : Other than that, line disciplines can go away. In the past I've uesd line disciplines to implement a keyboard driver for the Apple Newton Keyboard (serial protocol) so I could use it at any point after the loader (the system didn't run X11, so I couldn't use the X11 driver I wrote there). This system has been retired, and I don't think I ever forward ported them past about 3.mumble, if even that far. This code is badly decayed, and I have no requirement that it continues to work. But I know similar techniques are used in some embedded systems. Expect some delayed complaining if they go away entirely. But that may be OK given we're ridding tty of Giant. Now, if we could only sort out the syscons/keyboard/mouse mess... Warner From phk at phk.freebsd.dk Sun Jun 1 21:01:25 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sun Jun 1 21:01:33 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled In-Reply-To: Your message of "Sun, 01 Jun 2008 12:33:51 CST." <20080601.123351.-950433793.imp@bsdimp.com> Message-ID: <2204.1212354080@critter.freebsd.dk> In message <20080601.123351.-950433793.imp@bsdimp.com>, "M. Warner Losh" writes : >In the past I've uesd line disciplines to implement a keyboard driver >for the Apple Newton Keyboard (serial protocol) [...] But shouldn't you have used uart(4) for that ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From bilouro at bilouro.com Mon Jun 2 01:51:09 2008 From: bilouro at bilouro.com (Victor Hugo Bilouro) Date: Mon Jun 2 01:51:12 2008 Subject: establish connection without tcp options In-Reply-To: <48430A59.5090604@freebsd.org> References: <483E62D9.8000308@freebsd.org> <4842814C.3000508@freebsd.org> <48430A59.5090604@freebsd.org> Message-ID: On Sun, Jun 1, 2008 at 5:45 PM, Andre Oppermann wrote: > Victor Hugo Bilouro wrote: >> >> On Sun, Jun 1, 2008 at 8:00 AM, Andre Oppermann wrote: >>> >>> Victor Hugo Bilouro wrote: >>>> >>>> On Thu, May 29, 2008 at 5:01 AM, Andre Oppermann >>>> wrote: >>>>> >>>>> Victor Hugo Bilouro wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> I'm working into establish manually a tcp connection. >>>>>> >>>>>> Does anyone knows if freebsd 7.0 stable agree, a connection >>>>>> establishment without TCP options set? >>>>> >>>>> Yes, certainly it does. If you send a SYN w/o any options it >>>>> won't use any. If you establish a connection from FreeBSD you >>>>> may ignore any options in SYN and in your SYN-ACK not send any. >>>>> If you want FreeBSD not to send any options you can set the >>>>> socket option TCP_NOOPT before you do the connect. >>>>> >>>>> -- >>>>> Andre >>>>> >>>> Hello, >>>> >>>> First thanks Andre! >>>> >>>> So, as I told before, I'm trying to connect manually, but, something >>>> wrong is occurring, after accomplish 3way-handshake, the server >>>> (passive open) is sending a RESET. >>>> You can see by tcpdump dump, that everything is OK. >>>> >>>> tcpdump -ied0 -S -vv tcp >>>> >>>> 08:58:21.302052 IP (tos 0x0, ttl 64, id 55136, offset 0, flags [none], >>>> proto TCP (6), length 40) 192.168.1.10.53639 > 192.168.1.20.22022: S, >>>> cksum 0x2a4d (correct), 3204258715:3204258715(0) win 65535 >>>> >>>> 08:58:21.302125 IP (tos 0x0, ttl 64, id 411, offset 0, flags [DF], >>>> proto TCP (6), length 44) 192.168.1.20.22022 > 192.168.1.10.53639: S, >>>> cksum 0xba99 (correct), 400703492:400703492(0) ack 3204258716 win >>>> 65535 >>>> >>>> 08:58:21.697561 IP (tos 0x0, ttl 64, id 55137, offset 0, flags [none], >>>> proto TCP (6), length 40) 192.168.1.10.53639 > 192.168.1.20.22022: ., >>>> cksum 0xacf0 (correct), 0:0(0) ack 400703493 win 65535 >>>> >>>> 08:58:21.697632 IP (tos 0x0, ttl 64, id 412, offset 0, flags [DF], >>>> proto TCP (6), length 40) 192.168.1.20.22022 > 192.168.1.10.53639: R, >>>> cksum 0xacfc (correct), 400703493:400703493(0) win 0 >>>> >>>> >>>> Any suggestions? >>> >>> Enable net.inet.tcp.log_debug=1 and watch the log output. It will >>> tell you where it stumbled. >>> >>> -- >>> Andre >>> >>>> BTW, I'm GSoC student, doing TCP/IP Regression Test Suite. >>>> This code at bilouro_tcptest client at perfoce. >>>> (//depot/projects/soc2008/bilouro_tcptest/) >>>> This script: >>>> //depot/projects/soc2008/bilouro_tcptest/src/scripts/tcpconnect.py >>>> >>>> Best >>> >> >> cool I didn't know this... >> >> I'm seeing /var/log/debug.log and actually something is wrong.... >> >> syn--------------------------------- >> sport 56054 >> dport 22022 >> sequence 2992965889 >> ack_number 0 >> offset 5 >> reserved 0 >> urgent 0 >> ack 0 >> push 0 >> reset 0 >> syn 1 >> fin 0 >> window 65535 >> checksum 16400 >> urg_pointer 0 >> --------------------------------- >> >> syn+ack----------------------------- >> sport 22022 >> dport 56054 >> sequence 2079194755 >> ack_number 2992965890 >> offset 6 >> reserved 0 >> urgent 0 >> ack 1 >> push 2 >> reset 4 >> syn 9 >> fin 0 >> window 65535 >> checksum 44497 >> urg_pointer 0 >> --------------------------------- >> >> ack--------------------------------- >> sport 56054 >> dport 22022 >> sequence 0 > > ^^^^^^^^^^^^^ should be 2992965890 > >> ack_number 2079194756 >> offset 5 >> reserved 0 >> urgent 0 >> ack 1 >> push 0 >> reset 0 >> syn 0 >> fin 0 >> window 65535 >> checksum 33014 >> urg_pointer 0 >> --------------------------------- >> >> /var/log/debug.log: >> TCP [192.168.1.10]:56054 to [192.168.1.20]:22022 tcpflags 0x10; >> syncache_expand: SEQ 0 != IRS+1 2992965889, segment rejected. > > The sequence number of your segment is neither the previous value > not is incremented by one to account for the SYN. > >> Even though I know in step #3 of 3way-handshake I don't need pass the >> sequence, I sent a sequence... > > You do have to pass the sequence number at any time. And it has > to be correct all the time. > >> syn--------------------------------- >> sport 59966 >> dport 22022 >> sequence 874312230 >> ack_number 0 >> offset 5 >> reserved 0 >> urgent 0 >> ack 0 >> push 0 >> reset 0 >> syn 1 >> fin 0 >> window 65535 >> checksum 50667 >> urg_pointer 0 >> >> --------------------------------- >> >> syn+ack----------------------------- >> sport 22022 >> dport 59966 >> sequence 2755934977 >> ack_number 874312231 >> offset 6 >> reserved 0 >> urgent 0 >> ack 1 >> push 2 >> reset 4 >> syn 9 >> fin 0 >> window 65535 >> checksum 52952 >> urg_pointer 0 >> >> --------------------------------- >> >> ack--------------------------------- >> sport 59966 >> dport 22022 >> sequence 874312230 > > ^^^^^^^^^^^^^^ increment by one for SYN you sent. > See also the ACK you got back above. > >> ack_number 2755934978 >> offset 5 >> reserved 0 >> urgent 0 >> ack 1 >> push 0 >> reset 0 >> syn 0 >> fin 0 >> window 65535 >> checksum 59030 >> urg_pointer 0 >> --------------------------------- >> >> ...and the log showed: >> TCP [192.168.1.10]:59966 to [192.168.1.20]:22022 tcpflags 0x10; >> syncache_expand: SEQ 874312230 != IRS+1 874312230, segment rejected. >> >> I'm still working... > > You should familiarize yourself some more with the sequence number > system TCP uses. The Stevens books "TCP/IP Illustrated" Volume 1+2 > are very good for that. > > -- > Andre > PS.: I forgot to copy the list in the previous email exchanging, so I'm doing now.... Andre, thank you SO VERY MUCH. It's working fine! As every book show tcpdump examples of connection establishment , and when the SYN flag is 0(as step #3 of three way handshake), sequence number(SN) are omitted of dump, BUT, it's present. The thing is, the SN is present but it isn't consumed. So, packets that don't consumes the SN, must have the last consumed SN + 1. Only for curiosity, linux and windows 2k accomplished without problems the three way handshake without Sequence Number filled on step #3. More one time, thanks! -- Victor Hugo Bilouro FreeBSD! From andre at freebsd.org Mon Jun 2 07:49:42 2008 From: andre at freebsd.org (Andre Oppermann) Date: Mon Jun 2 07:49:45 2008 Subject: establish connection without tcp options In-Reply-To: References: <483E62D9.8000308@freebsd.org> <4842814C.3000508@freebsd.org> <48430A59.5090604@freebsd.org> Message-ID: <4843A615.90809@freebsd.org> Victor Hugo Bilouro wrote: > On Sun, Jun 1, 2008 at 5:45 PM, Andre Oppermann wrote: >> Victor Hugo Bilouro wrote: >>> syn--------------------------------- >>> sport 59966 >>> dport 22022 >>> sequence 874312230 >>> ack_number 0 >>> offset 5 >>> reserved 0 >>> urgent 0 >>> ack 0 >>> push 0 >>> reset 0 >>> syn 1 >>> fin 0 >>> window 65535 >>> checksum 50667 >>> urg_pointer 0 >>> >>> --------------------------------- >>> >>> syn+ack----------------------------- >>> sport 22022 >>> dport 59966 >>> sequence 2755934977 >>> ack_number 874312231 >>> offset 6 >>> reserved 0 >>> urgent 0 >>> ack 1 >>> push 2 >>> reset 4 >>> syn 9 >>> fin 0 >>> window 65535 >>> checksum 52952 >>> urg_pointer 0 >>> >>> --------------------------------- >>> >>> ack--------------------------------- >>> sport 59966 >>> dport 22022 >>> sequence 874312230 >> ^^^^^^^^^^^^^^ increment by one for SYN you sent. >> See also the ACK you got back above. >> >>> ack_number 2755934978 >>> offset 5 >>> reserved 0 >>> urgent 0 >>> ack 1 >>> push 0 >>> reset 0 >>> syn 0 >>> fin 0 >>> window 65535 >>> checksum 59030 >>> urg_pointer 0 >>> --------------------------------- >>> >>> ...and the log showed: >>> TCP [192.168.1.10]:59966 to [192.168.1.20]:22022 tcpflags 0x10; >>> syncache_expand: SEQ 874312230 != IRS+1 874312230, segment rejected. >>> >>> I'm still working... >> You should familiarize yourself some more with the sequence number >> system TCP uses. The Stevens books "TCP/IP Illustrated" Volume 1+2 >> are very good for that. >> >> -- >> Andre >> > > PS.: I forgot to copy the list in the previous email exchanging, so > I'm doing now.... > > > Andre, thank you SO VERY MUCH. It's working fine! > > As every book show tcpdump examples of connection establishment , and > when the SYN flag is 0(as step #3 of three way handshake), sequence > number(SN) are omitted of dump, BUT, it's present. You should use the "-S" option to tcpdump. It will show absolute sequence number instead of relative ones (as guessed by tcpdump). > The thing is, the SN is present but it isn't consumed. So, packets > that don't consumes the SN, must have the last consumed SN + 1. > > Only for curiosity, linux and windows 2k accomplished without > problems the three way handshake without Sequence Number filled on > step #3. I have a hard time believing that. At most they may have sent you a retransmit or a challenge-ACK. -- Andre From bilouro at gmail.com Mon Jun 2 09:58:07 2008 From: bilouro at gmail.com (Victor Hugo Bilouro) Date: Mon Jun 2 09:58:11 2008 Subject: [GSoC - tcptest] Weekly Status Report Message-ID: Hi, I posted the tcptest** weekly status report at freebsd wiki. Links: http://wiki.freebsd.org/VictorBilouro/TCP-IP_regression_test_suite http://wiki.freebsd.org/VictorBilouro/Following_tcptest http://wiki.freebsd.org/VictorBilouro/Release_0.1_Iteration_1 Thank you! cheers -- Victor Hugo Bilouro FreeBSD! **tcptest** --> tcptest is a GSoC (Google Summer of Code) project, it's a TCP/IP Regression Test Suite implementation. As a testing tool, it can perform regression, protocol conformance, and fuzz tests. The tool may also be employed as an aid to protocol developers and both testing and debugging of firewalls/routers. It's was built on top of pcs.sf.net of gnn at freebsd. ps: I will keep the nomenclature used at subject. From bilouro at bilouro.com Mon Jun 2 10:36:54 2008 From: bilouro at bilouro.com (Victor Hugo Bilouro) Date: Mon Jun 2 10:36:58 2008 Subject: establish connection without tcp options In-Reply-To: <4843A615.90809@freebsd.org> References: <483E62D9.8000308@freebsd.org> <4842814C.3000508@freebsd.org> <48430A59.5090604@freebsd.org> <4843A615.90809@freebsd.org> Message-ID: On Mon, Jun 2, 2008 at 4:49 AM, Andre Oppermann wrote: > Victor Hugo Bilouro wrote: >> >> On Sun, Jun 1, 2008 at 5:45 PM, Andre Oppermann wrote: >>> >>> Victor Hugo Bilouro wrote: >>>> >>>> syn--------------------------------- >>>> sport 59966 >>>> dport 22022 >>>> sequence 874312230 >>>> ack_number 0 >>>> offset 5 >>>> reserved 0 >>>> urgent 0 >>>> ack 0 >>>> push 0 >>>> reset 0 >>>> syn 1 >>>> fin 0 >>>> window 65535 >>>> checksum 50667 >>>> urg_pointer 0 >>>> >>>> --------------------------------- >>>> >>>> syn+ack----------------------------- >>>> sport 22022 >>>> dport 59966 >>>> sequence 2755934977 >>>> ack_number 874312231 >>>> offset 6 >>>> reserved 0 >>>> urgent 0 >>>> ack 1 >>>> push 2 >>>> reset 4 >>>> syn 9 >>>> fin 0 >>>> window 65535 >>>> checksum 52952 >>>> urg_pointer 0 >>>> >>>> --------------------------------- >>>> >>>> ack--------------------------------- >>>> sport 59966 >>>> dport 22022 >>>> sequence 874312230 >>> >>> ^^^^^^^^^^^^^^ increment by one for SYN you sent. >>> See also the ACK you got back above. >>> >>>> ack_number 2755934978 >>>> offset 5 >>>> reserved 0 >>>> urgent 0 >>>> ack 1 >>>> push 0 >>>> reset 0 >>>> syn 0 >>>> fin 0 >>>> window 65535 >>>> checksum 59030 >>>> urg_pointer 0 >>>> --------------------------------- >>>> >>>> ...and the log showed: >>>> TCP [192.168.1.10]:59966 to [192.168.1.20]:22022 tcpflags 0x10; >>>> syncache_expand: SEQ 874312230 != IRS+1 874312230, segment rejected. >>>> >>>> I'm still working... >>> >>> You should familiarize yourself some more with the sequence number >>> system TCP uses. The Stevens books "TCP/IP Illustrated" Volume 1+2 >>> are very good for that. >>> >>> -- >>> Andre >>> >> >> PS.: I forgot to copy the list in the previous email exchanging, so >> I'm doing now.... >> >> >> Andre, thank you SO VERY MUCH. It's working fine! >> >> As every book show tcpdump examples of connection establishment , and >> when the SYN flag is 0(as step #3 of three way handshake), sequence >> number(SN) are omitted of dump, BUT, it's present. > > You should use the "-S" option to tcpdump. It will show absolute > sequence number instead of relative ones (as guessed by tcpdump). > >> The thing is, the SN is present but it isn't consumed. So, packets >> that don't consumes the SN, must have the last consumed SN + 1. >> >> Only for curiosity, linux and windows 2k accomplished without >> problems the three way handshake without Sequence Number filled on >> step #3. > > I have a hard time believing that. At most they may have sent you > a retransmit or a challenge-ACK. > > -- > Andre > I will post here the tcpdump and tcptest dumps for both windows and linux with ACK with sequence 0. windows tcpdump: (tcpdump -i ed0 -S tcp) 17:01:46.420016 IP 192.168.1.10.59537 > 192.168.1.101.http: S 770272892:770272892(0) win 65535 17:01:46.421835 IP 192.168.1.101.http > 192.168.1.10.59537: S 1681202755:1681202755(0) ack 770272893 win 64240 17:01:46.834808 IP 192.168.1.10.59537 > 192.168.1.101.http: . ack 1681202756 win 65535 17:01:46.839584 IP 192.168.1.10.59537 > 192.168.1.101.http: F 770272893:770272893(0) ack 1681202756 win 65535 17:01:46.840613 IP 192.168.1.101.http > 192.168.1.10.59537: . ack 770272894 win 64240 17:01:46.840675 IP 192.168.1.101.http > 192.168.1.10.59537: F 1681202756:1681202756(0) ack 770272894 win 64240 17:01:47.297816 IP 192.168.1.10.59537 > 192.168.1.101.http: . ack 1681202757 win 65535 windows dump of tcptest (every packet of connection establishment and finalization) SYN--------------------------------- sport 56121 dport 80 sequence 1046947043 ack_number 0 offset 5 reserved 0 urgent 0 ack 0 push 0 reset 0 syn 1 fin 0 window 65535 checksum 60750 urg_pointer 0 --------------------------------- SYN+ACK--------------------------------- sport 80 dport 56121 sequence 1494256296 ack_number 1046947044 offset 6 reserved 0 urgent 0 ack 1 push 2 reset 4 syn 9 fin 0 window 64240 checksum 63191 urg_pointer 0 --------------------------------- ACK (SYN)--------------------------------- sport 56121 dport 80 sequence 0 ack_number 1494256297 offset 5 reserved 0 urgent 0 ack 1 push 0 reset 0 syn 0 fin 0 window 65535 checksum 27857 urg_pointer 0 --------------------------------- FIN--------------------------------- sport 56121 dport 80 sequence 1046947044 ack_number 1494256297 offset 5 reserved 0 urgent 0 ack 1 push 0 reset 0 syn 0 fin 1 window 65535 checksum 2437 urg_pointer 0 --------------------------------- ACK (FIN)--------------------------------- sport 80 dport 56121 sequence 1494256297 ack_number 1046947045 offset 5 reserved 0 urgent 0 ack 1 push 2 reset 4 syn 8 fin 0 window 64240 checksum 3732 urg_pointer 0 --------------------------------- FIN--------------------------------- sport 80 dport 56121 sequence 1494256297 ack_number 1046947045 offset 5 reserved 0 urgent 0 ack 1 push 2 reset 4 syn 8 fin 1 window 64240 checksum 3731 urg_pointer 0 --------------------------------- ACK (FIN)--------------------------------- sport 56121 dport 80 sequence 1046947045 ack_number 1494256298 offset 5 reserved 0 urgent 0 ack 1 push 0 reset 0 syn 0 fin 0 window 65535 checksum 2436 urg_pointer 0 --------------------------------- linux tcpdump: (tcpdump -i ed0 -S tcp) 17:06:12.493737 IP 192.168.1.10.54458 > hm389.locaweb.com.br.http: S 501941873:501941873(0) win 65535 17:06:12.934559 IP hm389.locaweb.com.br.http > 192.168.1.10.54458: S 1436097196:1436097196(0) ack 501941874 win 5840 17:06:13.313919 IP 192.168.1.10.54458 > hm389.locaweb.com.br.http: . ack 1436097197 win 65535 17:06:13.320533 IP 192.168.1.10.54458 > hm389.locaweb.com.br.http: F 501941874:501941874(0) ack 1436097197 win 65535 17:06:13.331289 IP hm389.locaweb.com.br.http > 192.168.1.10.54458: . ack 501941874 win 5840 17:06:13.337751 IP hm389.locaweb.com.br.http > 192.168.1.10.54458: F 1436097197:1436097197(0) ack 501941875 win 5840 17:06:13.762246 IP 192.168.1.10.54458 > hm389.locaweb.com.br.http: . ack 1436097198 win 65535 linux dump of tcptest (every packet of connection establishment and finalization) SYN--------------------------------- sport 54458 dport 80 sequence 501941873 ack_number 0 offset 5 reserved 0 urgent 0 ack 0 push 0 reset 0 syn 1 fin 0 window 65535 checksum 25507 urg_pointer 0 --------------------------------- SYN+ACK--------------------------------- sport 80 dport 54458 sequence 1436097196 ack_number 501941874 offset 6 reserved 0 urgent 0 ack 1 push 2 reset 4 syn 9 fin 0 window 5840 checksum 50368 urg_pointer 0 --------------------------------- ACK (SYN)--------------------------------- sport 54458 dport 80 sequence 0 ack_number 1436097197 offset 5 reserved 0 urgent 0 ack 1 push 0 reset 0 syn 0 fin 0 window 65535 checksum 6059 urg_pointer 0 --------------------------------- FIN--------------------------------- sport 54458 dport 80 sequence 501941874 ack_number 1436097197 offset 5 reserved 0 urgent 0 ack 1 push 0 reset 0 syn 0 fin 1 window 65535 checksum 62284 urg_pointer 0 --------------------------------- ACK (FIN)--------------------------------- sport 80 dport 54458 sequence 1436097197 ack_number 501941874 offset 5 reserved 0 urgent 0 ack 1 push 2 reset 4 syn 8 fin 0 window 5840 checksum 56445 urg_pointer 0 --------------------------------- FIN--------------------------------- sport 80 dport 54458 sequence 1436097197 ack_number 501941875 offset 5 reserved 0 urgent 0 ack 1 push 2 reset 4 syn 8 fin 1 window 5840 checksum 56443 urg_pointer 0 --------------------------------- ACK (FIN)--------------------------------- sport 54458 dport 80 sequence 501941875 ack_number 1436097198 offset 5 reserved 0 urgent 0 ack 1 push 0 reset 0 syn 0 fin 0 window 65535 checksum 62283 urg_pointer 0 --------------------------------- It was the first test conformance result of tcptest! cheers -- Victor Hugo Bilouro FreeBSD! From bugmaster at FreeBSD.org Mon Jun 2 11:06:57 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 2 11:07:19 2008 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200806021106.m52B6uZF093243@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/92090 net [bge] bge0: watchdog timeout -- resetting f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau f kern/102344 net [ipf] Some packets do not pass through network interfa o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109733 net [bge] bge link state issues [regression] o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116328 net [bge]: Solid hang with bge interface o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117423 net [vlan] Duplicate IP on different interfaces o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119361 net [bge] bge(4) transmit performance problem o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122082 net [in_pcb] NULL pointer dereference in in_pcbdrop o kern/122195 net [ed] Alignment problems in if_ed f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix f kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar f kern/122858 net [nsswitch] nsswitch in 7.0 is f*cked up o kern/122875 net [nfs] "rstatd: Can't get namelist. 1" - fbsd 7.0-stabl o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123330 net [nsswitch] Enabling samba wins in nsswitch.conf causes o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o bin/123465 net [ip6] route(1): route add -inet6 -interfac o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123617 net [tcp] breaking connection when client downloading file o bin/123633 net ifconfig(8) doesn't set inet and ether address in one p kern/123741 net [netgraph] [panic] kernel panic due to netgraph mpd o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123881 net [tcp] Turning on TCP blackholing causes slow localhost o kern/123950 net [tcp] TH_RST packet sended if received out-of-order da o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov 91 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 o kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/95267 net packet drops periodically appear o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/112179 net [sis] [patch] sis driver for natsemi DP83815D autonego o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o bin/117339 net [patch] route(8): loading routing management commands o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/119432 net [arp] route add -host -iface causes arp e f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/121242 net [ate] [patch] Promiscuous mode of if_ate (arm) doesn't o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122068 net [ppp] ppp can not set the correct interface with pptpd o kern/122145 net error while compiling with device ath_rate_amrr o kern/122295 net [bge] bge Ierr rate increase (since 6.0R) [regression] o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122697 net [ath] Atheros card is not well supported o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge f kern/122839 net [multicast] FreeBSD 7 multicast routing problem f kern/122928 net [em] interface watchdog timeouts and stops receiving p o kern/123892 net [tap] [patch] No buffer space available o kern/123961 net [vr] [patch] Allow vr interface to handle vlans o bin/124004 net ifconfig(8): Cannot assign both an IP and a MAC addres 51 problems total. From andre at freebsd.org Mon Jun 2 11:27:36 2008 From: andre at freebsd.org (Andre Oppermann) Date: Mon Jun 2 11:27:45 2008 Subject: establish connection without tcp options In-Reply-To: References: <483E62D9.8000308@freebsd.org> <4842814C.3000508@freebsd.org> <48430A59.5090604@freebsd.org> <4843A615.90809@freebsd.org> Message-ID: <4843D926.8010402@freebsd.org> Victor Hugo Bilouro wrote: > On Mon, Jun 2, 2008 at 4:49 AM, Andre Oppermann wrote: >> Victor Hugo Bilouro wrote: >>> On Sun, Jun 1, 2008 at 5:45 PM, Andre Oppermann wrote: >>>> Victor Hugo Bilouro wrote: >>>>> syn--------------------------------- >>>>> sport 59966 >>>>> dport 22022 >>>>> sequence 874312230 >>>>> ack_number 0 >>>>> offset 5 >>>>> reserved 0 >>>>> urgent 0 >>>>> ack 0 >>>>> push 0 >>>>> reset 0 >>>>> syn 1 >>>>> fin 0 >>>>> window 65535 >>>>> checksum 50667 >>>>> urg_pointer 0 >>>>> >>>>> --------------------------------- >>>>> >>>>> syn+ack----------------------------- >>>>> sport 22022 >>>>> dport 59966 >>>>> sequence 2755934977 >>>>> ack_number 874312231 >>>>> offset 6 >>>>> reserved 0 >>>>> urgent 0 >>>>> ack 1 >>>>> push 2 >>>>> reset 4 >>>>> syn 9 >>>>> fin 0 >>>>> window 65535 >>>>> checksum 52952 >>>>> urg_pointer 0 >>>>> >>>>> --------------------------------- >>>>> >>>>> ack--------------------------------- >>>>> sport 59966 >>>>> dport 22022 >>>>> sequence 874312230 >>>> ^^^^^^^^^^^^^^ increment by one for SYN you sent. >>>> See also the ACK you got back above. >>>> >>>>> ack_number 2755934978 >>>>> offset 5 >>>>> reserved 0 >>>>> urgent 0 >>>>> ack 1 >>>>> push 0 >>>>> reset 0 >>>>> syn 0 >>>>> fin 0 >>>>> window 65535 >>>>> checksum 59030 >>>>> urg_pointer 0 >>>>> --------------------------------- >>>>> >>>>> ...and the log showed: >>>>> TCP [192.168.1.10]:59966 to [192.168.1.20]:22022 tcpflags 0x10; >>>>> syncache_expand: SEQ 874312230 != IRS+1 874312230, segment rejected. >>>>> >>>>> I'm still working... >>>> You should familiarize yourself some more with the sequence number >>>> system TCP uses. The Stevens books "TCP/IP Illustrated" Volume 1+2 >>>> are very good for that. >>>> >>>> -- >>>> Andre >>>> >>> PS.: I forgot to copy the list in the previous email exchanging, so >>> I'm doing now.... >>> >>> >>> Andre, thank you SO VERY MUCH. It's working fine! >>> >>> As every book show tcpdump examples of connection establishment , and >>> when the SYN flag is 0(as step #3 of three way handshake), sequence >>> number(SN) are omitted of dump, BUT, it's present. >> You should use the "-S" option to tcpdump. It will show absolute >> sequence number instead of relative ones (as guessed by tcpdump). >> >>> The thing is, the SN is present but it isn't consumed. So, packets >>> that don't consumes the SN, must have the last consumed SN + 1. >>> >>> Only for curiosity, linux and windows 2k accomplished without >>> problems the three way handshake without Sequence Number filled on >>> step #3. >> I have a hard time believing that. At most they may have sent you >> a retransmit or a challenge-ACK. >> >> -- >> Andre >> > > I will post here the tcpdump and tcptest dumps for both windows and > linux with ACK with sequence 0. > > windows tcpdump: (tcpdump -i ed0 -S tcp) > 17:01:46.420016 IP 192.168.1.10.59537 > 192.168.1.101.http: S > 770272892:770272892(0) win 65535 > 17:01:46.421835 IP 192.168.1.101.http > 192.168.1.10.59537: S > 1681202755:1681202755(0) ack 770272893 win 64240 > 17:01:46.834808 IP 192.168.1.10.59537 > 192.168.1.101.http: . ack > 1681202756 win 65535 > 17:01:46.839584 IP 192.168.1.10.59537 > 192.168.1.101.http: F > 770272893:770272893(0) ack 1681202756 win 65535 > 17:01:46.840613 IP 192.168.1.101.http > 192.168.1.10.59537: . ack > 770272894 win 64240 > 17:01:46.840675 IP 192.168.1.101.http > 192.168.1.10.59537: F > 1681202756:1681202756(0) ack 770272894 win 64240 > 17:01:47.297816 IP 192.168.1.10.59537 > 192.168.1.101.http: . ack > 1681202757 win 65535 That's interesting. I don't see any rationale why that should be acceptable. We enforce the sequence number to be present and valid in the ACK. This hasn't caused any complaints or incompatibilities so far. What version/service-pack of Windows and Linux (kernel) are you testing against? According to RFC793, Section 3.9, Page 69 the first check is actually testing the SEG.SEQ as follows: RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND. RCV.NXT is obviously the SEG.SEQ you sent with your SYN segment. It seems that Windows and Linux are ignoring this test because you didn't send any data with the ACK. Or they are simply ignoring the segment as invalid and your FIN packet (with the correct SEG.SEQ and SEG.ACK) causes the internal state transition. One may discuss which response, none (just ignore segment) or sending a RST (as we do currently) is better. I tend to argue the latter as it makes problems/bugs much more evident as we've witnessed with your test. -- Andre > windows dump of tcptest (every packet of connection establishment and > finalization) > SYN--------------------------------- > sport 56121 > dport 80 > sequence 1046947043 > ack_number 0 > offset 5 > reserved 0 > urgent 0 > ack 0 > push 0 > reset 0 > syn 1 > fin 0 > window 65535 > checksum 60750 > urg_pointer 0 > > --------------------------------- > > SYN+ACK--------------------------------- > sport 80 > dport 56121 > sequence 1494256296 > ack_number 1046947044 > offset 6 > reserved 0 > urgent 0 > ack 1 > push 2 > reset 4 > syn 9 > fin 0 > window 64240 > checksum 63191 > urg_pointer 0 > > --------------------------------- > > ACK (SYN)--------------------------------- > sport 56121 > dport 80 > sequence 0 > ack_number 1494256297 > offset 5 > reserved 0 > urgent 0 > ack 1 > push 0 > reset 0 > syn 0 > fin 0 > window 65535 > checksum 27857 > urg_pointer 0 > > --------------------------------- > > FIN--------------------------------- > sport 56121 > dport 80 > sequence 1046947044 > ack_number 1494256297 > offset 5 > reserved 0 > urgent 0 > ack 1 > push 0 > reset 0 > syn 0 > fin 1 > window 65535 > checksum 2437 > urg_pointer 0 > > --------------------------------- > > ACK (FIN)--------------------------------- > sport 80 > dport 56121 > sequence 1494256297 > ack_number 1046947045 > offset 5 > reserved 0 > urgent 0 > ack 1 > push 2 > reset 4 > syn 8 > fin 0 > window 64240 > checksum 3732 > urg_pointer 0 > > --------------------------------- > > FIN--------------------------------- > sport 80 > dport 56121 > sequence 1494256297 > ack_number 1046947045 > offset 5 > reserved 0 > urgent 0 > ack 1 > push 2 > reset 4 > syn 8 > fin 1 > window 64240 > checksum 3731 > urg_pointer 0 > > --------------------------------- > > ACK (FIN)--------------------------------- > sport 56121 > dport 80 > sequence 1046947045 > ack_number 1494256298 > offset 5 > reserved 0 > urgent 0 > ack 1 > push 0 > reset 0 > syn 0 > fin 0 > window 65535 > checksum 2436 > urg_pointer 0 > > --------------------------------- > > > > > > > > > linux tcpdump: (tcpdump -i ed0 -S tcp) > 17:06:12.493737 IP 192.168.1.10.54458 > hm389.locaweb.com.br.http: S > 501941873:501941873(0) win 65535 > 17:06:12.934559 IP hm389.locaweb.com.br.http > 192.168.1.10.54458: S > 1436097196:1436097196(0) ack 501941874 win 5840 > 17:06:13.313919 IP 192.168.1.10.54458 > hm389.locaweb.com.br.http: . > ack 1436097197 win 65535 > 17:06:13.320533 IP 192.168.1.10.54458 > hm389.locaweb.com.br.http: F > 501941874:501941874(0) ack 1436097197 win 65535 > 17:06:13.331289 IP hm389.locaweb.com.br.http > 192.168.1.10.54458: . > ack 501941874 win 5840 > 17:06:13.337751 IP hm389.locaweb.com.br.http > 192.168.1.10.54458: F > 1436097197:1436097197(0) ack 501941875 win 5840 > 17:06:13.762246 IP 192.168.1.10.54458 > hm389.locaweb.com.br.http: . > ack 1436097198 win 65535 > > > > > linux dump of tcptest (every packet of connection establishment and > finalization) > SYN--------------------------------- > sport 54458 > dport 80 > sequence 501941873 > ack_number 0 > offset 5 > reserved 0 > urgent 0 > ack 0 > push 0 > reset 0 > syn 1 > fin 0 > window 65535 > checksum 25507 > urg_pointer 0 > > --------------------------------- > > SYN+ACK--------------------------------- > sport 80 > dport 54458 > sequence 1436097196 > ack_number 501941874 > offset 6 > reserved 0 > urgent 0 > ack 1 > push 2 > reset 4 > syn 9 > fin 0 > window 5840 > checksum 50368 > urg_pointer 0 > > --------------------------------- > > ACK (SYN)--------------------------------- > sport 54458 > dport 80 > sequence 0 > ack_number 1436097197 > offset 5 > reserved 0 > urgent 0 > ack 1 > push 0 > reset 0 > syn 0 > fin 0 > window 65535 > checksum 6059 > urg_pointer 0 > > --------------------------------- > > FIN--------------------------------- > sport 54458 > dport 80 > sequence 501941874 > ack_number 1436097197 > offset 5 > reserved 0 > urgent 0 > ack 1 > push 0 > reset 0 > syn 0 > fin 1 > window 65535 > checksum 62284 > urg_pointer 0 > > --------------------------------- > > ACK (FIN)--------------------------------- > sport 80 > dport 54458 > sequence 1436097197 > ack_number 501941874 > offset 5 > reserved 0 > urgent 0 > ack 1 > push 2 > reset 4 > syn 8 > fin 0 > window 5840 > checksum 56445 > urg_pointer 0 > > --------------------------------- > > FIN--------------------------------- > sport 80 > dport 54458 > sequence 1436097197 > ack_number 501941875 > offset 5 > reserved 0 > urgent 0 > ack 1 > push 2 > reset 4 > syn 8 > fin 1 > window 5840 > checksum 56443 > urg_pointer 0 > > --------------------------------- > > ACK (FIN)--------------------------------- > sport 54458 > dport 80 > sequence 501941875 > ack_number 1436097198 > offset 5 > reserved 0 > urgent 0 > ack 1 > push 0 > reset 0 > syn 0 > fin 0 > window 65535 > checksum 62283 > urg_pointer 0 > > --------------------------------- > > It was the first test conformance result of tcptest! > > > cheers From crapsh at MonkeyBrains.NET Mon Jun 2 16:44:54 2008 From: crapsh at MonkeyBrains.NET (Rudy) Date: Mon Jun 2 16:45:01 2008 Subject: carpdev? Message-ID: <48442389.9000602@MonkeyBrains.NET> Any plans for carpdev in FreeBSD? I'd be happy to poke around the OpenBSD source and try to get it working on FreeBSD. (Emphasis on the _try_) http://lists.freebsd.org/pipermail/freebsd-pf/2006-July/002429.html http://www.openbsd.org/faq/faq6.html#CARP Quick question: I notice the IP in carp examples is always a /24. If there is already a /24 IP on the 'host' interface for the carp device, why is it not a /32 (like when an alias is issued)? hostname="hosta.example.org" ifconfig_fxp0="inet 192.168.1.3 netmask 255.255.255.0" cloned_interfaces="carp0" ifconfig_carp0="vhid 1 pass testpass 192.168.1.50/24" Carpdev would get rid fo the 192.168.1.3 requirement and have something similar to vlandev. Rudy From crapsh at MonkeyBrains.NET Mon Jun 2 16:57:00 2008 From: crapsh at MonkeyBrains.NET (Rudy) Date: Mon Jun 2 16:57:04 2008 Subject: carpdev? In-Reply-To: <48442389.9000602@MonkeyBrains.NET> References: <48442389.9000602@MonkeyBrains.NET> Message-ID: <4844265F.4000405@MonkeyBrains.NET> Ah, someone already asked for this...http://lists.freebsd.org/pipermail/freebsd-pf/2007-July/003624.html Would this work? (I will test later today...) routerA ifconfig em0 10.0.0.8/24 ifconfig carp0 create ifconfig carp0 vhid 1 pass mekmitasdigoat 10.0.0.2/24 ifconfig carp0 1.2.3.4/30 <--- my "real" ip for my router routerB ifconfig em0 10.0.0.9/24 ifconfig carp0 create ifconfig carp0 vhid 1 advskew 100 pass mekmitasdigoat 10.0.0.2/24 ifconfig carp0 1.2.3.4/30 <--- my "real" ip for my router if so, would rc.conf be something like this: /cloned/*_*/interfaces="carp 0"/ ifconfig_carp0="vhid 1 pass mekmitasdigoat 10.0.0.2/24" ifconfig_carp0_alias0="1.2.3.4/30" Rudy From max at love2party.net Mon Jun 2 17:04:11 2008 From: max at love2party.net (Max Laier) Date: Mon Jun 2 17:04:16 2008 Subject: carpdev? In-Reply-To: <4844265F.4000405@MonkeyBrains.NET> References: <48442389.9000602@MonkeyBrains.NET> <4844265F.4000405@MonkeyBrains.NET> Message-ID: <200806021903.48986.max@love2party.net> I did the attached patch some time ago, but didn't find sufficient testers and when I did - I didn't have time. This should work. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News -------------- next part -------------- A non-text attachment was scrubbed... Name: carpdev.BETA2.diff Type: text/x-diff Size: 50376 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080602/52a51d51/carpdev.BETA2.bin From bilouro at bilouro.com Mon Jun 2 17:06:03 2008 From: bilouro at bilouro.com (Victor Hugo Bilouro) Date: Mon Jun 2 17:06:06 2008 Subject: establish connection without tcp options In-Reply-To: <4843D926.8010402@freebsd.org> References: <483E62D9.8000308@freebsd.org> <4842814C.3000508@freebsd.org> <48430A59.5090604@freebsd.org> <4843A615.90809@freebsd.org> <4843D926.8010402@freebsd.org> Message-ID: Hi, On Mon, Jun 2, 2008 at 8:27 AM, Andre Oppermann wrote: > Victor Hugo Bilouro wrote: >> >> On Mon, Jun 2, 2008 at 4:49 AM, Andre Oppermann wrote: >>> >>> Victor Hugo Bilouro wrote: >>>> >>>> On Sun, Jun 1, 2008 at 5:45 PM, Andre Oppermann >>>> wrote: >>>>> >>>>> Victor Hugo Bilouro wrote: >>>>>> >>>>>> syn--------------------------------- >>>>>> sport 59966 >>>>>> dport 22022 >>>>>> sequence 874312230 >>>>>> ack_number 0 >>>>>> offset 5 >>>>>> reserved 0 >>>>>> urgent 0 >>>>>> ack 0 >>>>>> push 0 >>>>>> reset 0 >>>>>> syn 1 >>>>>> fin 0 >>>>>> window 65535 >>>>>> checksum 50667 >>>>>> urg_pointer 0 >>>>>> >>>>>> --------------------------------- >>>>>> >>>>>> syn+ack----------------------------- >>>>>> sport 22022 >>>>>> dport 59966 >>>>>> sequence 2755934977 >>>>>> ack_number 874312231 >>>>>> offset 6 >>>>>> reserved 0 >>>>>> urgent 0 >>>>>> ack 1 >>>>>> push 2 >>>>>> reset 4 >>>>>> syn 9 >>>>>> fin 0 >>>>>> window 65535 >>>>>> checksum 52952 >>>>>> urg_pointer 0 >>>>>> >>>>>> --------------------------------- >>>>>> >>>>>> ack--------------------------------- >>>>>> sport 59966 >>>>>> dport 22022 >>>>>> sequence 874312230 >>>>> >>>>> ^^^^^^^^^^^^^^ increment by one for SYN you sent. >>>>> See also the ACK you got back above. >>>>> >>>>>> ack_number 2755934978 >>>>>> offset 5 >>>>>> reserved 0 >>>>>> urgent 0 >>>>>> ack 1 >>>>>> push 0 >>>>>> reset 0 >>>>>> syn 0 >>>>>> fin 0 >>>>>> window 65535 >>>>>> checksum 59030 >>>>>> urg_pointer 0 >>>>>> --------------------------------- >>>>>> >>>>>> ...and the log showed: >>>>>> TCP [192.168.1.10]:59966 to [192.168.1.20]:22022 tcpflags 0x10; >>>>>> syncache_expand: SEQ 874312230 != IRS+1 874312230, segment rejected. >>>>>> >>>>>> I'm still working... >>>>> >>>>> You should familiarize yourself some more with the sequence number >>>>> system TCP uses. The Stevens books "TCP/IP Illustrated" Volume 1+2 >>>>> are very good for that. >>>>> >>>>> -- >>>>> Andre >>>>> >>>> PS.: I forgot to copy the list in the previous email exchanging, so >>>> I'm doing now.... >>>> >>>> >>>> Andre, thank you SO VERY MUCH. It's working fine! >>>> >>>> As every book show tcpdump examples of connection establishment , and >>>> when the SYN flag is 0(as step #3 of three way handshake), sequence >>>> number(SN) are omitted of dump, BUT, it's present. >>> >>> You should use the "-S" option to tcpdump. It will show absolute >>> sequence number instead of relative ones (as guessed by tcpdump). >>> >>>> The thing is, the SN is present but it isn't consumed. So, packets >>>> that don't consumes the SN, must have the last consumed SN + 1. >>>> >>>> Only for curiosity, linux and windows 2k accomplished without >>>> problems the three way handshake without Sequence Number filled on >>>> step #3. >>> >>> I have a hard time believing that. At most they may have sent you >>> a retransmit or a challenge-ACK. >>> >>> -- >>> Andre >>> >> >> I will post here the tcpdump and tcptest dumps for both windows and >> linux with ACK with sequence 0. > >> >> >> windows tcpdump: (tcpdump -i ed0 -S tcp) >> 17:01:46.420016 IP 192.168.1.10.59537 > 192.168.1.101.http: S >> 770272892:770272892(0) win 65535 >> 17:01:46.421835 IP 192.168.1.101.http > 192.168.1.10.59537: S >> 1681202755:1681202755(0) ack 770272893 win 64240 >> 17:01:46.834808 IP 192.168.1.10.59537 > 192.168.1.101.http: . ack >> 1681202756 win 65535 >> 17:01:46.839584 IP 192.168.1.10.59537 > 192.168.1.101.http: F >> 770272893:770272893(0) ack 1681202756 win 65535 >> 17:01:46.840613 IP 192.168.1.101.http > 192.168.1.10.59537: . ack >> 770272894 win 64240 >> 17:01:46.840675 IP 192.168.1.101.http > 192.168.1.10.59537: F >> 1681202756:1681202756(0) ack 770272894 win 64240 >> 17:01:47.297816 IP 192.168.1.10.59537 > 192.168.1.101.http: . ack >> 1681202757 win 65535 > > That's interesting. I don't see any rationale why that should be > acceptable. We enforce the sequence number to be present and valid > in the ACK. This hasn't caused any complaints or incompatibilities > so far. What version/service-pack of Windows and Linux (kernel) are > you testing against? nmap -O (it's my hoster) "IPCop firewall 1.4.10 - 1.4.15 (Linux 2.4.31 - 2.4.34)" Windows Xp professional Service pack 1 build 2600.xpsp1.020828-1920 > > According to RFC793, Section 3.9, Page 69 the first check is actually > testing the SEG.SEQ as follows: RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND. > RCV.NXT is obviously the SEG.SEQ you sent with your SYN segment. It > seems that Windows and Linux are ignoring this test because you didn't > send any data with the ACK. Or they are simply ignoring the segment > as invalid and your FIN packet (with the correct SEG.SEQ and SEG.ACK) > causes the internal state transition. One may discuss which response, > none (just ignore segment) or sending a RST (as we do currently) is > better. I tend to argue the latter as it makes problems/bugs much > more evident as we've witnessed with your test. Now I know that a sucessful test of FreeBSD is receive back a Reset Packet. Test cataloged. > > -- > Andre > > >> windows dump of tcptest (every packet of connection establishment and >> finalization) >> SYN--------------------------------- >> sport 56121 >> dport 80 >> sequence 1046947043 >> ack_number 0 >> offset 5 >> reserved 0 >> urgent 0 >> ack 0 >> push 0 >> reset 0 >> syn 1 >> fin 0 >> window 65535 >> checksum 60750 >> urg_pointer 0 >> >> --------------------------------- >> >> SYN+ACK--------------------------------- >> sport 80 >> dport 56121 >> sequence 1494256296 >> ack_number 1046947044 >> offset 6 >> reserved 0 >> urgent 0 >> ack 1 >> push 2 >> reset 4 >> syn 9 >> fin 0 >> window 64240 >> checksum 63191 >> urg_pointer 0 >> >> --------------------------------- >> >> ACK (SYN)--------------------------------- >> sport 56121 >> dport 80 >> sequence 0 >> ack_number 1494256297 >> offset 5 >> reserved 0 >> urgent 0 >> ack 1 >> push 0 >> reset 0 >> syn 0 >> fin 0 >> window 65535 >> checksum 27857 >> urg_pointer 0 >> >> --------------------------------- >> >> FIN--------------------------------- >> sport 56121 >> dport 80 >> sequence 1046947044 >> ack_number 1494256297 >> offset 5 >> reserved 0 >> urgent 0 >> ack 1 >> push 0 >> reset 0 >> syn 0 >> fin 1 >> window 65535 >> checksum 2437 >> urg_pointer 0 >> >> --------------------------------- >> >> ACK (FIN)--------------------------------- >> sport 80 >> dport 56121 >> sequence 1494256297 >> ack_number 1046947045 >> offset 5 >> reserved 0 >> urgent 0 >> ack 1 >> push 2 >> reset 4 >> syn 8 >> fin 0 >> window 64240 >> checksum 3732 >> urg_pointer 0 >> >> --------------------------------- >> >> FIN--------------------------------- >> sport 80 >> dport 56121 >> sequence 1494256297 >> ack_number 1046947045 >> offset 5 >> reserved 0 >> urgent 0 >> ack 1 >> push 2 >> reset 4 >> syn 8 >> fin 1 >> window 64240 >> checksum 3731 >> urg_pointer 0 >> >> --------------------------------- >> >> ACK (FIN)--------------------------------- >> sport 56121 >> dport 80 >> sequence 1046947045 >> ack_number 1494256298 >> offset 5 >> reserved 0 >> urgent 0 >> ack 1 >> push 0 >> reset 0 >> syn 0 >> fin 0 >> window 65535 >> checksum 2436 >> urg_pointer 0 >> >> --------------------------------- >> >> >> >> >> >> >> >> >> linux tcpdump: (tcpdump -i ed0 -S tcp) >> 17:06:12.493737 IP 192.168.1.10.54458 > hm389.locaweb.com.br.http: S >> 501941873:501941873(0) win 65535 >> 17:06:12.934559 IP hm389.locaweb.com.br.http > 192.168.1.10.54458: S >> 1436097196:1436097196(0) ack 501941874 win 5840 >> 17:06:13.313919 IP 192.168.1.10.54458 > hm389.locaweb.com.br.http: . >> ack 1436097197 win 65535 >> 17:06:13.320533 IP 192.168.1.10.54458 > hm389.locaweb.com.br.http: F >> 501941874:501941874(0) ack 1436097197 win 65535 >> 17:06:13.331289 IP hm389.locaweb.com.br.http > 192.168.1.10.54458: . >> ack 501941874 win 5840 >> 17:06:13.337751 IP hm389.locaweb.com.br.http > 192.168.1.10.54458: F >> 1436097197:1436097197(0) ack 501941875 win 5840 >> 17:06:13.762246 IP 192.168.1.10.54458 > hm389.locaweb.com.br.http: . >> ack 1436097198 win 65535 >> >> >> >> >> linux dump of tcptest (every packet of connection establishment and >> finalization) >> SYN--------------------------------- >> sport 54458 >> dport 80 >> sequence 501941873 >> ack_number 0 >> offset 5 >> reserved 0 >> urgent 0 >> ack 0 >> push 0 >> reset 0 >> syn 1 >> fin 0 >> window 65535 >> checksum 25507 >> urg_pointer 0 >> >> --------------------------------- >> >> SYN+ACK--------------------------------- >> sport 80 >> dport 54458 >> sequence 1436097196 >> ack_number 501941874 >> offset 6 >> reserved 0 >> urgent 0 >> ack 1 >> push 2 >> reset 4 >> syn 9 >> fin 0 >> window 5840 >> checksum 50368 >> urg_pointer 0 >> >> --------------------------------- >> >> ACK (SYN)--------------------------------- >> sport 54458 >> dport 80 >> sequence 0 >> ack_number 1436097197 >> offset 5 >> reserved 0 >> urgent 0 >> ack 1 >> push 0 >> reset 0 >> syn 0 >> fin 0 >> window 65535 >> checksum 6059 >> urg_pointer 0 >> >> --------------------------------- >> >> FIN--------------------------------- >> sport 54458 >> dport 80 >> sequence 501941874 >> ack_number 1436097197 >> offset 5 >> reserved 0 >> urgent 0 >> ack 1 >> push 0 >> reset 0 >> syn 0 >> fin 1 >> window 65535 >> checksum 62284 >> urg_pointer 0 >> >> --------------------------------- >> >> ACK (FIN)--------------------------------- >> sport 80 >> dport 54458 >> sequence 1436097197 >> ack_number 501941874 >> offset 5 >> reserved 0 >> urgent 0 >> ack 1 >> push 2 >> reset 4 >> syn 8 >> fin 0 >> window 5840 >> checksum 56445 >> urg_pointer 0 >> >> --------------------------------- >> >> FIN--------------------------------- >> sport 80 >> dport 54458 >> sequence 1436097197 >> ack_number 501941875 >> offset 5 >> reserved 0 >> urgent 0 >> ack 1 >> push 2 >> reset 4 >> syn 8 >> fin 1 >> window 5840 >> checksum 56443 >> urg_pointer 0 >> >> --------------------------------- >> >> ACK (FIN)--------------------------------- >> sport 54458 >> dport 80 >> sequence 501941875 >> ack_number 1436097198 >> offset 5 >> reserved 0 >> urgent 0 >> ack 1 >> push 0 >> reset 0 >> syn 0 >> fin 0 >> window 65535 >> checksum 62283 >> urg_pointer 0 >> >> --------------------------------- >> >> It was the first test conformance result of tcptest! >> >> >> cheers > > -- Victor Hugo Bilouro FreeBSD! From fjwcash at gmail.com Mon Jun 2 17:44:52 2008 From: fjwcash at gmail.com (Freddie Cash) Date: Mon Jun 2 17:44:55 2008 Subject: carpdev? In-Reply-To: <200806021903.48986.max@love2party.net> References: <48442389.9000602@MonkeyBrains.NET> <4844265F.4000405@MonkeyBrains.NET> <200806021903.48986.max@love2party.net> Message-ID: <200806021017.40633.fjwcash@gmail.com> On June 2, 2008 10:03 am Max Laier wrote: > I did the attached patch some time ago, but didn't find sufficient > testers and when I did - I didn't have time. This should work. Is this the same patch I tested awhile back? Or is the "if the order of the IPs on the interfaces is different, they won't join the carp vhid" issue fixed in this patch? I'd be happy to test this again, if the IP order issue has been fixed. -- Freddie Cash fjwcash@gmail.com From max at love2party.net Mon Jun 2 17:56:55 2008 From: max at love2party.net (Max Laier) Date: Mon Jun 2 17:57:00 2008 Subject: carpdev? In-Reply-To: <200806021017.40633.fjwcash@gmail.com> References: <48442389.9000602@MonkeyBrains.NET> <200806021903.48986.max@love2party.net> <200806021017.40633.fjwcash@gmail.com> Message-ID: <200806021956.34892.max@love2party.net> On Monday 02 June 2008 19:17:40 Freddie Cash wrote: > On June 2, 2008 10:03 am Max Laier wrote: > > I did the attached patch some time ago, but didn't find sufficient > > testers and when I did - I didn't have time. This should work. > > Is this the same patch I tested awhile back? Or is the "if the order > of the IPs on the interfaces is different, they won't join the carp > vhid" issue fixed in this patch? > > I'd be happy to test this again, if the IP order issue has been fixed. I completely forgot ... there even is a PR (and patch) in my queue: http://www.freebsd.org/cgi/query-pr.cgi?pr=121574&cat= I'll commit in a bit - this should not conflict with the carpdev patch. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From agaviola at infoweapons.com Tue Jun 3 02:18:27 2008 From: agaviola at infoweapons.com (Archimedes S. Gaviola) Date: Tue Jun 3 02:18:31 2008 Subject: [Regarding FreeBSD and RFC Compliance] Message-ID: <4844A646.8010809@infoweapons.com> To Whom It May Concerned: Good day! Is there any document or web site that lists all the standard Request for Comments (RFCs) for all the networking protocols currently implemented on FreeBSD? This will help users identify what specific sections of a standard a certain network protocol is being implemented especially interoperability with other platforms. Thank you! Archimedes From linimon at FreeBSD.org Tue Jun 3 02:46:40 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue Jun 3 02:46:44 2008 Subject: kern/124225: [ndis] [patch] ndis network driver sometimes loses network connection Message-ID: <200806030246.m532kemP085717@freefall.freebsd.org> Old Synopsis: ndis network driver sometimes loses network connection New Synopsis: [ndis] [patch] ndis network driver sometimes loses network connection Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Jun 3 02:46:09 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=124225 From bilouro at bilouro.com Tue Jun 3 03:52:55 2008 From: bilouro at bilouro.com (Victor Hugo Bilouro) Date: Tue Jun 3 03:52:57 2008 Subject: [GSoC - tcptest] - Regression Tests, Conformance Tests... Message-ID: Hi, I'm in architectural phase of tcptest* development, so, I need understand every possible test it will need cover, because it would change tcptest architecture. I selected some tests: *connection establishment and finalization (a) *test cases where reset must be sent *tcp options establishment *tcp options conformance *tcp timmers *regression tests *basic: ping localhost *basic: checksum test I invite you to suggest some tests. :) (may be some remembered bug) (a)this test is done. It was the first test done, and as result, we notice different behaviors in windows, linux and freebsd network stack. Another important thing to know is: suppose you are planning to use this tool, how you intend to use? In which environment? What purpose? What do you initially prefer? (a)write tests programaticaly or (b)write tests ipfw-like oriented? Thank you! -- Victor Hugo Bilouro FreeBSD! tcptest** --> http://wiki.freebsd.org/VictorBilouro/TCP-IP_regression_test_suite tcptest is a GSoC (Google Summer of Code) project, it's a TCP/IP Regression Test Suite implementation. As a testing tool, it can perform regression, protocol conformance, and fuzz tests. The tool may also be employed as an aid to protocol developers and both testing and debugging of firewalls/routers. It's was built on top of pcs.sf.net of gnn at freebsd. ps: I will keep the nomenclature used at subject. From bms at FreeBSD.org Tue Jun 3 04:36:03 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Tue Jun 3 04:36:07 2008 Subject: [Regarding FreeBSD and RFC Compliance] In-Reply-To: <4844A646.8010809@infoweapons.com> References: <4844A646.8010809@infoweapons.com> Message-ID: <4844CA2F.2030805@FreeBSD.org> Archimedes S. Gaviola wrote: > To Whom It May Concerned: > > Good day! Is there any document or web site that lists all the > standard Request for Comments (RFCs) for all the networking protocols > currently implemented on FreeBSD? This will help users identify what > specific sections of a standard a certain network protocol is being > implemented especially interoperability with other platforms. No, want to compile one and contribute it to the project? We'd be very grateful for the help. cheers BMS From bms at FreeBSD.org Tue Jun 3 04:39:24 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Tue Jun 3 04:39:28 2008 Subject: [GSoC - tcptest] - Regression Tests, Conformance Tests... In-Reply-To: References: Message-ID: <4844CAF8.5080709@FreeBSD.org> Victor Hugo Bilouro wrote: > Hi, > > I'm in architectural phase of tcptest* development, so, I need > understand every possible test it will need cover, because it would > change tcptest architecture. > Hey, have you seen gnn's PCS toolkit? http://pcs.sourceforge.net/ I've made a lot of changes to it; diffs are with him but I can send folk a copy of my Mercurial repo. I wrote a set of IGMPv2 and IGMPv3 baseline regression tests using it, now that I've added things like expect(), etc. It might save you a lot of work, although the TCP stuff needs attention. With expect() you can track state between segments. I started on IP reassembly, but ain't finished. I think Kip Macy's been using it for testing too, I saw a chunk of PCS-using TCP code on his site the other day. cheers BMS From bilouro at bilouro.com Tue Jun 3 05:01:27 2008 From: bilouro at bilouro.com (Victor Hugo Bilouro) Date: Tue Jun 3 05:01:29 2008 Subject: [GSoC - tcptest] - Regression Tests, Conformance Tests... In-Reply-To: <4844CAF8.5080709@FreeBSD.org> References: <4844CAF8.5080709@FreeBSD.org> Message-ID: Hi On Tue, Jun 3, 2008 at 1:39 AM, Bruce M. Simpson wrote: > Victor Hugo Bilouro wrote: >> >> Hi, >> >> I'm in architectural phase of tcptest* development, so, I need >> understand every possible test it will need cover, because it would >> change tcptest architecture. >> > > Hey, have you seen gnn's PCS toolkit? > http://pcs.sourceforge.net/ sure, I'm using pcs. tcptest is built on top of pcs. > > I've made a lot of changes to it; diffs are with him but I can send folk a > copy of my Mercurial repo. I would appreciate that. > > I wrote a set of IGMPv2 and IGMPv3 baseline regression tests using it, now > that I've added things like expect(), etc. > > It might save you a lot of work, although the TCP stuff needs attention. > With expect() you can track state between segments. I started on IP > reassembly, but ain't finished. humm, track state is needed to make TCP tests. > > I think Kip Macy's been using it for testing too, I saw a chunk of PCS-using > TCP code on his site the other day. I didn't find his site, can you send me? > > cheers > BMS > -- Victor Hugo Bilouro FreeBSD! From bms at FreeBSD.org Tue Jun 3 08:16:30 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Tue Jun 3 08:16:35 2008 Subject: [GSoC - tcptest] - Regression Tests, Conformance Tests... In-Reply-To: References: <4844CAF8.5080709@FreeBSD.org> Message-ID: <4844FDDC.3020704@FreeBSD.org> Victor Hugo Bilouro wrote: >> I've made a lot of changes to it; diffs are with him but I can send folk a >> copy of my Mercurial repo. >> > I would appreciate that. > Sent (off-list). As an example of the new PCS syntax and expect() stuff, I'll forward you the IGMPv2 test off-list. (Also sent.) > humm, track state is needed to make TCP tests. > It is something you'll have to build yourself around the expect() functionality. The experimental IP reassembly code (in pcs/packets/ipv4sar.py) might be a good place to start. It isn't finished, but it should demonstrate the general principles -- i.e. you read packets in a loop and you pass them to an object which knows what to do, in this case, ipv4sar. One big problem I had was that the concept of fragmentation requires deep copies of PCS objects. I imagine that's less of an issue for TCP segmentation, as the situation is made somewhat easier by the fact you're dealing with streams. BTW: My snapshot of PCS fixes the IP and TCP option parsers. If you look at the IGMP and DHCP decoders, there is an example of a dictionary driven option parser. This could also be applied to TCP where it's likely to be useful. I believe most of the bugs have been shaken out of expect(). The main problem is buffering and the fact that expect() depends on non-blocking I/O. pcap can return more than one packet from the kernel every time you call into the non-blocking dispatch function, so I did some internal refactoring to allow expect() to deal with that. So your code has to be able to deal with multiple matches from the Connector, even if you only asked to match at *least* one packet. "Count" is mostly about stopping expect() from hanging the flow of control anyway. The syntax and semantics are intentionally similar to PExpect for Python. In fact the IGMPv2 test uses PExpect to drive a QEMU virtual machine encapsulated as a Python object, for regression testing the IGMP code. So my suggestion is check out PExpect too. > I didn't find his site, can you send me? http://www.fsmware.com/freebsd/syntest2.py I've added some Scapy-like syntax to PCS which can make the code look a bit smaller. cheers BMS From agaviola at infoweapons.com Tue Jun 3 10:06:17 2008 From: agaviola at infoweapons.com (Archimedes S. Gaviola) Date: Tue Jun 3 10:06:20 2008 Subject: [Regarding FreeBSD and RFC Compliance] In-Reply-To: <4844CA2F.2030805@FreeBSD.org> References: <4844A646.8010809@infoweapons.com> <4844CA2F.2030805@FreeBSD.org> Message-ID: <48451786.3040002@infoweapons.com> Bruce M. Simpson wrote: > Archimedes S. Gaviola wrote: >> To Whom It May Concerned: >> >> Good day! Is there any document or web site that lists all the >> standard Request for Comments (RFCs) for all the networking protocols >> currently implemented on FreeBSD? This will help users identify what >> specific sections of a standard a certain network protocol is being >> implemented especially interoperability with other platforms. > > No, want to compile one and contribute it to the project? We'd be very > grateful for the help. > > cheers > BMS > Ah okay, so this is still a window of opportunity for now but unfortunately I'm currently pre-occupied with my time. I might contribute on this someday. From marc.loerner at hob.de Tue Jun 3 11:46:27 2008 From: marc.loerner at hob.de (Marc =?iso-8859-1?q?L=F6rner?=) Date: Tue Jun 3 11:46:29 2008 Subject: Unaligned references in /usr/src/sys/netinet6/in6.h Message-ID: <200806031321.41768.marc.loerner@hob.de> Hello, within testing on a ia64-platform I spotted unaligned references in the macros: IN6_IS_ADDR_UNSPECIFIED(a), IN6_IS_ADDR_LOOPBACK(a), IN6_IS_ADDR_V4COMPAT(a) and IN6_IS_ADDR_V4MAPPED(a) It's not always true that the s6_addr array is aligned to 4-byte and this causes some trouble at least with ia64-platforms. After changing from u_int32_t to u_int8_t accesses the unalignment faults seem to be gone. Regards, Marc P.S.: On replies please CC me because I'm not on the list. From bms at FreeBSD.org Tue Jun 3 13:52:04 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Tue Jun 3 13:52:10 2008 Subject: [Regarding FreeBSD and RFC Compliance] In-Reply-To: <866fa9520806030634q5c3f3be1sf6ccb44668e5c3@mail.gmail.com> References: <4844A646.8010809@infoweapons.com> <4844CA2F.2030805@FreeBSD.org> <866fa9520806030634q5c3f3be1sf6ccb44668e5c3@mail.gmail.com> Message-ID: <48454C80.6080904@FreeBSD.org> Dalibor Gudzic wrote: > > > Any pointers for someone that wishes to do it? http://wiki.freebsd.org/NetworkRFCCompliance ...is one place to start... From pfgshield-freebsd at yahoo.com Tue Jun 3 15:17:09 2008 From: pfgshield-freebsd at yahoo.com (pfgshield-freebsd@yahoo.com) Date: Tue Jun 3 16:02:14 2008 Subject: Anyone interested in HDLC support for pppd ? Message-ID: <853261.35086.qm@web32707.mail.mud.yahoo.com> Hello; I started playing a bit with net/pppd23 and I noticed there are some patches for FreeBSD-3.0 that were never committed (NetBSD certainly has them). Our pppd(8) is derived from the "samba" pppd port and should have them if we want to continue updating it. I started adapting them but I am actually in a dead point due to my profound ignorance on FreeBSD and it's latest changes. I am stuck here: _____ ... ../../../net/ppp_tty.c: In function `pppsyncstart': ../../../net/ppp_tty.c:653: error: `cdevsw' undeclared (first use in this function) ../../../net/ppp_tty.c:653: error: (Each undeclared identifier is reported only once ../../../net/ppp_tty.c:653: error: for each function it appears in.) ../../../net/ppp_tty.c:653: warning: implicit declaration of function `major' ../../../net/ppp_tty.c:653: warning: nested extern declaration of `major' *** Error code 1 ______ the offending code is this: ______ /* call device driver IOCTL to transmit a frame */ if ((*cdevsw[major(tp->t_dev)]->d_ioctl) (tp->t_dev,TIOCXMTFRAME,(caddr_t)&m,0,0)) { /* busy or error, set as current packet */ sc->sc_outm = m; _____ If someone can give me (easy to follow) suggestions on how to fix it I'll be grateful. The changes I already did to the original patches are not huge but if someone wants to review them all just send me a private mail and I'll send them. cheers, Pedro. ___________________________________ Scopri il Blog di Yahoo! Mail: trucchi, novit?, consigli... e la tua opinione! http://www.ymailblogit.com/blog/ From bms at FreeBSD.org Tue Jun 3 16:30:50 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Tue Jun 3 16:30:56 2008 Subject: Anyone interested in HDLC support for pppd ? In-Reply-To: <853261.35086.qm@web32707.mail.mud.yahoo.com> References: <853261.35086.qm@web32707.mail.mud.yahoo.com> Message-ID: <484571B7.1050004@FreeBSD.org> pfgshield-freebsd@yahoo.com wrote: > Hello; > > I started playing a bit with net/pppd23 and I noticed there are some patches for FreeBSD-3.0 that were never committed (NetBSD certainly has them). Our pppd(8) is derived from the "samba" pppd port and should have them if we want to continue updating it. > Ed Schouten is currently rewriting the tty code. It sounds like line disciplines are about to go away, so pppd23 will most likely stop working at that point. There's a Netgraph node ng_cisco which claims to support HDLC. Perhaps tweaking MPD to work with it is a better use of effort. From jon.otterholm at ide.resurscentrum.se Tue Jun 3 21:26:36 2008 From: jon.otterholm at ide.resurscentrum.se (Jon Otterholm) Date: Tue Jun 3 21:26:39 2008 Subject: carpdev Message-ID: <4845B417.6030400@ide.resurscentrum.se> Hi. Are there any plans to implement option carpdev to carp in FreeBSD? //Jon From sullrich at gmail.com Tue Jun 3 22:05:53 2008 From: sullrich at gmail.com (Scott Ullrich) Date: Tue Jun 3 22:05:57 2008 Subject: carpdev In-Reply-To: <4845B417.6030400@ide.resurscentrum.se> References: <4845B417.6030400@ide.resurscentrum.se> Message-ID: On 6/3/08, Jon Otterholm wrote: > Hi. > > Are there any plans to implement option carpdev to carp in FreeBSD? > > //Jon See the freebsd-pf archives. Max has a patch ready for testing and needs more wide-spread testing. Scott From max at love2party.net Tue Jun 3 22:20:15 2008 From: max at love2party.net (Max Laier) Date: Tue Jun 3 22:20:20 2008 Subject: carpdev In-Reply-To: References: <4845B417.6030400@ide.resurscentrum.se> Message-ID: <200806040019.50942.max@love2party.net> On Tuesday 03 June 2008 23:39:42 Scott Ullrich wrote: > On 6/3/08, Jon Otterholm wrote: > > Hi. > > > > Are there any plans to implement option carpdev to carp in FreeBSD? > > > > //Jon > > See the freebsd-pf archives. Max has a patch ready for testing and > needs more wide-spread testing. Or scroll up to Monday on this list ;) -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From peterjeremy at optushome.com.au Wed Jun 4 08:14:50 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Wed Jun 4 08:14:56 2008 Subject: Understanding the interplay of ipfw, vlan, and carp In-Reply-To: <36735.192.168.4.151.1204669226.squirrel@router> References: <200803041351.46053.fjwcash@gmail.com> <36735.192.168.4.151.1204669226.squirrel@router> Message-ID: <20080604081443.GJ1028@server.vk2pj.dyndns.org> On 2008-Mar-04 23:20:26 +0100, Max Laier wrote: >You could try the attached patch. It adds carpdev support. You'll have >to recompile ifconfig to make use of it. I have just tried it and found that it does precisely the opposite of what I want :-( My situation: At work, I have a NAT box that is used to translate between our corporate intranet and my department's test models. There is (basically) 1:1 NAT and I use proxy-ARP on the intranet side (though I have gateway IPs on the internal side). I am trying to convert this to use CARP for failover. My external interface config currently looks like: ifconfig vlan10 10.10.10.1 vlandev fxp0 vlan 10 arp -s 10.10.10.2 auto pub arp -s 10.10.10.3 auto pub arp -s 10.10.10.4 auto pub arp -s 10.10.10.5 auto pub Ideally, I want to attach a carp device to vlan10 so I can do ifconfig vlan10 10.10.10.1 vlandev fxp0 vlan 10 ifconfig carp10 vhid 10 carpdev vlan10 arp -s 10.10.10.2 00:00:5e:00:01:0a pub arp -s 10.10.10.3 00:00:5e:00:01:0a pub arp -s 10.10.10.4 00:00:5e:00:01:0a pub arp -s 10.10.10.5 00:00:5e:00:01:0a pub ie the IP address remains with the specific box (the backup box has its own IP address). Unfortunately, the current carpdev code doesn't work this way: It lets me not assign an IP address to vlan10 but I still have to assign an IP address to carp10 (and it uses the latter address rather than the former address in the carp advertisements). Does what I want make sense to you and can you see any way it could be integrated into your carpdev patches. Note that one downside of your carpdev patches is that (AFAIK) it is no longer possible to identify which host sent the packet: The source and destination MAC addresses, as well as the destination IP address are all defined by CARP. Once you change the source IP address to be the shared address there's nothing to identify which host sent it. Finally, can anyone point me to a protocol specification for CARP. The only documentation I can find in either FreeBSD or OpenBSD is basically limited to "it's like VRRP but different to avoid the CISCO patent on HSRP". -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080604/47f3cc7c/attachment.pgp From zuan at mylinux.net.my Wed Jun 4 19:02:03 2008 From: zuan at mylinux.net.my (Izwan Mohd) Date: Wed Jun 4 19:02:05 2008 Subject: network keep droping Message-ID: Hi, I have being encountering a weird problem on my freebsd 6 , one of my remote machine being down frequently lately for no particular reason, when I go to the remote site to check then machine it was in good running condition but no network, it even can't ping the server on the same subnet, the only way to restore it back is by running: route -n flush && /etc/netstart but because it a remote machine it really troublesome to do that each time the machine is down, I resorted to use a crontab scripts to automatically run the previous command when it down, even tho that partial of the problem is solve I still need to know what causing it. can anyone could advise me where to start digging?? they is no any particular error in the log or dmseg when the machine dropped it connection so I'm stuck here don't know where to start, some help should clear something up for me TQ From peterjeremy at optushome.com.au Wed Jun 4 19:41:08 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Wed Jun 4 19:41:13 2008 Subject: network keep droping In-Reply-To: References: Message-ID: <20080604194059.GE1028@server.vk2pj.dyndns.org> On 2008-Jun-05 02:37:14 +0800, Izwan Mohd wrote: >I have being encountering a weird problem on my freebsd 6 , one of my remote >machine being down frequently lately for no particular reason, when I go to >the remote site to check then machine it was in good running condition but >no network, it even can't ping the server on the same subnet, the only way >to restore it back is by running: > >route -n flush && /etc/netstart First question would be: What has changed? Are you able to identify when the problem occurs? This might let you associate the problem with an internal cronjob or network activity. What does ifconfig report? Does the interface look normal or is it reporting something strange? Is the switch reporting any events associated with your port? What do you see if you tcpdump the interface whilst its not working? Are you seeing normal subnet broadcast traffic? Unicast traffic directed to your box? Outgoing traffic from your box? Does physically unplugging and re-connecting the network cable correct the problem? Are you able to (temporarily) use a different swichport or NIC? Finally, more detail on your configuration might trigger someone's memory: What version of 6.x? What NIC/MII? How much memory? What network features (vlan, firewall, dummynet, netgraph, carp, ...) are you using? -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080604/fb8feda4/attachment.pgp From lev at serebryakov.spb.ru Wed Jun 4 19:59:01 2008 From: lev at serebryakov.spb.ru (Lev Serebryakov) Date: Wed Jun 4 19:59:07 2008 Subject: samba performance on 1Gig link: how to replace black magic with science? And why TCP windows scaling is not in play? Message-ID: <1761236634.20080604234231@serebryakov.spb.ru> Hello, net. I'm setupping file server for WindowsXP/SP3 clients, based on FreeBSD 7.0-Stable nad latest samba port. First of all, Is et these kernel variables: kern.ipc.maxsockbuf=16777216 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.sendspace=131072 net.inet.tcp.recvspace=131072 All tests are performed with only one client for start. Server and client are linked with 1Gig link, jumbo frames are enabled (9014 bytes) and iperf shows about 900Mbit/s of raw TCP with big windows (about 256Kb for start). Local tests shows 75Mb/s Read/write from/to shared file system with big files. Default configuration of samba gives me only 20Mb/s read and loosy 15Mb/s write. With "socket options = TCP_NODELAY" speed becomes 25/20 Mb/S R/W. Then I start to change SO_RCVBUF/SO_SNDBUF and found (with binary search), that best values are 49152. Yes, this strange values. 65536 is worse, and 32768 is worse too. This magic value gives me about 40MB/s read and 30-35Mb/s write. "Recommended" 8192 gives me 40K/s read (YES, 40 _K_ilobytes per second!) But I don't like this situation. Why? Because, it is black magic, not science. Why 49152? How can this value be found without binary search? What affects this value? Second problem is about TCP windows, which can give more thoughtput on 1Gig link. I've tried to tcpdump traffic between samba and WinXP client, and it shows, that window scaling is turned off. Always. It is enabled on WinXP client, it is enabled on FreeBSD server, it us used by iperf (with great effect), but not by samba! What do I do wrong? -- // Black Lion AKA Lev Serebryakov From jfvogel at gmail.com Wed Jun 4 20:45:22 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Wed Jun 4 20:45:29 2008 Subject: Addition to the vlan driver Message-ID: <2a41acea0806041345x435ab61cq77f59a0cc0ae043f@mail.gmail.com> I had our test group report a bug when using jumbo frames and vlans in the new igb driver. After a couple days chasing it down it turns out the issue is that the igb driver does not know when a vlan is first attached, and when you use jumbo frames you need to program a register with the maximum frame size. The test case sets the MTU first, then did the vlan setup, so the driver did not have the tag accounted for in the frame size, and thus the hardware was happily throwing frames away due to size :( Now, as a workaround I have them set up the vlan first and THEN change the MTU, but I'd rather not require that, so.... What I would like to do is add some code into the vlan_ioctl() routine that will make a call to the PARENT ioctl with SETVLAN type and an argument of the tag. By doing this both the em and igb drivers will be able to enable hardware vlan filtering as well, a feature we've never been able to use. Anyone see any issue with doing this or have any objections to it? Cheers, Jack From arno at heho.snv.jussieu.fr Wed Jun 4 21:06:05 2008 From: arno at heho.snv.jussieu.fr (Arno J. Klaassen) Date: Wed Jun 4 21:06:09 2008 Subject: IP-forwarding (help) Message-ID: Hello, this is probably a FAQ and/or I'm to tired, but I'd be pleased if anyone can tell me what I do wrong : I have a box with two interfaces, one connected to my lan (172.16. ), one to a test-box (192.168.1.1) : em0: flags=8843 metric 0 mtu 1500 options=9b ether xxx inet 172.16.1.240 netmask 0xffffff00 broadcast 172.16.1.255 media: Ethernet autoselect (1000baseTX ) status: active em1: flags=8843 metric 0 mtu 1500 options=9b ether xxx inet 192.168.1.254 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (1000baseTX ) status: active I enable ip.forwarding : # sysctl net.inet.ip.forwarding net.inet.ip.forwarding: 1 And this is my routing table : Internet: Destination Gateway Flags Refs Use Netif Expire default 172.16.1.254 UGS 0 20 em0 127.0.0.1 127.0.0.1 UH 0 0 lo0 172.16.1.0/24 link#3 UC 0 0 em0 172.16.1.6 xxxxxxxxxxxxxxxxx UHLW 1 87 em0 1194 172.16.1.230 xxxxxxxxxxxxxxxxx UHLW 1 286 em0 572 172.16.1.240 xxxxxxxxxxxxxxxxx UHLW 1 0 lo0 172.16.1.254 xxxxxxxxxxxxxxxxx UHLW 2 0 em0 487 192.168.1.0/24 link#4 UC 0 0 em1 192.168.1.1 xxxxxxxxxxxxxxxxx UHLW 1 2 em1 616 192.168.1.254 xxxxxxxxxxxxxxxxx UHLW 1 0 lo0 For this I added to rc.conf : static_routes="test lan" route_test="-net 192.168.1.0/24 192.168.1.254" route_lan="-net 172.16.1.0/24 172.16.1.240" Now from my test-box 192.168.1.1 I can reach (of course) 192.168.1.254, I can reach 172.16.1.240, but no other IP. What do I wrong, please!? Thank you very much for any help in advance. Best regards, Arno From andrew at modulus.org Wed Jun 4 21:56:02 2008 From: andrew at modulus.org (Andrew Snow) Date: Wed Jun 4 21:56:08 2008 Subject: Addition to the vlan driver In-Reply-To: <2a41acea0806041345x435ab61cq77f59a0cc0ae043f@mail.gmail.com> References: <2a41acea0806041345x435ab61cq77f59a0cc0ae043f@mail.gmail.com> Message-ID: <48470F61.6060907@modulus.org> Jack Vogel wrote: > What I would like to do is add some code into the vlan_ioctl() routine > that will make a call > to the PARENT ioctl with SETVLAN type and an argument of the tag. > > By doing this both the em and igb drivers will be able to enable > hardware vlan filtering as > well, a feature we've never been able to use. I don't think vlan filtering is needed much, since I always use VLANs with switches that do the filtering at the port level. But it still sounds like a good idea and I can't think why not. - Andrew From jfvogel at gmail.com Wed Jun 4 21:58:01 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Wed Jun 4 21:58:04 2008 Subject: Addition to the vlan driver In-Reply-To: <48470F61.6060907@modulus.org> References: <2a41acea0806041345x435ab61cq77f59a0cc0ae043f@mail.gmail.com> <48470F61.6060907@modulus.org> Message-ID: <2a41acea0806041458p2f498dacvdf33dfbca75d8554@mail.gmail.com> On Wed, Jun 4, 2008 at 2:55 PM, Andrew Snow wrote: > Jack Vogel wrote: >> >> What I would like to do is add some code into the vlan_ioctl() routine >> that will make a call >> to the PARENT ioctl with SETVLAN type and an argument of the tag. >> >> By doing this both the em and igb drivers will be able to enable >> hardware vlan filtering as >> well, a feature we've never been able to use. > > I don't think vlan filtering is needed much, since I always use VLANs > with switches that do the filtering at the port level. But it still > sounds like a good idea and I can't think why not. > > - Andrew > Sam is going to make some change that should suit my needs, waiting to see his code to make my changes. Jack From petar at smokva.net Wed Jun 4 22:28:16 2008 From: petar at smokva.net (Petar Bogdanovic) Date: Wed Jun 4 22:28:20 2008 Subject: IP-forwarding (help) In-Reply-To: References: Message-ID: <20080604221738.GA6776@pintail.smokva.net> On Wed, Jun 04, 2008 at 11:06:01PM +0200, Arno J. Klaassen wrote: > > Hello, > > this is probably a FAQ and/or I'm to tired, but I'd be pleased > if anyone can tell me what I do wrong : > > I have a box with two interfaces, one connected to my lan > (172.16. ), one to a test-box (192.168.1.1) : > > em0: flags=8843 metric 0 mtu 1500 > options=9b > ether xxx > inet 172.16.1.240 netmask 0xffffff00 broadcast 172.16.1.255 > media: Ethernet autoselect (1000baseTX ) > status: active > > em1: flags=8843 metric 0 mtu 1500 > options=9b > ether xxx > inet 192.168.1.254 netmask 0xffffff00 broadcast 192.168.1.255 > media: Ethernet autoselect (1000baseTX ) > status: active > > > I enable ip.forwarding : > > # sysctl net.inet.ip.forwarding > net.inet.ip.forwarding: 1 > > > And this is my routing table : > > Internet: > Destination Gateway Flags Refs Use Netif Expire > default 172.16.1.254 UGS 0 20 em0 > 127.0.0.1 127.0.0.1 UH 0 0 lo0 > 172.16.1.0/24 link#3 UC 0 0 em0 > 172.16.1.6 xxxxxxxxxxxxxxxxx UHLW 1 87 em0 1194 > 172.16.1.230 xxxxxxxxxxxxxxxxx UHLW 1 286 em0 572 > 172.16.1.240 xxxxxxxxxxxxxxxxx UHLW 1 0 lo0 > 172.16.1.254 xxxxxxxxxxxxxxxxx UHLW 2 0 em0 487 > 192.168.1.0/24 link#4 UC 0 0 em1 > 192.168.1.1 xxxxxxxxxxxxxxxxx UHLW 1 2 em1 616 > 192.168.1.254 xxxxxxxxxxxxxxxxx UHLW 1 0 lo0 > > For this I added to rc.conf : > > static_routes="test lan" > route_test="-net 192.168.1.0/24 192.168.1.254" > route_lan="-net 172.16.1.0/24 172.16.1.240" I'm pretty sure that you don't need these three lines. Turning net.inet.ip.forwarding on should be enough. Petar From fox at verio.net Wed Jun 4 23:17:27 2008 From: fox at verio.net (David DeSimone) Date: Wed Jun 4 23:17:31 2008 Subject: IP-forwarding (help) In-Reply-To: References: Message-ID: <20080604231724.GG14447@verio.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Arno J. Klaassen wrote: > > Now from my test-box 192.168.1.1 I can reach (of course) > 192.168.1.254, I can reach 172.16.1.240, but no other IP. Check with tcpdump, are your network packets being sourced from the 192.168 network even when they go to the 172.16 network? Perhaps the box you reach does not know how to route back to you when you source from that IP. - -- David DeSimone == Network Admin == fox@verio.net "This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, dis- tribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you." --Lawyer Bot 6000 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFIRyKEFSrKRjX5eCoRAhT0AJsGMjSpUqXl7DG5Q0hkPSt6Rh321ACfduQU wdIKoSXxfTDMrxaz3S+cKkI= =EdLO -----END PGP SIGNATURE----- From arno at heho.snv.jussieu.fr Wed Jun 4 23:33:15 2008 From: arno at heho.snv.jussieu.fr (Arno J. Klaassen) Date: Wed Jun 4 23:33:18 2008 Subject: IP-forwarding (help) In-Reply-To: <20080604221738.GA6776@pintail.smokva.net> References: <20080604221738.GA6776@pintail.smokva.net> Message-ID: Petar Bogdanovic writes: > On Wed, Jun 04, 2008 at 11:06:01PM +0200, Arno J. Klaassen wrote: > > > > Hello, > > > > this is probably a FAQ and/or I'm to tired, but I'd be pleased > > if anyone can tell me what I do wrong : > > > > I have a box with two interfaces, one connected to my lan > > (172.16. ), one to a test-box (192.168.1.1) : > > > > em0: flags=8843 metric 0 mtu 1500 > > options=9b > > ether xxx > > inet 172.16.1.240 netmask 0xffffff00 broadcast 172.16.1.255 > > media: Ethernet autoselect (1000baseTX ) > > status: active > > > > em1: flags=8843 metric 0 mtu 1500 > > options=9b > > ether xxx > > inet 192.168.1.254 netmask 0xffffff00 broadcast 192.168.1.255 > > media: Ethernet autoselect (1000baseTX ) > > status: active > > > > > > I enable ip.forwarding : > > > > # sysctl net.inet.ip.forwarding > > net.inet.ip.forwarding: 1 > > > > > > And this is my routing table : > > > > Internet: > > Destination Gateway Flags Refs Use Netif Expire > > default 172.16.1.254 UGS 0 20 em0 > > 127.0.0.1 127.0.0.1 UH 0 0 lo0 > > 172.16.1.0/24 link#3 UC 0 0 em0 > > 172.16.1.6 xxxxxxxxxxxxxxxxx UHLW 1 87 em0 1194 > > 172.16.1.230 xxxxxxxxxxxxxxxxx UHLW 1 286 em0 572 > > 172.16.1.240 xxxxxxxxxxxxxxxxx UHLW 1 0 lo0 > > 172.16.1.254 xxxxxxxxxxxxxxxxx UHLW 2 0 em0 487 > > 192.168.1.0/24 link#4 UC 0 0 em1 > > 192.168.1.1 xxxxxxxxxxxxxxxxx UHLW 1 2 em1 616 > > 192.168.1.254 xxxxxxxxxxxxxxxxx UHLW 1 0 lo0 > > > > For this I added to rc.conf : > > > > static_routes="test lan" > > route_test="-net 192.168.1.0/24 192.168.1.254" > > route_lan="-net 172.16.1.0/24 172.16.1.240" > > I'm pretty sure that you don't need these three lines. Turning > net.inet.ip.forwarding on should be enough. That's what I thought? Without the above lines it doesn't work either. And ip.forwarding "works" in the sense trafic goes from 192.168.1.254 forward to 172.16.1.240 over lo0, but then taking "link#3" to go to 172.16.1.0/24 fails. I feel this is /me still not fully understand routing tables. NB, this is on 7-stable-amd64 Arno From bakul at bitblocks.com Thu Jun 5 00:16:28 2008 From: bakul at bitblocks.com (Bakul Shah) Date: Thu Jun 5 00:16:31 2008 Subject: IP-forwarding (help) In-Reply-To: Your message of "05 Jun 2008 01:33:05 +0200." Message-ID: <20080605000622.6481A5B46@mail.bitblocks.com> On 05 Jun 2008 01:33:05 +0200 "Arno J. Klaassen" wrote: > Petar Bogdanovic writes: > > > On Wed, Jun 04, 2008 at 11:06:01PM +0200, Arno J. Klaassen wrote: > > > > > > Hello, > > > > > > this is probably a FAQ and/or I'm to tired, but I'd be pleased > > > if anyone can tell me what I do wrong : > > > > > > I have a box with two interfaces, one connected to my lan > > > (172.16. ), one to a test-box (192.168.1.1) : > > > > > > em0: flags=8843 metric 0 mtu 15 > 00 > > > options=9b > > > ether xxx > > > inet 172.16.1.240 netmask 0xffffff00 broadcast 172.16.1.255 > > > media: Ethernet autoselect (1000baseTX ) > > > status: active > > > > > > em1: flags=8843 metric 0 mtu 15 > 00 > > > options=9b > > > ether xxx > > > inet 192.168.1.254 netmask 0xffffff00 broadcast 192.168.1.255 > > > media: Ethernet autoselect (1000baseTX ) > > > status: active > > > > > > > > > I enable ip.forwarding : > > > > > > # sysctl net.inet.ip.forwarding > > > net.inet.ip.forwarding: 1 > > > > > > > > > And this is my routing table : > > > > > > Internet: > > > Destination Gateway Flags Refs Use Netif Expi > re > > > default 172.16.1.254 UGS 0 20 em0 > > > 127.0.0.1 127.0.0.1 UH 0 0 lo0 > > > 172.16.1.0/24 link#3 UC 0 0 em0 > > > 172.16.1.6 xxxxxxxxxxxxxxxxx UHLW 1 87 em0 11 > 94 > > > 172.16.1.230 xxxxxxxxxxxxxxxxx UHLW 1 286 em0 5 > 72 > > > 172.16.1.240 xxxxxxxxxxxxxxxxx UHLW 1 0 lo0 > > > 172.16.1.254 xxxxxxxxxxxxxxxxx UHLW 2 0 em0 4 > 87 > > > 192.168.1.0/24 link#4 UC 0 0 em1 > > > 192.168.1.1 xxxxxxxxxxxxxxxxx UHLW 1 2 em1 6 > 16 > > > 192.168.1.254 xxxxxxxxxxxxxxxxx UHLW 1 0 lo0 > > > > > > For this I added to rc.conf : > > > > > > static_routes="test lan" > > > route_test="-net 192.168.1.0/24 192.168.1.254" > > > route_lan="-net 172.16.1.0/24 172.16.1.240" > > > > I'm pretty sure that you don't need these three lines. Turning > > net.inet.ip.forwarding on should be enough. > I feel this is /me still not fully understand routing tables. This is your topology, right? test-box main-box gateway [192.168.1.1]------[192.168.1.254 172.16.1.240]-------[172.16.1.254 On the test-box set default route to 192.168.1.254. On the main-box set net.inet.ip.forwarding 1 but remove the static routes. But how would machines on the 172.16.1.0/24 net know they must send packets for 192.168.1.0/24 to 172.16.1.240? For that you need static routes on all the machines on 172.16.1.0/24 that need to read your test box. From max at love2party.net Thu Jun 5 00:56:59 2008 From: max at love2party.net (Max Laier) Date: Thu Jun 5 00:57:03 2008 Subject: Understanding the interplay of ipfw, vlan, and carp In-Reply-To: <20080604081443.GJ1028@server.vk2pj.dyndns.org> References: <200803041351.46053.fjwcash@gmail.com> <36735.192.168.4.151.1204669226.squirrel@router> <20080604081443.GJ1028@server.vk2pj.dyndns.org> Message-ID: <200806050256.30476.max@love2party.net> On Wednesday 04 June 2008 10:14:43 Peter Jeremy wrote: > On 2008-Mar-04 23:20:26 +0100, Max Laier wrote: > >You could try the attached patch. It adds carpdev support. You'll > > have to recompile ifconfig to make use of it. > > I have just tried it and found that it does precisely the opposite of > what I want :-( > > My situation: At work, I have a NAT box that is used to translate > between our corporate intranet and my department's test models. There > is (basically) 1:1 NAT and I use proxy-ARP on the intranet side (though > I have gateway IPs on the internal side). I am trying to convert this > to use CARP for failover. > > My external interface config currently looks like: > ifconfig vlan10 10.10.10.1 vlandev fxp0 vlan 10 > arp -s 10.10.10.2 auto pub > arp -s 10.10.10.3 auto pub > arp -s 10.10.10.4 auto pub > arp -s 10.10.10.5 auto pub > > Ideally, I want to attach a carp device to vlan10 so I can do > ifconfig vlan10 10.10.10.1 vlandev fxp0 vlan 10 > ifconfig carp10 vhid 10 carpdev vlan10 > arp -s 10.10.10.2 00:00:5e:00:01:0a pub > arp -s 10.10.10.3 00:00:5e:00:01:0a pub > arp -s 10.10.10.4 00:00:5e:00:01:0a pub > arp -s 10.10.10.5 00:00:5e:00:01:0a pub > ie the IP address remains with the specific box (the backup box has > its own IP address). Unfortunately, the current carpdev code doesn't > work this way: It lets me not assign an IP address to vlan10 but I > still have to assign an IP address to carp10 (and it uses the latter > address rather than the former address in the carp advertisements). > > Does what I want make sense to you and can you see any way it could be > integrated into your carpdev patches. Sorry, I don't quite understand what you are after here. Can you give a network layout and more details on the objective? > Note that one downside of your carpdev patches is that (AFAIK) it is > no longer possible to identify which host sent the packet: The source > and destination MAC addresses, as well as the destination IP address > are all defined by CARP. Once you change the source IP address to be > the shared address there's nothing to identify which host sent it. That's the point of CARP: *Transparent* address failover. In order to provide that you have to hide the identity of the actual host. If you want to talk to the individual hosts you have to assign them an IP of their own and if you do that you don't need the carpdev patch. > Finally, can anyone point me to a protocol specification for CARP. > The only documentation I can find in either FreeBSD or OpenBSD is > basically limited to "it's like VRRP but different to avoid the CISCO > patent on HSRP". Take a look at: http://www.countersiege.com/doc/pfsync-carp/ Really good pictures to get the gist of it. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From linimon at FreeBSD.org Thu Jun 5 02:35:51 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu Jun 5 02:35:53 2008 Subject: kern/122928: [em] interface watchdog timeouts and stops receiving packets Message-ID: <200806050235.m552ZpPW019965@freefall.freebsd.org> Synopsis: [em] interface watchdog timeouts and stops receiving packets State-Changed-From-To: feedback->open State-Changed-By: linimon State-Changed-When: Thu Jun 5 02:35:42 UTC 2008 State-Changed-Why: Feedback received. http://www.freebsd.org/cgi/query-pr.cgi?pr=122928 From agaviola at infoweapons.com Thu Jun 5 03:23:46 2008 From: agaviola at infoweapons.com (Archimedes S. Gaviola) Date: Thu Jun 5 03:23:50 2008 Subject: [Regarding FreeBSD and RFC Compliance] In-Reply-To: <48451786.3040002@infoweapons.com> References: <4844A646.8010809@infoweapons.com> <4844CA2F.2030805@FreeBSD.org> <48451786.3040002@infoweapons.com> Message-ID: <484758A5.2050808@infoweapons.com> Archimedes S. Gaviola wrote: > Bruce M. Simpson wrote: >> Archimedes S. Gaviola wrote: >>> To Whom It May Concerned: >>> >>> Good day! Is there any document or web site that lists all the >>> standard Request for Comments (RFCs) for all the networking >>> protocols currently implemented on FreeBSD? This will help users >>> identify what specific sections of a standard a certain network >>> protocol is being implemented especially interoperability with other >>> platforms. >> >> No, want to compile one and contribute it to the project? We'd be >> very grateful for the help. >> >> cheers >> BMS >> > Ah okay, so this is still a window of opportunity for now but > unfortunately I'm currently pre-occupied with my time. I might > contribute on this someday. > By the way, I want to share the IPv6 conformance test results from TAHI project (www.tahi.org) because they are working on IPv6 conformance tools. On their web site, a FreeBSD-6.1 were tested for IPv6 core protocols conformance both router mode http://www.tahi.org/logo/phase2-core/result/Self_Test_4-0-1/freebsd61.router/ and host mode http://www.tahi.org/logo/phase2-core/result/Self_Test_4-0-1/freebsd61.host/. From adrian at freebsd.org Thu Jun 5 03:33:04 2008 From: adrian at freebsd.org (Adrian Chadd) Date: Thu Jun 5 03:33:06 2008 Subject: samba performance on 1Gig link: how to replace black magic with science? And why TCP windows scaling is not in play? In-Reply-To: <1761236634.20080604234231@serebryakov.spb.ru> References: <1761236634.20080604234231@serebryakov.spb.ru> Message-ID: Figure out why window scaling isn't working - look at the options being negotiated (use tcpdump) and try to figure out which side isn't offering or is rejecting window size scaling negotiation. CIFS isn't the same profile as iperf/etc - its not just shovelling raw data down the socket, there's a whole protocol involved in scheduling what to transfer. Latency in handling commands screws your performance.. Adrian 2008/6/5 Lev Serebryakov : > Hello, net. > > I'm setupping file server for WindowsXP/SP3 clients, based on > FreeBSD 7.0-Stable nad latest samba port. > > First of all, Is et these kernel variables: > > kern.ipc.maxsockbuf=16777216 > net.inet.tcp.sendbuf_max=16777216 > net.inet.tcp.recvbuf_max=16777216 > net.inet.tcp.sendspace=131072 > net.inet.tcp.recvspace=131072 > > All tests are performed with only one client for start. Server and > client are linked with 1Gig link, jumbo frames are enabled (9014 > bytes) and iperf shows about 900Mbit/s of raw TCP with big windows > (about 256Kb for start). > > Local tests shows 75Mb/s Read/write from/to shared file system with > big files. > > Default configuration of samba gives me only 20Mb/s read and loosy > 15Mb/s write. > > With "socket options = TCP_NODELAY" speed becomes 25/20 Mb/S R/W. > > Then I start to change SO_RCVBUF/SO_SNDBUF and found (with binary > search), that best values are 49152. Yes, this strange values. 65536 > is worse, and 32768 is worse too. This magic value gives me about > 40MB/s read and 30-35Mb/s write. > > "Recommended" 8192 gives me 40K/s read (YES, 40 _K_ilobytes per > second!) > > But I don't like this situation. Why? Because, it is black magic, > not science. Why 49152? How can this value be found without binary > search? What affects this value? > > Second problem is about TCP windows, which can give more thoughtput > on 1Gig link. I've tried to tcpdump traffic between samba and WinXP > client, and it shows, that window scaling is turned off. Always. It is > enabled on WinXP client, it is enabled on FreeBSD server, it us used > by iperf (with great effect), but not by samba! What do I do wrong? > > -- > // Black Lion AKA Lev Serebryakov > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Adrian Chadd - adrian@freebsd.org From zuan at mylinux.net.my Thu Jun 5 04:27:21 2008 From: zuan at mylinux.net.my (Izwan Mohd) Date: Thu Jun 5 04:27:25 2008 Subject: network keep droping In-Reply-To: <20080604194059.GE1028@server.vk2pj.dyndns.org> References: <20080604194059.GE1028@server.vk2pj.dyndns.org> Message-ID: > First question would be: What has changed? > > Are you able to identify when the problem occurs? This might let you > associate the problem with an internal cronjob or network activity. it randomly happen so I can't determine when it happen my cron script just try to ping and if it not successfull it will flush and restart the network > > What does ifconfig report? Does the interface look normal or is it > reporting something strange? ifconfig does not show any abnormality but maybe I will double check it Is the switch reporting any events associated with your port? > Nope no report from switch indicating something wrong the the port that the machine are using > What do you see if you tcpdump the interface whilst its not working? > Are you seeing normal subnet broadcast traffic? Unicast traffic > directed to your box? Outgoing traffic from your box? > I will check this one this afternoon because the machine is dead again I'll post the finding later on > > Does physically unplugging and re-connecting the network cable > correct the problem? Are you able to (temporarily) use a different > swichport or NIC? > sometime it does sometime it wont, already try changing to other port on the switch still the same, changing the NIC is not an option for me because it a rack mount server using on board NIC and no extra slot to add a new network card on it. > Finally, more detail on your configuration might trigger someone's > memory: What version of 6.x? What NIC/MII? How much memory? What > network features (vlan, firewall, dummynet, netgraph, carp, ...) are > you using? > The server using FreeBSD 6.0-RELEASE the NIC is intel i can't remember the model but freebsd detect it as "em0" the server memory is 1GB, not special network fetures it only running snort and nessus will post more detail after I check the machine this afternoon Thank You, Regards, Zuan > > -- > Peter Jeremy > Please excuse any delays as the result of my ISP's inability to implement > an MTA that is either RFC2821-compliant or matches their claimed behaviour. > -- Izwan Mohd Malaysian Linux Community http://mylinux.net.my From bms at FreeBSD.org Thu Jun 5 06:39:59 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Thu Jun 5 06:40:03 2008 Subject: Understanding the interplay of ipfw, vlan, and carp In-Reply-To: <20080604081443.GJ1028@server.vk2pj.dyndns.org> References: <200803041351.46053.fjwcash@gmail.com> <36735.192.168.4.151.1204669226.squirrel@router> <20080604081443.GJ1028@server.vk2pj.dyndns.org> Message-ID: <48478A3C.6070107@FreeBSD.org> Peter Jeremy wrote: > Note that one downside of your carpdev patches is that (AFAIK) it is > no longer possible to identify which host sent the packet: The source > and destination MAC addresses, as well as the destination IP address > are all defined by CARP. Once you change the source IP address to be > the shared address there's nothing to identify which host sent it. > If you really, really wanted to, you could write code to prepend the original IP or MAC as an experimental IP option. Options less than <0x80 are not forwarded in IP fragments. I can understand why you'd want to do this (debugging springs to mind), though it does go against the gist of what carp is and does. Also, there is compatibility to keep in mind, and it's entirely possible that the presence of a new and unknown IP option is going to break implementations which don't parse IP option headers correctly, or trigger other unwanted behaviour ("I don't know what this IP option is therefore I will drop it"). From zuan at mylinux.net.my Thu Jun 5 09:09:47 2008 From: zuan at mylinux.net.my (Izwan Mohd) Date: Thu Jun 5 09:09:54 2008 Subject: network keep droping In-Reply-To: References: <20080604194059.GE1028@server.vk2pj.dyndns.org> Message-ID: Update: just got back from the remote site and checked the following: 1. tcpdump on the interface only show switch broadcast nothing more 2. the connection restored by doing arp -ad && ping On Thu, Jun 5, 2008 at 12:27 PM, Izwan Mohd wrote: > > First question would be: What has changed? >> >> Are you able to identify when the problem occurs? This might let you >> associate the problem with an internal cronjob or network activity. > > > it randomly happen so I can't determine when it happen my cron script just > try to ping and if it not successfull it will flush and restart the network > >> >> What does ifconfig report? Does the interface look normal or is it >> reporting something strange? > > > ifconfig does not show any abnormality but maybe I will double check it > > Is the switch reporting any events associated with your port? >> > > Nope no report from switch indicating something wrong the the port that > the machine are using > > >> What do you see if you tcpdump the interface whilst its not working? >> Are you seeing normal subnet broadcast traffic? Unicast traffic >> directed to your box? Outgoing traffic from your box? >> > > I will check this one this afternoon because the machine is dead again > I'll post the finding later on > > >> >> Does physically unplugging and re-connecting the network cable >> correct the problem? Are you able to (temporarily) use a different >> swichport or NIC? >> > > sometime it does sometime it wont, already try changing to other port on > the switch still the same, changing the NIC is not an option for me because > it a rack mount server using on board NIC and no extra slot to add a new > network card on it. > > >> Finally, more detail on your configuration might trigger someone's >> memory: What version of 6.x? What NIC/MII? How much memory? What >> network features (vlan, firewall, dummynet, netgraph, carp, ...) are >> you using? >> > > The server using FreeBSD 6.0-RELEASE the NIC is intel i can't remember the > model but freebsd detect it as "em0" the server memory is 1GB, not special > network fetures it only running snort and nessus > > will post more detail after I check the machine this afternoon > > Thank You, > > Regards, > Zuan > >> >> -- >> Peter Jeremy >> Please excuse any delays as the result of my ISP's inability to implement >> an MTA that is either RFC2821-compliant or matches their claimed >> behaviour. >> > From freebsd-net at pp.dyndns.biz Thu Jun 5 09:10:59 2008 From: freebsd-net at pp.dyndns.biz (PP) Date: Thu Jun 5 09:11:06 2008 Subject: network keep droping In-Reply-To: References: Message-ID: <4847A8BE.4010201@pp.dyndns.biz> Izwan Mohd wrote: > Hi, > > I have being encountering a weird problem on my freebsd 6 , one of my remote > machine being down frequently lately for no particular reason, when I go to > the remote site to check then machine it was in good running condition but > no network, it even can't ping the server on the same subnet, the only way > to restore it back is by running: > > route -n flush && /etc/netstart > > but because it a remote machine it really troublesome to do that each time > the machine is down, I resorted to use a crontab scripts to automatically > run the previous command when it down, even tho that partial of the problem > is solve I still need to know what causing it. can anyone could advise me > where to start digging?? they is no any particular error in the log or dmseg > when the machine dropped it connection so I'm stuck here don't know where to > start, some help should clear something up for me > > TQ This sounds vaguely similar to what I've experienced myself with an onboard em0 on a Supermicro mainboard. NIC suddenly stopped working for no appearent reason. Believing the NIC was bad I throw in an extra NIC and ran the machine from that. But within a month a capacitor blew in the PSU and when I replaced the PSU the onboard NIC worked again. This scenario repeated 3 times in exactly the same way before I switched to another PSU brand and haven't had any problems since. In my case I couldn't get the NIC running with a simple flushing of the routes though. But if nothing has changed in the software on the machine you should probably start looking at the hardware. /PP From lev at serebryakov.spb.ru Thu Jun 5 11:20:00 2008 From: lev at serebryakov.spb.ru (Lev A. Serebryakov) Date: Thu Jun 5 11:20:05 2008 Subject: samba performance on 1Gig link: how to replace black magic with science? And why TCP windows scaling is not in play? In-Reply-To: References: <1761236634.20080604234231@serebryakov.spb.ru> Message-ID: <4847CC58.4060104@serebryakov.spb.ru> Adrian Chadd wrote: > Figure out why window scaling isn't working - look at the options > being negotiated (use tcpdump) and try to figure out which side isn't > offering or is rejecting window size scaling negotiation. FreeBSD suggest scaling 9, Windows -- scaling 0. After that FreeBSD uses scaling, but windows is 49152 (scaled! 0x0060 in header!) always from FreeBSD to Win due to SO_RCVBUF=49152. Without this option window is 130560, but speed is MUCH worse! > CIFS isn't the same profile as iperf/etc - its not just shovelling raw > data down the socket, there's a whole protocol involved in scheduling > what to transfer. Latency in handling commands screws your > performance.. But how this "magic values" in socket buffers can be explained? As far as I know, there are "big read/big write" commands in CIFS, which allows use more than 64K in one operation? -- // Lev Sserebryakov From marc.loerner at hob.de Thu Jun 5 15:13:08 2008 From: marc.loerner at hob.de (Marc =?iso-8859-1?q?L=F6rner?=) Date: Thu Jun 5 15:13:15 2008 Subject: Probable Bug in tcp.h Message-ID: <200806051712.47048.marc.loerner@hob.de> Hello, I probably found a bug in declaration of "struct tcphdr"! struct tcphdr { u_short th_sport; /* source port */ u_short th_dport; /* destination port */ tcp_seq th_seq; /* sequence number */ tcp_seq th_ack; /* acknowledgement number */ #if BYTE_ORDER == LITTLE_ENDIAN u_int th_x2:4, /* (unused) */ <---here th_off:4; /* data offset */ <--- #endif #if BYTE_ORDER == BIG_ENDIAN u_int th_off:4, /* data offset */ th_x2:4; /* (unused) */ #endif u_char th_flags; First of all I have the problam of misalignment of th_off. Because in this way always 4 bytes are read and the the bits of th_off are replaced. Then the 4 bytes are written back. But should (th_x and th_off) not only be 1 byte in whole -> only read and write 1 byte? I think if this was changed, my misalignment problems would go away! I'll appreciate any thoughts on this! Regards, Marc P.S.: Please cc me because I'm not on the list! From rpaulo at FreeBSD.org Thu Jun 5 15:56:55 2008 From: rpaulo at FreeBSD.org (Rui Paulo) Date: Thu Jun 5 15:57:01 2008 Subject: Probable Bug in tcp.h In-Reply-To: <200806051712.47048.marc.loerner@hob.de> References: <200806051712.47048.marc.loerner@hob.de> Message-ID: <20080605155646.GC6864@epsilon.local> On Thu, Jun 05, 2008 at 05:12:47PM +0200, =?ISO-8859-1?Q?Marc_L=F6rner_ wrote: > Hello, > I probably found a bug in declaration of "struct tcphdr"! > > struct tcphdr { > u_short th_sport; /* source port */ > u_short th_dport; /* destination port */ > tcp_seq th_seq; /* sequence number */ > tcp_seq th_ack; /* acknowledgement number */ > #if BYTE_ORDER == LITTLE_ENDIAN > u_int th_x2:4, /* (unused) */ <---here > th_off:4; /* data offset */ <--- > #endif > #if BYTE_ORDER == BIG_ENDIAN > u_int th_off:4, /* data offset */ > th_x2:4; /* (unused) */ > #endif > u_char th_flags; > > First of all I have the problam of misalignment of th_off. Because in this way > always 4 bytes are read and the the bits of th_off are replaced. Then the 4 > bytes are written back. > > But should (th_x and th_off) not only be 1 byte in whole -> only read and > write 1 byte? > > I think if this was changed, my misalignment problems would go away! I'm not sure what you mean. Please supply more information, like: 1) Are you running on little endian? Or big endian? 2) th_x2 + th_off are 1 byte in size. What do you mean? 3) What is exactly the effect? I don't understand the "replaced", "written back" etc. sentence. Regards, -- Rui Paulo From bms at FreeBSD.org Thu Jun 5 16:09:12 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Thu Jun 5 16:09:15 2008 Subject: Probable Bug in tcp.h In-Reply-To: <200806051712.47048.marc.loerner@hob.de> References: <200806051712.47048.marc.loerner@hob.de> Message-ID: <48480FA5.3020800@FreeBSD.org> Marc L?rner wrote: > .. > First of all I have the problam of misalignment of th_off. Because in this way > always 4 bytes are read and the the bits of th_off are replaced. Then the 4 > bytes are written back. > > But should (th_x and th_off) not only be 1 byte in whole -> only read and > write 1 byte? > Which machine architecture are you attempting to compile this code on? On FreeBSD Tier 1 platforms, the access is probably going to come out of L2 cache anyway, so the fields in question will be read by a burst cycle. It is worth noting that NetBSD changed the base type of tcphdr's bitfields to uint8_t, however this shuffles the compiler dependency into the treatment of the "char" type. Most modern C compilers support "unsigned char". From raggen at passagen.se Thu Jun 5 19:08:09 2008 From: raggen at passagen.se (Roger Olofsson) Date: Thu Jun 5 19:08:16 2008 Subject: network keep droping In-Reply-To: <4847A8BE.4010201@pp.dyndns.biz> References: <4847A8BE.4010201@pp.dyndns.biz> Message-ID: <48483297.5030809@passagen.se> PP skrev: > Izwan Mohd wrote: >> Hi, >> >> I have being encountering a weird problem on my freebsd 6 , one of my >> remote >> machine being down frequently lately for no particular reason, when I >> go to >> the remote site to check then machine it was in good running condition >> but >> no network, it even can't ping the server on the same subnet, the only >> way >> to restore it back is by running: >> >> route -n flush && /etc/netstart >> >> but because it a remote machine it really troublesome to do that each >> time >> the machine is down, I resorted to use a crontab scripts to automatically >> run the previous command when it down, even tho that partial of the >> problem >> is solve I still need to know what causing it. can anyone could advise me >> where to start digging?? they is no any particular error in the log or >> dmseg >> when the machine dropped it connection so I'm stuck here don't know >> where to >> start, some help should clear something up for me >> >> TQ > > This sounds vaguely similar to what I've experienced myself with an > onboard em0 on a Supermicro mainboard. NIC suddenly stopped working for > no appearent reason. Believing the NIC was bad I throw in an extra NIC > and ran the machine from that. But within a month a capacitor blew in > the PSU and when I replaced the PSU the onboard NIC worked again. This > scenario repeated 3 times in exactly the same way before I switched to > another PSU brand and haven't had any problems since. In my case I > couldn't get the NIC running with a simple flushing of the routes > though. But if nothing has changed in the software on the machine you > should probably start looking at the hardware. > /PP > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG. > Version: 8.0.100 / Virus Database: 270.0.0/1484 - Release Date: 2008-06-04 16:40 Is it on DHCP? Sounds like it's lost the lease or the default route? /R From max at love2party.net Thu Jun 5 19:31:57 2008 From: max at love2party.net (Max Laier) Date: Thu Jun 5 19:32:01 2008 Subject: anyone tried the Multi routing table code yet? In-Reply-To: <483FCCBC.6040802@elischer.org> References: <483763B5.4030205@elischer.org> <64de5c8b0805300118v3874ec3bx2b2978a80bae08b8@mail.gmail.com> <483FCCBC.6040802@elischer.org> Message-ID: <200806052131.23063.max@love2party.net> On Friday 30 May 2008 11:45:32 Julian Elischer wrote: > Rajkumar S wrote: > > On Sat, May 24, 2008 at 6:09 AM, Julian Elischer wrote: > >> subject says it all really.. > > > > I am using pf and rtable to setfib and get an pfctl: DIOCADDRULE: > > Device busy when trying to load "pass in quick on fxp0 from any to > > any keep state rtable 1" > > I'm not really familiar with the pf syntax > as I didn't do that part of the patch (max laier (CC'd) did) > and I don't use pf. > > Max may be able to see if the patch to the pf code ahs an error. See attached - stupid error, my bad. Confirmed to work now, with limited testing, though. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News -------------- next part -------------- An embedded message was scrubbed... From: Max Laier Subject: svn commit: r179570 - head/sys/contrib/pf/net Date: Thu, 5 Jun 2008 19:30:20 +0000 (UTC) Size: 3588 Url: http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080605/3160223f/attachment.eml From arno at heho.snv.jussieu.fr Thu Jun 5 21:01:32 2008 From: arno at heho.snv.jussieu.fr (Arno J. Klaassen) Date: Thu Jun 5 21:01:36 2008 Subject: IP-forwarding (help) In-Reply-To: <20080605000622.6481A5B46@mail.bitblocks.com> References: <20080605000622.6481A5B46@mail.bitblocks.com> Message-ID: Bakul Shah writes: > On 05 Jun 2008 01:33:05 +0200 "Arno J. Klaassen" wrote: > > Petar Bogdanovic writes: > > > > > On Wed, Jun 04, 2008 at 11:06:01PM +0200, Arno J. Klaassen wrote: > > > > > > > > [ problem description ] > > I feel this is /me still not fully understand routing tables. > > This is your topology, right? yes > test-box main-box gateway > [192.168.1.1]------[192.168.1.254 172.16.1.240]-------[172.16.1.254 > > On the test-box set default route to 192.168.1.254. > On the main-box set net.inet.ip.forwarding 1 but remove the > static routes. > > But how would machines on the 172.16.1.0/24 net know they > must send packets for 192.168.1.0/24 to 172.16.1.240? For > that you need static routes on all the machines on > 172.16.1.0/24 that need to read your test box. Yes, of course ... Thank you very much (I felt it were a simple problem, but somehow blocked finding the solution). Best regards, Arno From crapsh at monkeybrains.net Fri Jun 6 02:21:03 2008 From: crapsh at monkeybrains.net (Support (Rudy)) Date: Fri Jun 6 02:21:08 2008 Subject: vlan oddness Message-ID: <48489F0E.3030203@monkeybrains.net> I created and destoryed, brought up and down a vlan... now it is not accepting an IP.... what does the 'File exists' mean? #ifconfig vlan9 vlan9: flags=8843 metric 0 mtu 1500 options=3 ether 00:30:48:5c:ba:9c media: Ethernet autoselect (1000baseTX ) status: active vlan: 9 parent interface: em0 # ifconfig vlan9 10.5.43.225/27 ifconfig: ioctl (SIOCAIFADDR): File exists Also, I don't have the IP/net assigned on any IPs: # ifconfig | grep inet inet 10.5.40.8 netmask 0xffffff00 inet 10.5.42.254 netmask 0xffffff80 inet 64.215.30.154 netmask 0xfffffffc inet 127.0.0.1 netmask 0xff000000 inet 10.9.212.1 netmask 0xfffffe00 inet 10.5.41.1 netmask 0xffffff00 inet 10.9.2215.225 netmask 0xffffffe0 inet 10.9.215.9 netmask 0xfffffffc inet 10.77.0.6 netmask 0xffffff00 inet 10.5.42.126 netmask 0xffffff80 inet 10.99.0.1 netmask 0xffffff00 probably a reboot will fix it, but if anyone has seen this oddness, let me know if you found out what caused it. (Running fresh freebsd 7.0-STABLE) Rudy From paul at gtcomm.net Fri Jun 6 02:27:32 2008 From: paul at gtcomm.net (Paul) Date: Fri Jun 6 02:27:37 2008 Subject: vlan oddness In-Reply-To: <48489F0E.3030203@monkeybrains.net> References: <48489F0E.3030203@monkeybrains.net> Message-ID: <4848A106.9050709@gtcomm.net> Probably still in the routing table and didn't get removed when the interface was destroyed.. do a route get 10.5.43.225 Support (Rudy) wrote: > > I created and destoryed, brought up and down a vlan... now it is not > accepting an IP.... what does the 'File exists' mean? > > #ifconfig vlan9 > vlan9: flags=8843 metric 0 mtu > 1500 > options=3 > ether 00:30:48:5c:ba:9c > media: Ethernet autoselect (1000baseTX ) > status: active > vlan: 9 parent interface: em0 > > # ifconfig vlan9 10.5.43.225/27 > ifconfig: ioctl (SIOCAIFADDR): File exists > > Also, I don't have the IP/net assigned on any IPs: > # ifconfig | grep inet > inet 10.5.40.8 netmask 0xffffff00 > inet 10.5.42.254 netmask 0xffffff80 > inet 64.215.30.154 netmask 0xfffffffc > inet 127.0.0.1 netmask 0xff000000 > inet 10.9.212.1 netmask 0xfffffe00 > inet 10.5.41.1 netmask 0xffffff00 > inet 10.9.2215.225 netmask 0xffffffe0 > inet 10.9.215.9 netmask 0xfffffffc > inet 10.77.0.6 netmask 0xffffff00 > inet 10.5.42.126 netmask 0xffffff80 > inet 10.99.0.1 netmask 0xffffff00 > > probably a reboot will fix it, but if anyone has seen this oddness, > let me know if you found out what caused it. > (Running fresh freebsd 7.0-STABLE) > > Rudy > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From crapsh at monkeybrains.net Fri Jun 6 02:42:17 2008 From: crapsh at monkeybrains.net (Support (Rudy)) Date: Fri Jun 6 02:42:22 2008 Subject: vlan oddness In-Reply-To: <4848A106.9050709@gtcomm.net> References: <48489F0E.3030203@monkeybrains.net> <4848A106.9050709@gtcomm.net> Message-ID: <4848A408.4070008@monkeybrains.net> Paul wrote: > Probably still in the routing table Yep. Had to go into quagga and delete the route... :) moved GW from another router to another. Thanks, Rudy From zuan at mylinux.net.my Fri Jun 6 05:57:34 2008 From: zuan at mylinux.net.my (Izwan Mohd) Date: Fri Jun 6 05:57:38 2008 Subject: network keep droping In-Reply-To: <48483297.5030809@passagen.se> References: <4847A8BE.4010201@pp.dyndns.biz> <48483297.5030809@passagen.se> Message-ID: Hi, > > > Is it on DHCP? Sounds like it's lost the lease or the default route? > > /R > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > Nope it not on DHCP it using static configuration and even to eliminate fw issue I even put it before firewall without going thru firewall it just use my ISP default router as it gateway tks From marc.loerner at hob.de Fri Jun 6 07:30:50 2008 From: marc.loerner at hob.de (Marc =?iso-8859-1?q?L=F6rner?=) Date: Fri Jun 6 07:30:53 2008 Subject: Probable Bug in tcp.h In-Reply-To: <20080605155646.GC6864@epsilon.local> References: <200806051712.47048.marc.loerner@hob.de> <20080605155646.GC6864@epsilon.local> Message-ID: <200806060930.28527.marc.loerner@hob.de> On Thursday 05 June 2008 17:56, Rui Paulo wrote: > On Thu, Jun 05, 2008 at 05:12:47PM +0200, =?ISO-8859-1?Q?Marc_L=F6rner_ wrote: > > Hello, > > I probably found a bug in declaration of "struct tcphdr"! > > > > struct tcphdr { > > u_short th_sport; /* source port */ > > u_short th_dport; /* destination port */ > > tcp_seq th_seq; /* sequence number */ > > tcp_seq th_ack; /* acknowledgement number */ > > #if BYTE_ORDER == LITTLE_ENDIAN > > u_int th_x2:4, /* (unused) */ <---here > > th_off:4; /* data offset */ <--- > > #endif > > #if BYTE_ORDER == BIG_ENDIAN > > u_int th_off:4, /* data offset */ > > th_x2:4; /* (unused) */ > > #endif > > u_char th_flags; > > > > First of all I have the problam of misalignment of th_off. Because in > > this way always 4 bytes are read and the the bits of th_off are replaced. > > Then the 4 bytes are written back. > > > > But should (th_x and th_off) not only be 1 byte in whole -> only read and > > write 1 byte? > > > > I think if this was changed, my misalignment problems would go away! > > I'm not sure what you mean. > > Please supply more information, like: > 1) Are you running on little endian? Or big endian? I'm on itanium-architecture, therefore I can run big and little endian. But for now it is little endian. > 2) th_x2 + th_off are 1 byte in size. What do you mean? th_x2 and th_off are created as a bitfield. But C-Standard says that bitfields are accessed as integers => 4-bytes On itanium integers are read with ld4-command but the address of th_x2/th_off may not be aligned to 4-bytes => we get an unaligned reference fault. If we'd change to 1 byte-accesses => I won't get any misaligned faults anymore. Hope this makes my dilemma a bit clearer, Marc From marc.loerner at hob.de Fri Jun 6 07:36:41 2008 From: marc.loerner at hob.de (Marc =?iso-8859-1?q?L=F6rner?=) Date: Fri Jun 6 07:36:44 2008 Subject: Probable Bug in tcp.h In-Reply-To: <48480FA5.3020800@FreeBSD.org> References: <200806051712.47048.marc.loerner@hob.de> <48480FA5.3020800@FreeBSD.org> Message-ID: <200806060936.20113.marc.loerner@hob.de> On Thursday 05 June 2008 18:09, Bruce M. Simpson wrote: > Marc L?rner wrote: > > .. > > First of all I have the problam of misalignment of th_off. Because in > > this way always 4 bytes are read and the the bits of th_off are replaced. > > Then the 4 bytes are written back. > > > > But should (th_x and th_off) not only be 1 byte in whole -> only read and > > write 1 byte? > > Which machine architecture are you attempting to compile this code on? > ia64/itanium > On FreeBSD Tier 1 platforms, the access is probably going to come out of > L2 cache anyway, so the fields in question will be read by a burst cycle. > I know! But the problem (on itanium) is that bitfields are always accessed as integers => 4-byte access But th_x/th_off may not always be aligned to 4-bytes => I get an unalignment reference fault If access of th_x/th_off could be changed to 1-byte => 1-byte aligned => my unaligned reference fault would go away > It is worth noting that NetBSD changed the base type of tcphdr's > bitfields to uint8_t, however this shuffles the compiler dependency into > the treatment of the "char" type. Most modern C compilers support > "unsigned char". Does this really change the access to 1-byte? As in "Programming in C" by Kernighan and Ritchie is stated that bitfields must and will always be defined as ints. From bms at FreeBSD.org Fri Jun 6 07:40:13 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Fri Jun 6 07:40:19 2008 Subject: Probable Bug in tcp.h In-Reply-To: <200806060930.28527.marc.loerner@hob.de> References: <200806051712.47048.marc.loerner@hob.de> <20080605155646.GC6864@epsilon.local> <200806060930.28527.marc.loerner@hob.de> Message-ID: <4848E9DA.8090802@FreeBSD.org> Marc L?rner wrote: > th_x2 and th_off are created as a bitfield. But C-Standard says that bitfields > are accessed as integers => 4-bytes > > On itanium integers are read with ld4-command but the address of th_x2/th_off > may not be aligned to 4-bytes => we get an unaligned reference fault. > > If we'd change to 1 byte-accesses => I won't get any misaligned faults > anymore. > It's worth noting that Linux implements its version of tcphdr using a 32-bit-wide bitfield and the TCP header flags live there as bits instead of as integer quantities. I think it should be OK to change the u_int to a uint8_t as NetBSD has. The problem with bitfields in "signed char" is that they can become unintentionally sign extended on a read, and for many years compilers only supported "char", not "unsigned char". Does anyone see a reason why we should not make this change? From ganbold at micom.mng.net Fri Jun 6 07:49:43 2008 From: ganbold at micom.mng.net (Ganbold) Date: Fri Jun 6 07:49:48 2008 Subject: MFC of em/igb drivers In-Reply-To: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> References: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> Message-ID: <4848EC14.8060700@micom.mng.net> Jack Vogel wrote: > I got the new drivers in Friday afternoon for those that don't see CVS > messages. > > The igb driver is for 82575 and 82576 adapters, it has multiqueue support and > MSIX, there will be more server type enhancements in that driver as I get the > time. > > The em driver now will be client oriented, the latest hardware support however > is for 82574, Hartwell, which is a really nice low cost PCIE dual-port adapter, > that actually also has MSIX. This first released support for it will > use 3 interrupt > vectors, one for TX, one for RX, and Link. The hardware actually supports 5 > vectors, so I am planning to add support for another RX and TX queue as my > schedule allows. > > Hartwell is also the first adapter that has IEEE 1588 PTP support, the driver > provides init and an ioctl interface to use that facility, I hope we > see software > support follow on soon. This is an early announcement, I am not sure on > exact dates for availability but they should be soon. > > As ever, issues and bugs should be sent to me. Cheers everyone! > > Jack > Jack, I have Intel Gigabit card and FreeBSD-7.0-STABLE recognizes it as following: ... em0@pci0:0:25:0: class=0x020000 card=0x2800103c chip=0x104a8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82566DM Gigabit Network Connection' class = network subclass = ethernet ... # uname -an FreeBSD test.ub.mng.net 7.0-STABLE FreeBSD 7.0-STABLE #0: Thu Jun 5 11:12:34 ULAT 2008 tsgan@test.ub.mng.net:/usr/obj/usr/src/sys/FIREWALL i386 It has some problem, 1000baseTX connection status almost never goes to active in bridged mode, sometimes it goes to active but then immediately it goes to no carrier. (The other end is Cisco4507R, Gigabit Ethernet port) ... em0: flags=8943 metric 0 mtu 1500 options=198 ether 00:0f:fe:82:23:db media: Ethernet 1000baseTX (autoselect) status: no carrier ... Any idea how to solve this issue? thanks, Ganbold > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > > -- Q: How many pre-med's does it take to change a lightbulb? A: Five: One to change the bulb and four to pull the ladder out from under him. From peterjeremy at optushome.com.au Fri Jun 6 07:52:14 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Fri Jun 6 07:52:17 2008 Subject: Probable Bug in tcp.h In-Reply-To: <200806060930.28527.marc.loerner@hob.de> References: <200806051712.47048.marc.loerner@hob.de> <20080605155646.GC6864@epsilon.local> <200806060930.28527.marc.loerner@hob.de> Message-ID: <20080606075210.GD67629@server.vk2pj.dyndns.org> On 2008-Jun-06 09:30:28 +0200, Marc L?rner wrote: >th_x2 and th_off are created as a bitfield. But C-Standard says that >bitfields are accessed as integers => 4-bytes > >On itanium integers are read with ld4-command but the address of >th_x2/th_off may not be aligned to 4-bytes => we get an unaligned >reference fault. If the C compiler chooses to implement bitfields as a subset of a 32-bit integers, it is up to it to load an aligned 32-bit integer and shift/mask the result appropriately to extract the fields. In this particular case, th_x2/th_off are immediately preceeded by a tcp_seq (u_int32_t) field and so will have 32-bit alignment. Note that the presence of 32-bit fields in the definition for struct tcphdr means that the struct must be aligned to at least 32 bits. >If we'd change to 1 byte-accesses => I won't get any misaligned faults >anymore. I gather from this comment that you have some code using struct tcphdr that is getting alignment errors. struct tcphdr is extensively used in the TCP stack within the kernel so it's likely that any layout or alignment problem with it would show up there. I suspect you are dereferencing a mis-aligned struct tcphdr. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080606/53cdc978/attachment.pgp From marc.loerner at hob.de Fri Jun 6 08:25:58 2008 From: marc.loerner at hob.de (Marc =?iso-8859-1?q?L=F6rner?=) Date: Fri Jun 6 08:26:01 2008 Subject: Probable Bug in tcp.h In-Reply-To: <20080606075210.GD67629@server.vk2pj.dyndns.org> References: <200806051712.47048.marc.loerner@hob.de> <200806060930.28527.marc.loerner@hob.de> <20080606075210.GD67629@server.vk2pj.dyndns.org> Message-ID: <200806061025.37856.marc.loerner@hob.de> On Friday 06 June 2008 09:52, Peter Jeremy wrote: > On 2008-Jun-06 09:30:28 +0200, Marc L?rner wrote: > >th_x2 and th_off are created as a bitfield. But C-Standard says that > >bitfields are accessed as integers => 4-bytes > > > >On itanium integers are read with ld4-command but the address of > >th_x2/th_off may not be aligned to 4-bytes => we get an unaligned > >reference fault. > > If the C compiler chooses to implement bitfields as a subset of a > 32-bit integers, it is up to it to load an aligned 32-bit integer > and shift/mask the result appropriately to extract the fields. > > In this particular case, th_x2/th_off are immediately preceeded by > a tcp_seq (u_int32_t) field and so will have 32-bit alignment. Note > that the presence of 32-bit fields in the definition for struct tcphdr > means that the struct must be aligned to at least 32 bits. > > >If we'd change to 1 byte-accesses => I won't get any misaligned faults > >anymore. > > I gather from this comment that you have some code using struct tcphdr > that is getting alignment errors. struct tcphdr is extensively used > in the TCP stack within the kernel so it's likely that any layout or > alignment problem with it would show up there. I suspect you are > dereferencing a mis-aligned struct tcphdr. The funny thing is that the dereferencing occurs in "/usr/src/sys/netinet/tcp_input.c" in function tcp_input in line 550: /* * Check that TCP offset makes sense, * pull out TCP options and adjust length. XXX */ off = th->th_off << 2; <----- here if (off < sizeof (struct tcphdr) || off > tlen) { tcpstat.tcps_rcvbadoff++; goto drop; } So the misalignment may probably lie in TCP stack? From koitsu at FreeBSD.org Fri Jun 6 09:04:52 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Jun 6 09:05:05 2008 Subject: MFC of em/igb drivers In-Reply-To: <4848EC14.8060700@micom.mng.net> References: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> <4848EC14.8060700@micom.mng.net> Message-ID: <20080606090452.GA38593@eos.sc1.parodius.com> On Fri, Jun 06, 2008 at 03:49:40PM +0800, Ganbold wrote: > Jack Vogel wrote: >> I got the new drivers in Friday afternoon for those that don't see CVS >> messages. >> >> The igb driver is for 82575 and 82576 adapters, it has multiqueue support and >> MSIX, there will be more server type enhancements in that driver as I get the >> time. >> >> The em driver now will be client oriented, the latest hardware support however >> is for 82574, Hartwell, which is a really nice low cost PCIE dual-port adapter, >> that actually also has MSIX. This first released support for it will >> use 3 interrupt >> vectors, one for TX, one for RX, and Link. The hardware actually supports 5 >> vectors, so I am planning to add support for another RX and TX queue as my >> schedule allows. >> >> Hartwell is also the first adapter that has IEEE 1588 PTP support, the driver >> provides init and an ioctl interface to use that facility, I hope we >> see software >> support follow on soon. This is an early announcement, I am not sure on >> exact dates for availability but they should be soon. >> >> As ever, issues and bugs should be sent to me. Cheers everyone! > > I have Intel Gigabit card and FreeBSD-7.0-STABLE recognizes it as following: > ... > em0@pci0:0:25:0: class=0x020000 card=0x2800103c chip=0x104a8086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82566DM Gigabit Network Connection' > class = network > subclass = ethernet > ... > # uname -an > FreeBSD test.ub.mng.net 7.0-STABLE FreeBSD 7.0-STABLE #0: Thu Jun 5 > 11:12:34 ULAT 2008 tsgan@test.ub.mng.net:/usr/obj/usr/src/sys/FIREWALL > i386 > > > It has some problem, 1000baseTX connection status almost never goes to > active in bridged mode, sometimes > it goes to active but then immediately it goes to no carrier. (The other > end is Cisco4507R, Gigabit Ethernet port) > ... > em0: flags=8943 metric 0 > mtu 1500 > options=198 > ether 00:0f:fe:82:23:db > media: Ethernet 1000baseTX (autoselect) > status: no carrier > ... > > Any idea how to solve this issue? Have you tried disabling speed and duplex negotiation and explicitly stating speed and duplex like so? ifconfig_em0="... media 1000baseTX mediaopt full-duplex" Cisco switches have a notorious history of not being "friendly" with non-Cisco hardware. Forcing duplex on both ends of the link (that means on both the host side, and the Cisco side!) usually fixes it. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From ganbold at micom.mng.net Fri Jun 6 09:29:49 2008 From: ganbold at micom.mng.net (Ganbold) Date: Fri Jun 6 09:30:00 2008 Subject: MFC of em/igb drivers In-Reply-To: <20080606090452.GA38593@eos.sc1.parodius.com> References: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> <4848EC14.8060700@micom.mng.net> <20080606090452.GA38593@eos.sc1.parodius.com> Message-ID: <4849038A.5040007@micom.mng.net> Jeremy Chadwick wrote: > On Fri, Jun 06, 2008 at 03:49:40PM +0800, Ganbold wrote: > >> Jack Vogel wrote: >> >>> I got the new drivers in Friday afternoon for those that don't see CVS >>> messages. >>> >>> The igb driver is for 82575 and 82576 adapters, it has multiqueue support and >>> MSIX, there will be more server type enhancements in that driver as I get the >>> time. >>> >>> The em driver now will be client oriented, the latest hardware support however >>> is for 82574, Hartwell, which is a really nice low cost PCIE dual-port adapter, >>> that actually also has MSIX. This first released support for it will >>> use 3 interrupt >>> vectors, one for TX, one for RX, and Link. The hardware actually supports 5 >>> vectors, so I am planning to add support for another RX and TX queue as my >>> schedule allows. >>> >>> Hartwell is also the first adapter that has IEEE 1588 PTP support, the driver >>> provides init and an ioctl interface to use that facility, I hope we >>> see software >>> support follow on soon. This is an early announcement, I am not sure on >>> exact dates for availability but they should be soon. >>> >>> As ever, issues and bugs should be sent to me. Cheers everyone! >>> >> I have Intel Gigabit card and FreeBSD-7.0-STABLE recognizes it as following: >> ... >> em0@pci0:0:25:0: class=0x020000 card=0x2800103c chip=0x104a8086 >> rev=0x02 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82566DM Gigabit Network Connection' >> class = network >> subclass = ethernet >> ... >> # uname -an >> FreeBSD test.ub.mng.net 7.0-STABLE FreeBSD 7.0-STABLE #0: Thu Jun 5 >> 11:12:34 ULAT 2008 tsgan@test.ub.mng.net:/usr/obj/usr/src/sys/FIREWALL >> i386 >> >> >> It has some problem, 1000baseTX connection status almost never goes to >> active in bridged mode, sometimes >> it goes to active but then immediately it goes to no carrier. (The other >> end is Cisco4507R, Gigabit Ethernet port) >> ... >> em0: flags=8943 metric 0 >> mtu 1500 >> options=198 >> ether 00:0f:fe:82:23:db >> media: Ethernet 1000baseTX (autoselect) >> status: no carrier >> ... >> >> Any idea how to solve this issue? >> > > Have you tried disabling speed and duplex negotiation and explicitly > stating speed and duplex like so? > > ifconfig_em0="... media 1000baseTX mediaopt full-duplex" > I tried it and it doesn't work. > Cisco switches have a notorious history of not being "friendly" with > non-Cisco hardware. Forcing duplex on both ends of the link (that means > on both the host side, and the Cisco side!) usually fixes it. > Tried too, doesn't work. Ganbold -- Life is too important to take seriously. -- Corky Siegel From peterjeremy at optushome.com.au Fri Jun 6 10:13:56 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Fri Jun 6 10:14:01 2008 Subject: network keep droping In-Reply-To: References: <20080604194059.GE1028@server.vk2pj.dyndns.org> Message-ID: <20080606101343.GI67629@server.vk2pj.dyndns.org> On 2008-Jun-05 12:27:19 +0800, Izwan Mohd wrote: >The server using FreeBSD 6.0-RELEASE the NIC is intel i can't remember the >model but freebsd detect it as "em0" the server memory is 1GB, not special >network fetures it only running snort and nessus 6.0-RELEASE is very old and no longer supported. There have been lots of bug-fixes since then. I suggest you include an upgrade to 6.3/6.4 or 7.0/7.1 in your forward planning. The em(4) device is quite well supported and maintained (by an Intel employee). There have been major changes to em(4) included in 6.3 and 7.0 and these may correct the problem you are seeing. My initial recommendation would be that you try 6.3 (or 7.0). If that is impractical, you may be able to upgrade the em driver to whilst retaining the rest of your 6.0 system - I haven't tried that but I don't see anything in UPDATING that would rule it out. [The approach would be to checkout a RELENG_6_0_0_RELEASE kernel then update sys/dev/em to RELENG_6_3 and build a new kernel]. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080606/8b2d5d9b/attachment.pgp From koitsu at FreeBSD.org Fri Jun 6 12:14:57 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Jun 6 12:15:02 2008 Subject: MFC of em/igb drivers In-Reply-To: <4849038A.5040007@micom.mng.net> References: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> <4848EC14.8060700@micom.mng.net> <20080606090452.GA38593@eos.sc1.parodius.com> <4849038A.5040007@micom.mng.net> Message-ID: <20080606121457.GA46283@eos.sc1.parodius.com> On Fri, Jun 06, 2008 at 05:29:46PM +0800, Ganbold wrote: >> Have you tried disabling speed and duplex negotiation and explicitly >> stating speed and duplex like so? >> >> ifconfig_em0="... media 1000baseTX mediaopt full-duplex" >> > > I tried it and it doesn't work. > >> Cisco switches have a notorious history of not being "friendly" with >> non-Cisco hardware. Forcing duplex on both ends of the link (that means >> on both the host side, and the Cisco side!) usually fixes it. >> > > Tried too, doesn't work. Good to know. Sounds like a driver problem; back to Jack for that one. :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From brde at optusnet.com.au Fri Jun 6 12:15:12 2008 From: brde at optusnet.com.au (Bruce Evans) Date: Fri Jun 6 12:15:15 2008 Subject: Probable Bug in tcp.h In-Reply-To: <48480FA5.3020800@FreeBSD.org> References: <200806051712.47048.marc.loerner@hob.de> <48480FA5.3020800@FreeBSD.org> Message-ID: <20080606212657.X16250@delplex.bde.org> On Thu, 5 Jun 2008, Bruce M. Simpson wrote: > Marc Lörner wrote: >> .. >> First of all I have the problam of misalignment of th_off. Because in this >> way always 4 bytes are read and the the bits of th_off are replaced. Then >> the 4 bytes are written back. >> But should (th_x and th_off) not only be 1 byte in whole -> only read and >> write 1 byte? 1 or 2, since struct tcphdr must be 16-bit aligned due to the shorts in it. An unportability in gcc's treatment of bit-fields results in gcc thinking that the struct is 4-byte aligned. Thus alignment traps may occur if an instance of the struct is not in fact aligned. > Which machine architecture are you attempting to compile this code on? [ia64]. > On FreeBSD Tier 1 platforms, the access is probably going to come out of L2 > cache anyway, so the fields in question will be read by a burst cycle. > > It is worth noting that NetBSD changed the base type of tcphdr's bitfields to > uint8_t, however this shuffles the compiler dependency into the treatment of > the "char" type. Most modern C compilers support "unsigned char". No C compilers support bit-fields of type uint8_t (unless _Bool is uint8_t), since C requires bit-fields to have type a possibly-qualified version of _Bool, signed int or insigned int. Howver, the behaviour for other types is unspecified, so the compiler can do anything with them including what broken software wants, so it is really no C programs that use bit-fields of type uint8_t. Bit-fields of type larger than u_int are useful for holding more bits than a u_int (since C unfortunately limits the number of bits in a bit-field to the number in the type of the bit-field, so you can't write u_int foo:64 to get a 64-bit integer), but bit-fields of type smaller than u_int are not very useful -- compilers are free to treat them the same as bit fields of larger type. gcc's actual treatment of bit-fields of type smaller than u_int is unportable and apparently undocumented. It affects alignment and the struct size but not padding: e.g., in the following struct: struct { unsigned x:1; char y; } foo; This allocates 1 bit for x and pads to a byte boundary, so that y has offset 1. Any more padding would be bogus. Then, bogusly, due to the bit-field having type unsigned, gcc makes the whole struct have alignment requirements that of u_int and pads the struct at the end to have size a multiple of sizeof(u_int) = 32 bits. Then it is justified as accessing foo.x as part of an an aligned object of size 32 bits, and may trap if foo.x is not actually aligned. Something like this happens for struct tcphdr, with the alignment trap actually ocurring on ia64. Some bug elsewhere is responsible for generating a misaligned struct. OTOH, if `unsigned' in the above is changed to `unsigned char', giving a non-C program: struct { unsigned char x:1; char y; } foo; then all the padding is non-bogus when this is compiled by the non-C compiler gcc: the offset of y is unchanged, but now the struct has size 2 and alignment 1. Due to unportabilities like this, bit-fields should never be used when the layout of an object must be controlled precisely. This includes layouts related to hardware which includes most network layouts. Unportabilities like this are sometimes hacked around using packed structs. ipv6 headers do this a lot. ipv4 headers are not so bad. ip.h now says `__packed __aligned(4)' for struct ip where it used to say just `__packed' __packed forces 1-byte alignment for everything. On ia64, this results in specially pessimized accesses for all the fields in a struct, with 1- byte accesses even for the 32-bit fields and large code to combine the bytes into a word. But struct ip (unlike struct tcphdr?) must always be 32-bit aligned, and declaring it as __aligned(4) is supposed to restore the possibility of wide accesses after declaration it as __packed forces it to have no padding. No padding should occur automatically, and the u_int bit-fields don't affect this since the size of struct ip is 20, but there is a another problem with bogus padding at the end (on arm only?). Bruce From brde at optusnet.com.au Fri Jun 6 12:25:42 2008 From: brde at optusnet.com.au (Bruce Evans) Date: Fri Jun 6 12:25:46 2008 Subject: Probable Bug in tcp.h In-Reply-To: <200806061025.37856.marc.loerner@hob.de> References: <200806051712.47048.marc.loerner@hob.de> <200806060930.28527.marc.loerner@hob.de> <20080606075210.GD67629@server.vk2pj.dyndns.org> <200806061025.37856.marc.loerner@hob.de> Message-ID: <20080606221917.A16250@delplex.bde.org> On Fri, 6 Jun 2008, Marc [iso-8859-1] Lörner wrote: > On Friday 06 June 2008 09:52, Peter Jeremy wrote: >> I gather from this comment that you have some code using struct tcphdr >> that is getting alignment errors. struct tcphdr is extensively used >> in the TCP stack within the kernel so it's likely that any layout or >> alignment problem with it would show up there. I suspect you are >> dereferencing a mis-aligned struct tcphdr. > > The funny thing is that the dereferencing occurs in > "/usr/src/sys/netinet/tcp_input.c" in function tcp_input in line 550: > > /* > * Check that TCP offset makes sense, > * pull out TCP options and adjust length. XXX > */ > off = th->th_off << 2; <----- here > if (off < sizeof (struct tcphdr) || off > tlen) { > tcpstat.tcps_rcvbadoff++; > goto drop; > } > > So the misalignment may probably lie in TCP stack? Quite likely. th is normally at offset off0 in ip, where ip is required to be 32-bit aligned (see my previous reply). You can see off0 in a stack trace. Bruce From sthaug at nethelp.no Fri Jun 6 16:47:51 2008 From: sthaug at nethelp.no (sthaug@nethelp.no) Date: Fri Jun 6 16:47:54 2008 Subject: MFC of em/igb drivers In-Reply-To: <20080606090452.GA38593@eos.sc1.parodius.com> References: <2a41acea0805030014x244e1311v945e23266961193d@mail.gmail.com> <4848EC14.8060700@micom.mng.net> <20080606090452.GA38593@eos.sc1.parodius.com> Message-ID: <20080606.182108.74659907.sthaug@nethelp.no> > Have you tried disabling speed and duplex negotiation and explicitly > stating speed and duplex like so? > > ifconfig_em0="... media 1000baseTX mediaopt full-duplex" Disagree with this piece of advice. > Cisco switches have a notorious history of not being "friendly" with > non-Cisco hardware. Forcing duplex on both ends of the link (that means > on both the host side, and the Cisco side!) usually fixes it. I might have said the same myself five years ago. But this is 2008, and we have autoneg as default on all ports (even at 100 Mbps). Our Cisco switch ports (and we have a *lot* of them) work just fine with autoneg. Note that GigE is different from FE here - autoneg is a compulsory part of the GigE standard, while it's not compulsory for FE. The only GigE ports that have needed anything else were some pre-standard GigE ports. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From mainland at eecs.harvard.edu Fri Jun 6 20:18:45 2008 From: mainland at eecs.harvard.edu (Geoffrey Mainland) Date: Fri Jun 6 20:18:50 2008 Subject: Major Atheros issues with Ubiquiti SR9/XR9 Message-ID: <484997B1.5020708@eecs.harvard.edu> Hi, I'm running 7-CURRENT on several ALIX 3c2 boards with SR9 radios and having major performance problems: throughput on TCP streams generated by iperf often falls to zero, and, depending on the HAL I use, I see ping latencies during one of these iperf transfers of up to more than a *minute*. I've tried both the 0.9.30.13 HAL and the new 0.10.5.6 HAL. I see this bad behavior with both, but the new HAL seems even worse. I've documented my configuration and the test results at http://www.eecs.harvard.edu/~mainland/freebsd/sr9/. This includes the kernel configuration, dmesg output, pciconf output, rc.conf, athstats output, appropriate sysctl values, iperf/ping output generated by my driver script and some plots showing the problem. We are trying to deploy a bunch of these nodes outdoors, using the 900MHz radios as a backhaul, so the drop-outs I see with SR9s are a major problem for us. I've also run the same tests on Soekris nodes, used different SR9s, and also tried the new XR9s on the same ALIX boards---all with similar results. We also have a bunch of Wistrom CM9s which seem to work just fine. Any idea what could be going on? Thanks! Geoff From agaviola at infoweapons.com Fri Jun 6 23:30:34 2008 From: agaviola at infoweapons.com (Archimedes S. Gaviola) Date: Fri Jun 6 23:30:36 2008 Subject: [Removal of mrouted in FreeBSD-7.0] Message-ID: <4849C87F.9030804@infoweapons.com> To Whom It May Concerned: Hi! I have just read from the FreeBSD-7.0 release notes http://www.freebsd.org/releases/7.0R/relnotes.html that the mrouted multicast routing protocol (DVMRP implementation) has been removed from the base system. I want to know what multicast routing protocol will served as replacement to this? The KAME snap kit have PIM-SM and PIM-DM implementations but are specific only to IPv6. Thanks, Archimedes From linimon at FreeBSD.org Sat Jun 7 04:45:21 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sat Jun 7 04:45:23 2008 Subject: kern/124341: [ral] promiscuous mode for wireless device ral0 looses signal after ~30 mins (airodump-ng loses all stations after ~30 minutes) Message-ID: <200806070445.m574jLQm018738@freefall.freebsd.org> Old Synopsis: promiscuous mode for wireless device ral0 looses signal after ~30 mins (airodump-ng loses all stations after ~30 minutes) New Synopsis: [ral] promiscuous mode for wireless device ral0 looses signal after ~30 mins (airodump-ng loses all stations after ~30 minutes) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Jun 7 04:44:24 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=124341 From bu7cher at yandex.ru Sat Jun 7 05:31:46 2008 From: bu7cher at yandex.ru (Andrey V. Elsukov) Date: Sat Jun 7 05:31:49 2008 Subject: [Removal of mrouted in FreeBSD-7.0] In-Reply-To: <4849C87F.9030804@infoweapons.com> References: <4849C87F.9030804@infoweapons.com> Message-ID: <484A1ABB.2080501@yandex.ru> Archimedes S. Gaviola wrote: > To Whom It May Concerned: > > Hi! I have just read from the FreeBSD-7.0 release notes > http://www.freebsd.org/releases/7.0R/relnotes.html that the mrouted > multicast routing protocol (DVMRP implementation) has been removed from > the base system. If you want to use mrouted, you can install it from ports/net/mrouted. -- WBR, Andrey V. Elsukov From bms at FreeBSD.org Sat Jun 7 08:42:02 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Sat Jun 7 08:42:28 2008 Subject: [Removal of mrouted in FreeBSD-7.0] In-Reply-To: <4849C87F.9030804@infoweapons.com> References: <4849C87F.9030804@infoweapons.com> Message-ID: <484A49D6.1000808@FreeBSD.org> Archimedes S. Gaviola wrote: > Hi! I have just read from the FreeBSD-7.0 release notes > http://www.freebsd.org/releases/7.0R/relnotes.html that the mrouted > multicast routing protocol (DVMRP implementation) has been removed > from the base system. I want to know what multicast routing protocol > will served as replacement to this? The KAME snap kit have PIM-SM and > PIM-DM implementations but are specific only to IPv6. DVMRP is something of a legacy protocol now, most deployments use PIM-SM. mrouted is still available in ports as other folk have pointed out If you want a freely available router with full multicast capability, please give XORP a try. From daniel at skytek.it Sat Jun 7 21:34:36 2008 From: daniel at skytek.it (Daniel Ponticello) Date: Sat Jun 7 21:34:39 2008 Subject: kernel panic on em0/taskq Message-ID: <484AFEF1.4040500@skytek.it> Hello, i'm experiencing periodic kernel panics on a server with FreeBSD 7.0-STABLE #0: Tue May 20 19:09:43 CEST 2008. My big problem is that the system is not performing memory dumping and/or automatic reoboot, it just stays there. Here' console output: em0: watchdog timeout -- resetting kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic_id = 00 fault virtual address = 0x14 fault code = supervisor read, page not present intruction pointerr = 0x20:0xc056e2ce stack pointer = 0x28:0xe537fc08 frame pointer = 0x28:0xe537fc28 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 29 (em0 taskq) trap number = 12 panic: page fault cpuid = 0 It just stays there, unresponsive (no automatic reboot). Any ideas? Thanks, Daniel -- WBR, Cordiali Saluti, Daniel Ponticello, VP of Engineering Network Coordination Centre of Skytek --- - For further information about our services: - Please visit our website at http://www.Skytek.it --- From paul at gtcomm.net Sun Jun 8 05:01:09 2008 From: paul at gtcomm.net (Paul) Date: Sun Jun 8 05:01:12 2008 Subject: using ipfw forward with gre tunnel crashes machine (BUG) Message-ID: <484B6807.1000007@gtcomm.net> Hoping maybe one of you can test this as I didn't have time to look into it, but I tried twice. Setting up gre interface and then using IPFW Gre interface 1.1.1.1 -- 1.1.1.2 ipfw fwd 1.1.1.2 ip from any to any recv lagg2 Command works no problem. The instant any traffic at all is sent incoming on lagg2 machine crashes (reboots), nothing in log. Thanks :) From paul at gtcomm.net Sun Jun 8 05:02:31 2008 From: paul at gtcomm.net (Paul) Date: Sun Jun 8 05:02:35 2008 Subject: using ipfw forward with gre tunnel crashes machine (BUG) In-Reply-To: <484B6807.1000007@gtcomm.net> References: <484B6807.1000007@gtcomm.net> Message-ID: <484B6859.6070500@gtcomm.net> Grr.. forgot.. 7.0-STABLE FreeBSD 7.0-STABLE #5: Sun May 11 19:00:57 EDT 2008 amd64 Paul wrote: > Hoping maybe one of you can test this as I didn't have time to look > into it, but I tried twice. > > Setting up gre interface and then using IPFW > > Gre interface 1.1.1.1 -- 1.1.1.2 > ipfw fwd 1.1.1.2 ip from any to any recv lagg2 > > Command works no problem. The instant any traffic at all is sent > incoming on lagg2 machine crashes (reboots), nothing in log. > > > Thanks :) > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From jfvogel at gmail.com Sun Jun 8 06:42:39 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Sun Jun 8 06:42:45 2008 Subject: kernel panic on em0/taskq In-Reply-To: <484AFEF1.4040500@skytek.it> References: <484AFEF1.4040500@skytek.it> Message-ID: <2a41acea0806072342q518ac2afo663c91e730c16db@mail.gmail.com> On Sat, Jun 7, 2008 at 2:34 PM, Daniel Ponticello wrote: > Hello, > i'm experiencing periodic kernel panics on a server with FreeBSD 7.0-STABLE > #0: Tue May 20 19:09:43 CEST 2008. > My big problem is that the system is not performing memory dumping and/or > automatic reoboot, > it just stays there. > > Here' console output: > > em0: watchdog timeout -- resetting > kernel trap 12 with interrupts disabled > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic_id = 00 > fault virtual address = 0x14 > fault code = supervisor read, page not present > intruction pointerr = 0x20:0xc056e2ce > stack pointer = 0x28:0xe537fc08 > frame pointer = 0x28:0xe537fc28 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = resume, IOPL = 0 > current process = 29 (em0 taskq) > trap number = 12 > panic: page fault > cpuid = 0 > > > It just stays there, unresponsive (no automatic reboot). > > > > Any ideas? There was a problem in the watchdog path, I don't recall if it was checked in to STABLE, I will check after the weekend. But, there is also the question of why you are in the watchdog path in the first place. Jack From daniel at skytek.it Sun Jun 8 09:06:00 2008 From: daniel at skytek.it (Daniel Ponticello) Date: Sun Jun 8 09:06:04 2008 Subject: kernel panic on em0/taskq In-Reply-To: <2a41acea0806072342q518ac2afo663c91e730c16db@mail.gmail.com> References: <484AFEF1.4040500@skytek.it> <2a41acea0806072342q518ac2afo663c91e730c16db@mail.gmail.com> Message-ID: <484BA0FD.40706@skytek.it> Hello Jack! > > There was a problem in the watchdog path, I don't recall if > it was checked in to STABLE, I will check after the weekend. > > But, there is also the question of why you are in the watchdog > path in the first place. > I tried to apply the latest patch 1.184.2.3 2008/05/21 21:34:05 which includes the watchdog fix you mentioned. Let's see if it helps! No idea of why i'm in the watchdog path, but I forgot to add that this is virtualized VM on VmWare ESX (it emulates em interface)... so i guess it might the cause of why i am in the watchdog path. Do you have any ideas of why i wasn't able to collect dump and the system did not reboot automatically? Thanks, Daniel -- WBR, Cordiali Saluti, Daniel Ponticello, VP of Engineering Network Coordination Centre of Skytek --- - For further information about our services: - Please visit our website at http://www.Skytek.it --- From koitsu at FreeBSD.org Sun Jun 8 12:08:53 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sun Jun 8 12:08:56 2008 Subject: kernel panic on em0/taskq In-Reply-To: <484AFEF1.4040500@skytek.it> References: <484AFEF1.4040500@skytek.it> Message-ID: <20080608120852.GB50122@eos.sc1.parodius.com> On Sat, Jun 07, 2008 at 11:34:41PM +0200, Daniel Ponticello wrote: > Hello, > i'm experiencing periodic kernel panics on a server with FreeBSD > 7.0-STABLE #0: Tue May 20 19:09:43 CEST 2008. > My big problem is that the system is not performing memory dumping and/or > automatic reoboot, > it just stays there. Try adjusting some of these sysctl values: hw.acpi.disable_on_reboot hw.acpi.handle_reboot You're using VMware, which may or may not behave properly anyways. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From daniel at skytek.it Sun Jun 8 12:58:55 2008 From: daniel at skytek.it (Daniel Ponticello) Date: Sun Jun 8 12:59:00 2008 Subject: kernel panic on em0/taskq In-Reply-To: <20080608120852.GB50122@eos.sc1.parodius.com> References: <484AFEF1.4040500@skytek.it> <20080608120852.GB50122@eos.sc1.parodius.com> Message-ID: <484BD795.80502@skytek.it> Hello, disabling acpi is not an option, since i'm running SMP. I have several other systems running 7.0 Release without problems, so it might be something on 7-Stable. Thanks, Daniel Jeremy Chadwick ha scritto: > On Sat, Jun 07, 2008 at 11:34:41PM +0200, Daniel Ponticello wrote: > >> Hello, >> i'm experiencing periodic kernel panics on a server with FreeBSD >> 7.0-STABLE #0: Tue May 20 19:09:43 CEST 2008. >> My big problem is that the system is not performing memory dumping and/or >> automatic reoboot, >> it just stays there. >> > > Try adjusting some of these sysctl values: > > hw.acpi.disable_on_reboot > hw.acpi.handle_reboot > > You're using VMware, which may or may not behave properly anyways. > > -- WBR, Cordiali Saluti, Daniel Ponticello, VP of Engineering Network Coordination Centre of Skytek --- - For further information about our services: - Please visit our website at http://www.Skytek.it --- From daniel at skytek.it Sun Jun 8 13:07:03 2008 From: daniel at skytek.it (Daniel Ponticello) Date: Sun Jun 8 13:07:09 2008 Subject: kernel panic on em0/taskq In-Reply-To: <484BD795.80502@skytek.it> References: <484AFEF1.4040500@skytek.it> <20080608120852.GB50122@eos.sc1.parodius.com> <484BD795.80502@skytek.it> Message-ID: <484BD97C.5000009@skytek.it> Sorry, I did not read well you suggestion ;) Anyway, the system reboots correctly if I issue the reboot command from command line. Should i adjust those values anyway? Thanks, Daniel Daniel Ponticello ha scritto: > Hello, > disabling acpi is not an option, since i'm running SMP. > I have several other systems running 7.0 Release without problems, > so it might be something on 7-Stable. > > > Thanks, > > Daniel > > > Jeremy Chadwick ha scritto: >> On Sat, Jun 07, 2008 at 11:34:41PM +0200, Daniel Ponticello wrote: >> >>> Hello, >>> i'm experiencing periodic kernel panics on a server with FreeBSD >>> 7.0-STABLE #0: Tue May 20 19:09:43 CEST 2008. >>> My big problem is that the system is not performing memory dumping >>> and/or automatic reoboot, >>> it just stays there. >>> >> >> Try adjusting some of these sysctl values: >> >> hw.acpi.disable_on_reboot >> hw.acpi.handle_reboot >> >> You're using VMware, which may or may not behave properly anyways. >> >> > -- WBR, Cordiali Saluti, Daniel Ponticello, VP of Engineering Network Coordination Centre of Skytek --- - For further information about our services: - Please visit our website at http://www.Skytek.it --- From koitsu at FreeBSD.org Sun Jun 8 13:31:14 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sun Jun 8 13:31:21 2008 Subject: kernel panic on em0/taskq In-Reply-To: <484BD97C.5000009@skytek.it> References: <484AFEF1.4040500@skytek.it> <20080608120852.GB50122@eos.sc1.parodius.com> <484BD795.80502@skytek.it> <484BD97C.5000009@skytek.it> Message-ID: <20080608133114.GA61781@eos.sc1.parodius.com> On Sun, Jun 08, 2008 at 03:07:08PM +0200, Daniel Ponticello wrote: > Sorry, I did not read well you suggestion ;) > > Anyway, the system reboots correctly if I issue the reboot command from > command line. > Should i adjust those values anyway? I'd recommend adjusting them and see if the bug (not automatically rebooting on panic) changes. I'm guessing it won't (especially if reboot(8) works fine), but it's worth trying. You're the 2nd person I've seen who has reported this problem (re: FreeBSD not properly rebooting on panic). The other person: http://lists.freebsd.org/pipermail/freebsd-stable/2008-May/042250.html I'll add this to my Commonly reported issues Wiki. As for the problem itself, sorry, I have no idea what's causing it. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From daniel at skytek.it Sun Jun 8 18:28:45 2008 From: daniel at skytek.it (Daniel Ponticello) Date: Sun Jun 8 18:28:50 2008 Subject: kernel panic on em0/taskq In-Reply-To: <20080608133114.GA61781@eos.sc1.parodius.com> References: <484AFEF1.4040500@skytek.it> <20080608120852.GB50122@eos.sc1.parodius.com> <484BD795.80502@skytek.it> <484BD97C.5000009@skytek.it> <20080608133114.GA61781@eos.sc1.parodius.com> Message-ID: <484C24E4.5040108@skytek.it> I just checked the link you have reported. It looks like the problem is present only on SMP machines with both ULE and 4BSD scheduler. I can confirm that the problem is also present on 6.3-Stable. Basically, it freezes before collecting dump and before being able to reboot. I wish i could have more informations to open a PR. Thanks, Daniel Jeremy Chadwick ha scritto: > On Sun, Jun 08, 2008 at 03:07:08PM +0200, Daniel Ponticello wrote: > >> Sorry, I did not read well you suggestion ;) >> >> Anyway, the system reboots correctly if I issue the reboot command from >> command line. >> Should i adjust those values anyway? >> > > I'd recommend adjusting them and see if the bug (not automatically > rebooting on panic) changes. I'm guessing it won't (especially if > reboot(8) works fine), but it's worth trying. > > You're the 2nd person I've seen who has reported this problem (re: > FreeBSD not properly rebooting on panic). The other person: > > http://lists.freebsd.org/pipermail/freebsd-stable/2008-May/042250.html > > I'll add this to my Commonly reported issues Wiki. As for the problem > itself, sorry, I have no idea what's causing it. > > -- WBR, Cordiali Saluti, Daniel Ponticello, VP of Engineering Network Coordination Centre of Skytek --- - For further information about our services: - Please visit our website at http://www.Skytek.it --- From kernel.panic007 at gmail.com Mon Jun 9 03:14:36 2008 From: kernel.panic007 at gmail.com (Segnale007) Date: Mon Jun 9 03:14:41 2008 Subject: I need some information about how to build my first voip . Message-ID: <45BD6738-5D37-4B22-91B6-3CB60B9BEA24@gmail.com> Hello, I am getting an soekris net5501-70 where I will install freebsd, and I will build my voip. I don't know how to build a voip because I never did one, and I am wondering which program should I use to set it up, I did a lot of googling and I found many programs, such as Asterisk or SER, but I still don't know the difference between either of them, and I am trying to understand how I am supposed to start to build it. I am still wondering which kind of phone I should use. For example, can I use a standard landline phone or do I have to use something else? Thank you, Sincerely Pietro From marc.loerner at hob.de Mon Jun 9 08:13:49 2008 From: marc.loerner at hob.de (Marc =?iso-8859-1?q?L=F6rner?=) Date: Mon Jun 9 08:13:53 2008 Subject: Probable Bug in tcp.h In-Reply-To: <20080606221917.A16250@delplex.bde.org> References: <200806051712.47048.marc.loerner@hob.de> <200806061025.37856.marc.loerner@hob.de> <20080606221917.A16250@delplex.bde.org> Message-ID: <200806091013.27813.marc.loerner@hob.de> On Friday 06 June 2008 14:25, Bruce Evans wrote: > On Fri, 6 Jun 2008, Marc [iso-8859-1] L?rner wrote: > > On Friday 06 June 2008 09:52, Peter Jeremy wrote: > >> I gather from this comment that you have some code using struct tcphdr > >> that is getting alignment errors. struct tcphdr is extensively used > >> in the TCP stack within the kernel so it's likely that any layout or > >> alignment problem with it would show up there. I suspect you are > >> dereferencing a mis-aligned struct tcphdr. > > > > The funny thing is that the dereferencing occurs in > > "/usr/src/sys/netinet/tcp_input.c" in function tcp_input in line 550: > > > > /* > > * Check that TCP offset makes sense, > > * pull out TCP options and adjust length. XXX > > */ > > off = th->th_off << 2; <----- here > > if (off < sizeof (struct tcphdr) || off > tlen) { > > tcpstat.tcps_rcvbadoff++; > > goto drop; > > } > > > > So the misalignment may probably lie in TCP stack? > > Quite likely. th is normally at offset off0 in ip, where ip is required > to be 32-bit aligned (see my previous reply). You can see off0 in a > stack trace. > off0 is 0x14 => no problem with that but address of ip is 0xe000000021c8706e => not correct aligned to 32-bits Can anyone tell me, where ip is allocated, so I can do a little bit more research? Marc From bms at FreeBSD.org Mon Jun 9 10:16:31 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Mon Jun 9 10:16:58 2008 Subject: Probable Bug in tcp.h In-Reply-To: <200806091013.27813.marc.loerner@hob.de> References: <200806051712.47048.marc.loerner@hob.de> <200806061025.37856.marc.loerner@hob.de> <20080606221917.A16250@delplex.bde.org> <200806091013.27813.marc.loerner@hob.de> Message-ID: <484D02FC.9090407@FreeBSD.org> Marc L?rner wrote: > off0 is 0x14 => no problem with that > but address of ip is 0xe000000021c8706e => not correct aligned to 32-bits > > Can anyone tell me, where ip is allocated, so I can do a little bit more > research? > It really depends on the context! That's a very wide ranging question. It depends upon whether mbuf chains are flowing up or down the stack, whether or not the network driver supports checksum or header/segment offload, and whether or not it is using zero-copy. Zero copy transmit normally only has mmu cost if the mbuf (from userland) can be mapped to a location where headers are easily prepended. Zero copy receive is more expensive and complex as it requires that the DMA engine on the network interface card supports header splitting. The FreeBSD stack is known to have some issues with mbuf alignment and architectures other than those in its Tier 1. From bugmaster at FreeBSD.org Mon Jun 9 11:07:03 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 9 11:07:31 2008 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200806091107.m59B72qd070815@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/92090 net [bge] bge0: watchdog timeout -- resetting f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau f kern/102344 net [ipf] Some packets do not pass through network interfa o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109733 net [bge] bge link state issues [regression] o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116328 net [bge]: Solid hang with bge interface o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117423 net [vlan] Duplicate IP on different interfaces o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119361 net [bge] bge(4) transmit performance problem o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122082 net [in_pcb] NULL pointer dereference in in_pcbdrop o kern/122195 net [ed] Alignment problems in if_ed f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix f kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar f conf/122858 net [nsswitch.conf] nsswitch in 7.0 is f*cked up o kern/122875 net [nfs] "rstatd: Can't get namelist. 1" - fbsd 7.0-stabl o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 f kern/123172 net [bce] Watchdog timeout problems with if_bce o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o bin/123465 net [ip6] route(1): route add -inet6 -interfac o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123617 net [tcp] breaking connection when client downloading file o bin/123633 net ifconfig(8) doesn't set inet and ether address in one p kern/123741 net [netgraph] [panic] kernel panic due to netgraph mpd o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123881 net [tcp] Turning on TCP blackholing causes slow localhost o kern/123950 net [tcp] TH_RST packet sended if received out-of-order da o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov 91 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 o kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/95267 net packet drops periodically appear o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/112179 net [sis] [patch] sis driver for natsemi DP83815D autonego o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o bin/117339 net [patch] route(8): loading routing management commands o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/119432 net [arp] route add -host -iface causes arp e f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/121242 net [ate] [patch] Promiscuous mode of if_ate (arm) doesn't o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122068 net [ppp] ppp can not set the correct interface with pptpd o kern/122145 net error while compiling with device ath_rate_amrr o kern/122295 net [bge] bge Ierr rate increase (since 6.0R) [regression] o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122697 net [ath] Atheros card is not well supported o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge f kern/122839 net [multicast] FreeBSD 7 multicast routing problem o kern/122928 net [em] interface watchdog timeouts and stops receiving p o kern/123892 net [tap] [patch] No buffer space available o kern/123961 net [vr] [patch] Allow vr interface to handle vlans o bin/124004 net ifconfig(8): Cannot assign both an IP and a MAC addres o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses 53 problems total. From julian at elischer.org Mon Jun 9 19:47:12 2008 From: julian at elischer.org (Julian Elischer) Date: Mon Jun 9 19:47:19 2008 Subject: vimage include files Message-ID: <484D88AC.2000402@elischer.org> The current vimage code adds a handful of new include files.. e.g. vnet.h for vimage related defines that are related to general networking stuff vinet for vimage related defines that are related to inet. however eventually these defines would move to other files. For example I think every single file that includes vinet.h already includes netinet/in.h so these definitions move into that file. My question however comes with vnet.h 95% of the files that use it also include so possibly they could go there, but a few of them don't. they are: uipc_socket.c (sets a reference counter in the vnet structure) raw_cb.c accesses V_rawcb_list raw_usrreq.c accesses V_rawcb_list tcp_output.c lots of stuff of course but doesn't use if.h tcp_timer.c ditto vnet appears to be needed jsut for the SYSCTL_V_ stuff. (marko?) netipsec/keysock.c no need for if.h so there is no one place where all of the vnet structure is in scope but if.h is the closest. so should we: keep vnet.h? split it up a bit to make it more in scope? Find/make an include file for "networking in general?" is there such a file? As I said if.h seems the closest. From gnn at freebsd.org Mon Jun 9 22:35:25 2008 From: gnn at freebsd.org (gnn@freebsd.org) Date: Mon Jun 9 22:35:29 2008 Subject: Anyone seen this error on em ? Message-ID: Jun 9 18:23:59 ... kernel: em0: port 0x2000-0x201f mem 0xd8020000-0xd803ffff,0xd800 0000-0xd801ffff irq 18 at device 0.0 on pci4 Jun 9 18:23:59 ... kernel: em0: Using MSI interrupt Jun 9 18:23:59 ... kernel: em0: Setup of Shared code failed Jun 9 18:23:59 ... kernel: device_attach: em0 attach returned 6 I've never seen the "returned 6" thing. Plugging a cable into the other em device on the motherboard, a super micro, currently works, but it looks like bad hardware to me. Thoughts? Later, George From kip.macy at gmail.com Mon Jun 9 23:57:09 2008 From: kip.macy at gmail.com (Kip Macy) Date: Mon Jun 9 23:57:13 2008 Subject: Anyone seen this error on em ? In-Reply-To: References: Message-ID: Paul Saab has seen the same. What hardware are you using? -Kip On Mon, Jun 9, 2008 at 3:34 PM, wrote: > > > > Jun 9 18:23:59 ... kernel: em0: Version - 6.7.3> port 0x2000-0x201f mem 0xd8020000-0xd803ffff,0xd800 > 0000-0xd801ffff irq 18 at device 0.0 on pci4 > Jun 9 18:23:59 ... kernel: em0: Using MSI interrupt > Jun 9 18:23:59 ... kernel: em0: Setup of Shared code failed > Jun 9 18:23:59 ... kernel: device_attach: em0 attach returned 6 > > I've never seen the "returned 6" thing. Plugging a cable into the > other em device on the motherboard, a super micro, currently works, > but it looks like bad hardware to me. Thoughts? > > Later, > George > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From spawk at acm.poly.edu Tue Jun 10 00:20:29 2008 From: spawk at acm.poly.edu (Boris Kochergin) Date: Tue Jun 10 00:20:34 2008 Subject: Anyone seen this error on em ? In-Reply-To: References: Message-ID: <484DC272.6020002@acm.poly.edu> gnn@freebsd.org wrote: > > Jun 9 18:23:59 ... kernel: em0: Version - 6.7.3> port 0x2000-0x201f mem 0xd8020000-0xd803ffff,0xd800 > 0000-0xd801ffff irq 18 at device 0.0 on pci4 > Jun 9 18:23:59 ... kernel: em0: Using MSI interrupt > Jun 9 18:23:59 ... kernel: em0: Setup of Shared code failed > Jun 9 18:23:59 ... kernel: device_attach: em0 attach returned 6 > > I've never seen the "returned 6" thing. Plugging a cable into the > other em device on the motherboard, a super micro, currently works, > but it looks like bad hardware to me. Thoughts? > > Later, > George > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > Just a "me, too." Also on a Supermicro board, and it happens on some boots, but not all. -Boris From andrew at modulus.org Tue Jun 10 00:51:47 2008 From: andrew at modulus.org (Andrew Snow) Date: Tue Jun 10 00:51:52 2008 Subject: Anyone seen this error on em ? In-Reply-To: <484DC272.6020002@acm.poly.edu> References: <484DC272.6020002@acm.poly.edu> Message-ID: <484DD008.6090009@modulus.org> > Just a "me, too." Also on a Supermicro board, and it happens on some > boots, but not all. I used to have this problem, but it went away after upgrading FreeBSD version (7-stable) - Andrew From jfvogel at gmail.com Tue Jun 10 01:11:49 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Tue Jun 10 01:11:52 2008 Subject: Anyone seen this error on em ? In-Reply-To: <484DD008.6090009@modulus.org> References: <484DC272.6020002@acm.poly.edu> <484DD008.6090009@modulus.org> Message-ID: <2a41acea0806091811t2d085d64ra9e9e24029e91d73@mail.gmail.com> There is more than one problem that results in the same error in the core driver, the more common one is actually fixed, as Andrew notes, in the shared code in the latest driver. However, this is a more obscure bug that occurs on some hardware, and it seems to require that you have a management BMC, this is what Paul Saab is seeing, there is not a final fix for this issue yet. Note that both these problems only occur with the esb2lan type NIC. Jack On Mon, Jun 9, 2008 at 5:51 PM, Andrew Snow wrote: >> Just a "me, too." Also on a Supermicro board, and it happens on some >> boots, but not all. > > > I used to have this problem, but it went away after upgrading FreeBSD > version (7-stable) > > - Andrew > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From ps at mu.org Tue Jun 10 02:04:23 2008 From: ps at mu.org (Paul Saab) Date: Tue Jun 10 02:04:26 2008 Subject: Anyone seen this error on em ? In-Reply-To: <2a41acea0806091811t2d085d64ra9e9e24029e91d73@mail.gmail.com> References: <484DC272.6020002@acm.poly.edu> <484DD008.6090009@modulus.org> <2a41acea0806091811t2d085d64ra9e9e24029e91d73@mail.gmail.com> Message-ID: <5c0ff6a70806091835p2c206fe2p203b37433b87e073@mail.gmail.com> http://yogurt.org/FreeBSD/em.diff On Mon, Jun 9, 2008 at 6:11 PM, Jack Vogel wrote: > There is more than one problem that results in the same error in the > core driver, the more common one is actually fixed, as Andrew notes, > in the shared code in the latest driver. However, this is a more obscure > bug that occurs on some hardware, and it seems to require that you have > a management BMC, this is what Paul Saab is seeing, there is not a final > fix for this issue yet. > > Note that both these problems only occur with the esb2lan type NIC. > > Jack > > > On Mon, Jun 9, 2008 at 5:51 PM, Andrew Snow wrote: > >> Just a "me, too." Also on a Supermicro board, and it happens on some > >> boots, but not all. > > > > > > I used to have this problem, but it went away after upgrading FreeBSD > > version (7-stable) > > > > - Andrew > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From agaviola at infoweapons.com Tue Jun 10 03:51:13 2008 From: agaviola at infoweapons.com (Archimedes S. Gaviola) Date: Tue Jun 10 03:51:17 2008 Subject: [Removal of mrouted in FreeBSD-7.0] In-Reply-To: <484A49D6.1000808@FreeBSD.org> References: <4849C87F.9030804@infoweapons.com> <484A49D6.1000808@FreeBSD.org> Message-ID: <484DF690.6010101@infoweapons.com> Bruce M. Simpson wrote: > Archimedes S. Gaviola wrote: >> Hi! I have just read from the FreeBSD-7.0 release notes >> http://www.freebsd.org/releases/7.0R/relnotes.html that the mrouted >> multicast routing protocol (DVMRP implementation) has been removed >> from the base system. I want to know what multicast routing protocol >> will served as replacement to this? The KAME snap kit have PIM-SM and >> PIM-DM implementations but are specific only to IPv6. > > DVMRP is something of a legacy protocol now, most deployments use PIM-SM. > > mrouted is still available in ports as other folk have pointed out > > If you want a freely available router with full multicast capability, > please give XORP a try. > Thanks Bruce and Andrey to your reply! Yes DVMRP is a legacy protocol which I've known many users used it on the IP multicast backbone (MBONE) deployment. Yes XORP, which I'm familiar with and have used it but if ever there's a way to implement IP multicasting with PIM-SM and or PIM-DM in the FreeBSD base system, how big is the work would be? What are the things that needs to be considered if we are going to implement PIM-SM and or PIM-DM to the current FreeBSD network subsystem? The goal is to be able FreeBSD to provide native IP multicast using PIM just like the way DVMRP protocol is implemented before as part of the base system. Thanks, Archimedes From jfvogel at gmail.com Tue Jun 10 03:58:32 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Tue Jun 10 03:58:35 2008 Subject: Anyone seen this error on em ? In-Reply-To: <5c0ff6a70806091835p2c206fe2p203b37433b87e073@mail.gmail.com> References: <484DC272.6020002@acm.poly.edu> <484DD008.6090009@modulus.org> <2a41acea0806091811t2d085d64ra9e9e24029e91d73@mail.gmail.com> <5c0ff6a70806091835p2c206fe2p203b37433b87e073@mail.gmail.com> Message-ID: <2a41acea0806092058o5d559329pd6138d90fe67a484@mail.gmail.com> Just so people understand, you can try this change and if it eliminates the init failure then use it temporarily. What the code is, is a way that the driver and BMC have agreed to use to keep out of eachother's way, but at the moment the code is flawed, its being actively worked and I expect new shared code soon. If you disable the BMC, by the way, you should not see this error or need this change. Jack On Mon, Jun 9, 2008 at 6:35 PM, Paul Saab wrote: > http://yogurt.org/FreeBSD/em.diff > > On Mon, Jun 9, 2008 at 6:11 PM, Jack Vogel wrote: > >> There is more than one problem that results in the same error in the >> core driver, the more common one is actually fixed, as Andrew notes, >> in the shared code in the latest driver. However, this is a more obscure >> bug that occurs on some hardware, and it seems to require that you have >> a management BMC, this is what Paul Saab is seeing, there is not a final >> fix for this issue yet. >> >> Note that both these problems only occur with the esb2lan type NIC. >> >> Jack >> >> >> On Mon, Jun 9, 2008 at 5:51 PM, Andrew Snow wrote: >> >> Just a "me, too." Also on a Supermicro board, and it happens on some >> >> boots, but not all. >> > >> > >> > I used to have this problem, but it went away after upgrading FreeBSD >> > version (7-stable) >> > >> > - Andrew >> > _______________________________________________ >> > freebsd-net@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-net >> > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From dougb at FreeBSD.org Tue Jun 10 05:07:24 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Tue Jun 10 05:07:28 2008 Subject: Proposal: Enable IPv6 Privacy Extensions (RFCs 3041/4941) by default Message-ID: <484E0C08.1060800@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 By default, IPv6 stateless autoconfiguration creates a 64 bit hostid for each interface based on the mac address (for ethernet, but for us that's the common case). This is convenient since if you're using RA neither the user nor the admin has to do anything to get the node on line, it "just works." There is a privacy issue with this however, because this identifier is created in such a way as to make it globally unique, the machine (and therefore in almost all cases the user) can be tracked by third parties such as web sites, even if they move from one network prefix to another, such as with a laptop. To address those privacy concerns RFC 3041 was written, and eventually obsoleted by RFC 4941. ftp://ftp.rfc-editor.org/in-notes/rfc4941.txt Our IPv6 implementation comes with the code to enable this feature, but by default it is turned off. My proposal is to enable it by default, and give the user a knob in rc.conf to turn it off. I'm interested in any arguments y'all might have for or against. To test this is pretty simple, add the following to /etc/sysctl.conf: net.inet6.ip6.use_tempaddr=1 net.inet6.ip6.prefer_tempaddr=1 The "normal" EUI-64-based address will still be configured, but there will also be a random identifier added to the interface as an alias, and outgoing traffic will go out from that address. In way of comparison, windows starting with XP enables this feature by default for clients, and has a knob to enable it for servers. I'd be interested to hear what other systems do. Thoughts? Doug - -- ~ This .signature sanitized for your protection -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEAREDAAYFAkhODAcACgkQyIakK9Wy8PumNgCg8Gi+sa0OYanbVcY1IgGu0S3i 64sAn2edBnEh1YkEeqvKPHrAZnOQAbsr =PNXz -----END PGP SIGNATURE----- From randy at psg.com Tue Jun 10 07:45:31 2008 From: randy at psg.com (Randy Bush) Date: Tue Jun 10 07:45:33 2008 Subject: Proposal: Enable IPv6 Privacy Extensions (RFCs 3041/4941) by default In-Reply-To: <484E0C08.1060800@FreeBSD.org> References: <484E0C08.1060800@FreeBSD.org> Message-ID: <484E3119.4060102@psg.com> > To address those privacy concerns RFC 3041 was written, and eventually > obsoleted by RFC 4941. ftp://ftp.rfc-editor.org/in-notes/rfc4941.txt > Our IPv6 implementation comes with the code to enable this feature, > but by default it is turned off. My proposal is to enable it by > default, and give the user a knob in rc.conf to turn it off. the only drawback is that forward and reverse dns would not be easily filled. but anyone who relies on a mac address for dns hacking is asking for trouble; use dhcpv6 or hard code the host's ip address in /etc/rc.conf. so i have no problem with the change. thanks for asking. randy From yonyossef.lists at gmail.com Tue Jun 10 08:03:22 2008 From: yonyossef.lists at gmail.com (Yony Yossef) Date: Tue Jun 10 08:03:25 2008 Subject: TCP messages go OUT OF ORDER on FreeBSD 7 Message-ID: <20def4870806100103o6fcc70e3t78adf8f94d0b3b47@mail.gmail.com> Hi All. I'm working on a 10GigE driver for FreeBSD 7, supporting both LRO and TSO (LSO). I get a stable connection enabling LRO alone and TSO alone, but when I enable both offloads I get OUT OF ORDER packets on the sender side. Meaning the sending OS sends the same packet several times without getting any ACKs in between. The wireshark timestamps show that the sender did not even wait too long in order to retransmit the packets, there is only a 10-20 microsecs gap between the first and second sends of the same packet. I'm a TCP/IP newbee, can anybody explain to me how can this happen? Yony From yonyossef.lists at gmail.com Tue Jun 10 08:25:42 2008 From: yonyossef.lists at gmail.com (Yony Yossef) Date: Tue Jun 10 08:25:45 2008 Subject: tso_segsz and mss above jumbo MTU in FreeBSD 7 Message-ID: <20def4870806100125l7b5b1e6fhd295d46d1106abb5@mail.gmail.com> Hi All. I'm working on a 10GigE driver for FreeBSD 7. Looking at other GigE and 10GigE drivers I've seen that mbuf->m_pkthdr.tso_segsz is assigned to MSS (Max Segment Size) on the Tx routines. If I understand correctly the tso_segsz is supposed to inform the driver with the MTU set by the OS, therefore it should change upon ifconfig mtu commands. When I set my MTU to 9600 I still recieve tso_segsz=1500 in the Tx mbufs from the OS. Where's my mistake here? Yony From steve at ibctech.ca Tue Jun 10 12:42:05 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Tue Jun 10 12:42:10 2008 Subject: Proposal: Enable IPv6 Privacy Extensions (RFCs 3041/4941) by default In-Reply-To: <484E3119.4060102@psg.com> References: <484E0C08.1060800@FreeBSD.org> <484E3119.4060102@psg.com> Message-ID: <484E7718.9050607@ibctech.ca> Randy Bush wrote: >> To address those privacy concerns RFC 3041 was written, and eventually >> obsoleted by RFC 4941. ftp://ftp.rfc-editor.org/in-notes/rfc4941.txt >> Our IPv6 implementation comes with the code to enable this feature, >> but by default it is turned off. My proposal is to enable it by >> default, and give the user a knob in rc.conf to turn it off. > > the only drawback is that forward and reverse dns would not be easily > filled. but anyone who relies on a mac address for dns hacking is > asking for trouble; use dhcpv6 or hard code the host's ip address in > /etc/rc.conf. DNS in this context is really of least concern, and there are simple ways around that as Randy states. I would think that enabling IPv6 Privacy Extensions by default would have no worse effect on a host in regards to DNS than a similar situation with IPv4 Auto Configuration. > so i have no problem with the change. thanks for asking. I also support following the specification by default. Steve From bms at FreeBSD.org Tue Jun 10 12:47:41 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Tue Jun 10 12:47:48 2008 Subject: [Removal of mrouted in FreeBSD-7.0] In-Reply-To: <484DF690.6010101@infoweapons.com> References: <4849C87F.9030804@infoweapons.com> <484A49D6.1000808@FreeBSD.org> <484DF690.6010101@infoweapons.com> Message-ID: <484E77E9.5030101@FreeBSD.org> Archimedes S. Gaviola wrote: > ...if ever there's a way to implement IP multicasting with PIM-SM and > or PIM-DM in the FreeBSD base system, how big is the work would be? > What are the things that needs to be considered if we are going to > implement PIM-SM and or PIM-DM to the current FreeBSD network > subsystem? The goal is to be able FreeBSD to provide native IP > multicast using PIM just like the way DVMRP protocol is implemented > before as part of the base system. I really think the remit of multicast routing is too wide to be addressed in the base system, which is why projects like XORP and pimdd exist -- it doesn't strike me as a good fit for the FreeBSD base system. Separate projects already exist for this. If someone is willing to commit to all the man-hours involved in the reimplementation and ongoing support of such a thing, blimey... they must have a lot of free time! cheers BMS From max at love2party.net Tue Jun 10 12:54:33 2008 From: max at love2party.net (Max Laier) Date: Tue Jun 10 12:54:37 2008 Subject: Proposal: Enable IPv6 Privacy Extensions (RFCs 3041/4941) by default In-Reply-To: <484E0C08.1060800@FreeBSD.org> References: <484E0C08.1060800@FreeBSD.org> Message-ID: Am Di, 10.06.2008, 07:07, schrieb Doug Barton: > By default, IPv6 stateless autoconfiguration creates a 64 bit hostid > for each interface based on the mac address (for ethernet, but for us > that's the common case). This is convenient since if you're using RA > neither the user nor the admin has to do anything to get the node on > line, it "just works." There is a privacy issue with this however, > because this identifier is created in such a way as to make it > globally unique, the machine (and therefore in almost all cases the > user) can be tracked by third parties such as web sites, even if they > move from one network prefix to another, such as with a laptop. > > To address those privacy concerns RFC 3041 was written, and eventually > obsoleted by RFC 4941. ftp://ftp.rfc-editor.org/in-notes/rfc4941.txt > Our IPv6 implementation comes with the code to enable this feature, > but by default it is turned off. My proposal is to enable it by > default, and give the user a knob in rc.conf to turn it off. I'm > interested in any arguments y'all might have for or against. To test > this is pretty simple, add the following to /etc/sysctl.conf: > net.inet6.ip6.use_tempaddr=1 > net.inet6.ip6.prefer_tempaddr=1 > > The "normal" EUI-64-based address will still be configured, but there > will also be a random identifier added to the interface as an alias, > and outgoing traffic will go out from that address. > > In way of comparison, windows starting with XP enables this feature by > default for clients, and has a knob to enable it for servers. I'd be > interested to hear what other systems do. > > > Thoughts? All for it. Are you, however, sure that we implement RFC 4941 fully? I think there are some configuration parameters missing. Also, I seem to recall that our DAD wasn't quite state-of-the-art, yet. Finally, any chance I can get you to implement the socket options in RFC 5014, so that programs have can force a temp/static address if they so choose - independent of the global setting. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From rjohanne at wnk.hamline.edu Tue Jun 10 15:52:07 2008 From: rjohanne at wnk.hamline.edu (R J) Date: Tue Jun 10 15:52:14 2008 Subject: tcpdump/snort to capture chat sessions Message-ID: I am trying to use tcpdump (or snort, but they are both behaving the same in this case) to capture all the lines or contents of an msn chat session, the actual conversation. I am getting partial output; i.e, I'll only get half of a sentence, and I don't see the rest of the lines. And ofcourse, alot of it seems to be hex or obfuscated html? What switches do I need to capture the entire lines of text? I am using these options with snort: snort -i hme1 -v -K None -X That's sending output to stdout, which is fine with me. Thanks for any pointers/suggestions/recommendations. Robert From rpaulo at FreeBSD.org Tue Jun 10 16:01:52 2008 From: rpaulo at FreeBSD.org (Rui Paulo) Date: Tue Jun 10 16:01:56 2008 Subject: Proposal: Enable IPv6 Privacy Extensions (RFCs 3041/4941) by default In-Reply-To: <484E0C08.1060800@FreeBSD.org> References: <484E0C08.1060800@FreeBSD.org> Message-ID: <20080610160140.GB33773@epsilon.local> On Mon, Jun 09, 2008 at 10:07:20PM -0700, Doug Barton wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > By default, IPv6 stateless autoconfiguration creates a 64 bit hostid > for each interface based on the mac address (for ethernet, but for us > that's the common case). This is convenient since if you're using RA > neither the user nor the admin has to do anything to get the node on > line, it "just works." There is a privacy issue with this however, > because this identifier is created in such a way as to make it > globally unique, the machine (and therefore in almost all cases the > user) can be tracked by third parties such as web sites, even if they > move from one network prefix to another, such as with a laptop. > > To address those privacy concerns RFC 3041 was written, and eventually > obsoleted by RFC 4941. ftp://ftp.rfc-editor.org/in-notes/rfc4941.txt > Our IPv6 implementation comes with the code to enable this feature, > but by default it is turned off. My proposal is to enable it by > default, and give the user a knob in rc.conf to turn it off. I'm > interested in any arguments y'all might have for or against. To test > this is pretty simple, add the following to /etc/sysctl.conf: > net.inet6.ip6.use_tempaddr=1 > net.inet6.ip6.prefer_tempaddr=1 > > The "normal" EUI-64-based address will still be configured, but there > will also be a random identifier added to the interface as an alias, > and outgoing traffic will go out from that address. > > In way of comparison, windows starting with XP enables this feature by > default for clients, and has a knob to enable it for servers. I'd be > interested to hear what other systems do. > > > Thoughts? +1. I'm okay with it. Regards, -- Rui Paulo From wmoran at collaborativefusion.com Tue Jun 10 16:03:21 2008 From: wmoran at collaborativefusion.com (Bill Moran) Date: Tue Jun 10 16:03:25 2008 Subject: tcpdump/snort to capture chat sessions In-Reply-To: References: Message-ID: <20080610120222.9e2760fe.wmoran@collaborativefusion.com> In response to R J : > I am trying to use tcpdump (or snort, but they are both behaving the same > in this case) to capture all the lines or contents of an msn > chat session, the actual conversation. I am getting partial output; i.e, > I'll only get half of a sentence, and I don't see the rest of the lines. > And ofcourse, alot of it seems to be hex or obfuscated html? > > What switches do I need to capture the entire lines of text? Don't know about snort, but with tcpdump use -s0 -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wmoran@collaborativefusion.com Phone: 412-422-3463x4023 From rahman.sazzadur at gmail.com Tue Jun 10 16:29:00 2008 From: rahman.sazzadur at gmail.com (sazzadur rahman) Date: Tue Jun 10 16:29:05 2008 Subject: Could not enable SCTP trace: "Sysctl: unknown OID: net.inet.sctp.sctp_logging" Message-ID: <82bdb5ec0806100928q15e25480k24f88798e12bffc4@mail.gmail.com> Hi, Thanks for the suggestion. I am trying to get real time cwnd data via SCTP logging function (SCTP_LOCAL_TRACE_BUF). I could compile the utilities dump_apple_log and prtcwdlog successfully. But I failed to enable logging trace. Below are the steps I have proceeded: 1. Installed FreeBSD 7.0 2. Build a custom kernel cd /usr/src/sys/i386/conf cp GENERIC /root/CUSTOM_KERNEL_9_6 ln -s /root/CUSTOM_KERNEL_9_6 cd /usr/src make buildkernel KERNCONF=CUSTOM_KERNEL_9_6 3. I found opt_sctp.h in /usr/obj/usr/src/sys/CUSTOM_KERNEL_9_6 along with all sctp binaries here. 4. To see SCTP_LOCAL_TRACE_BUF is already defined or not, I executed the following command: Cd /usr/obj/usr/src/sys/CUSTOM_KERNEL_9_6 nm sctputil.o | grep sctp_log_trace And it didn't show me any symbol. That means SCTP_LOCAL_TRACE_BUF is not defined so far. 5. Added the following line in opt_sctp.h #define SCTP_LOCAL_TRACE_BUF 1 6. Run 'make' to compile sctp with SCTP_LOCAL_TRACE_BUF 7. To see SCTP_LOCAL_TRACE_BUF is compiled or not, again, I executed the following command: nm sctputil.o | grep sctp_log_trace 00000130 T sctp_log_trace Hence, I assumed that sctp is built with SCTP_LOCAL_TRACE_BUF. 8. I installed this custom kernel : Make installkernel KERNCONF=CUSTOM_KERNEL_9_6 9. Reboot and load the new kernel. 10. Tried to enable trace point by: Sysctl -w "net.inet.sctp.sctp_logging=0x00000004" But got:( Sysctl: unknown OID: net.inet.sctp.sctp_logging At this point, I guess that SCTP was not successfully built with SCTP_LOCAL_TRACE_BUF and that's why sysctl is unable to find the OID. Do you have any suggestions how can I build SCTP with SCTP_LOCAL_TRACE_BUF successfully? I would appreciate any help in this regard. Best Regards, Md Sazzadur Rahman Graduate Student, School of Computer Science, University of Oklahoma, Norman, Oklahoma, USA -----Original Message----- From: Randall Stewart [mailto:rrs@cisco.com] Sent: Wednesday, April 16, 2008 9:04 AM To: Rahman, Md Sazzadur Cc: freebsd-net@freebsd.org Subject: Re: A query regarding SCTP congestion control Rahman, Md Sazzadur wrote: > Hi, I would like to get the values of SCTP congestion control > algorithm variables (cwnd, ssthresh, flightsize and pba) from any > SCTP based application in runtime for research purpose. Does any API > exist in SCTP for that? Do I need to dig the SCTP code in kernel to > get the values? There is a socket option to get the cwnd. However, I think what you really want is some of the researchish tracing stuff that SCTP provides. You can actually get a real time trace of the cwnd/flight etc via the various logging functions. You basically must compile this as an option.. have to go look at the options.. And then you can either use ktrace (which I don't recommend since it turns on to much overhead in the kernel) or you can use SCTP_LOCAL_TRACE_BUF This will put it into a piece of memory only for SCTP and not turn on all the other ktrace points. After you enable the logging in your compile you must turn on the logging level.. SCTP_CWND_LOGGING_ENABLE woudl be my recommendation. It gives you a real time up/down growth of the cwnd/flight/rwnd I think I wrote a "how to" somewhere.. let me go look.. R > > I will appreciate any help in this regard. > > Best Regards, Md Sazzadur Rahman Graduate Student, School of Computer > Science, University of Oklahoma, Norman, Oklahoma, USA > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, > send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From jfvogel at gmail.com Tue Jun 10 16:51:53 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Tue Jun 10 16:51:57 2008 Subject: Vlan EVENT patch Message-ID: <2a41acea0806100951x1142edc6qc872d3810c2bd467@mail.gmail.com> This is a small patch that Sam came up with for me, it will allow drivers to know when a vlan attaches. It is transparent to any code that doesn't want to change, but this will allow my drivers to finally utilize the vlan hardware filter (something Linux has had for ever but we lacked). My test group has done some basic testing of this and it is working great. But we wanted to give any vlan users a chance to see, ask questions, or whatever before its committed. Jack From jfvogel at gmail.com Tue Jun 10 17:30:37 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Tue Jun 10 17:30:40 2008 Subject: Vlan EVENT patch In-Reply-To: <2a41acea0806100951x1142edc6qc872d3810c2bd467@mail.gmail.com> References: <2a41acea0806100951x1142edc6qc872d3810c2bd467@mail.gmail.com> Message-ID: <2a41acea0806101030xa9f0689k663709a4595b1771@mail.gmail.com> On 6/10/08, Jack Vogel wrote: > This is a small patch that Sam came up with for me, it will allow > drivers to know > when a vlan attaches. > > It is transparent to any code that doesn't want to change, but this > will allow my > drivers to finally utilize the vlan hardware filter (something Linux has had > for > ever but we lacked). > > My test group has done some basic testing of this and it is working great. > But we wanted to give any vlan users a chance to see, ask questions, or > whatever before its committed. > > Jack > Sigh, sorry, here's the actual patch :) Jack -------------- next part -------------- A non-text attachment was scrubbed... Name: vlan.patch Type: text/x-patch Size: 1394 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080610/08448448/vlan.bin From jhb at FreeBSD.org Tue Jun 10 18:48:36 2008 From: jhb at FreeBSD.org (jhb@FreeBSD.org) Date: Tue Jun 10 18:48:39 2008 Subject: kern/122875: [nfs] "rstatd: Can't get namelist. 1" - fbsd 7.0-stable (works ok in 7.0-release) [regression] Message-ID: <200806101848.m5AImZ9I089383@freefall.freebsd.org> Synopsis: [nfs] "rstatd: Can't get namelist. 1" - fbsd 7.0-stable (works ok in 7.0-release) [regression] State-Changed-From-To: open->patched State-Changed-By: jhb State-Changed-When: Tue Jun 10 18:47:56 UTC 2008 State-Changed-Why: Fix committed to HEAD. Responsible-Changed-From-To: freebsd-net->jhb Responsible-Changed-By: jhb Responsible-Changed-When: Tue Jun 10 18:47:56 UTC 2008 Responsible-Changed-Why: Fix committed to HEAD. http://www.freebsd.org/cgi/query-pr.cgi?pr=122875 From hostmaster at GTS.Infra-service.CA Tue Jun 10 19:15:37 2008 From: hostmaster at GTS.Infra-service.CA (hotlips Internet admin) Date: Tue Jun 10 19:15:40 2008 Subject: kern/122875: [nfs] "rstatd: Can't get namelist. 1" - fbsd 7.0-stable (works ok in 7.0-release) [regression] In-Reply-To: <200806101848.m5AImZ9I089383@freefall.freebsd.org> References: <200806101848.m5AImZ9I089383@freefall.freebsd.org> Message-ID: On Tue, 10 Jun 2008 jhb@FreeBSD.org wrote: |Synopsis: [nfs] "rstatd: Can't get namelist. 1" - fbsd 7.0-stable (works ok in 7.0-release) [regression] | |State-Changed-From-To: open->patched |State-Changed-By: jhb |State-Changed-When: Tue Jun 10 18:47:56 UTC 2008 |State-Changed-Why: |Fix committed to HEAD. | | |Responsible-Changed-From-To: freebsd-net->jhb |Responsible-Changed-By: jhb |Responsible-Changed-When: Tue Jun 10 18:47:56 UTC 2008 |Responsible-Changed-Why: |Fix committed to HEAD. | |http://www.freebsd.org/cgi/query-pr.cgi?pr=122875 will this get propagated to 6.3 & 7.0 ? Thanks, Bruce Becker +1 416 410 0879 GTS Network Administration Toronto, Ont. Email: hostmaster@GTS.Infra-service.CA From jhb at freebsd.org Tue Jun 10 19:25:18 2008 From: jhb at freebsd.org (John Baldwin) Date: Tue Jun 10 19:25:20 2008 Subject: kern/122875: [nfs] "rstatd: Can't get namelist. 1" - fbsd 7.0-stable (works ok in 7.0-release) [regression] In-Reply-To: References: <200806101848.m5AImZ9I089383@freefall.freebsd.org> Message-ID: <200806101524.15124.jhb@freebsd.org> On Tuesday 10 June 2008 03:01:34 pm hotlips Internet admin wrote: > On Tue, 10 Jun 2008 jhb@FreeBSD.org wrote: > > |Synopsis: [nfs] "rstatd: Can't get namelist. 1" - fbsd 7.0-stable (works ok in 7.0-release) [regression] > | > |State-Changed-From-To: open->patched > |State-Changed-By: jhb > |State-Changed-When: Tue Jun 10 18:47:56 UTC 2008 > |State-Changed-Why: > |Fix committed to HEAD. > | > | > |Responsible-Changed-From-To: freebsd-net->jhb > |Responsible-Changed-By: jhb > |Responsible-Changed-When: Tue Jun 10 18:47:56 UTC 2008 > |Responsible-Changed-Why: > |Fix committed to HEAD. > | > |http://www.freebsd.org/cgi/query-pr.cgi?pr=122875 > > > will this get propagated to 6.3 & 7.0 ? It will go to RELENG_6 and RELENG_7. The cp_time changes were never made in RELENG_6_3 and RELENG_7_0 so they should not need this change. -- John Baldwin From hostmaster at GTS.Infra-service.CA Tue Jun 10 19:45:50 2008 From: hostmaster at GTS.Infra-service.CA (hotlips Internet admin) Date: Tue Jun 10 19:45:56 2008 Subject: kern/122875: [nfs] "rstatd: Can't get namelist. 1" - fbsd 7.0-stable (works ok in 7.0-release) [regression] In-Reply-To: <200806101524.15124.jhb@freebsd.org> References: <200806101848.m5AImZ9I089383@freefall.freebsd.org> <200806101524.15124.jhb@freebsd.org> Message-ID: On Tue, 10 Jun 2008, John Baldwin wrote: |On Tuesday 10 June 2008 03:01:34 pm hotlips Internet admin wrote: |> On Tue, 10 Jun 2008 jhb@FreeBSD.org wrote: |> |> |Synopsis: [nfs] "rstatd: Can't get namelist. 1" - fbsd 7.0-stable (works ok |in 7.0-release) [regression] |> | |> |State-Changed-From-To: open->patched |> |State-Changed-By: jhb |> |State-Changed-When: Tue Jun 10 18:47:56 UTC 2008 |> |State-Changed-Why: |> |Fix committed to HEAD. |> | |> | |> |Responsible-Changed-From-To: freebsd-net->jhb |> |Responsible-Changed-By: jhb |> |Responsible-Changed-When: Tue Jun 10 18:47:56 UTC 2008 |> |Responsible-Changed-Why: |> |Fix committed to HEAD. |> | |> |http://www.freebsd.org/cgi/query-pr.cgi?pr=122875 |> |> will this get propagated to 6.3 & 7.0 ? | |It will go to RELENG_6 and RELENG_7. The cp_time changes were never made in |RELENG_6_3 and RELENG_7_0 so they should not need this change. perfect - this will make my life a bit easier when it's in place :) Thanks, Bruce Becker +1 416 410 0879 GTS Network Administration Toronto, Ont. Email: hostmaster@GTS.Infra-service.CA From steve at ibctech.ca Wed Jun 11 02:51:11 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Wed Jun 11 02:51:14 2008 Subject: Throughput rate testing configurations Message-ID: <484F3E1B.9050104@ibctech.ca> Hi everyone, I see what I believe to be less-than-adequate communication performance between many devices in parts of our network. Can someone recommend software (and config recommendations if possible) that I can implement to test both throughput and pps reliably, initially/primarily in a simple host-sw-host configuration? Perhaps I'm asking too much, but I'd like to have something that can push the link to it's absolute maximum capacity (for now, up to 1Gbps) for a long sustained time, that I can just walk away from and let it do it's work, and review the reports later where it had to scale down due to errors. What I'm really trying to achieve is: - test the link between hosts alone - throw in a switch - test the link while r/w to disk - test the link while r/w to GELI disk - test the link with oddball MTU sizes ...and see what impact occurs in each scenario, to be able to tell where things can be improved. All machines that will be part of this test will be either 6.3 or 7. Steve From tarkhil at webmail.sub.ru Wed Jun 11 07:06:56 2008 From: tarkhil at webmail.sub.ru (Alex Povolotsky) Date: Wed Jun 11 07:07:00 2008 Subject: mpd, nat, netflow: does not work for me Message-ID: <484F7339.7040400@webmail.sub.ru> Hello! I'm trying to use mpd 5.1, on FreeBSD 6.2, and got some really strange problems. 1. NAT. [10:37] services-new:/<2>etc/mpd5 # grep nat /usr/local/etc/mpd5/mpd.conf set nat address 81.195.122.86 set iface enable nat in web interface, option for interface includes "nat enable" NO address translation at all. 2. Netflow set iface enable netflow-out set netflow peer PEER-IP-ADDR 8787 netflow-out, of course, is labeled as "enable" MPD even sends some netflow data (1464 bytes packet every 15-20 minutes, it is definitely insufficient to send required data), collector receives it and stores nothing. Maybe someone could help? Alex. From pyunyh at gmail.com Wed Jun 11 07:35:25 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Wed Jun 11 07:35:30 2008 Subject: Vlan EVENT patch In-Reply-To: <2a41acea0806100951x1142edc6qc872d3810c2bd467@mail.gmail.com> References: <2a41acea0806100951x1142edc6qc872d3810c2bd467@mail.gmail.com> Message-ID: <20080611073313.GF3529@cdnetworks.co.kr> On Tue, Jun 10, 2008 at 09:51:53AM -0700, Jack Vogel wrote: > This is a small patch that Sam came up with for me, it will allow > drivers to know > when a vlan attaches. > > It is transparent to any code that doesn't want to change, but this > will allow my > drivers to finally utilize the vlan hardware filter (something Linux has had for > ever but we lacked). > Just curious, is there any rule how to use that new capability? Because drivers will receive events whenever VLAN tags are added/removed they would know how to act for these events. If promiscuous mode is on for interface, driver should not filter any VLAN tagged frames, right? If users want to disable VLAN hardware filtering feature what is best way to perform this? Introducing a new flag like IFCAP_VLAN_HWFILT or add a new sysctl that control this feature? I guess VIA Rhine III also have VLAN hardware filtering capability so it would be even better if we have a way to share common part. > My test group has done some basic testing of this and it is working great. > But we wanted to give any vlan users a chance to see, ask questions, or > whatever before its committed. > > Jack -- Regards, Pyun YongHyeon From gavin at FreeBSD.org Wed Jun 11 13:01:35 2008 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Wed Jun 11 13:01:40 2008 Subject: kern/122145: error while compiling with device ath_rate_amrr Message-ID: <200806111301.m5BD1ZuU037570@freefall.freebsd.org> Synopsis: error while compiling with device ath_rate_amrr State-Changed-From-To: open->patched State-Changed-By: gavin State-Changed-When: Wed Jun 11 12:59:14 UTC 2008 State-Changed-Why: Mark as patched, this is fixed in HEAD and RELENG_7 http://www.freebsd.org/cgi/query-pr.cgi?pr=122145 From jfvogel at gmail.com Wed Jun 11 16:52:25 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Wed Jun 11 16:52:27 2008 Subject: Vlan EVENT patch In-Reply-To: <20080611073313.GF3529@cdnetworks.co.kr> References: <2a41acea0806100951x1142edc6qc872d3810c2bd467@mail.gmail.com> <20080611073313.GF3529@cdnetworks.co.kr> Message-ID: <2a41acea0806110952n2851415dyf3b3213249779bf1@mail.gmail.com> On Wed, Jun 11, 2008 at 12:33 AM, Pyun YongHyeon wrote: > On Tue, Jun 10, 2008 at 09:51:53AM -0700, Jack Vogel wrote: > > This is a small patch that Sam came up with for me, it will allow > > drivers to know > > when a vlan attaches. > > > > It is transparent to any code that doesn't want to change, but this > > will allow my > > drivers to finally utilize the vlan hardware filter (something Linux has had for > > ever but we lacked). > > > > Just curious, is there any rule how to use that new capability? > Because drivers will receive events whenever VLAN tags are > added/removed they would know how to act for these events. If > promiscuous mode is on for interface, driver should not filter any > VLAN tagged frames, right? > If users want to disable VLAN hardware filtering feature what is > best way to perform this? Introducing a new flag like > IFCAP_VLAN_HWFILT or add a new sysctl that control this feature? > I guess VIA Rhine III also have VLAN hardware filtering capability > so it would be even better if we have a way to share common part. All the patch does is have the vlan driver generate events when it attaches or detaches from a NIC, there are no rules, however I can tell you what I'm coding into this in the Intel drivers. The way it works is the driver registers a callback for each event, I will call that [igb,em,ixgbe]_register_vlan(), and unregister obviously. Right now, the drivers just generically enable VLAN capability because there is never a trigger to know IF and WHEN you need to do so, but with this change the VLAN capability will only get turned on by the registration routine. Most significantly, now when the pseudo device it gives the driver the VLAN tag, this will mean the driver will be able from the start to use the VFTA, the hardware filter, for each vlan attach the driver will add the ID into this table. The unregister event will turn the table entry off, and if this is the last VLAN being detached it will then disable the features. Oh yes, these routines will also take care of the size change of the frame due to the tag. I already have the changes in place in the igb drive, and they are working great. I do not understand why you think you need a flag to disable this, yes it could be done, but why? If you need to do some sort of debugging won't a system not using vlans and in promiscuous mode do just fine? It just seems to violate the whole reason for doing vlans in the first place, however perhaps I am missing something? I do not believe the Linux driver has some way to disable use of the table but I'll double check on that. Remember, this change requires NO driver changes unless they wish to take advantage of the ability. Cheers, Jack From security at jim-liesl.org Wed Jun 11 17:18:14 2008 From: security at jim-liesl.org (security) Date: Wed Jun 11 17:18:19 2008 Subject: Throughput rate testing configurations In-Reply-To: <484F3E1B.9050104@ibctech.ca> References: <484F3E1B.9050104@ibctech.ca> Message-ID: <4850028F.6090103@jim-liesl.org> Steve Bertrand wrote: > Hi everyone, > > I see what I believe to be less-than-adequate communication > performance between many devices in parts of our network. > > Can someone recommend software (and config recommendations if > possible) that I can implement to test both throughput and pps > reliably, initially/primarily in a simple host-sw-host configuration? > > Perhaps I'm asking too much, but I'd like to have something that can > push the link to it's absolute maximum capacity (for now, up to 1Gbps) > for a long sustained time, that I can just walk away from and let it > do it's work, and review the reports later where it had to scale down > due to errors. > > What I'm really trying to achieve is: > > - test the link between hosts alone > - throw in a switch > - test the link while r/w to disk > - test the link while r/w to GELI disk > - test the link with oddball MTU sizes > Iperf or netperf are probably what you're looking for. Both try real had NOT to tweak other subsystems while they run, so if you want to throw disk activity in, you'll need to run another tool or roll your own to create disk activity. You probably don't want to run them for extended periods in a production network. Depending on the adapters at each end, you may or may not be able to drive the link to saturation or alter frame size. The Intel adapters I've seen allow jumbo frames, and generally good performance (as opposed to say the realtek). It's also useful to have a managed switch in between so you can look at the counters on it. jim From tom at tomjudge.com Wed Jun 11 20:20:43 2008 From: tom at tomjudge.com (Tom Judge) Date: Wed Jun 11 20:20:50 2008 Subject: tcpdump/snort to capture chat sessions In-Reply-To: <20080610120222.9e2760fe.wmoran@collaborativefusion.com> References: <20080610120222.9e2760fe.wmoran@collaborativefusion.com> Message-ID: <48502F2C.7090505@tomjudge.com> Bill Moran wrote: > In response to R J : > >> I am trying to use tcpdump (or snort, but they are both behaving the same >> in this case) to capture all the lines or contents of an msn >> chat session, the actual conversation. I am getting partial output; i.e, >> I'll only get half of a sentence, and I don't see the rest of the lines. >> And ofcourse, alot of it seems to be hex or obfuscated html? >> >> What switches do I need to capture the entire lines of text? > > Don't know about snort, but with tcpdump use -s0 > This is a good start however you are not guaranteed to see the whole chat message in a single TCP packet. If you are looking for something more advanced you will have to write a program around pcap/bpf or similar to read the TCP stream. Tom J From hostmaster at GTS.Infra-service.CA Wed Jun 11 20:41:35 2008 From: hostmaster at GTS.Infra-service.CA (hotlips Internet admin) Date: Wed Jun 11 20:41:38 2008 Subject: kern/122875: [nfs] "rstatd: Can't get namelist. 1" - fbsd 7.0-stable (works ok in 7.0-release) [regression] In-Reply-To: <200806101524.15124.jhb@freebsd.org> References: <200806101848.m5AImZ9I089383@freefall.freebsd.org> <200806101524.15124.jhb@freebsd.org> Message-ID: On Tue, 10 Jun 2008, John Baldwin wrote: |On Tuesday 10 June 2008 03:01:34 pm hotlips Internet admin wrote: |> On Tue, 10 Jun 2008 jhb@FreeBSD.org wrote: |> |> |Synopsis: [nfs] "rstatd: Can't get namelist. 1" - fbsd 7.0-stable (works ok in 7.0-release) [regression] |> | |> |State-Changed-From-To: open->patched |> |State-Changed-By: jhb |> |State-Changed-When: Tue Jun 10 18:47:56 UTC 2008 |> |State-Changed-Why: |> |Fix committed to HEAD. |> | |> |Responsible-Changed-From-To: freebsd-net->jhb |> |Responsible-Changed-By: jhb |> |Responsible-Changed-When: Tue Jun 10 18:47:56 UTC 2008 |> |Responsible-Changed-Why: |> |Fix committed to HEAD. |> | |> |http://www.freebsd.org/cgi/query-pr.cgi?pr=122875 |> |> will this get propagated to 6.3 & 7.0 ? | |It will go to RELENG_6 and RELENG_7. The cp_time changes were never made in |RELENG_6_3 and RELENG_7_0 so they should not need this change. ok, I'm somewhat confused. It seems the patch is to rpc.rstatd, and not to src/sys/kern/kern_clock.c please note that a patch to kern_clock.c for RELENG_6 seems to have been committed on June 3 (but not for RELENG_7 ??!) also please note that the patch shown below has been in the queue for quite a while now without any action, so further patches to rpc.rstatd should take its fixes into account (since it's rather broken in general without them): http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/92412 Bruce Becker +1 416 410 0879 GTS Network Administration Toronto, Ont. Email: hostmaster@GTS.Infra-service.CA From wmoran at collaborativefusion.com Wed Jun 11 20:42:23 2008 From: wmoran at collaborativefusion.com (Bill Moran) Date: Wed Jun 11 20:42:26 2008 Subject: tcpdump/snort to capture chat sessions In-Reply-To: <48502F2C.7090505@tomjudge.com> References: <20080610120222.9e2760fe.wmoran@collaborativefusion.com> <48502F2C.7090505@tomjudge.com> Message-ID: <20080611164125.ac5b7312.wmoran@collaborativefusion.com> In response to Tom Judge : > Bill Moran wrote: > > In response to R J : > > > >> I am trying to use tcpdump (or snort, but they are both behaving the same > >> in this case) to capture all the lines or contents of an msn > >> chat session, the actual conversation. I am getting partial output; i.e, > >> I'll only get half of a sentence, and I don't see the rest of the lines. > >> And ofcourse, alot of it seems to be hex or obfuscated html? > >> > >> What switches do I need to capture the entire lines of text? > > > > Don't know about snort, but with tcpdump use -s0 > > > This is a good start however you are not guaranteed to see the whole > chat message in a single TCP packet. If you are looking for something > more advanced you will have to write a program around pcap/bpf or > similar to read the TCP stream. He could use wireshark. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wmoran@collaborativefusion.com Phone: 412-422-3463x4023 From pyunyh at gmail.com Thu Jun 12 00:11:54 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Thu Jun 12 00:12:11 2008 Subject: Vlan EVENT patch In-Reply-To: <2a41acea0806110952n2851415dyf3b3213249779bf1@mail.gmail.com> References: <2a41acea0806100951x1142edc6qc872d3810c2bd467@mail.gmail.com> <20080611073313.GF3529@cdnetworks.co.kr> <2a41acea0806110952n2851415dyf3b3213249779bf1@mail.gmail.com> Message-ID: <20080612000943.GA7250@cdnetworks.co.kr> On Wed, Jun 11, 2008 at 09:52:23AM -0700, Jack Vogel wrote: > On Wed, Jun 11, 2008 at 12:33 AM, Pyun YongHyeon wrote: > > On Tue, Jun 10, 2008 at 09:51:53AM -0700, Jack Vogel wrote: > > > This is a small patch that Sam came up with for me, it will allow > > > drivers to know > > > when a vlan attaches. > > > > > > It is transparent to any code that doesn't want to change, but this > > > will allow my > > > drivers to finally utilize the vlan hardware filter (something Linux has had for > > > ever but we lacked). > > > > > > > Just curious, is there any rule how to use that new capability? > > Because drivers will receive events whenever VLAN tags are > > added/removed they would know how to act for these events. If > > promiscuous mode is on for interface, driver should not filter any > > VLAN tagged frames, right? > > If users want to disable VLAN hardware filtering feature what is > > best way to perform this? Introducing a new flag like > > IFCAP_VLAN_HWFILT or add a new sysctl that control this feature? > > I guess VIA Rhine III also have VLAN hardware filtering capability > > so it would be even better if we have a way to share common part. > > All the patch does is have the vlan driver generate events when it attaches > or detaches from a NIC, there are no rules, however I can tell you what > I'm coding into this in the Intel drivers. > > The way it works is the driver registers a callback for each event, I will > call that [igb,em,ixgbe]_register_vlan(), and unregister obviously. > > Right now, the drivers just generically enable VLAN capability because > there is never a trigger to know IF and WHEN you need to do so, but > with this change the VLAN capability will only get turned on by the > registration routine. > > Most significantly, now when the pseudo device it gives the driver > the VLAN tag, this will mean the driver will be able from the start > to use the VFTA, the hardware filter, for each vlan attach the driver > will add the ID into this table. > > The unregister event will turn the table entry off, and if this is the > last VLAN being detached it will then disable the features. > > Oh yes, these routines will also take care of the size change of > the frame due to the tag. I already have the changes in place in > the igb drive, and they are working great. > > I do not understand why you think you need a flag to disable this, > yes it could be done, but why? If you need to do some sort of > debugging won't a system not using vlans and in promiscuous > mode do just fine? > I guess this would be the same reason why FreeBSD have a way to disable checksum offload for buggy hardware. Diabling all hardware VLAN assistance due to broken VLAN filtering doesn't look right. > It just seems to violate the whole reason for doing vlans in the > first place, however perhaps I am missing something? I do not > believe the Linux driver has some way to disable use of the table > but I'll double check on that. > > Remember, this change requires NO driver changes unless they > wish to take advantage of the ability. Yes. > > Cheers, > > Jack Thanks. -- Regards, Pyun YongHyeon From sam at errno.com Thu Jun 12 02:41:40 2008 From: sam at errno.com (Sam Leffler) Date: Thu Jun 12 02:41:47 2008 Subject: Vlan EVENT patch In-Reply-To: <20080612000943.GA7250@cdnetworks.co.kr> References: <2a41acea0806100951x1142edc6qc872d3810c2bd467@mail.gmail.com> <20080611073313.GF3529@cdnetworks.co.kr> <2a41acea0806110952n2851415dyf3b3213249779bf1@mail.gmail.com> <20080612000943.GA7250@cdnetworks.co.kr> Message-ID: <48508708.50903@errno.com> [trimming cc list to reduce spamage] Pyun YongHyeon wrote: > On Wed, Jun 11, 2008 at 09:52:23AM -0700, Jack Vogel wrote: > > On Wed, Jun 11, 2008 at 12:33 AM, Pyun YongHyeon wrote: > > > On Tue, Jun 10, 2008 at 09:51:53AM -0700, Jack Vogel wrote: > > > > This is a small patch that Sam came up with for me, it will allow > > > > drivers to know > > > > when a vlan attaches. > > > > > > > > It is transparent to any code that doesn't want to change, but this > > > > will allow my > > > > drivers to finally utilize the vlan hardware filter (something Linux has had for > > > > ever but we lacked). > > > > > > > > > > Just curious, is there any rule how to use that new capability? > > > Because drivers will receive events whenever VLAN tags are > > > added/removed they would know how to act for these events. If > > > promiscuous mode is on for interface, driver should not filter any > > > VLAN tagged frames, right? > > > If users want to disable VLAN hardware filtering feature what is > > > best way to perform this? Introducing a new flag like > > > IFCAP_VLAN_HWFILT or add a new sysctl that control this feature? > > > I guess VIA Rhine III also have VLAN hardware filtering capability > > > so it would be even better if we have a way to share common part. > > > > All the patch does is have the vlan driver generate events when it attaches > > or detaches from a NIC, there are no rules, however I can tell you what > > I'm coding into this in the Intel drivers. > > > > The way it works is the driver registers a callback for each event, I will > > call that [igb,em,ixgbe]_register_vlan(), and unregister obviously. > > > > Right now, the drivers just generically enable VLAN capability because > > there is never a trigger to know IF and WHEN you need to do so, but > > with this change the VLAN capability will only get turned on by the > > registration routine. > > > > Most significantly, now when the pseudo device it gives the driver > > the VLAN tag, this will mean the driver will be able from the start > > to use the VFTA, the hardware filter, for each vlan attach the driver > > will add the ID into this table. > > > > The unregister event will turn the table entry off, and if this is the > > last VLAN being detached it will then disable the features. > > > > Oh yes, these routines will also take care of the size change of > > the frame due to the tag. I already have the changes in place in > > the igb drive, and they are working great. > > > > I do not understand why you think you need a flag to disable this, > > yes it could be done, but why? If you need to do some sort of > > debugging won't a system not using vlans and in promiscuous > > mode do just fine? > > > > I guess this would be the same reason why FreeBSD have a way to > disable checksum offload for buggy hardware. Diabling all hardware > VLAN assistance due to broken VLAN filtering doesn't look right. > > > It just seems to violate the whole reason for doing vlans in the > > first place, however perhaps I am missing something? I do not > > believe the Linux driver has some way to disable use of the table > > but I'll double check on that. > > > > Remember, this change requires NO driver changes unless they > > wish to take advantage of the ability. > > Yes. > > > > > Cheers, > > > > Jack > > Thanks. Sounds like there needs to be a h/w vlan assist capability bit that controls this in the driver. Then you'd have a way to disable via ifconfig w/ a trivial mod. Sam From jfvogel at gmail.com Thu Jun 12 03:49:04 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Thu Jun 12 03:49:06 2008 Subject: Vlan EVENT patch In-Reply-To: <48508708.50903@errno.com> References: <2a41acea0806100951x1142edc6qc872d3810c2bd467@mail.gmail.com> <20080611073313.GF3529@cdnetworks.co.kr> <2a41acea0806110952n2851415dyf3b3213249779bf1@mail.gmail.com> <20080612000943.GA7250@cdnetworks.co.kr> <48508708.50903@errno.com> Message-ID: <2a41acea0806112048g60084f72o4391701ba242442@mail.gmail.com> On Wed, Jun 11, 2008 at 7:16 PM, Sam Leffler wrote: > [trimming cc list to reduce spamage] > > Pyun YongHyeon wrote: >> >> On Wed, Jun 11, 2008 at 09:52:23AM -0700, Jack Vogel wrote: >> > On Wed, Jun 11, 2008 at 12:33 AM, Pyun YongHyeon >> wrote: >> > > On Tue, Jun 10, 2008 at 09:51:53AM -0700, Jack Vogel wrote: >> > > > This is a small patch that Sam came up with for me, it will allow >> > > > drivers to know >> > > > when a vlan attaches. >> > > > >> > > > It is transparent to any code that doesn't want to change, but >> this >> > > > will allow my >> > > > drivers to finally utilize the vlan hardware filter (something >> Linux has had for >> > > > ever but we lacked). >> > > > >> > > >> > > Just curious, is there any rule how to use that new capability? >> > > Because drivers will receive events whenever VLAN tags are >> > > added/removed they would know how to act for these events. If >> > > promiscuous mode is on for interface, driver should not filter any >> > > VLAN tagged frames, right? >> > > If users want to disable VLAN hardware filtering feature what is >> > > best way to perform this? Introducing a new flag like >> > > IFCAP_VLAN_HWFILT or add a new sysctl that control this feature? >> > > I guess VIA Rhine III also have VLAN hardware filtering capability >> > > so it would be even better if we have a way to share common part. >> > > All the patch does is have the vlan driver generate events when it >> attaches >> > or detaches from a NIC, there are no rules, however I can tell you what >> > I'm coding into this in the Intel drivers. >> > > The way it works is the driver registers a callback for each event, >> I will >> > call that [igb,em,ixgbe]_register_vlan(), and unregister obviously. >> > > Right now, the drivers just generically enable VLAN capability >> because >> > there is never a trigger to know IF and WHEN you need to do so, but >> > with this change the VLAN capability will only get turned on by the >> > registration routine. >> > > Most significantly, now when the pseudo device it gives the driver >> > the VLAN tag, this will mean the driver will be able from the start >> > to use the VFTA, the hardware filter, for each vlan attach the driver >> > will add the ID into this table. >> > > The unregister event will turn the table entry off, and if this is >> the >> > last VLAN being detached it will then disable the features. >> > > Oh yes, these routines will also take care of the size change of >> > the frame due to the tag. I already have the changes in place in >> > the igb drive, and they are working great. >> > > I do not understand why you think you need a flag to disable this, >> > yes it could be done, but why? If you need to do some sort of >> > debugging won't a system not using vlans and in promiscuous >> > mode do just fine? >> > >> I guess this would be the same reason why FreeBSD have a way to >> disable checksum offload for buggy hardware. Diabling all hardware >> VLAN assistance due to broken VLAN filtering doesn't look right. >> >> > It just seems to violate the whole reason for doing vlans in the >> > first place, however perhaps I am missing something? I do not >> > believe the Linux driver has some way to disable use of the table >> > but I'll double check on that. >> > > Remember, this change requires NO driver changes unless they >> > wish to take advantage of the ability. >> >> Yes. >> >> > > Cheers, >> > > Jack >> >> Thanks. > > Sounds like there needs to be a h/w vlan assist capability bit that controls > this in the driver. Then you'd have a way to disable via ifconfig w/ a > trivial mod. I don't want to create stuff in ifconfig when I'm not convinced of the need. If there were, as he says, 'buggy hardware', specifically buggy Intel hardware, then either our drivers would have had special errata or workarounds in it for that, but none of the OS drivers have any special code for issues involving VFTA (the filter) or other VLAN controlling components that I am aware of. If there are other network drivers that are buggy in this regard then why encumber the generic interface due to that, let the drivers deal with it, via sysctl or something of the sort. There are enough real cases of hardware problems we need to address in code that I don't just want to modify code on the mere theoretical possibility of such. How bout this, we put the change into HEAD, I add support as I've planned into the em and igb drivers, and then we let them get tested, if a real problem comes up, THEN we worry about adding special case code, how's that? Regards, Jack From pyunyh at gmail.com Thu Jun 12 04:07:04 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Thu Jun 12 04:07:10 2008 Subject: Vlan EVENT patch In-Reply-To: <2a41acea0806112048g60084f72o4391701ba242442@mail.gmail.com> References: <2a41acea0806100951x1142edc6qc872d3810c2bd467@mail.gmail.com> <20080611073313.GF3529@cdnetworks.co.kr> <2a41acea0806110952n2851415dyf3b3213249779bf1@mail.gmail.com> <20080612000943.GA7250@cdnetworks.co.kr> <48508708.50903@errno.com> <2a41acea0806112048g60084f72o4391701ba242442@mail.gmail.com> Message-ID: <20080612040452.GE7250@cdnetworks.co.kr> On Wed, Jun 11, 2008 at 08:48:58PM -0700, Jack Vogel wrote: > On Wed, Jun 11, 2008 at 7:16 PM, Sam Leffler wrote: > > [trimming cc list to reduce spamage] > > > > Pyun YongHyeon wrote: > >> > >> On Wed, Jun 11, 2008 at 09:52:23AM -0700, Jack Vogel wrote: > >> > On Wed, Jun 11, 2008 at 12:33 AM, Pyun YongHyeon > >> wrote: > >> > > On Tue, Jun 10, 2008 at 09:51:53AM -0700, Jack Vogel wrote: > >> > > > This is a small patch that Sam came up with for me, it will allow > >> > > > drivers to know > >> > > > when a vlan attaches. > >> > > > > >> > > > It is transparent to any code that doesn't want to change, but > >> this > >> > > > will allow my > >> > > > drivers to finally utilize the vlan hardware filter (something > >> Linux has had for > >> > > > ever but we lacked). > >> > > > > >> > > > >> > > Just curious, is there any rule how to use that new capability? > >> > > Because drivers will receive events whenever VLAN tags are > >> > > added/removed they would know how to act for these events. If > >> > > promiscuous mode is on for interface, driver should not filter any > >> > > VLAN tagged frames, right? > >> > > If users want to disable VLAN hardware filtering feature what is > >> > > best way to perform this? Introducing a new flag like > >> > > IFCAP_VLAN_HWFILT or add a new sysctl that control this feature? > >> > > I guess VIA Rhine III also have VLAN hardware filtering capability > >> > > so it would be even better if we have a way to share common part. > >> > > All the patch does is have the vlan driver generate events when it > >> attaches > >> > or detaches from a NIC, there are no rules, however I can tell you what > >> > I'm coding into this in the Intel drivers. > >> > > The way it works is the driver registers a callback for each event, > >> I will > >> > call that [igb,em,ixgbe]_register_vlan(), and unregister obviously. > >> > > Right now, the drivers just generically enable VLAN capability > >> because > >> > there is never a trigger to know IF and WHEN you need to do so, but > >> > with this change the VLAN capability will only get turned on by the > >> > registration routine. > >> > > Most significantly, now when the pseudo device it gives the driver > >> > the VLAN tag, this will mean the driver will be able from the start > >> > to use the VFTA, the hardware filter, for each vlan attach the driver > >> > will add the ID into this table. > >> > > The unregister event will turn the table entry off, and if this is > >> the > >> > last VLAN being detached it will then disable the features. > >> > > Oh yes, these routines will also take care of the size change of > >> > the frame due to the tag. I already have the changes in place in > >> > the igb drive, and they are working great. > >> > > I do not understand why you think you need a flag to disable this, > >> > yes it could be done, but why? If you need to do some sort of > >> > debugging won't a system not using vlans and in promiscuous > >> > mode do just fine? > >> > > >> I guess this would be the same reason why FreeBSD have a way to > >> disable checksum offload for buggy hardware. Diabling all hardware > >> VLAN assistance due to broken VLAN filtering doesn't look right. > >> > >> > It just seems to violate the whole reason for doing vlans in the > >> > first place, however perhaps I am missing something? I do not > >> > believe the Linux driver has some way to disable use of the table > >> > but I'll double check on that. > >> > > Remember, this change requires NO driver changes unless they > >> > wish to take advantage of the ability. > >> > >> Yes. > >> > >> > > Cheers, > >> > > Jack > >> > >> Thanks. > > > > Sounds like there needs to be a h/w vlan assist capability bit that controls > > this in the driver. Then you'd have a way to disable via ifconfig w/ a > > trivial mod. > > I don't want to create stuff in ifconfig when I'm not convinced > of the need. If there were, as he says, 'buggy hardware', specifically > buggy Intel hardware, then either our drivers would have had special > errata or workarounds in it for that, but none of the OS drivers have > any special code for issues involving VFTA (the filter) or other VLAN > controlling components that I am aware of. > > If there are other network drivers that are buggy in this regard then why > encumber the generic interface due to that, let the drivers deal with it, > via sysctl or something of the sort. > > There are enough real cases of hardware problems we need to address in > code that I don't just want to modify code on the mere theoretical possibility > of such. > > How bout this, we put the change into HEAD, I add support as I've planned into > the em and igb drivers, and then we let them get tested, if a real problem comes > up, THEN we worry about adding special case code, how's that? > Please go ahead. I don't have any objections on it. I just thought it would be better to show a flag to indicate hardware VLAN filtering is active in ifconfig(8) and have user disable this feature in some rare cases. > Regards, > > Jack -- Regards, Pyun YongHyeon From phoemix at harmless.hu Thu Jun 12 07:43:21 2008 From: phoemix at harmless.hu (CZUCZY Gergely) Date: Thu Jun 12 07:43:26 2008 Subject: Vlan EVENT patch In-Reply-To: <20080612040452.GE7250@cdnetworks.co.kr> References: <2a41acea0806100951x1142edc6qc872d3810c2bd467@mail.gmail.com> <20080611073313.GF3529@cdnetworks.co.kr> <2a41acea0806110952n2851415dyf3b3213249779bf1@mail.gmail.com> <20080612000943.GA7250@cdnetworks.co.kr> <48508708.50903@errno.com> <2a41acea0806112048g60084f72o4391701ba242442@mail.gmail.com> <20080612040452.GE7250@cdnetworks.co.kr> Message-ID: <20080612092621.61b44529@twoflower.in.publishing.hu> On Thu, 12 Jun 2008 13:04:52 +0900 Pyun YongHyeon wrote: > On Wed, Jun 11, 2008 at 08:48:58PM -0700, Jack Vogel wrote: > > On Wed, Jun 11, 2008 at 7:16 PM, Sam Leffler wrote: > > > [trimming cc list to reduce spamage] > > > > > > Pyun YongHyeon wrote: > > >> > > >> On Wed, Jun 11, 2008 at 09:52:23AM -0700, Jack Vogel wrote: > > >> > On Wed, Jun 11, 2008 at 12:33 AM, Pyun YongHyeon > > >> wrote: > > >> > > On Tue, Jun 10, 2008 at 09:51:53AM -0700, Jack Vogel wrote: > > >> > > > This is a small patch that Sam came up with for me, it will > > >> > > > allow drivers to know > > >> > > > when a vlan attaches. > > >> > > > > > >> > > > It is transparent to any code that doesn't want to change, but > > >> this > > >> > > > will allow my > > >> > > > drivers to finally utilize the vlan hardware filter (something > > >> Linux has had for > > >> > > > ever but we lacked). > > >> > > > > > >> > > > > >> > > Just curious, is there any rule how to use that new capability? > > >> > > Because drivers will receive events whenever VLAN tags are > > >> > > added/removed they would know how to act for these events. If > > >> > > promiscuous mode is on for interface, driver should not filter any > > >> > > VLAN tagged frames, right? > > >> > > If users want to disable VLAN hardware filtering feature what is > > >> > > best way to perform this? Introducing a new flag like > > >> > > IFCAP_VLAN_HWFILT or add a new sysctl that control this feature? > > >> > > I guess VIA Rhine III also have VLAN hardware filtering capability > > >> > > so it would be even better if we have a way to share common part. > > >> > > All the patch does is have the vlan driver generate events when it > > >> attaches > > >> > or detaches from a NIC, there are no rules, however I can tell you > > >> > what I'm coding into this in the Intel drivers. > > >> > > The way it works is the driver registers a callback for each > > >> > > event, > > >> I will > > >> > call that [igb,em,ixgbe]_register_vlan(), and unregister obviously. > > >> > > Right now, the drivers just generically enable VLAN capability > > >> because > > >> > there is never a trigger to know IF and WHEN you need to do so, but > > >> > with this change the VLAN capability will only get turned on by the > > >> > registration routine. > > >> > > Most significantly, now when the pseudo device it gives the driver > > >> > the VLAN tag, this will mean the driver will be able from the start > > >> > to use the VFTA, the hardware filter, for each vlan attach the driver > > >> > will add the ID into this table. > > >> > > The unregister event will turn the table entry off, and if this is > > >> the > > >> > last VLAN being detached it will then disable the features. > > >> > > Oh yes, these routines will also take care of the size change of > > >> > the frame due to the tag. I already have the changes in place in > > >> > the igb drive, and they are working great. > > >> > > I do not understand why you think you need a flag to disable this, > > >> > yes it could be done, but why? If you need to do some sort of > > >> > debugging won't a system not using vlans and in promiscuous > > >> > mode do just fine? > > >> > > > >> I guess this would be the same reason why FreeBSD have a way to > > >> disable checksum offload for buggy hardware. Diabling all hardware > > >> VLAN assistance due to broken VLAN filtering doesn't look right. > > >> > > >> > It just seems to violate the whole reason for doing vlans in the > > >> > first place, however perhaps I am missing something? I do not > > >> > believe the Linux driver has some way to disable use of the table > > >> > but I'll double check on that. > > >> > > Remember, this change requires NO driver changes unless they > > >> > wish to take advantage of the ability. > > >> > > >> Yes. > > >> > > >> > > Cheers, > > >> > > Jack > > >> > > >> Thanks. > > > > > > Sounds like there needs to be a h/w vlan assist capability bit that > > > controls this in the driver. Then you'd have a way to disable via > > > ifconfig w/ a trivial mod. > > > > I don't want to create stuff in ifconfig when I'm not convinced > > of the need. If there were, as he says, 'buggy hardware', specifically > > buggy Intel hardware, then either our drivers would have had special > > errata or workarounds in it for that, but none of the OS drivers have > > any special code for issues involving VFTA (the filter) or other VLAN > > controlling components that I am aware of. > > > > If there are other network drivers that are buggy in this regard then why > > encumber the generic interface due to that, let the drivers deal with it, > > via sysctl or something of the sort. > > > > There are enough real cases of hardware problems we need to address in > > code that I don't just want to modify code on the mere theoretical > > possibility of such. > > > > How bout this, we put the change into HEAD, I add support as I've planned > > into the em and igb drivers, and then we let them get tested, if a real > > problem comes up, THEN we worry about adding special case code, how's that? > > > > Please go ahead. I don't have any objections on it. > I just thought it would be better to show a flag to indicate > hardware VLAN filtering is active in ifconfig(8) and have user > disable this feature in some rare cases. > > > Regards, > > > > Jack I don't know whether it's a policy or not in FreeBSD, but I also agree with the opinion, that a flag should show up in the ifconfig output indicating that hardware filtering is being done on that interface. It helps the administrator to clarify how the hardware is working, which features of the hardware are in use, and also, they can be disabled. Disabling features is important. Sometimes the code is messed up, the hardware is messed up, or neither are messed up, but they are unable to work together. In these cases the feature could be disabled without hacking the source, which is a clean solution. FreeBSD has design, and prefers clean solutions as I see. I understand, that you _currently_ have no troubles and problems with your code and hardware, but there are unforseen cases out there, lots of other hardware then intel's, and to quote Douglas N. Adams, "expect the unexpected". So, it won't hurt if it shows up in ifconfig, and it can be controlled, but definitely helps our job, the administrators'. -- ?dv?lettel, Czuczy Gergely Harmless Digital Bt mailto: gergely.czuczy@harmless.hu Tel: +36-30-9702963 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080612/3abdcf21/signature.pgp From bilouro at bilouro.com Thu Jun 12 14:47:25 2008 From: bilouro at bilouro.com (Victor Hugo Bilouro) Date: Thu Jun 12 14:47:37 2008 Subject: [GSoC - tcptest] Weekly Status Report #02 Message-ID: Hi, I posted the tcptest** weekly status report at freebsd wiki. Links: http://wiki.freebsd.org/VictorBilouro/TCP-IP_regression_test_suite http://wiki.freebsd.org/VictorBilouro/Following_tcptest http://wiki.freebsd.org/VictorBilouro/Release_0.1_Iteration_2 http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2008/bilouro%5ftcptest&HIDEDEL=NO Thank you! cheers -- Victor Hugo Bilouro FreeBSD! **tcptest** --> tcptest is a GSoC (Google Summer of Code) project, it's a TCP/IP Regression Test Suite implementation. As a testing tool, it can perform regression, protocol conformance, and fuzz tests. The tool may also be employed as an aid to protocol developers and both testing and debugging of firewalls/routers. It's was built on top of pcs.sf.net of gnn at freebsd. ps: I will keep the nomenclature used at subject. From gnn at neville-neil.com Thu Jun 12 15:03:42 2008 From: gnn at neville-neil.com (George V. Neville-Neil) Date: Thu Jun 12 15:03:46 2008 Subject: Throughput rate testing configurations In-Reply-To: <4850028F.6090103@jim-liesl.org> References: <484F3E1B.9050104@ibctech.ca> <4850028F.6090103@jim-liesl.org> Message-ID: At Wed, 11 Jun 2008 09:51:27 -0700, security wrote: > > Steve Bertrand wrote: > > Hi everyone, > > > > I see what I believe to be less-than-adequate communication > > performance between many devices in parts of our network. > > > > Can someone recommend software (and config recommendations if > > possible) that I can implement to test both throughput and pps > > reliably, initially/primarily in a simple host-sw-host configuration? > > > > Perhaps I'm asking too much, but I'd like to have something that can > > push the link to it's absolute maximum capacity (for now, up to 1Gbps) > > for a long sustained time, that I can just walk away from and let it > > do it's work, and review the reports later where it had to scale down > > due to errors. > > > > What I'm really trying to achieve is: > > > > - test the link between hosts alone > > - throw in a switch > > - test the link while r/w to disk > > - test the link while r/w to GELI disk > > - test the link with oddball MTU sizes > > > Iperf or netperf are probably what you're looking for. Both try real > had NOT to tweak other subsystems while they run, so if you want to > throw disk activity in, you'll need to run another tool or roll your own > to create disk activity. You probably don't want to run them for > extended periods in a production network. Depending on the adapters at > each end, you may or may not be able to drive the link to saturation or > alter frame size. The Intel adapters I've seen allow jumbo frames, and > generally good performance (as opposed to say the realtek). It's also > useful to have a managed switch in between so you can look at the > counters on it. > I personally prefer netpipe because it tries odd sized (non power of 2) messages and tends to help edge cases come to light. /usr/ports/benchmarks/netpipe Later, George From yonyossef.lists at gmail.com Thu Jun 12 15:17:21 2008 From: yonyossef.lists at gmail.com (Yony Yossef) Date: Thu Jun 12 15:17:24 2008 Subject: TSO bug in FreeBSD 7.0 ? Message-ID: <20def4870806120817q5b755805hfafa0d0d1523f2ad@mail.gmail.com> Hi freebsd-net, I'm seeing mbuf chains larger than 64K being sent down by FreeBSD 7 when TSO is enabled. Then my driver crashes in bus_dmamap_load_mbuf_sg (error=EINVAL). I'm printing the mbuf m_pkthdr.len size right after the DEQUEUE from the stack: IFQ_DRV_DEQUEUE(&dev->if_snd, m_head); if (m_head == NULL) break; if (m_head->m_pkthdr.len > 65000) { printf("TSO packet mbuf len:%d\n", m_head->m_pkthdr.len); } and the output is: .... TSO packet mbuf len:65387 TSO packet mbuf len:65417 TSO packet mbuf len:65447 TSO packet mbuf len:65477 TSO packet mbuf len:65507 TSO packet mbuf len:65537 mtnic0: bus_dmamap_load_mbuf_sg error: 22 xmit_failure:12 ... Note the 65537, I've also seen TSO packets sized 65542. There's this old thread talking about it: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2007-02/msg00312.html but I've seen no solution for this bug. Is there a fix for that? Thanks, Yony From olli at lurza.secnetix.de Thu Jun 12 15:26:28 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Thu Jun 12 15:26:31 2008 Subject: CARP + multiple addresses Message-ID: <200806121526.m5CFQPAI021114@lurza.secnetix.de> Hi, I'm building a fail-over setup with two database servers, so when the first one fails, the second takes over. The data is replicated. So far it seems to work fine with CARP, but now it turned out that I need another address from a different subnet which also needs to access the database. What's the best way to do that? Add a second IP address to the existing carp interface, or create a new carp interface? Are there any pros and cons? I.e. currently it looks like this: Database server A: bge0: physical interface vlan101: 10.1.101.41/24 on bge0 vlan202: 10.1.202.41/24 on bge0 carp0: 10.1.101.40/32 vhid 1 Database server B: bge0: physical interface vlan101: 10.1.101.42/24 on bge0 vlan202: 10.1.202.42/24 on bge0 carp0: 10.1.101.40/32 vhid 1 And now I need to add an IP address from vlan202 which also needs to access the same database. I'm inclined to add 10.1.202.40/32 vhid 1 to the existing carp0 on both servers. I assume that the CARP interface goes to BACKUP when *any* of its IP addresses fail, right? Can anybody confirm this, please? So, would that work, or is there a better way? Any hints are appreciated! Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "In My Egoistical Opinion, most people's C programs should be indented six feet downward and covered with dirt." -- Blair P. Houghton From andre at freebsd.org Thu Jun 12 16:38:01 2008 From: andre at freebsd.org (Andre Oppermann) Date: Thu Jun 12 16:38:05 2008 Subject: TSO bug in FreeBSD 7.0 ? In-Reply-To: <20def4870806120817q5b755805hfafa0d0d1523f2ad@mail.gmail.com> References: <20def4870806120817q5b755805hfafa0d0d1523f2ad@mail.gmail.com> Message-ID: <485150E8.7050903@freebsd.org> Yony Yossef wrote: > Hi freebsd-net, > > I'm seeing mbuf chains larger than 64K being sent down by FreeBSD 7 when TSO > is enabled. > Then my driver crashes in bus_dmamap_load_mbuf_sg (error=EINVAL). > I'm printing the mbuf m_pkthdr.len size right after the DEQUEUE from the > stack: > > IFQ_DRV_DEQUEUE(&dev->if_snd, m_head); > if (m_head == NULL) > break; > if (m_head->m_pkthdr.len > 65000) { > printf("TSO packet mbuf len:%d\n", m_head->m_pkthdr.len); > } > and the output is: > > .... > TSO packet mbuf len:65387 > TSO packet mbuf len:65417 > TSO packet mbuf len:65447 > TSO packet mbuf len:65477 > TSO packet mbuf len:65507 > TSO packet mbuf len:65537 > mtnic0: bus_dmamap_load_mbuf_sg error: 22 > xmit_failure:12 > ... > > Note the 65537, I've also seen TSO packets sized 65542. > > There's this old thread talking about it: > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2007-02/msg00312.html > but I've seen no solution for this bug. > > Is there a fix for that? This bug is supposed to be fixed and the fix should also be included in 7.0. The other users of TSO reported no more overflows. I'll have another look whether later changes may have had an effect. -- Andre From jfvogel at gmail.com Thu Jun 12 17:06:06 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Thu Jun 12 17:06:09 2008 Subject: Vlan EVENT patch In-Reply-To: <20080612092621.61b44529@twoflower.in.publishing.hu> References: <2a41acea0806100951x1142edc6qc872d3810c2bd467@mail.gmail.com> <20080611073313.GF3529@cdnetworks.co.kr> <2a41acea0806110952n2851415dyf3b3213249779bf1@mail.gmail.com> <20080612000943.GA7250@cdnetworks.co.kr> <48508708.50903@errno.com> <2a41acea0806112048g60084f72o4391701ba242442@mail.gmail.com> <20080612040452.GE7250@cdnetworks.co.kr> <20080612092621.61b44529@twoflower.in.publishing.hu> Message-ID: <2a41acea0806121006r23936007x5acf1fa9e302a94d@mail.gmail.com> On Thu, Jun 12, 2008 at 12:26 AM, CZUCZY Gergely wrote: > On Thu, 12 Jun 2008 13:04:52 +0900 > Pyun YongHyeon wrote: > >> On Wed, Jun 11, 2008 at 08:48:58PM -0700, Jack Vogel wrote: >> > On Wed, Jun 11, 2008 at 7:16 PM, Sam Leffler wrote: >> > > [trimming cc list to reduce spamage] >> > > >> > > Pyun YongHyeon wrote: >> > >> >> > >> On Wed, Jun 11, 2008 at 09:52:23AM -0700, Jack Vogel wrote: >> > >> > On Wed, Jun 11, 2008 at 12:33 AM, Pyun YongHyeon >> > >> wrote: >> > >> > > On Tue, Jun 10, 2008 at 09:51:53AM -0700, Jack Vogel wrote: >> > >> > > > This is a small patch that Sam came up with for me, it will >> > >> > > > allow drivers to know >> > >> > > > when a vlan attaches. >> > >> > > > >> > >> > > > It is transparent to any code that doesn't want to change, but >> > >> this >> > >> > > > will allow my >> > >> > > > drivers to finally utilize the vlan hardware filter (something >> > >> Linux has had for >> > >> > > > ever but we lacked). >> > >> > > > >> > >> > > >> > >> > > Just curious, is there any rule how to use that new capability? >> > >> > > Because drivers will receive events whenever VLAN tags are >> > >> > > added/removed they would know how to act for these events. If >> > >> > > promiscuous mode is on for interface, driver should not filter any >> > >> > > VLAN tagged frames, right? >> > >> > > If users want to disable VLAN hardware filtering feature what is >> > >> > > best way to perform this? Introducing a new flag like >> > >> > > IFCAP_VLAN_HWFILT or add a new sysctl that control this feature? >> > >> > > I guess VIA Rhine III also have VLAN hardware filtering capability >> > >> > > so it would be even better if we have a way to share common part. >> > >> > > All the patch does is have the vlan driver generate events when it >> > >> attaches >> > >> > or detaches from a NIC, there are no rules, however I can tell you >> > >> > what I'm coding into this in the Intel drivers. >> > >> > > The way it works is the driver registers a callback for each >> > >> > > event, >> > >> I will >> > >> > call that [igb,em,ixgbe]_register_vlan(), and unregister obviously. >> > >> > > Right now, the drivers just generically enable VLAN capability >> > >> because >> > >> > there is never a trigger to know IF and WHEN you need to do so, but >> > >> > with this change the VLAN capability will only get turned on by the >> > >> > registration routine. >> > >> > > Most significantly, now when the pseudo device it gives the driver >> > >> > the VLAN tag, this will mean the driver will be able from the start >> > >> > to use the VFTA, the hardware filter, for each vlan attach the driver >> > >> > will add the ID into this table. >> > >> > > The unregister event will turn the table entry off, and if this is >> > >> the >> > >> > last VLAN being detached it will then disable the features. >> > >> > > Oh yes, these routines will also take care of the size change of >> > >> > the frame due to the tag. I already have the changes in place in >> > >> > the igb drive, and they are working great. >> > >> > > I do not understand why you think you need a flag to disable this, >> > >> > yes it could be done, but why? If you need to do some sort of >> > >> > debugging won't a system not using vlans and in promiscuous >> > >> > mode do just fine? >> > >> > >> > >> I guess this would be the same reason why FreeBSD have a way to >> > >> disable checksum offload for buggy hardware. Diabling all hardware >> > >> VLAN assistance due to broken VLAN filtering doesn't look right. >> > >> >> > >> > It just seems to violate the whole reason for doing vlans in the >> > >> > first place, however perhaps I am missing something? I do not >> > >> > believe the Linux driver has some way to disable use of the table >> > >> > but I'll double check on that. >> > >> > > Remember, this change requires NO driver changes unless they >> > >> > wish to take advantage of the ability. >> > >> >> > >> Yes. >> > >> >> > >> > > Cheers, >> > >> > > Jack >> > >> >> > >> Thanks. >> > > >> > > Sounds like there needs to be a h/w vlan assist capability bit that >> > > controls this in the driver. Then you'd have a way to disable via >> > > ifconfig w/ a trivial mod. >> > >> > I don't want to create stuff in ifconfig when I'm not convinced >> > of the need. If there were, as he says, 'buggy hardware', specifically >> > buggy Intel hardware, then either our drivers would have had special >> > errata or workarounds in it for that, but none of the OS drivers have >> > any special code for issues involving VFTA (the filter) or other VLAN >> > controlling components that I am aware of. >> > >> > If there are other network drivers that are buggy in this regard then why >> > encumber the generic interface due to that, let the drivers deal with it, >> > via sysctl or something of the sort. >> > >> > There are enough real cases of hardware problems we need to address in >> > code that I don't just want to modify code on the mere theoretical >> > possibility of such. >> > >> > How bout this, we put the change into HEAD, I add support as I've planned >> > into the em and igb drivers, and then we let them get tested, if a real >> > problem comes up, THEN we worry about adding special case code, how's that? >> > >> >> Please go ahead. I don't have any objections on it. >> I just thought it would be better to show a flag to indicate >> hardware VLAN filtering is active in ifconfig(8) and have user >> disable this feature in some rare cases. >> >> > Regards, >> > >> > Jack > > I don't know whether it's a policy or not in FreeBSD, but I also agree with the > opinion, that a flag should show up in the ifconfig output indicating that > hardware filtering is being done on that interface. It helps the administrator > to clarify how the hardware is working, which features of the hardware are in > use, and also, they can be disabled. > Disabling features is important. Sometimes the code is messed up, the hardware > is messed up, or neither are messed up, but they are unable to work together. > In these cases the feature could be disabled without hacking the source, which > is a clean solution. FreeBSD has design, and prefers clean solutions as I see. > I understand, that you _currently_ have no troubles and problems with your code > and hardware, but there are unforseen cases out there, lots of other hardware > then intel's, and to quote Douglas N. Adams, "expect the unexpected". > > So, it won't hurt if it shows up in ifconfig, and it can be controlled, but > definitely helps our job, the administrators'. OK, if people feel strongly about this, and someone wants to implement the code in ifconfig I'll go along with it. Jack From ups at FreeBSD.org Thu Jun 12 18:52:53 2008 From: ups at FreeBSD.org (ups@FreeBSD.org) Date: Thu Jun 12 18:52:55 2008 Subject: kern/123950: [tcp] TH_RST packet sended if received out-of-order data (ACK) in SYN_RECEIVED state Message-ID: <200806121852.m5CIqqj9088608@freefall.freebsd.org> Synopsis: [tcp] TH_RST packet sended if received out-of-order data (ACK) in SYN_RECEIVED state Responsible-Changed-From-To: freebsd-net->ups Responsible-Changed-By: ups Responsible-Changed-When: Thu Jun 12 18:47:47 UTC 2008 Responsible-Changed-Why: Currently working on the syn cache and have encountered the same problem. Fix should be checked in in a few days. http://www.freebsd.org/cgi/query-pr.cgi?pr=123950 From peterjeremy at optushome.com.au Thu Jun 12 19:19:09 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Thu Jun 12 19:19:14 2008 Subject: CARP + multiple addresses In-Reply-To: <200806121526.m5CFQPAI021114@lurza.secnetix.de> References: <200806121526.m5CFQPAI021114@lurza.secnetix.de> Message-ID: <20080612191905.GK84454@server.vk2pj.dyndns.org> On 2008-Jun-12 17:26:25 +0200, Oliver Fromme wrote: >So far it seems to work fine with CARP, but now it turned >out that I need another address from a different subnet >which also needs to access the database. What's the best >way to do that? Add a second IP address to the existing >carp interface, or create a new carp interface? Are there >any pros and cons? I'm currently working towards something like this and intending to have one CARP interface for each VLAN. >And now I need to add an IP address from vlan202 which >also needs to access the same database. I'm inclined to >add 10.1.202.40/32 vhid 1 to the existing carp0 on both >servers. I assume that the CARP interface goes to BACKUP >when *any* of its IP addresses fail, right? Can anybody >confirm this, please? My reading of the various documentation says that you are on the right track but, by default, each CARP interface will fail over independently. If you want them all to fail over together then you should set net.inet.carp.preempt (see carp(4) and its first example) -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080612/f8fd2b35/attachment.pgp From davidch at broadcom.com Thu Jun 12 21:12:58 2008 From: davidch at broadcom.com (David Christensen) Date: Thu Jun 12 21:13:02 2008 Subject: Vlan EVENT patch In-Reply-To: <2a41acea0806121006r23936007x5acf1fa9e302a94d@mail.gmail.com> References: <2a41acea0806100951x1142edc6qc872d3810c2bd467@mail.gmail.com> <20080611073313.GF3529@cdnetworks.co.kr> <2a41acea0806110952n2851415dyf3b3213249779bf1@mail.gmail.com> <20080612000943.GA7250@cdnetworks.co.kr> <48508708.50903@errno.com> <2a41acea0806112048g60084f72o4391701ba242442@mail.gmail.com> <20080612040452.GE7250@cdnetworks.co.kr> <20080612092621.61b44529@twoflower.in.publishing.hu> <2a41acea0806121006r23936007x5acf1fa9e302a94d@mail.gmail.com> Message-ID: <5D267A3F22FD854F8F48B3D2B523819324F0D70877@IRVEXCHCCR01.corp.ad.broadcom.com> > > So, it won't hurt if it shows up in ifconfig, and it can be > controlled, but > > definitely helps our job, the administrators'. > > OK, if people feel strongly about this, and someone wants to implement > the > code in ifconfig I'll go along with it. I believe there are some valid reasons when you consider virtualization with Xen where you need to pass VLAN tags to the hypervisor. Not sure if Xen is running on FreeBSD yet but I can definitely see the need. dave From steve at ibctech.ca Fri Jun 13 00:29:29 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Fri Jun 13 00:29:31 2008 Subject: Throughput rate testing configurations In-Reply-To: References: <484F3E1B.9050104@ibctech.ca> <4850028F.6090103@jim-liesl.org> Message-ID: <4851BFE9.5070905@ibctech.ca> George V. Neville-Neil wrote: > At Wed, 11 Jun 2008 09:51:27 -0700, > security wrote: >> Iperf or netperf are probably what you're looking for. > I personally prefer netpipe because it tries odd sized (non power of > 2) messages and tends to help edge cases come to light. > > /usr/ports/benchmarks/netpipe Thank you for the recommendations. I will try out all three of them. I'm certain I'll get the results I am after. Cheers, Steve From randy at psg.com Fri Jun 13 01:25:43 2008 From: randy at psg.com (Randy Bush) Date: Fri Jun 13 01:25:45 2008 Subject: ssh window Message-ID: <4851CC95.8070902@psg.com> this has been a cause of great pain for a loooong time. http://www.psc.edu/networking/projects/hpn-ssh/ as openssh seems not to be fixing it (and i do not consider a 2mb fixed buffer to be fixed, especially not from a 100mb link here in tokyo and servers in the states, europe, and africa), perhaps i could convince freebsd net folk to do so? randy From Peter_Losher at isc.org Fri Jun 13 01:30:13 2008 From: Peter_Losher at isc.org (Peter Losher) Date: Fri Jun 13 01:30:15 2008 Subject: ssh window In-Reply-To: <4851CC95.8070902@psg.com> References: <4851CC95.8070902@psg.com> Message-ID: <4851CD9D.3010801@isc.org> Randy Bush wrote: > this has been a cause of great pain for a loooong time. > > http://www.psc.edu/networking/projects/hpn-ssh/ > > as openssh seems not to be fixing it (and i do not consider a 2mb fixed > buffer to be fixed, especially not from a 100mb link here in tokyo and > servers in the states, europe, and africa), perhaps i could convince > freebsd net folk to do so? FYI - HPN is already a build option in the openssh-portable port. -Peter -- Peter_Losher@isc.org | ISC | OpenPGP 0xE8048D08 | "The bits must flow" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 186 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080613/9332e5d5/signature.pgp From brooks at freebsd.org Fri Jun 13 02:51:28 2008 From: brooks at freebsd.org (Brooks Davis) Date: Fri Jun 13 02:51:31 2008 Subject: ssh window In-Reply-To: <4851CD9D.3010801@isc.org> References: <4851CC95.8070902@psg.com> <4851CD9D.3010801@isc.org> Message-ID: <20080613025157.GA90190@lor.one-eyed-alien.net> On Thu, Jun 12, 2008 at 06:30:05PM -0700, Peter Losher wrote: > Randy Bush wrote: >> this has been a cause of great pain for a loooong time. >> >> http://www.psc.edu/networking/projects/hpn-ssh/ >> >> as openssh seems not to be fixing it (and i do not consider a 2mb fixed >> buffer to be fixed, especially not from a 100mb link here in tokyo and >> servers in the states, europe, and africa), perhaps i could convince >> freebsd net folk to do so? > > FYI - HPN is already a build option in the openssh-portable port. I do think we should strongly consider adding the rest of it to the base. -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080613/a3fb456d/attachment.pgp From smithi at nimnet.asn.au Fri Jun 13 03:26:36 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Fri Jun 13 03:26:40 2008 Subject: ssh window In-Reply-To: <20080613025157.GA90190@lor.one-eyed-alien.net> Message-ID: On Thu, 12 Jun 2008, Brooks Davis wrote: > On Thu, Jun 12, 2008 at 06:30:05PM -0700, Peter Losher wrote: > > Randy Bush wrote: > >> this has been a cause of great pain for a loooong time. > >> > >> http://www.psc.edu/networking/projects/hpn-ssh/ > >> > >> as openssh seems not to be fixing it (and i do not consider a 2mb fixed > >> buffer to be fixed, especially not from a 100mb link here in tokyo and > >> servers in the states, europe, and africa), perhaps i could convince > >> freebsd net folk to do so? > > > > FYI - HPN is already a build option in the openssh-portable port. > > I do think we should strongly consider adding the rest of it to the base. Presumably with suitable caveats re NONE CYPHER, NoneEnabled=no default? cheers, Ian From randy at psg.com Fri Jun 13 03:29:52 2008 From: randy at psg.com (Randy Bush) Date: Fri Jun 13 03:29:56 2008 Subject: ssh window In-Reply-To: References: Message-ID: <4851E9A9.90809@psg.com> Ian Smith wrote: > On Thu, 12 Jun 2008, Brooks Davis wrote: > > On Thu, Jun 12, 2008 at 06:30:05PM -0700, Peter Losher wrote: > > > Randy Bush wrote: > > >> this has been a cause of great pain for a loooong time. > > >> > > >> http://www.psc.edu/networking/projects/hpn-ssh/ > > >> > > >> as openssh seems not to be fixing it (and i do not consider a 2mb fixed > > >> buffer to be fixed, especially not from a 100mb link here in tokyo and > > >> servers in the states, europe, and africa), perhaps i could convince > > >> freebsd net folk to do so? > > > > > > FYI - HPN is already a build option in the openssh-portable port. > > > > I do think we should strongly consider adding the rest of it to the base. > > Presumably with suitable caveats re NONE CYPHER, NoneEnabled=no default? for sure! randy From oberman at es.net Fri Jun 13 03:36:47 2008 From: oberman at es.net (Kevin Oberman) Date: Fri Jun 13 03:36:50 2008 Subject: ssh window In-Reply-To: Your message of "Fri, 13 Jun 2008 12:29:45 +0900." <4851E9A9.90809@psg.com> Message-ID: <20080613033641.9A5C345048@ptavv.es.net> > Date: Fri, 13 Jun 2008 12:29:45 +0900 > From: Randy Bush > Sender: owner-freebsd-net@freebsd.org > > Ian Smith wrote: > > On Thu, 12 Jun 2008, Brooks Davis wrote: > > > On Thu, Jun 12, 2008 at 06:30:05PM -0700, Peter Losher wrote: > > > > Randy Bush wrote: > > > >> this has been a cause of great pain for a loooong time. > > > >> > > > >> http://www.psc.edu/networking/projects/hpn-ssh/ > > > >> > > > >> as openssh seems not to be fixing it (and i do not consider a 2mb fixed > > > >> buffer to be fixed, especially not from a 100mb link here in tokyo and > > > >> servers in the states, europe, and africa), perhaps i could convince > > > >> freebsd net folk to do so? > > > > > > > > FYI - HPN is already a build option in the openssh-portable port. > > > > > > I do think we should strongly consider adding the rest of it to the base. > > > > Presumably with suitable caveats re NONE CYPHER, NoneEnabled=no default? > > for sure! Agreed. PSC had valid reasons to allow NONE. They just don't apply to most cases and are a a very bad idea for a default install. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080613/27eb8a69/attachment.pgp From wollman at hergotha.csail.mit.edu Fri Jun 13 03:49:43 2008 From: wollman at hergotha.csail.mit.edu (Garrett Wollman) Date: Fri Jun 13 03:49:47 2008 Subject: ssh window In-Reply-To: <20080613025157.GA90190@lor.one-eyed-alien.net> References: <4851CC95.8070902@psg.com> <4851CD9D.3010801@isc.org> Message-ID: <200806130311.m5D3BD5m063745@hergotha.csail.mit.edu> In article <20080613025157.GA90190@lor.one-eyed-alien.net>, Brooks Davis writes: >On Thu, Jun 12, 2008 at 06:30:05PM -0700, Peter Losher wrote: >> FYI - HPN is already a build option in the openssh-portable port. > >I do think we should strongly consider adding the rest of it to the base. Am I the only one who would be happier if openssh were not in the base system at all? I always have to install the port anyway; having it in the base just gives me more files I need to delete after an install. (Heimdal is the other big culprit.) -GAWollman From kris at FreeBSD.org Fri Jun 13 11:02:13 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Fri Jun 13 11:02:16 2008 Subject: ssh window In-Reply-To: <20080613025157.GA90190@lor.one-eyed-alien.net> References: <4851CC95.8070902@psg.com> <4851CD9D.3010801@isc.org> <20080613025157.GA90190@lor.one-eyed-alien.net> Message-ID: <485253AF.4000000@FreeBSD.org> Brooks Davis wrote: > On Thu, Jun 12, 2008 at 06:30:05PM -0700, Peter Losher wrote: >> Randy Bush wrote: >>> this has been a cause of great pain for a loooong time. >>> >>> http://www.psc.edu/networking/projects/hpn-ssh/ >>> >>> as openssh seems not to be fixing it (and i do not consider a 2mb fixed >>> buffer to be fixed, especially not from a 100mb link here in tokyo and >>> servers in the states, europe, and africa), perhaps i could convince >>> freebsd net folk to do so? >> FYI - HPN is already a build option in the openssh-portable port. > > I do think we should strongly consider adding the rest of it to the base. > > -- Brooks There seem to be a couple of issues: 1) Connection aborts during interactive use. I started using this patch only yesterday but already a couple of times my interactive session to a machine has aborted from typing one character to the next. It doesnt seem to be affecting non-interactive use. I have not investigated this yet. 2) -c none handling is a bit weird. There is no way to shut up the warnings on non-interactive connections ("WARNING: ENABLED NONE CIPHER"; yes, I know, because I WROTE THAT SCRIPT :). Also it doesn't fall back gracefully if the other side doesn't support -c none; it just aborts the collection. This means you can't automatically interoperate with a non-HPN server if you want to use 'none' encryption. This is not related to the buffer handling but it is part of the same patch set. I really like the idea of -c none, but I think they have gone overboard with the paranoia. Kris From kris at FreeBSD.org Fri Jun 13 11:04:14 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Fri Jun 13 11:04:16 2008 Subject: ssh window In-Reply-To: <200806130311.m5D3BD5m063745@hergotha.csail.mit.edu> References: <4851CC95.8070902@psg.com> <4851CD9D.3010801@isc.org> <200806130311.m5D3BD5m063745@hergotha.csail.mit.edu> Message-ID: <48525428.9000703@FreeBSD.org> Garrett Wollman wrote: > In article <20080613025157.GA90190@lor.one-eyed-alien.net>, Brooks > Davis writes: > >> On Thu, Jun 12, 2008 at 06:30:05PM -0700, Peter Losher wrote: >>> FYI - HPN is already a build option in the openssh-portable port. >> I do think we should strongly consider adding the rest of it to the base. > > Am I the only one who would be happier if openssh were not in the base > system at all? Quite possibly :) I don't think it's at all viable to ship FreeBSD without an ssh client in this day and age. Kris From des at des.no Fri Jun 13 11:31:51 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Fri Jun 13 11:31:54 2008 Subject: ssh window In-Reply-To: <200806130311.m5D3BD5m063745@hergotha.csail.mit.edu> (Garrett Wollman's message of "Thu\, 12 Jun 2008 23\:11\:13 -0400 \(EDT\)") References: <4851CC95.8070902@psg.com> <4851CD9D.3010801@isc.org> <200806130311.m5D3BD5m063745@hergotha.csail.mit.edu> Message-ID: <861w31oago.fsf@ds4.des.no> Garrett Wollman writes: > Am I the only one who would be happier if openssh were not in the base > system at all? I always have to install the port anyway; having it in > the base just gives me more files I need to delete after an install. Well, it's not going to get any better if you don't talk to me about it. I don't read minds. As for the OP: Randy Bush writes: > this has been a cause of great pain for a loooong time. > > http://www.psc.edu/networking/projects/hpn-ssh/ > > as openssh seems not to be fixing it (and i do not consider a 2mb fixed > buffer to be fixed, especially not from a 100mb link here in tokyo and > servers in the states, europe, and africa), perhaps i could convince > freebsd net folk to do so? OpenSSH is not within the purview of the "freebsd net folk". If you have an issue with OpenSSH, you need to talk to me. The last time I was asked to apply the HPN patches to base, IIRC, they had not yet been submitted to (and rejected by) the upstream vendor, so I decided to wait and see. The NoneCipher issue comes up regularly, and is on my todo list for the 5.0p1 upgrade (along with several other things, such as changing the default key type back to RSA). I hope to import 5.0p1 as soon as we have a vendor import policy in place for Subversion. DES -- Dag-Erling Sm?rgrav - des@des.no From brennanma at gmail.com Fri Jun 13 14:28:13 2008 From: brennanma at gmail.com (Matt Brennan) Date: Fri Jun 13 14:28:21 2008 Subject: Static NAT and PAT on 6.2 Message-ID: <1c01b5070806130659ufaa761ax18de48287c7064d1@mail.gmail.com> Hi All, I am running FreeBSD 6.2-release. I have been running PAT via natd and ipfw for some time now and it runs great. However, I continue to try and employ static NAT on this router, and as soon as I do so all other clients lose routing. My natd.conf is as below: unregistered_only use_sockets log_ipfw_denied redirect_address 10.100.1.2 66.92.79.20 alias_address 66.92.79.89 Whenever I run with this configuration all clients except the static'ed one lose routing out of the building. I have tried switching the order of the alias_address and redirect_address. Any help is appreciated. -Matt From remko at FreeBSD.org Fri Jun 13 14:39:19 2008 From: remko at FreeBSD.org (remko@FreeBSD.org) Date: Fri Jun 13 14:39:28 2008 Subject: kern/124540: RTM_MISS with the transit packets Message-ID: <200806131439.m5DEdJb0079654@freefall.freebsd.org> Synopsis: RTM_MISS with the transit packets Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Fri Jun 13 14:39:07 UTC 2008 Responsible-Changed-Why: This looks like networking code :) http://www.freebsd.org/cgi/query-pr.cgi?pr=124540 From piso at FreeBSD.org Fri Jun 13 15:52:36 2008 From: piso at FreeBSD.org (Paolo Pisati) Date: Fri Jun 13 15:52:40 2008 Subject: [OT] Supported wifi express card Message-ID: <20080613152835.GA97758@tin.it> Hi, as the subjects says i'm looking for a freebsd-supported wifi express card. I know i should look for an atheros-based card, but it's really difficult to find which chip a card is using without trying it out first. Googling around, it seems the belkin n express card is what i'm looking for, but i'm open to suggestions. -- bye, P. From brooks at FreeBSD.org Fri Jun 13 15:54:06 2008 From: brooks at FreeBSD.org (Brooks Davis) Date: Fri Jun 13 15:54:09 2008 Subject: ssh window In-Reply-To: <485253AF.4000000@FreeBSD.org> References: <4851CC95.8070902@psg.com> <4851CD9D.3010801@isc.org> <20080613025157.GA90190@lor.one-eyed-alien.net> <485253AF.4000000@FreeBSD.org> Message-ID: <20080613155435.GB90190@lor.one-eyed-alien.net> On Fri, Jun 13, 2008 at 01:02:07PM +0200, Kris Kennaway wrote: > Brooks Davis wrote: >> On Thu, Jun 12, 2008 at 06:30:05PM -0700, Peter Losher wrote: >>> Randy Bush wrote: >>>> this has been a cause of great pain for a loooong time. >>>> >>>> http://www.psc.edu/networking/projects/hpn-ssh/ >>>> >>>> as openssh seems not to be fixing it (and i do not consider a 2mb fixed >>>> buffer to be fixed, especially not from a 100mb link here in tokyo and >>>> servers in the states, europe, and africa), perhaps i could convince >>>> freebsd net folk to do so? >>> FYI - HPN is already a build option in the openssh-portable port. >> >> I do think we should strongly consider adding the rest of it to the base. >> >> -- Brooks > > There seem to be a couple of issues: > > 1) Connection aborts during interactive use. I started using this patch > only yesterday but already a couple of times my interactive session to a > machine has aborted from typing one character to the next. It doesnt seem > to be affecting non-interactive use. I have not investigated this yet. > > 2) -c none handling is a bit weird. There is no way to shut up the > warnings on non-interactive connections ("WARNING: ENABLED NONE CIPHER"; > yes, I know, because I WROTE THAT SCRIPT :). Also it doesn't fall back > gracefully if the other side doesn't support -c none; it just aborts the > collection. This means you can't automatically interoperate with a non-HPN > server if you want to use 'none' encryption. This is not related to the > buffer handling but it is part of the same patch set. I really like the > idea of -c none, but I think they have gone overboard with the paranoia. It is worth noting that over most people's WAN's the none cipher is pretty pointless since you can do nearly 200Mbps with arcfour and a decent CPU (IIRC the graphs are several years old). -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080613/3f1db874/attachment.pgp From oberman at es.net Fri Jun 13 17:29:50 2008 From: oberman at es.net (Kevin Oberman) Date: Fri Jun 13 17:29:55 2008 Subject: ssh window In-Reply-To: Your message of "Thu, 12 Jun 2008 23:11:13 EDT." <200806130311.m5D3BD5m063745@hergotha.csail.mit.edu> Message-ID: <20080613172947.2ED344500E@ptavv.es.net> > Date: Thu, 12 Jun 2008 23:11:13 -0400 (EDT) > From: Garrett Wollman > Sender: owner-freebsd-net@freebsd.org > > In article <20080613025157.GA90190@lor.one-eyed-alien.net>, Brooks > Davis writes: > > >On Thu, Jun 12, 2008 at 06:30:05PM -0700, Peter Losher wrote: > >> FYI - HPN is already a build option in the openssh-portable port. > > > >I do think we should strongly consider adding the rest of it to the base. > > Am I the only one who would be happier if openssh were not in the base > system at all? I always have to install the port anyway; having it in > the base just gives me more files I need to delete after an install. > (Heimdal is the other big culprit.) Build it with OVERRIDE_BASE and make the required entry in /etc/make.conf (pre-V7) or /etc/sys.conf (V7) so that rebuilding the system does not over-write them. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080613/45065f37/attachment.pgp From spawk at acm.poly.edu Fri Jun 13 17:37:14 2008 From: spawk at acm.poly.edu (Boris Kochergin) Date: Fri Jun 13 17:37:17 2008 Subject: [OT] Supported wifi express card In-Reply-To: <20080613152835.GA97758@tin.it> References: <20080613152835.GA97758@tin.it> Message-ID: <4852A9F3.4000107@acm.poly.edu> Someone I know got a http://www.buy.com/prod/thinkpad-11a-b-g-wireless-lan-mini-pci-express-adapter-network-adapter/q/loc/101/201992199.html and it works well. -Boris Paolo Pisati wrote: > Hi, > > as the subjects says i'm looking for a freebsd-supported wifi express card. > I know i should look for an atheros-based card, but it's really difficult to find > which chip a card is using without trying it out first. > > Googling around, it seems the belkin n express card is what i'm > looking for, but i'm open to suggestions. > From wollman at bimajority.org Fri Jun 13 18:43:41 2008 From: wollman at bimajority.org (Garrett Wollman) Date: Fri Jun 13 18:43:44 2008 Subject: ssh window In-Reply-To: <48525428.9000703@FreeBSD.org> References: <4851CC95.8070902@psg.com> <4851CD9D.3010801@isc.org> <200806130311.m5D3BD5m063745@hergotha.csail.mit.edu> <48525428.9000703@FreeBSD.org> Message-ID: <18514.49115.708560.587859@hergotha.csail.mit.edu> < said: > Garrett Wollman wrote: >> Am I the only one who would be happier if openssh were not in the base >> system at all? > Quite possibly :) > I don't think it's at all viable to ship FreeBSD without an ssh client > in this day and age. If that were what I had suggested, you might have a point. I'm want FreeBSD to ship with an ssh client, too. I just want it shipped as a package, so that it's easier to delete when I'm ready to replace it with one that meets my requirements (about an hour after install). Having it be easier to update when there's a security issue would be an added bonus. -GAWollman From oberman at es.net Fri Jun 13 19:02:58 2008 From: oberman at es.net (Kevin Oberman) Date: Fri Jun 13 19:03:01 2008 Subject: ssh window In-Reply-To: Your message of "Fri, 13 Jun 2008 14:43:39 EDT." <18514.49115.708560.587859@hergotha.csail.mit.edu> Message-ID: <20080613190256.0B4AE4500E@ptavv.es.net> > Date: Fri, 13 Jun 2008 14:43:39 -0400 > From: Garrett Wollman > Sender: owner-freebsd-net@freebsd.org > > < said: > > > Garrett Wollman wrote: > >> Am I the only one who would be happier if openssh were not in the base > >> system at all? > > > Quite possibly :) > > > I don't think it's at all viable to ship FreeBSD without an ssh client > > in this day and age. > > If that were what I had suggested, you might have a point. I'm want > FreeBSD to ship with an ssh client, too. I just want it shipped as a > package, so that it's easier to delete when I'm ready to replace it > with one that meets my requirements (about an hour after install). > Having it be easier to update when there's a security issue would be > an added bonus. Replacing the base ssh with the port is utterly trivial. You already are setting configuration options, so OVERWRITE_BASE is no more than a few key presses and a one-liner in make.conf or src.conf is pretty trivial. V7---Add "WITHOUT_OPENSSH=" to /etc/src.conf Pre-V7--=-Add "NO_OPENSSH=" to /etc/make.conf That is all it takes. We use SmartCards for authentication, so I already have a bunch of systems that are configured this way. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080613/bcd0cb1a/attachment.pgp From paul at gtcomm.net Fri Jun 13 21:08:26 2008 From: paul at gtcomm.net (Paul) Date: Fri Jun 13 21:08:29 2008 Subject: Route messages Message-ID: <4852E23E.2040505@gtcomm.net> Get these with GRE tunnel on FreeBSD 7.0-STABLE FreeBSD 7.0-STABLE #5: Sun May 11 19:00:57 EDT 2008 :/usr/obj/usr/src/sys/ROUTER amd64 But do not get them with 7.0-RELEASE Any ideas what changed? :) Wish there was some sort of changelog.. # of messages per second seems consistent with packets per second on GRE interface.. No impact in routing, but definitely impact in cpu usage for all processes monitoring the route messages. got message of size 160 on Fri Jun 13 16:58:37 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default got message of size 160 on Fri Jun 13 16:58:37 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default got message of size 160 on Fri Jun 13 16:58:37 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default got message of size 160 on Fri Jun 13 16:58:37 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default got message of size 160 on Fri Jun 13 16:58:37 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default got message of size 160 on Fri Jun 13 16:58:37 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default got message of size 160 on Fri Jun 13 16:58:37 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default got message of size 160 on Fri Jun 13 17:08:16 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default got message of size 160 on Fri Jun 13 17:08:16 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default got message of size 160 on Fri Jun 13 17:08:16 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default got message of size 160 on Fri Jun 13 17:08:16 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default got message of size 160 on Fri Jun 13 17:08:16 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default got message of size 160 on Fri Jun 13 17:08:16 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default got message of size 160 on Fri Jun 13 17:08:16 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default got message of size 160 on Fri Jun 13 17:08:16 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default From kris at FreeBSD.org Fri Jun 13 23:03:28 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Fri Jun 13 23:03:31 2008 Subject: ssh window In-Reply-To: <20080613155435.GB90190@lor.one-eyed-alien.net> References: <4851CC95.8070902@psg.com> <4851CD9D.3010801@isc.org> <20080613025157.GA90190@lor.one-eyed-alien.net> <485253AF.4000000@FreeBSD.org> <20080613155435.GB90190@lor.one-eyed-alien.net> Message-ID: <4852FCBD.6060702@FreeBSD.org> Brooks Davis wrote: > It is worth noting that over most people's WAN's the none cipher is > pretty pointless since you can do nearly 200Mbps with arcfour and a decent CPU > (IIRC the graphs are several years old). In my case I'm CPU bound from other processes, so reducing SSH overhead will have a net benefit. Kris From crapsh at MonkeyBrains.NET Fri Jun 13 23:40:16 2008 From: crapsh at MonkeyBrains.NET (Rudy) Date: Fri Jun 13 23:40:21 2008 Subject: em0: watchdog timeout -- resetting In-Reply-To: <2a41acea0805160904g7dcf9f58rf69ca5d0612945cc@mail.gmail.com> References: <20080516185813.H866@logos.sky.od.ua> <2a41acea0805160904g7dcf9f58rf69ca5d0612945cc@mail.gmail.com> Message-ID: <4853055C.2030303@MonkeyBrains.NET> Jack Vogel wrote: > Did you ever install the fix to the 82573 NIC eeprom? Just saw the "watchdog" error using an Intel Pro Quad PT card... it has the '82571EB' chip on it. -- Do those cards need the eeprom 'fix'? -- or is related to kern/122928 -- how does one go about disabling the watchdog? (turning off acpi?) Thanks, Rudy SYSTEM INFO: # grep Exp /usr/src/sys/dev/em/if_em.c /*$FreeBSD: src/sys/dev/em/if_em.c,v 1.184.2.3 2008/05/21 21:34:05 jfv Exp $*/ # pciconf -lv | grep -A 4 em2 em2@pci0:6:0:0: class=0x020000 card=0x10a48086 chip=0x10a48086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = '82571EB Gigabit Ethernet Controller' class = network subclass = ethernet # sysctl dev.em.2 dev.em.2.%desc: Intel(R) PRO/1000 Network Connection 6.9.5 dev.em.2.%driver: em dev.em.2.%location: slot=0 function=0 dev.em.2.%pnpinfo: vendor=0x8086 device=0x10a4 subvendor=0x8086 subdevice=0x10a4 class=0x020000 dev.em.2.%parent: pci6 dev.em.2.debug: -1 dev.em.2.stats: -1 dev.em.2.rx_int_delay: 0 dev.em.2.tx_int_delay: 66 dev.em.2.rx_abs_int_delay: 66 dev.em.2.tx_abs_int_delay: 66 dev.em.2.rx_processing_limit: 100 # ifconfig em2 em2: flags=8843 metric 0 mtu 1500 options=1db ether 00:15:17:78:99:72 inet 10.10.30.154 netmask 0xfffffffc broadcast 10.10.30.155 media: Ethernet autoselect (1000baseTX ) status: active # uname -a FreeBSD example.monkeybrains.net 7.0-STABLE FreeBSD 7.0-STABLE #0: Tue Jun 3 16:43:19 PDT 2008 root@buildbox.monkeybrains.net:/usr/obj/usr/src/sys/ROUTER i386 # grep em2 /var/log/messages Jun 11 23:08:34 example kernel: em2: port 0x3000-0x301f mem 0xd8120000-0xd813ffff,0xd8100000-0xd811ffff irq 17 at device 0.0 on pci6 Jun 11 23:08:34 example kernel: em2: Using MSI interrupt Jun 11 23:08:34 example kernel: em2: [FILTER] Jun 11 23:08:34 example kernel: em2: Ethernet address: 00:15:17:78:99:72 Jun 11 23:18:08 example kernel: em2: link state changed to UP Jun 13 00:27:22 example kernel: em2: watchdog timeout -- resetting Jun 13 00:27:22 example kernel: em2: link state changed to DOWN Jun 13 00:27:25 example kernel: em2: link state changed to UP Jun 13 03:37:52 example kernel: em2: watchdog timeout -- resetting Jun 13 03:37:52 example kernel: em2: link state changed to DOWN Jun 13 03:37:55 example kernel: em2: link state changed to UP Jun 13 05:17:18 example kernel: em2: watchdog timeout -- resetting Jun 13 05:17:18 example kernel: em2: link state changed to DOWN Jun 13 05:17:22 example kernel: em2: link state changed to UP Jun 13 05:17:23 example kernel: em2: link state changed to DOWN Jun 13 05:17:25 example kernel: em2: link state changed to UP Jun 13 06:54:47 example kernel: em2: watchdog timeout -- resetting Jun 13 06:54:47 example kernel: em2: link state changed to DOWN Jun 13 06:54:51 example kernel: em2: link state changed to UP Jun 13 06:59:22 example kernel: em2: watchdog timeout -- resetting Jun 13 06:59:22 example kernel: em2: link state changed to DOWN Jun 13 06:59:25 example kernel: em2: link state changed to UP From jmg at funkthat.com Fri Jun 13 23:49:35 2008 From: jmg at funkthat.com (John-Mark Gurney) Date: Fri Jun 13 23:49:39 2008 Subject: tcpdump/snort to capture chat sessions In-Reply-To: <48502F2C.7090505@tomjudge.com> References: <20080610120222.9e2760fe.wmoran@collaborativefusion.com> <48502F2C.7090505@tomjudge.com> Message-ID: <20080613231440.GH3767@funkthat.com> Tom Judge wrote this message on Wed, Jun 11, 2008 at 15:01 -0500: > Bill Moran wrote: > >In response to R J : > > > >>I am trying to use tcpdump (or snort, but they are both behaving the same > >>in this case) to capture all the lines or contents of an msn > >>chat session, the actual conversation. I am getting partial output; i.e, > >>I'll only get half of a sentence, and I don't see the rest of the lines. > >>And ofcourse, alot of it seems to be hex or obfuscated html? > >> > >>What switches do I need to capture the entire lines of text? > > > >Don't know about snort, but with tcpdump use -s0 > > > This is a good start however you are not guaranteed to see the whole > chat message in a single TCP packet. If you are looking for something > more advanced you will have to write a program around pcap/bpf or > similar to read the TCP stream. such as tcpflow which read tcpdump streams and outputs each TCP byte stream... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From killing at multiplay.co.uk Sat Jun 14 02:51:14 2008 From: killing at multiplay.co.uk (Steven Hartland) Date: Sat Jun 14 02:51:21 2008 Subject: ssh window References: <20080613172947.2ED344500E@ptavv.es.net> Message-ID: <224D75AFD2724FC1A3E6E1004AB87F07@multiplay.co.uk> >> Date: Thu, 12 Jun 2008 23:11:13 -0400 (EDT) >> In article <20080613025157.GA90190@lor.one-eyed-alien.net>, Brooks >> Am I the only one who would be happier if openssh were not in the base >> system at all? I always have to install the port anyway; having it in >> the base just gives me more files I need to delete after an install. >> (Heimdal is the other big culprit.) > > Build it with OVERRIDE_BASE and make the required entry in >/etc/make.conf (pre-V7) or /etc/sys.conf (V7) so that rebuilding the >system does not over-write them. Unfortunately this doesnt stop sysinstall breaking rc.conf by adding back in sshd_enable="YES" every time its used :( Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From oberman at es.net Sat Jun 14 04:09:01 2008 From: oberman at es.net (Kevin Oberman) Date: Sat Jun 14 04:09:05 2008 Subject: ssh window In-Reply-To: Your message of "Sat, 14 Jun 2008 03:32:39 BST." <224D75AFD2724FC1A3E6E1004AB87F07@multiplay.co.uk> Message-ID: <20080614035806.E118D45047@ptavv.es.net> > From: "Steven Hartland" > Date: Sat, 14 Jun 2008 03:32:39 +0100 > > >> Date: Thu, 12 Jun 2008 23:11:13 -0400 (EDT) > >> In article <20080613025157.GA90190@lor.one-eyed-alien.net>, Brooks > >> Am I the only one who would be happier if openssh were not in the base > >> system at all? I always have to install the port anyway; having it in > >> the base just gives me more files I need to delete after an install. > >> (Heimdal is the other big culprit.) > > > > Build it with OVERRIDE_BASE and make the required entry in > >/etc/make.conf (pre-V7) or /etc/sys.conf (V7) so that rebuilding the > >system does not over-write them. > > Unfortunately this doesnt stop sysinstall breaking rc.conf by > adding back in sshd_enable="YES" every time its used :( If you OVERWRITE_BASE, sshd is written into /usr/sbin, so the stock /etc/rc.d/ntpd works just fine. I don't see the need to change to the one in the port when the port replaces the system version. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080614/daabded1/attachment.pgp From crapsh at monkeybrains.net Sat Jun 14 05:41:43 2008 From: crapsh at monkeybrains.net (Rudy) Date: Sat Jun 14 05:41:46 2008 Subject: em0: watchdog timeout -- resetting In-Reply-To: <4853055C.2030303@MonkeyBrains.NET> References: <20080516185813.H866@logos.sky.od.ua> <2a41acea0805160904g7dcf9f58rf69ca5d0612945cc@mail.gmail.com> <4853055C.2030303@MonkeyBrains.NET> Message-ID: <48535A11.4020003@monkeybrains.net> > Just saw the "watchdog" error using an Intel Pro Quad PT card... more info: doing about 100Mbps plugged into a Cisco 2960: Gi0/23 mango-em2 connected a-full a-1000 10/100/1000BaseTX Would setting the duplex and speed manually (instead of using auto-negotionation) help prevent the watchdog timer? What is the watchdog timeout for? Does the driver catch stalled interface conditions? Rudy From bms at FreeBSD.org Sun Jun 15 10:16:20 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Sun Jun 15 10:16:28 2008 Subject: Route messages In-Reply-To: <4852E23E.2040505@gtcomm.net> References: <4852E23E.2040505@gtcomm.net> Message-ID: <4854EBF1.7020708@FreeBSD.org> Paul wrote: > Get these with GRE tunnel on > FreeBSD 7.0-STABLE FreeBSD 7.0-STABLE #5: Sun May 11 19:00:57 EDT > 2008 :/usr/obj/usr/src/sys/ROUTER amd64 > But do not get them with 7.0-RELEASE > > Any ideas what changed? :) Wish there was some sort of changelog.. > # of messages per second seems consistent with packets per second on > GRE interface.. > No impact in routing, but definitely impact in cpu usage for all > processes monitoring the route messages. RTM_MISS is actually fairly common when you don't have a default route. Messages which get enqueued don't necessarily get delivered -- and very few processes actually listen to the routing socket actively like this, so I wouldn't worry about it. If it's a real concern for you then you could try hacking in a sysctl to tell the radix trie code not to issue RTM_MISS messages on the routing socket. From linimon at FreeBSD.org Sun Jun 15 14:01:43 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sun Jun 15 14:01:46 2008 Subject: kern/124609: [ipsec] [panic] ipsec 'remainder too big' panic with ping -s 3989 Message-ID: <200806151401.m5FE1hmg064151@freefall.freebsd.org> Synopsis: [ipsec] [panic] ipsec 'remainder too big' panic with ping -s 3989 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Jun 15 14:01:36 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=124609 From om-lists-bsd at omx.ch Sun Jun 15 16:38:46 2008 From: om-lists-bsd at omx.ch (Olivier Mueller) Date: Sun Jun 15 16:38:53 2008 Subject: mrtg peak on reboot / snmp-issue? Message-ID: <1213546323.29846.24.camel@bigapple.omnis.ch> Hello, Small but curious thing on my freebsd-based systems: when a server is rebooted, it generates a peak (or "spike"?) on the network mrtg for all interfaces (here just before 1 am): http://8304.ch/om/stuff/mrtg_localhost_1-day.png It happens with both net-snmp and ucd-snmp, with a quite standard mrtg installation (generated by cfgmaker). Do you have the same "issue" on your own servers? All I can add, is that there is not such a high traffic after a reboot, and that it doesn't happen on similar linux-based systems. Regards & a nice week to you, Olivier From hartmut.brandt at dlr.de Sun Jun 15 17:55:26 2008 From: hartmut.brandt at dlr.de (Hartmut Brandt) Date: Sun Jun 15 17:55:33 2008 Subject: mrtg peak on reboot / snmp-issue? In-Reply-To: <1213546323.29846.24.camel@bigapple.omnis.ch> References: <1213546323.29846.24.camel@bigapple.omnis.ch> Message-ID: <48555468.9090203@dlr.de> Olivier Mueller wrote: > Hello, > > Small but curious thing on my freebsd-based systems: when a > server is rebooted, it generates a peak (or "spike"?) on the > network mrtg for all interfaces (here just before 1 am): > http://8304.ch/om/stuff/mrtg_localhost_1-day.png This could happen if either the daemon fails to correctly provide ifCounterDiscontinuityTime or mrtg fails to correctly interpret sysUpTime and/or ifCounterDiscontinuityTime. > It happens with both net-snmp and ucd-snmp, with a quite standard > mrtg installation (generated by cfgmaker). > > Do you have the same "issue" on your own servers? All I can add, is > that there is not such a high traffic after a reboot, and that it > doesn't happen on similar linux-based systems. harti From vova at fbsd.ru Sun Jun 15 17:59:18 2008 From: vova at fbsd.ru (Vladimir Grebenschikov) Date: Sun Jun 15 17:59:23 2008 Subject: ppp vs mpd: ppp fails to keep connection, mpd works Message-ID: <1213550909.5038.56.camel@localhost> Hi I am trying to find why with same configuration ppp does not works with my CDMA modem (connected over usb) but mpd works. MPD log (it works as expected): ... [umodem0] link: UP event [umodem0] link: origination is remote [umodem0] LCP: Up event [umodem0] LCP: state change Starting --> Req-Sent [umodem0] LCP: phase shift DEAD --> ESTABLISH [umodem0] LCP: SendConfigReq #1 ACFCOMP PROTOCOMP ACCMAP 0x000a0000 MRU 1500 MAGICNUM 04eb5958 MP MRRU 1600 MP SHORTSEQ ENDPOINTDISC [Magic] 41 a2 7a c0 29 08 7a c0 [umodem0] LCP: rec'd Configure Reject #1 link 0 (Req-Sent) MP MRRU 1600 MP SHORTSEQ [umodem0] LCP: SendConfigReq #2 ACFCOMP PROTOCOMP ACCMAP 0x000a0000 MRU 1500 MAGICNUM 04eb5958 [umodem0] LCP: rec'd Configure Ack #2 link 0 (Req-Sent) ACFCOMP PROTOCOMP ACCMAP 0x000a0000 MRU 1500 MAGICNUM 04eb5958 [umodem0] LCP: state change Req-Sent --> Ack-Rcvd [umodem0] LCP: rec'd Configure Request #8 link 0 (Ack-Rcvd) ACCMAP 0x00000000 AUTHPROTO CHAP MD5 MAGICNUM 43aeaeee [umodem0] LCP: SendConfigNak #8 AUTHPROTO PAP [umodem0] LCP: rec'd Configure Request #9 link 0 (Ack-Rcvd) ACCMAP 0x00000000 AUTHPROTO PAP MAGICNUM 43aeaeee [umodem0] LCP: SendConfigAck #9 ACCMAP 0x00000000 AUTHPROTO PAP MAGICNUM 43aeaeee [umodem0] LCP: state change Ack-Rcvd --> Opened [umodem0] LCP: phase shift ESTABLISH --> AUTHENTICATE [umodem0] LCP: auth: peer wants PAP, I want nothing [umodem0] PAP: using authname "mobile" [umodem0] PAP: sending REQUEST [umodem0] LCP: LayerUp [umodem0] PAP: rec'd ACK #1 [umodem0] LCP: authorization successful [umodem0] LCP: phase shift AUTHENTICATE --> NETWORK [skylink] setting interface ng0 MTU to 1500 bytes [skylink] up: 1 link, total bandwidth 28800 bps [skylink] IPCP: Up event [skylink] IPCP: state change Starting --> Req-Sent [skylink] IPCP: SendConfigReq #1 IPADDR 0.0.0.0 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [skylink] error writing len 20 frame to bypass: Network is down [skylink] IPCP: rec'd Configure Request #2 link 0 (Req-Sent) IPADDR 212.119.106.147 212.119.106.147 is OK [skylink] IPCP: SendConfigAck #2 IPADDR 212.119.106.147 [skylink] IPCP: state change Req-Sent --> Ack-Sent [skylink] rec'd unexpected protocol CCP on link 0, rejecting [skylink] IPCP: SendConfigReq #2 IPADDR 0.0.0.0 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [skylink] IPCP: rec'd Configure Reject #2 link 0 (Ack-Sent) COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [skylink] IPCP: SendConfigReq #3 IPADDR 0.0.0.0 [skylink] IPCP: rec'd Configure Nak #3 link 0 (Ack-Sent) IPADDR 92.36.111.152 92.36.111.152 is OK [skylink] IPCP: SendConfigReq #4 IPADDR 92.36.111.152 [skylink] IPCP: rec'd Configure Ack #4 link 0 (Ack-Sent) IPADDR 92.36.111.152 [skylink] IPCP: state change Ack-Sent --> Opened [skylink] IPCP: LayerUp 92.36.111.152 -> 212.119.106.147 [skylink] IFACE: Up event [skylink] setting interface ng0 MTU to 1500 bytes [skylink] exec: /sbin/ifconfig ng0 92.36.111.152 212.119.106.147 netmask 0xffffffff -link0 [skylink] exec: /sbin/route add 92.36.111.152 -iface lo0 [skylink] exec: /sbin/route add 0.0.0.0 212.119.106.147 [skylink] IFACE: Up event [skylink] rec'd unexpected protocol IP on link 0 [umodem0] NEW FRAME ERRS: FCS 1 RUNT 0 OVFL 0 Then it just works. But ppp, closes connection just after negotiation (log below). After pair of empty config requests. What may be wrong here ? Any hints will be very appreciated. Jun 15 20:03:54 vbook ppp[4771]: Phase: Using interface: tun0 Jun 15 20:03:54 vbook ppp[4771]: Phase: deflink: Created in closed state Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: default: ident user-ppp VERSION (built COMPILATIONDATE) Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: default: set speed 115200 Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: default: set dial ABORT BUSY ABORT NO\sCARRIER TIMEOUT 5 "" AT OK-AT-OK ATE1Q0 OK \dATDT\T TIMEOUT 40 CONNECT Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: default: set timeout 0 Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: skylink: set log Phase Chat LCP IPCP CCP tun command Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: skylink: disable pred1 deflate deflate24 protocomp acfcomp shortseq vj Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: skylink: deny pred1 deflate deflate24 protocomp acfcomp shortseq vj Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: skylink: set speed 460800 Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: skylink: set timeout 180 Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: skylink: enable dns Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: skylink: set device /dev/ttyU0 Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: skylink: set phone #777 Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: skylink: set dial ABORT BUSY ABORT NO\sCARRIER TIMEOUT 15 "" AT OK-AT-OK ATE1Q0 OK \dATDT\T TIMEOUT 40 CONNECT Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: skylink: set authname mobile Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: skylink: set authkey ******** Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: skylink: add default HISADDR Jun 15 20:03:54 vbook ppp[4771]: tun0: Phase: PPP Started (interactive mode). Jun 15 20:03:57 vbook ppp[4771]: tun0: Command: /dev/ttyp1: dial Jun 15 20:03:57 vbook ppp[4771]: tun0: Phase: bundle: Establish Jun 15 20:03:57 vbook ppp[4771]: tun0: Phase: deflink: closed -> opening Jun 15 20:03:57 vbook ppp[4771]: tun0: Phase: deflink: Connected! Jun 15 20:03:57 vbook ppp[4771]: tun0: Phase: deflink: opening -> dial Jun 15 20:03:57 vbook ppp[4771]: tun0: Chat: Phone: #777 Jun 15 20:03:57 vbook ppp[4771]: tun0: Chat: deflink: Dial attempt 1 of 1 Jun 15 20:03:57 vbook ppp[4771]: tun0: Chat: Send: AT^M Jun 15 20:03:57 vbook ppp[4771]: tun0: Chat: Expect(15): OK Jun 15 20:03:57 vbook ppp[4771]: tun0: Chat: Received: AT^M^M Jun 15 20:03:57 vbook ppp[4771]: tun0: Chat: Received: OK^M Jun 15 20:03:57 vbook ppp[4771]: tun0: Chat: Send: ATE1Q0^M Jun 15 20:03:57 vbook ppp[4771]: tun0: Chat: Expect(15): OK Jun 15 20:03:57 vbook ppp[4771]: tun0: Chat: Received: ATE1Q0^M^M Jun 15 20:03:57 vbook ppp[4771]: tun0: Chat: Received: OK^M Jun 15 20:03:57 vbook ppp[4771]: tun0: Chat: Send: ATDT#777^M Jun 15 20:03:59 vbook ppp[4771]: tun0: Chat: Expect(40): CONNECT Jun 15 20:03:59 vbook ppp[4771]: tun0: Chat: Received: ATDT#777^M^M Jun 15 20:03:59 vbook ppp[4771]: tun0: Chat: Received: CONNECT^M Jun 15 20:03:59 vbook ppp[4771]: tun0: Phase: deflink: dial -> carrier Jun 15 20:04:00 vbook ppp[4771]: tun0: Phase: deflink: /dev/ttyU0 doesn't support CD Jun 15 20:04:00 vbook ppp[4771]: tun0: Phase: deflink: carrier -> login Jun 15 20:04:00 vbook ppp[4771]: tun0: Phase: deflink: login -> lcp Jun 15 20:04:00 vbook ppp[4771]: tun0: LCP: FSM: Using "deflink" as a transport Jun 15 20:04:00 vbook ppp[4771]: tun0: LCP: deflink: State change Initial --> Closed Jun 15 20:04:00 vbook ppp[4771]: tun0: LCP: deflink: State change Closed --> Stopped Jun 15 20:04:00 vbook ppp[4771]: tun0: LCP: deflink: RecvConfigReq(2) state = Stopped Jun 15 20:04:00 vbook ppp[4771]: tun0: LCP: ACCMAP[6] 0x00000000 Jun 15 20:04:00 vbook ppp[4771]: tun0: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x05) Jun 15 20:04:00 vbook ppp[4771]: tun0: LCP: MAGICNUM[6] 0x36bc6422 Jun 15 20:04:00 vbook ppp[4771]: tun0: LCP: deflink: SendConfigReq(1) state = Stopped Jun 15 20:04:00 vbook ppp[4771]: tun0: LCP: ACCMAP[6] 0x00000000 Jun 15 20:04:00 vbook ppp[4771]: tun0: LCP: MRU[4] 1500 Jun 15 20:04:00 vbook ppp[4771]: tun0: LCP: MAGICNUM[6] 0x031c8dad Jun 15 20:04:00 vbook ppp[4771]: tun0: LCP: deflink: SendConfigAck(2) state = Stopped Jun 15 20:04:00 vbook ppp[4771]: tun0: LCP: ACCMAP[6] 0x00000000 Jun 15 20:04:00 vbook ppp[4771]: tun0: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x05) Jun 15 20:04:00 vbook ppp[4771]: tun0: LCP: MAGICNUM[6] 0x36bc6422 Jun 15 20:04:00 vbook ppp[4771]: tun0: LCP: deflink: LayerStart Jun 15 20:04:00 vbook ppp[4771]: tun0: LCP: deflink: State change Stopped --> Ack-Sent Jun 15 20:04:02 vbook ppp[4771]: tun0: LCP: deflink: RecvConfigReq(3) state = Ack-Sent Jun 15 20:04:02 vbook ppp[4771]: tun0: LCP: ACCMAP[6] 0x00000000 Jun 15 20:04:02 vbook ppp[4771]: tun0: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x05) Jun 15 20:04:02 vbook ppp[4771]: tun0: LCP: MAGICNUM[6] 0x36bc6422 Jun 15 20:04:02 vbook ppp[4771]: tun0: LCP: deflink: SendConfigAck(3) state = Ack-Sent Jun 15 20:04:02 vbook ppp[4771]: tun0: LCP: ACCMAP[6] 0x00000000 Jun 15 20:04:02 vbook ppp[4771]: tun0: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x05) Jun 15 20:04:02 vbook ppp[4771]: tun0: LCP: MAGICNUM[6] 0x36bc6422 Jun 15 20:04:03 vbook ppp[4771]: tun0: LCP: deflink: SendConfigReq(1) state = Ack-Sent Jun 15 20:04:03 vbook ppp[4771]: tun0: LCP: ACCMAP[6] 0x00000000 Jun 15 20:04:03 vbook ppp[4771]: tun0: LCP: MRU[4] 1500 Jun 15 20:04:03 vbook ppp[4771]: tun0: LCP: MAGICNUM[6] 0x031c8dad Jun 15 20:04:03 vbook ppp[4771]: tun0: LCP: deflink: RecvConfigAck(1) state = Ack-Sent Jun 15 20:04:03 vbook ppp[4771]: tun0: LCP: ACCMAP[6] 0x00000000 Jun 15 20:04:03 vbook ppp[4771]: tun0: LCP: MRU[4] 1500 Jun 15 20:04:03 vbook ppp[4771]: tun0: LCP: MAGICNUM[6] 0x031c8dad Jun 15 20:04:03 vbook ppp[4771]: tun0: LCP: deflink: State change Ack-Sent --> Opened Jun 15 20:04:03 vbook ppp[4771]: tun0: LCP: deflink: LayerUp Jun 15 20:04:03 vbook ppp[4771]: tun0: LCP: deflink: SendIdent(0) state = Opened Jun 15 20:04:03 vbook ppp[4771]: tun0: LCP: MAGICNUM 031c8dad Jun 15 20:04:03 vbook ppp[4771]: tun0: LCP: TEXT user-ppp 3.4.2 (built COMPILATIONDATE) Jun 15 20:04:03 vbook ppp[4771]: tun0: Phase: bundle: Authenticate Jun 15 20:04:03 vbook ppp[4771]: tun0: Phase: deflink: his = CHAP 0x05, mine = none Jun 15 20:04:03 vbook ppp[4771]: tun0: Phase: Chap Input: CHALLENGE (16 bytes from pdsn-m34-7cm6) Jun 15 20:04:03 vbook ppp[4771]: tun0: Phase: Chap Output: RESPONSE (mobile) Jun 15 20:04:03 vbook ppp[4771]: tun0: Phase: Chap Input: SUCCESS Jun 15 20:04:03 vbook ppp[4771]: tun0: CCP: FSM: Using "deflink" as a transport Jun 15 20:04:03 vbook ppp[4771]: tun0: CCP: deflink: State change Initial --> Closed Jun 15 20:04:03 vbook ppp[4771]: tun0: CCP: deflink: LayerStart. Jun 15 20:04:03 vbook ppp[4771]: tun0: CCP: MPPE: Not usable without CHAP81 Jun 15 20:04:03 vbook ppp[4771]: tun0: CCP: deflink: SendConfigReq(1) state = Closed Jun 15 20:04:03 vbook ppp[4771]: tun0: CCP: [EMPTY] Jun 15 20:04:03 vbook ppp[4771]: tun0: CCP: deflink: State change Closed --> Req-Sent Jun 15 20:04:03 vbook ppp[4771]: tun0: Phase: deflink: lcp -> open Jun 15 20:04:03 vbook ppp[4771]: tun0: Phase: bundle: Network Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: FSM: Using "deflink" as a transport Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: deflink: State change Initial --> Closed Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: deflink: LayerStart. Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: deflink: SendConfigReq(1) state = Closed Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: IPADDR[6] 127.0.0.1 Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: PRIDNS[6] 212.119.97.5 Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: SECDNS[6] 255.255.255.255 Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: deflink: State change Closed --> Req-Sent Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: deflink: RecvConfigReq(1) state = Req-Sent Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: IPADDR[6] 212.119.106.161 Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: deflink: SendConfigAck(1) state = Req-Sent Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: IPADDR[6] 212.119.106.161 Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: deflink: State change Req-Sent --> Ack-Sent Jun 15 20:04:03 vbook ppp[4771]: tun0: CCP: deflink: RecvConfigReq(1) state = Req-Sent Jun 15 20:04:03 vbook ppp[4771]: tun0: CCP: MPPE[6] value 0x00000001 (0 bits, stateful, compressed) Jun 15 20:04:03 vbook ppp[4771]: tun0: CCP: MPPE: Not usable without CHAP81 Jun 15 20:04:03 vbook ppp[4771]: tun0: CCP: deflink: SendConfigRej(1) state = Req-Sent Jun 15 20:04:03 vbook ppp[4771]: tun0: CCP: MPPE[6] value 0x00000001 (0 bits, stateful, compressed) Jun 15 20:04:03 vbook ppp[4771]: tun0: LCP: deflink: SendIdent(1) state = Opened Jun 15 20:04:03 vbook ppp[4771]: tun0: LCP: MAGICNUM 031c8dad Jun 15 20:04:03 vbook ppp[4771]: tun0: LCP: TEXT user-ppp 3.4.2 (built COMPILATIONDATE) Jun 15 20:04:03 vbook ppp[4771]: tun0: CCP: deflink: RecvConfigAck(1) state = Req-Sent Jun 15 20:04:03 vbook ppp[4771]: tun0: CCP: [EMPTY] Jun 15 20:04:03 vbook ppp[4771]: tun0: CCP: deflink: State change Req-Sent --> Ack-Rcvd Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: deflink: RecvConfigNak(1) state = Ack-Sent Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: IPADDR[6] 92.36.20.41 Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: IPADDR[6] changing address: 127.0.0.1 --> 92.36.20.41 Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: PRIDNS[6] 212.119.96.33 Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: SECDNS[6] 212.119.97.5 Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: Primary nameserver set to 212.119.96.33 Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: Secondary nameserver set to 212.119.97.5 Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: deflink: SendConfigReq(2) state = Ack-Sent Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: IPADDR[6] 92.36.20.41 Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: PRIDNS[6] 212.119.96.33 Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: SECDNS[6] 212.119.97.5 Jun 15 20:04:03 vbook ppp[4771]: tun0: CCP: deflink: RecvConfigReq(2) state = Ack-Rcvd Jun 15 20:04:03 vbook ppp[4771]: tun0: CCP: LZS-DCP[6] Jun 15 20:04:03 vbook ppp[4771]: tun0: CCP: deflink: SendConfigRej(2) state = Ack-Rcvd Jun 15 20:04:03 vbook ppp[4771]: tun0: CCP: LZS-DCP[6] Jun 15 20:04:03 vbook ppp[4771]: tun0: LCP: deflink: SendIdent(2) state = Opened Jun 15 20:04:03 vbook ppp[4771]: tun0: LCP: MAGICNUM 031c8dad Jun 15 20:04:03 vbook ppp[4771]: tun0: LCP: TEXT user-ppp 3.4.2 (built COMPILATIONDATE) Jun 15 20:04:04 vbook ppp[4771]: tun0: IPCP: deflink: RecvConfigAck(2) state = Ack-Sent Jun 15 20:04:04 vbook ppp[4771]: tun0: IPCP: IPADDR[6] 92.36.20.41 Jun 15 20:04:04 vbook ppp[4771]: tun0: IPCP: PRIDNS[6] 212.119.96.33 Jun 15 20:04:04 vbook ppp[4771]: tun0: IPCP: SECDNS[6] 212.119.97.5 Jun 15 20:04:04 vbook ppp[4771]: tun0: IPCP: deflink: State change Ack-Sent --> Opened Jun 15 20:04:04 vbook ppp[4771]: tun0: IPCP: deflink: LayerUp. Jun 15 20:04:04 vbook ppp[4771]: tun0: IPCP: myaddr 92.36.20.41 hisaddr = 212.119.106.161 Jun 15 20:04:04 vbook ppp[4771]: tun0: Warning: 0.0.0.0/0: Change route failed: errno: No such process Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: deflink: RecvConfigReq(3) state = Ack-Rcvd Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: STAC[5] Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: deflink: SendConfigRej(3) state = Ack-Rcvd Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: STAC[5] Jun 15 20:04:04 vbook ppp[4771]: tun0: LCP: deflink: SendIdent(3) state = Opened Jun 15 20:04:04 vbook ppp[4771]: tun0: LCP: MAGICNUM 031c8dad Jun 15 20:04:04 vbook ppp[4771]: tun0: LCP: TEXT user-ppp 3.4.2 (built COMPILATIONDATE) Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: deflink: RecvConfigReq(4) state = Ack-Rcvd Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: STAC[5] Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: deflink: SendConfigRej(4) state = Ack-Rcvd Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: STAC[5] Jun 15 20:04:04 vbook ppp[4771]: tun0: LCP: deflink: SendIdent(4) state = Opened Jun 15 20:04:04 vbook ppp[4771]: tun0: LCP: MAGICNUM 031c8dad Jun 15 20:04:04 vbook ppp[4771]: tun0: LCP: TEXT user-ppp 3.4.2 (built COMPILATIONDATE) Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: deflink: RecvConfigReq(5) state = Ack-Rcvd Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: PRED1[2] Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: deflink: SendConfigRej(5) state = Ack-Rcvd Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: PRED1[2] Jun 15 20:04:04 vbook ppp[4771]: tun0: LCP: deflink: SendIdent(5) state = Opened Jun 15 20:04:04 vbook ppp[4771]: tun0: LCP: MAGICNUM 031c8dad Jun 15 20:04:04 vbook ppp[4771]: tun0: LCP: TEXT user-ppp 3.4.2 (built COMPILATIONDATE) Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: deflink: RecvConfigReq(6) state = Ack-Rcvd Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: [EMPTY] Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: deflink: SendConfigAck(6) state = Ack-Rcvd Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: [EMPTY] Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: deflink: State change Ack-Rcvd --> Opened Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: deflink: LayerUp. Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: deflink: Out = none[-1], In = none[-1] Jun 15 20:04:04 vbook ppp[4771]: tun0: Warning: 0.0.0.0/0: Change route failed: errno: No such process Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: deflink: RecvTerminateReq(7) state = Opened Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: deflink: LayerDown. Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: deflink: SendTerminateAck(7) state = Opened Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: deflink: State change Opened --> Stopping Jun 15 20:04:04 vbook ppp[4771]: tun0: LCP: deflink: RecvEchoRequest(1) state = Opened Jun 15 20:04:04 vbook ppp[4771]: tun0: LCP: deflink: SendEchoReply(1) state = Opened Jun 15 20:04:07 vbook ppp[4771]: tun0: CCP: deflink: LayerFinish. Jun 15 20:04:07 vbook ppp[4771]: tun0: CCP: deflink: State change Stopping --> Stopped Jun 15 20:04:29 vbook ppp[4771]: tun0: Phase: /dev/ttyp1: Client connection closed. Jun 15 20:04:29 vbook ppp[4771]: tun0: IPCP: deflink: LayerDown: 92.36.20.41 Jun 15 20:04:29 vbook ppp[4771]: tun0: IPCP: deflink: SendTerminateReq(3) state = Opened Jun 15 20:04:29 vbook ppp[4771]: tun0: IPCP: deflink: State change Opened --> Closing Jun 15 20:04:29 vbook ppp[4771]: tun0: IPCP: deflink: RecvTerminateAck(3) state = Closing Jun 15 20:04:29 vbook ppp[4771]: tun0: IPCP: deflink: LayerFinish. -- Vladimir B. Grebenschikov vova@fbsd.ru From josh.carroll at gmail.com Sun Jun 15 19:23:14 2008 From: josh.carroll at gmail.com (Josh Carroll) Date: Sun Jun 15 19:23:17 2008 Subject: mrtg peak on reboot / snmp-issue? In-Reply-To: <1213546323.29846.24.camel@bigapple.omnis.ch> References: <1213546323.29846.24.camel@bigapple.omnis.ch> Message-ID: <8cb6106e0806151157n1dbf3b49wf7a56e51da8c1988@mail.gmail.com> Sorry the blackberry is truncating your original mail, but yes I have noticed the same thing on my setup. In my case I am using a custom rrdtool perl script. While not a fix for the actual problem, my workaround has been to use a CDEF in my rrdgraph command to set the value to 0 if it exceeds a sane maximum. I'm not sure off hand if mrtg has a similar capability but you might be able to set a max value for the graph so at least it won't skew the graph and hide the rest of the data points. Another option is to use a custom script to collect the values by grabbing the data from snmp and then sanitizing them prior to outputting to the value. Regards, Josh On 6/15/08, Olivier Mueller wrote: > Hello, > > Small but curious thing on my freebsd-based systems: when a > server is rebooted, it generates a peak (or "spike"?) on the > network mrtg for all interfaces (here just before 1 am): > http://8304.ch/om/stuff/mrtg_localhost_1-day.png > > It happens with both net-snmp and ucd-snmp, with a quite standard > mrtg installation (generated by cfgmaker). > > Do you have the same "issue" on your own servers? All I can add, is > that there is not such a high traffic after a reboot, and that it > doesn't happen on similar linux-based systems. > > Regards & a nice week to you, > Olivier > > > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" > From linimon at FreeBSD.org Sun Jun 15 22:21:31 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sun Jun 15 22:21:33 2008 Subject: kern/124622: [rl] [patch] if_rl.ko bug fix: unknown device ID: 8039 Message-ID: <200806152221.m5FMLVMX073747@freefall.freebsd.org> Old Synopsis: if_rl.ko bug fix New Synopsis: [rl] [patch] if_rl.ko bug fix: unknown device ID: 8039 Responsible-Changed-From-To: gnats-admin->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Jun 15 22:19:23 UTC 2008 Responsible-Changed-Why: Rescue this PR from the 'pending' category and assign. Note to submitter: your mailer is mangling your GNATS submissions. http://www.freebsd.org/cgi/query-pr.cgi?pr=124622 From sinister at gmail.com Mon Jun 16 02:48:32 2008 From: sinister at gmail.com (Sin) Date: Mon Jun 16 02:48:35 2008 Subject: ppp vs mpd: ppp fails to keep connection, mpd works References: <1213550909.5038.56.camel@localhost> Message-ID: <008701c8cf57$93bab3d0$0200a8c0@dts> I ran accross this anoying problem years ago when I upgraded to 4.11 I'm not sure if your problem is related to LQR, but these logs look familliar. In your default ppp.conf file add this: default: enable lqr set timeout 0 set lqrperiod 10 I'm not sure why they changed this from one version of PPP to the next, it made more sense to keep it on by default. ----- Original Message ----- From: "Vladimir Grebenschikov" To: "freebsd-net" Sent: Sunday, June 15, 2008 1:28 PM Subject: ppp vs mpd: ppp fails to keep connection, mpd works > Hi > > I am trying to find why with same configuration ppp does not works with > my CDMA modem (connected over usb) but mpd works. > > MPD log (it works as expected): > ... > [umodem0] link: UP event > [umodem0] link: origination is remote > [umodem0] LCP: Up event > [umodem0] LCP: state change Starting --> Req-Sent > [umodem0] LCP: phase shift DEAD --> ESTABLISH > [umodem0] LCP: SendConfigReq #1 > ACFCOMP > PROTOCOMP > ACCMAP 0x000a0000 > MRU 1500 > MAGICNUM 04eb5958 > MP MRRU 1600 > MP SHORTSEQ > ENDPOINTDISC [Magic] 41 a2 7a c0 29 08 7a c0 > [umodem0] LCP: rec'd Configure Reject #1 link 0 (Req-Sent) > MP MRRU 1600 > MP SHORTSEQ > [umodem0] LCP: SendConfigReq #2 > ACFCOMP > PROTOCOMP > ACCMAP 0x000a0000 > MRU 1500 > MAGICNUM 04eb5958 > [umodem0] LCP: rec'd Configure Ack #2 link 0 (Req-Sent) > ACFCOMP > PROTOCOMP > ACCMAP 0x000a0000 > MRU 1500 > MAGICNUM 04eb5958 > [umodem0] LCP: state change Req-Sent --> Ack-Rcvd > [umodem0] LCP: rec'd Configure Request #8 link 0 (Ack-Rcvd) > ACCMAP 0x00000000 > AUTHPROTO CHAP MD5 > MAGICNUM 43aeaeee > [umodem0] LCP: SendConfigNak #8 > AUTHPROTO PAP > [umodem0] LCP: rec'd Configure Request #9 link 0 (Ack-Rcvd) > ACCMAP 0x00000000 > AUTHPROTO PAP > MAGICNUM 43aeaeee > [umodem0] LCP: SendConfigAck #9 > ACCMAP 0x00000000 > AUTHPROTO PAP > MAGICNUM 43aeaeee > [umodem0] LCP: state change Ack-Rcvd --> Opened > [umodem0] LCP: phase shift ESTABLISH --> AUTHENTICATE > [umodem0] LCP: auth: peer wants PAP, I want nothing > [umodem0] PAP: using authname "mobile" > [umodem0] PAP: sending REQUEST > [umodem0] LCP: LayerUp > [umodem0] PAP: rec'd ACK #1 > [umodem0] LCP: authorization successful > [umodem0] LCP: phase shift AUTHENTICATE --> NETWORK > [skylink] setting interface ng0 MTU to 1500 bytes > [skylink] up: 1 link, total bandwidth 28800 bps > [skylink] IPCP: Up event > [skylink] IPCP: state change Starting --> Req-Sent > [skylink] IPCP: SendConfigReq #1 > IPADDR 0.0.0.0 > COMPPROTO VJCOMP, 16 comp. channels, no comp-cid > [skylink] error writing len 20 frame to bypass: Network is down > [skylink] IPCP: rec'd Configure Request #2 link 0 (Req-Sent) > IPADDR 212.119.106.147 > 212.119.106.147 is OK > [skylink] IPCP: SendConfigAck #2 > IPADDR 212.119.106.147 > [skylink] IPCP: state change Req-Sent --> Ack-Sent > [skylink] rec'd unexpected protocol CCP on link 0, rejecting > [skylink] IPCP: SendConfigReq #2 > IPADDR 0.0.0.0 > COMPPROTO VJCOMP, 16 comp. channels, no comp-cid > [skylink] IPCP: rec'd Configure Reject #2 link 0 (Ack-Sent) > COMPPROTO VJCOMP, 16 comp. channels, no comp-cid > [skylink] IPCP: SendConfigReq #3 > IPADDR 0.0.0.0 > [skylink] IPCP: rec'd Configure Nak #3 link 0 (Ack-Sent) > IPADDR 92.36.111.152 > 92.36.111.152 is OK > [skylink] IPCP: SendConfigReq #4 > IPADDR 92.36.111.152 > [skylink] IPCP: rec'd Configure Ack #4 link 0 (Ack-Sent) > IPADDR 92.36.111.152 > [skylink] IPCP: state change Ack-Sent --> Opened > [skylink] IPCP: LayerUp > 92.36.111.152 -> 212.119.106.147 > [skylink] IFACE: Up event > [skylink] setting interface ng0 MTU to 1500 bytes > [skylink] exec: /sbin/ifconfig ng0 92.36.111.152 212.119.106.147 netmask > 0xffffffff -link0 > [skylink] exec: /sbin/route add 92.36.111.152 -iface lo0 > [skylink] exec: /sbin/route add 0.0.0.0 212.119.106.147 > [skylink] IFACE: Up event > [skylink] rec'd unexpected protocol IP on link 0 > [umodem0] NEW FRAME ERRS: FCS 1 RUNT 0 OVFL 0 > > Then it just works. > > But ppp, closes connection just after negotiation (log below). > After pair of empty config requests. > What may be wrong here ? > Any hints will be very appreciated. > > Jun 15 20:03:54 vbook ppp[4771]: Phase: Using interface: tun0 > Jun 15 20:03:54 vbook ppp[4771]: Phase: deflink: Created in closed state > Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: default: ident user-ppp > VERSION (built COMPILATIONDATE) > Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: default: set speed 115200 > Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: default: set dial ABORT > BUSY ABORT NO\sCARRIER TIMEOUT 5 "" AT OK-AT-OK ATE1Q0 OK > \dATDT\T TIMEOUT 40 CONNECT > Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: default: set timeout 0 > Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: skylink: set log Phase > Chat LCP IPCP CCP tun command > Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: skylink: disable pred1 > deflate deflate24 protocomp acfcomp shortseq vj > Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: skylink: deny pred1 > deflate deflate24 protocomp acfcomp shortseq vj > Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: skylink: set speed 460800 > Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: skylink: set timeout 180 > Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: skylink: enable dns > Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: skylink: set device > /dev/ttyU0 > Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: skylink: set phone #777 > Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: skylink: set dial ABORT > BUSY ABORT NO\sCARRIER TIMEOUT 15 "" AT OK-AT-OK ATE1Q0 OK \dATDT\T > TIMEOUT 40 CONNECT > Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: skylink: set authname > mobile > Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: skylink: set authkey > ******** > Jun 15 20:03:54 vbook ppp[4771]: tun0: Command: skylink: add default > HISADDR > Jun 15 20:03:54 vbook ppp[4771]: tun0: Phase: PPP Started (interactive > mode). > Jun 15 20:03:57 vbook ppp[4771]: tun0: Command: /dev/ttyp1: dial > Jun 15 20:03:57 vbook ppp[4771]: tun0: Phase: bundle: Establish > Jun 15 20:03:57 vbook ppp[4771]: tun0: Phase: deflink: closed -> opening > Jun 15 20:03:57 vbook ppp[4771]: tun0: Phase: deflink: Connected! > Jun 15 20:03:57 vbook ppp[4771]: tun0: Phase: deflink: opening -> dial > Jun 15 20:03:57 vbook ppp[4771]: tun0: Chat: Phone: #777 > Jun 15 20:03:57 vbook ppp[4771]: tun0: Chat: deflink: Dial attempt 1 of 1 > Jun 15 20:03:57 vbook ppp[4771]: tun0: Chat: Send: AT^M > Jun 15 20:03:57 vbook ppp[4771]: tun0: Chat: Expect(15): OK > Jun 15 20:03:57 vbook ppp[4771]: tun0: Chat: Received: AT^M^M > Jun 15 20:03:57 vbook ppp[4771]: tun0: Chat: Received: OK^M > Jun 15 20:03:57 vbook ppp[4771]: tun0: Chat: Send: ATE1Q0^M > Jun 15 20:03:57 vbook ppp[4771]: tun0: Chat: Expect(15): OK > Jun 15 20:03:57 vbook ppp[4771]: tun0: Chat: Received: ATE1Q0^M^M > Jun 15 20:03:57 vbook ppp[4771]: tun0: Chat: Received: OK^M > Jun 15 20:03:57 vbook ppp[4771]: tun0: Chat: Send: ATDT#777^M > Jun 15 20:03:59 vbook ppp[4771]: tun0: Chat: Expect(40): CONNECT > Jun 15 20:03:59 vbook ppp[4771]: tun0: Chat: Received: ATDT#777^M^M > Jun 15 20:03:59 vbook ppp[4771]: tun0: Chat: Received: CONNECT^M > Jun 15 20:03:59 vbook ppp[4771]: tun0: Phase: deflink: dial -> carrier > Jun 15 20:04:00 vbook ppp[4771]: tun0: Phase: deflink: /dev/ttyU0 doesn't > support CD > Jun 15 20:04:00 vbook ppp[4771]: tun0: Phase: deflink: carrier -> login > Jun 15 20:04:00 vbook ppp[4771]: tun0: Phase: deflink: login -> lcp > Jun 15 20:04:00 vbook ppp[4771]: tun0: LCP: FSM: Using "deflink" as a > transport > Jun 15 20:04:00 vbook ppp[4771]: tun0: LCP: deflink: State change > Initial --> Closed > Jun 15 20:04:00 vbook ppp[4771]: tun0: LCP: deflink: State change > Closed --> Stopped > Jun 15 20:04:00 vbook ppp[4771]: tun0: LCP: deflink: RecvConfigReq(2) > state = Stopped > Jun 15 20:04:00 vbook ppp[4771]: tun0: LCP: ACCMAP[6] 0x00000000 > Jun 15 20:04:00 vbook ppp[4771]: tun0: LCP: AUTHPROTO[5] 0xc223 (CHAP > 0x05) > Jun 15 20:04:00 vbook ppp[4771]: tun0: LCP: MAGICNUM[6] 0x36bc6422 > Jun 15 20:04:00 vbook ppp[4771]: tun0: LCP: deflink: SendConfigReq(1) > state = Stopped > Jun 15 20:04:00 vbook ppp[4771]: tun0: LCP: ACCMAP[6] 0x00000000 > Jun 15 20:04:00 vbook ppp[4771]: tun0: LCP: MRU[4] 1500 > Jun 15 20:04:00 vbook ppp[4771]: tun0: LCP: MAGICNUM[6] 0x031c8dad > Jun 15 20:04:00 vbook ppp[4771]: tun0: LCP: deflink: SendConfigAck(2) > state = Stopped > Jun 15 20:04:00 vbook ppp[4771]: tun0: LCP: ACCMAP[6] 0x00000000 > Jun 15 20:04:00 vbook ppp[4771]: tun0: LCP: AUTHPROTO[5] 0xc223 (CHAP > 0x05) > Jun 15 20:04:00 vbook ppp[4771]: tun0: LCP: MAGICNUM[6] 0x36bc6422 > Jun 15 20:04:00 vbook ppp[4771]: tun0: LCP: deflink: LayerStart > Jun 15 20:04:00 vbook ppp[4771]: tun0: LCP: deflink: State change > Stopped --> Ack-Sent > Jun 15 20:04:02 vbook ppp[4771]: tun0: LCP: deflink: RecvConfigReq(3) > state = Ack-Sent > Jun 15 20:04:02 vbook ppp[4771]: tun0: LCP: ACCMAP[6] 0x00000000 > Jun 15 20:04:02 vbook ppp[4771]: tun0: LCP: AUTHPROTO[5] 0xc223 (CHAP > 0x05) > Jun 15 20:04:02 vbook ppp[4771]: tun0: LCP: MAGICNUM[6] 0x36bc6422 > Jun 15 20:04:02 vbook ppp[4771]: tun0: LCP: deflink: SendConfigAck(3) > state = Ack-Sent > Jun 15 20:04:02 vbook ppp[4771]: tun0: LCP: ACCMAP[6] 0x00000000 > Jun 15 20:04:02 vbook ppp[4771]: tun0: LCP: AUTHPROTO[5] 0xc223 (CHAP > 0x05) > Jun 15 20:04:02 vbook ppp[4771]: tun0: LCP: MAGICNUM[6] 0x36bc6422 > Jun 15 20:04:03 vbook ppp[4771]: tun0: LCP: deflink: SendConfigReq(1) > state = Ack-Sent > Jun 15 20:04:03 vbook ppp[4771]: tun0: LCP: ACCMAP[6] 0x00000000 > Jun 15 20:04:03 vbook ppp[4771]: tun0: LCP: MRU[4] 1500 > Jun 15 20:04:03 vbook ppp[4771]: tun0: LCP: MAGICNUM[6] 0x031c8dad > Jun 15 20:04:03 vbook ppp[4771]: tun0: LCP: deflink: RecvConfigAck(1) > state = Ack-Sent > Jun 15 20:04:03 vbook ppp[4771]: tun0: LCP: ACCMAP[6] 0x00000000 > Jun 15 20:04:03 vbook ppp[4771]: tun0: LCP: MRU[4] 1500 > Jun 15 20:04:03 vbook ppp[4771]: tun0: LCP: MAGICNUM[6] 0x031c8dad > Jun 15 20:04:03 vbook ppp[4771]: tun0: LCP: deflink: State change > Ack-Sent --> Opened > Jun 15 20:04:03 vbook ppp[4771]: tun0: LCP: deflink: LayerUp > Jun 15 20:04:03 vbook ppp[4771]: tun0: LCP: deflink: SendIdent(0) state = > Opened > Jun 15 20:04:03 vbook ppp[4771]: tun0: LCP: MAGICNUM 031c8dad > Jun 15 20:04:03 vbook ppp[4771]: tun0: LCP: TEXT user-ppp 3.4.2 (built > COMPILATIONDATE) > Jun 15 20:04:03 vbook ppp[4771]: tun0: Phase: bundle: Authenticate > Jun 15 20:04:03 vbook ppp[4771]: tun0: Phase: deflink: his = CHAP 0x05, > mine = none > Jun 15 20:04:03 vbook ppp[4771]: tun0: Phase: Chap Input: CHALLENGE (16 > bytes from pdsn-m34-7cm6) > Jun 15 20:04:03 vbook ppp[4771]: tun0: Phase: Chap Output: RESPONSE > (mobile) > Jun 15 20:04:03 vbook ppp[4771]: tun0: Phase: Chap Input: SUCCESS > Jun 15 20:04:03 vbook ppp[4771]: tun0: CCP: FSM: Using "deflink" as a > transport > Jun 15 20:04:03 vbook ppp[4771]: tun0: CCP: deflink: State change > Initial --> Closed > Jun 15 20:04:03 vbook ppp[4771]: tun0: CCP: deflink: LayerStart. > Jun 15 20:04:03 vbook ppp[4771]: tun0: CCP: MPPE: Not usable without > CHAP81 > Jun 15 20:04:03 vbook ppp[4771]: tun0: CCP: deflink: SendConfigReq(1) > state = Closed > Jun 15 20:04:03 vbook ppp[4771]: tun0: CCP: [EMPTY] > Jun 15 20:04:03 vbook ppp[4771]: tun0: CCP: deflink: State change > Closed --> Req-Sent > Jun 15 20:04:03 vbook ppp[4771]: tun0: Phase: deflink: lcp -> open > Jun 15 20:04:03 vbook ppp[4771]: tun0: Phase: bundle: Network > Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: FSM: Using "deflink" as a > transport > Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: deflink: State change > Initial --> Closed > Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: deflink: LayerStart. > Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: deflink: SendConfigReq(1) > state = Closed > Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: IPADDR[6] 127.0.0.1 > Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: PRIDNS[6] 212.119.97.5 > Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: SECDNS[6] 255.255.255.255 > Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: deflink: State change > Closed --> Req-Sent > Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: deflink: RecvConfigReq(1) > state = Req-Sent > Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: IPADDR[6] 212.119.106.161 > Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: deflink: SendConfigAck(1) > state = Req-Sent > Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: IPADDR[6] 212.119.106.161 > Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: deflink: State change > Req-Sent --> Ack-Sent > Jun 15 20:04:03 vbook ppp[4771]: tun0: CCP: deflink: RecvConfigReq(1) > state = Req-Sent > Jun 15 20:04:03 vbook ppp[4771]: tun0: CCP: MPPE[6] value 0x00000001 (0 > bits, stateful, compressed) > Jun 15 20:04:03 vbook ppp[4771]: tun0: CCP: MPPE: Not usable without > CHAP81 > Jun 15 20:04:03 vbook ppp[4771]: tun0: CCP: deflink: SendConfigRej(1) > state = Req-Sent > Jun 15 20:04:03 vbook ppp[4771]: tun0: CCP: MPPE[6] value 0x00000001 (0 > bits, stateful, compressed) > Jun 15 20:04:03 vbook ppp[4771]: tun0: LCP: deflink: SendIdent(1) state = > Opened > Jun 15 20:04:03 vbook ppp[4771]: tun0: LCP: MAGICNUM 031c8dad > Jun 15 20:04:03 vbook ppp[4771]: tun0: LCP: TEXT user-ppp 3.4.2 (built > COMPILATIONDATE) > Jun 15 20:04:03 vbook ppp[4771]: tun0: CCP: deflink: RecvConfigAck(1) > state = Req-Sent > Jun 15 20:04:03 vbook ppp[4771]: tun0: CCP: [EMPTY] > Jun 15 20:04:03 vbook ppp[4771]: tun0: CCP: deflink: State change > Req-Sent --> Ack-Rcvd > Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: deflink: RecvConfigNak(1) > state = Ack-Sent > Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: IPADDR[6] 92.36.20.41 > Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: IPADDR[6] changing address: > 127.0.0.1 --> 92.36.20.41 > Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: PRIDNS[6] 212.119.96.33 > Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: SECDNS[6] 212.119.97.5 > Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: Primary nameserver set to > 212.119.96.33 > Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: Secondary nameserver set to > 212.119.97.5 > Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: deflink: SendConfigReq(2) > state = Ack-Sent > Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: IPADDR[6] 92.36.20.41 > Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: PRIDNS[6] 212.119.96.33 > Jun 15 20:04:03 vbook ppp[4771]: tun0: IPCP: SECDNS[6] 212.119.97.5 > Jun 15 20:04:03 vbook ppp[4771]: tun0: CCP: deflink: RecvConfigReq(2) > state = Ack-Rcvd > Jun 15 20:04:03 vbook ppp[4771]: tun0: CCP: LZS-DCP[6] > Jun 15 20:04:03 vbook ppp[4771]: tun0: CCP: deflink: SendConfigRej(2) > state = Ack-Rcvd > Jun 15 20:04:03 vbook ppp[4771]: tun0: CCP: LZS-DCP[6] > Jun 15 20:04:03 vbook ppp[4771]: tun0: LCP: deflink: SendIdent(2) state = > Opened > Jun 15 20:04:03 vbook ppp[4771]: tun0: LCP: MAGICNUM 031c8dad > Jun 15 20:04:03 vbook ppp[4771]: tun0: LCP: TEXT user-ppp 3.4.2 (built > COMPILATIONDATE) > Jun 15 20:04:04 vbook ppp[4771]: tun0: IPCP: deflink: RecvConfigAck(2) > state = Ack-Sent > Jun 15 20:04:04 vbook ppp[4771]: tun0: IPCP: IPADDR[6] 92.36.20.41 > Jun 15 20:04:04 vbook ppp[4771]: tun0: IPCP: PRIDNS[6] 212.119.96.33 > Jun 15 20:04:04 vbook ppp[4771]: tun0: IPCP: SECDNS[6] 212.119.97.5 > Jun 15 20:04:04 vbook ppp[4771]: tun0: IPCP: deflink: State change > Ack-Sent --> Opened > Jun 15 20:04:04 vbook ppp[4771]: tun0: IPCP: deflink: LayerUp. > Jun 15 20:04:04 vbook ppp[4771]: tun0: IPCP: myaddr 92.36.20.41 hisaddr = > 212.119.106.161 > Jun 15 20:04:04 vbook ppp[4771]: tun0: Warning: 0.0.0.0/0: Change route > failed: errno: No such process > Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: deflink: RecvConfigReq(3) > state = Ack-Rcvd > Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: STAC[5] > Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: deflink: SendConfigRej(3) > state = Ack-Rcvd > Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: STAC[5] > Jun 15 20:04:04 vbook ppp[4771]: tun0: LCP: deflink: SendIdent(3) state = > Opened > Jun 15 20:04:04 vbook ppp[4771]: tun0: LCP: MAGICNUM 031c8dad > Jun 15 20:04:04 vbook ppp[4771]: tun0: LCP: TEXT user-ppp 3.4.2 (built > COMPILATIONDATE) > Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: deflink: RecvConfigReq(4) > state = Ack-Rcvd > Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: STAC[5] > Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: deflink: SendConfigRej(4) > state = Ack-Rcvd > Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: STAC[5] > Jun 15 20:04:04 vbook ppp[4771]: tun0: LCP: deflink: SendIdent(4) state = > Opened > Jun 15 20:04:04 vbook ppp[4771]: tun0: LCP: MAGICNUM 031c8dad > Jun 15 20:04:04 vbook ppp[4771]: tun0: LCP: TEXT user-ppp 3.4.2 (built > COMPILATIONDATE) > Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: deflink: RecvConfigReq(5) > state = Ack-Rcvd > Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: PRED1[2] > Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: deflink: SendConfigRej(5) > state = Ack-Rcvd > Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: PRED1[2] > Jun 15 20:04:04 vbook ppp[4771]: tun0: LCP: deflink: SendIdent(5) state = > Opened > Jun 15 20:04:04 vbook ppp[4771]: tun0: LCP: MAGICNUM 031c8dad > Jun 15 20:04:04 vbook ppp[4771]: tun0: LCP: TEXT user-ppp 3.4.2 (built > COMPILATIONDATE) > Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: deflink: RecvConfigReq(6) > state = Ack-Rcvd > Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: [EMPTY] > Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: deflink: SendConfigAck(6) > state = Ack-Rcvd > Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: [EMPTY] > Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: deflink: State change > Ack-Rcvd --> Opened > Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: deflink: LayerUp. > Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: deflink: Out = none[-1], In = > none[-1] > Jun 15 20:04:04 vbook ppp[4771]: tun0: Warning: 0.0.0.0/0: Change route > failed: errno: No such process > Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: deflink: RecvTerminateReq(7) > state = Opened > Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: deflink: LayerDown. > Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: deflink: SendTerminateAck(7) > state = Opened > Jun 15 20:04:04 vbook ppp[4771]: tun0: CCP: deflink: State change > Opened --> Stopping > Jun 15 20:04:04 vbook ppp[4771]: tun0: LCP: deflink: RecvEchoRequest(1) > state = Opened > Jun 15 20:04:04 vbook ppp[4771]: tun0: LCP: deflink: SendEchoReply(1) > state = Opened > Jun 15 20:04:07 vbook ppp[4771]: tun0: CCP: deflink: LayerFinish. > Jun 15 20:04:07 vbook ppp[4771]: tun0: CCP: deflink: State change > Stopping --> Stopped > Jun 15 20:04:29 vbook ppp[4771]: tun0: Phase: /dev/ttyp1: Client > connection closed. > Jun 15 20:04:29 vbook ppp[4771]: tun0: IPCP: deflink: LayerDown: > 92.36.20.41 > Jun 15 20:04:29 vbook ppp[4771]: tun0: IPCP: deflink: SendTerminateReq(3) > state = Opened > Jun 15 20:04:29 vbook ppp[4771]: tun0: IPCP: deflink: State change > Opened --> Closing > Jun 15 20:04:29 vbook ppp[4771]: tun0: IPCP: deflink: RecvTerminateAck(3) > state = Closing > Jun 15 20:04:29 vbook ppp[4771]: tun0: IPCP: deflink: LayerFinish. > > > -- > Vladimir B. Grebenschikov > vova@fbsd.ru > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From bugmaster at FreeBSD.org Mon Jun 16 11:07:00 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 16 11:07:51 2008 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200806161106.m5GB6x9R036784@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/92090 net [bge] bge0: watchdog timeout -- resetting f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau f kern/102344 net [ipf] Some packets do not pass through network interfa o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109733 net [bge] bge link state issues [regression] o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116328 net [bge]: Solid hang with bge interface o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117423 net [vlan] Duplicate IP on different interfaces o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119361 net [bge] bge(4) transmit performance problem o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122082 net [in_pcb] NULL pointer dereference in in_pcbdrop o kern/122195 net [ed] Alignment problems in if_ed f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix f kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar f conf/122858 net [nsswitch.conf] nsswitch in 7.0 is f*cked up o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 f kern/123172 net [bce] Watchdog timeout problems with if_bce o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123617 net [tcp] breaking connection when client downloading file o bin/123633 net ifconfig(8) doesn't set inet and ether address in one p kern/123741 net [netgraph] [panic] kernel panic due to netgraph mpd o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123881 net [tcp] Turning on TCP blackholing causes slow localhost o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124540 net [tcp] RTM_MISS with the transit packets o kern/124622 net [rl] [patch] if_rl.ko bug fix: unknown device ID: 8039 91 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 o kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/95267 net packet drops periodically appear o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/112179 net [sis] [patch] sis driver for natsemi DP83815D autonego o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o bin/117339 net [patch] route(8): loading routing management commands o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/119432 net [arp] route add -host -iface causes arp e f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/121242 net [ate] [patch] Promiscuous mode of if_ate (arm) doesn't o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122068 net [ppp] ppp can not set the correct interface with pptpd p kern/122145 net error while compiling with device ath_rate_amrr o kern/122295 net [bge] bge Ierr rate increase (since 6.0R) [regression] o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122697 net [ath] Atheros card is not well supported o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge f kern/122839 net [multicast] FreeBSD 7 multicast routing problem o kern/122928 net [em] interface watchdog timeouts and stops receiving p o kern/123892 net [tap] [patch] No buffer space available o kern/123961 net [vr] [patch] Allow vr interface to handle vlans o bin/124004 net ifconfig(8): Cannot assign both an IP and a MAC addres o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124609 net [ipsec] [panic] ipsec 'remainder too big' panic with p 54 problems total. From stefan.lambrev at moneybookers.com Mon Jun 16 12:13:11 2008 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Mon Jun 16 12:13:18 2008 Subject: carpdev? In-Reply-To: <200806021903.48986.max@love2party.net> References: <48442389.9000602@MonkeyBrains.NET> <4844265F.4000405@MonkeyBrains.NET> <200806021903.48986.max@love2party.net> Message-ID: <485658CF.2080603@moneybookers.com> Greetings, I'm trying this patch against 7-stable amd64 from today. The patch applies cleanly, but: ifconfig carp create ifconfig carp0 carpdev em3 ifconfig: carpdev: bad value What is the proper syntax to set carpdev? Btw 5-10min latter the server panic, but failed to dump a core. The pid to blame was em3 taskq. If I manage to get working configuration, I'll test the patch against unpatched CARP from 6.3 and will test also with quad core/amd64 and dual core i386 (both 7-stable from today) and let you know the results. Max Laier wrote: > I did the attached patch some time ago, but didn't find sufficient testers > and when I did - I didn't have time. This should work. > > > ------------------------------------------------------------------------ > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- Best Wishes, Stefan Lambrev ICQ# 24134177 From remko at FreeBSD.org Mon Jun 16 17:50:29 2008 From: remko at FreeBSD.org (remko@FreeBSD.org) Date: Mon Jun 16 17:50:32 2008 Subject: kern/124622: [rl] [patch] if_rl.ko bug fix: unknown device ID: 8039 Message-ID: <200806161750.m5GHoT0D003839@freefall.freebsd.org> Synopsis: [rl] [patch] if_rl.ko bug fix: unknown device ID: 8039 Responsible-Changed-From-To: freebsd-net->remko Responsible-Changed-By: remko Responsible-Changed-When: Mon Jun 16 17:50:29 UTC 2008 Responsible-Changed-Why: I'll take it. http://www.freebsd.org/cgi/query-pr.cgi?pr=124622 From paul at gtcomm.net Mon Jun 16 21:00:32 2008 From: paul at gtcomm.net (Paul) Date: Mon Jun 16 21:00:36 2008 Subject: Route messages In-Reply-To: <4854EBF1.7020708@FreeBSD.org> References: <4852E23E.2040505@gtcomm.net> <4854EBF1.7020708@FreeBSD.org> Message-ID: <4856D4E1.6070909@gtcomm.net> Yes but I DO have a default route.. I tried putting one in, removing it, putting it back, rebooting.. The problem is ZEBRA listens to the socket and uses 10-15% cpu because of these messages.. It doesn't happen on -RELEASE though so hmmmm.. I guess I could hack it to skip over the reporting of the message.. probably be good in the future, but something is wrong because I've added a default and removed it also so maybe something with the -STABLE code that changed something in the routing area.. Bruce M. Simpson wrote: > Paul wrote: >> Get these with GRE tunnel on >> FreeBSD 7.0-STABLE FreeBSD 7.0-STABLE #5: Sun May 11 19:00:57 EDT >> 2008 :/usr/obj/usr/src/sys/ROUTER amd64 >> But do not get them with 7.0-RELEASE >> >> Any ideas what changed? :) Wish there was some sort of changelog.. >> # of messages per second seems consistent with packets per second on >> GRE interface.. >> No impact in routing, but definitely impact in cpu usage for all >> processes monitoring the route messages. > > RTM_MISS is actually fairly common when you don't have a default route. > > Messages which get enqueued don't necessarily get delivered -- and > very few processes actually listen to the routing socket actively like > this, so I wouldn't worry about it. > > If it's a real concern for you then you could try hacking in a sysctl > to tell the radix trie code not to issue RTM_MISS messages on the > routing socket. > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From steve at ibctech.ca Mon Jun 16 23:56:59 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Mon Jun 16 23:57:01 2008 Subject: if_vlan subinterfaces at boot Message-ID: <4856FE0B.8030901@ibctech.ca> Hi everyone, Is there any way to create, and assign addresses to a if_vlan sub-interface (eg: em6.3) via rc.conf at boot? If not, is there a documented best practice on how and where in the startup routine a custom script should be run from in order to perform the necessary commands? I'd like to rid myself of using interface aliases if at all possible. Regards, Steve From steve at ibctech.ca Tue Jun 17 00:26:42 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Tue Jun 17 00:26:44 2008 Subject: if_vlan subinterfaces at boot In-Reply-To: <4856FE0B.8030901@ibctech.ca> References: <4856FE0B.8030901@ibctech.ca> Message-ID: <48570503.2030608@ibctech.ca> > Is there any way to create, and assign addresses to a if_vlan > sub-interface (eg: em6.3) via rc.conf at boot? Sorry for the noise... cloned_interfaces="em6.3" ifconfig_em6.3="inet x.x.x.x netmask x.x.x.x" ...seems to be the job. Steve From brooks at freebsd.org Tue Jun 17 00:31:48 2008 From: brooks at freebsd.org (Brooks Davis) Date: Tue Jun 17 00:31:50 2008 Subject: if_vlan subinterfaces at boot In-Reply-To: <48570503.2030608@ibctech.ca> References: <4856FE0B.8030901@ibctech.ca> <48570503.2030608@ibctech.ca> Message-ID: <20080617003216.GA34683@lor.one-eyed-alien.net> On Mon, Jun 16, 2008 at 08:27:47PM -0400, Steve Bertrand wrote: >> Is there any way to create, and assign addresses to a if_vlan >> sub-interface (eg: em6.3) via rc.conf at boot? > > Sorry for the noise... > > cloned_interfaces="em6.3" > ifconfig_em6.3="inet x.x.x.x netmask x.x.x.x" > > ...seems to be the job. Almost. '.' isn't a valid character in a shell variable. We support '.' by converting it into _ in shell variables so it should be: cloned_interfaces="em6.3" ifconfig_em6_3="inet x.x.x.x netmask x.x.x.x" -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080617/301e7b55/attachment.pgp From steve at ibctech.ca Tue Jun 17 00:42:57 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Tue Jun 17 00:43:00 2008 Subject: if_vlan subinterfaces at boot In-Reply-To: <20080617003216.GA34683@lor.one-eyed-alien.net> References: <4856FE0B.8030901@ibctech.ca> <48570503.2030608@ibctech.ca> <20080617003216.GA34683@lor.one-eyed-alien.net> Message-ID: <485708D1.7060401@ibctech.ca> Brooks Davis wrote: > On Mon, Jun 16, 2008 at 08:27:47PM -0400, Steve Bertrand wrote: >>> Is there any way to create, and assign addresses to a if_vlan >>> sub-interface (eg: em6.3) via rc.conf at boot? >> Sorry for the noise... >> >> cloned_interfaces="em6.3" >> ifconfig_em6.3="inet x.x.x.x netmask x.x.x.x" >> >> ...seems to be the job. > > Almost. '.' isn't a valid character in a shell variable. We support '.' by > converting it into _ in shell variables so it should be: > > cloned_interfaces="em6.3" > ifconfig_em6_3="inet x.x.x.x netmask x.x.x.x" Thanks Brooks for the feedback. I was just about to do a reboot with my config before I caught your message. I'll update the config and run with it. While perusing the 'net in order to try to find a solution prior to posting, I came across a couple of other posts (I can't remember if it was specific to this list) in which the recommendation appeared to be incorrect for this exact setup I desired (ie: the recommendation failed miserably). I'll post back with the results in case anyone else here has been interested in 'Cisco style' (as I for some reason refer to them as) sub-ints on FreeBSD. Steve From steve at ibctech.ca Tue Jun 17 01:21:28 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Tue Jun 17 01:21:32 2008 Subject: if_vlan subinterfaces at boot In-Reply-To: <485708D1.7060401@ibctech.ca> References: <4856FE0B.8030901@ibctech.ca> <48570503.2030608@ibctech.ca> <20080617003216.GA34683@lor.one-eyed-alien.net> <485708D1.7060401@ibctech.ca> Message-ID: <485711D8.70308@ibctech.ca> Steve Bertrand wrote: > Brooks Davis wrote: >> On Mon, Jun 16, 2008 at 08:27:47PM -0400, Steve Bertrand wrote: >>>> Is there any way to create, and assign addresses to a if_vlan >>>> sub-interface (eg: em6.3) via rc.conf at boot? > I'll post back with the results in case anyone else here has been > interested in 'Cisco style' (as I for some reason refer to them as) > sub-ints on FreeBSD. # cat /etc/rc.conf (snipped for brevity) cloned_interfaces="em6.7" ifconfig_em6_7="inet6 2607:f118:ddc0:8000::e19" # reboot # ifconfig (again, snipped for brevity) em6: flags=8802 mtu 1500 options=b ether 00:60:e0:42:b1:7c media: Ethernet autoselect (1000baseTX ) status: active em6.7: flags=8843 mtu 1500 inet6 2607:f118:ddc0:8000::e19 prefixlen 64 ether 00:60:e0:42:b1:7c media: Ethernet autoselect (1000baseTX ) status: active vlan: 7 parent interface: em6 ----- Now, my next question is, can I have interface em6.7 operate on multiple vlans? ie, change the default behavior of the if_vlan interface's implicit designation to only vlan 7? I want to have multiple prefixes (ie: subnets) within a single broadcast domain, but each prefix on its own sub-interface on the FreeBSD box, without designating a VLAN for each. (Please forgive the IPv6 test above, as it probably misguides my efforts... my tests at this point are purely to *hopefully* meet an IPv4 conceptual design goal). Is this possible? Steve From brooks at freebsd.org Tue Jun 17 04:46:38 2008 From: brooks at freebsd.org (Brooks Davis) Date: Tue Jun 17 04:46:45 2008 Subject: if_vlan subinterfaces at boot In-Reply-To: <485711D8.70308@ibctech.ca> References: <4856FE0B.8030901@ibctech.ca> <48570503.2030608@ibctech.ca> <20080617003216.GA34683@lor.one-eyed-alien.net> <485708D1.7060401@ibctech.ca> <485711D8.70308@ibctech.ca> Message-ID: <20080617044706.GA36170@lor.one-eyed-alien.net> On Mon, Jun 16, 2008 at 09:22:32PM -0400, Steve Bertrand wrote: > Steve Bertrand wrote: >> Brooks Davis wrote: > >>> On Mon, Jun 16, 2008 at 08:27:47PM -0400, Steve Bertrand wrote: >>>>> Is there any way to create, and assign addresses to a if_vlan >>>>> sub-interface (eg: em6.3) via rc.conf at boot? > >> I'll post back with the results in case anyone else here has been >> interested in 'Cisco style' (as I for some reason refer to them as) >> sub-ints on FreeBSD. > > # cat /etc/rc.conf (snipped for brevity) > > cloned_interfaces="em6.7" > ifconfig_em6_7="inet6 2607:f118:ddc0:8000::e19" > > # reboot > > # ifconfig (again, snipped for brevity) > > em6: flags=8802 mtu 1500 > options=b > ether 00:60:e0:42:b1:7c > media: Ethernet autoselect (1000baseTX ) > status: active > > em6.7: flags=8843 mtu 1500 > inet6 2607:f118:ddc0:8000::e19 prefixlen 64 > ether 00:60:e0:42:b1:7c > media: Ethernet autoselect (1000baseTX ) > status: active > vlan: 7 parent interface: em6 > > ----- > > Now, my next question is, can I have interface em6.7 operate on multiple > vlans? ie, change the default behavior of the if_vlan interface's implicit > designation to only vlan 7? > > I want to have multiple prefixes (ie: subnets) within a single broadcast > domain, but each prefix on its own sub-interface on the FreeBSD box, > without designating a VLAN for each. (Please forgive the IPv6 test above, > as it probably misguides my efforts... my tests at this point are purely to > *hopefully* meet an IPv4 conceptual design goal). > > Is this possible? Currently there's no easy way to assign multiple interfaces for the same broadcast domain. In theory, if you could create some sort of virtual ethernet device you could bridge one to the real interface for each subnet. I don't think we have such a device in the tree at the moment, but I don't think they are very hard to create in principle. -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080617/0132c7e8/attachment.pgp From steve at ibctech.ca Tue Jun 17 06:08:34 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Tue Jun 17 06:08:38 2008 Subject: if_vlan subinterfaces at boot In-Reply-To: <20080617044706.GA36170@lor.one-eyed-alien.net> References: <4856FE0B.8030901@ibctech.ca> <48570503.2030608@ibctech.ca> <20080617003216.GA34683@lor.one-eyed-alien.net> <485708D1.7060401@ibctech.ca> <485711D8.70308@ibctech.ca> <20080617044706.GA36170@lor.one-eyed-alien.net> Message-ID: <48575520.708@ibctech.ca> Brooks Davis wrote: > On Mon, Jun 16, 2008 at 09:22:32PM -0400, Steve Bertrand wrote: >> Steve Bertrand wrote: >>> Brooks Davis wrote: >>>> On Mon, Jun 16, 2008 at 08:27:47PM -0400, Steve Bertrand wrote: >>>>>> Is there any way to create, and assign addresses to a if_vlan >>>>>> sub-interface (eg: em6.3) via rc.conf at boot? >> Now, my next question is, can I have interface em6.7 operate on multiple >> vlans? ie, change the default behavior of the if_vlan interface's implicit >> designation to only vlan 7? >> >> I want to have multiple prefixes (ie: subnets) within a single broadcast >> domain, but each prefix on its own sub-interface on the FreeBSD box, >> without designating a VLAN for each. (Please forgive the IPv6 test above, >> as it probably misguides my efforts... my tests at this point are purely to >> *hopefully* meet an IPv4 conceptual design goal). >> >> Is this possible? > > Currently there's no easy way to assign multiple interfaces for the same > broadcast domain. In theory, if you could create some sort of virtual > ethernet device you could bridge one to the real interface for each > subnet. I don't think we have such a device in the tree at the moment, > but I don't think they are very hard to create in principle. Brooks, et-al, I am attempting to simulate (at this point) relatively basic Cisco router capabilities with the complete understanding that FreeBSD is an OS and can NOT be used as-is for Cisco emulation. My conceptual tests are in conjunction with the functionalities of Quagga routing suite. (Which, according to personal experience with it's implementation and this thread: http://forums.whirlpool.net.au/forum-replies-archive.cfm/335988.html ...is not/can not be taken as a Cisco simulator/emulator in any form). Quagga does (IMHO) a relatively decent job of making it easy to transition from production Cisco gear to USB thumbdrive bootable lab gear very quickly, running on commodity hardware. In theory (I am no where near an expert with FBSD network implementation), would it be possible to use the likes of if_bridge to undermine if_vlan interfaces? More importantly, has my request made any sense, and if so, does anyone else have interest in a specification for it? If so, how would one go about requesting such a specification/implementation? Does anyone else use this sort of setup, how do you do it currently? High level overview: - numerous physical interfaces - several logical (ie: subnets) per interface - each 'subnet' on each interface connected via sub-int (no vlan tags) - no implicit vlan designation, or; - the ability to create manual 'broadcast domain' subints - ability for an equivalent 'sw-acc vlan xx' on a sub-int directly to take it *out* of a default implied vlan (I haven't tested this) ...I know with the former I'm pretty well pushing the boundaries of what FreeBSD has ever been designed for, but I've known it to be robust in everything that it does, particularly to it's network stack. Anything I can and have thought about would depend on the implementation of the routing 'suite', and not FreeBSD in itself. Perhaps most of what I've asked about is out of scope, but I need to ask. If anyone can provide me with information on specific working groups or locations that I can directly obtain information for certain areas without disturbing the list, I would be appreciative. Currently, I am deeply focused on the above, and: - 7.0 and IPv6 jails - work/compliance within the scope of RFC 4861 & 4862 - implementation regarding RFC 3484 - how a user (granted, 'user' in this case fully understands that most all hands on deck are not paid for their 'job') can find out when/if drafts are being considered: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-addr-select-ps-08.txt ...as one example. Steve From steve at ibctech.ca Tue Jun 17 07:38:24 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Tue Jun 17 07:38:26 2008 Subject: if_vlan subinterfaces at boot In-Reply-To: <48575520.708@ibctech.ca> References: <4856FE0B.8030901@ibctech.ca> <48570503.2030608@ibctech.ca> <20080617003216.GA34683@lor.one-eyed-alien.net> <485708D1.7060401@ibctech.ca> <485711D8.70308@ibctech.ca> <20080617044706.GA36170@lor.one-eyed-alien.net> <48575520.708@ibctech.ca> Message-ID: <48576A31.7040008@ibctech.ca> Steve Bertrand wrote: > Brooks Davis wrote: > If anyone can provide me with information on specific working groups or > locations that I can directly obtain information for certain areas > without disturbing the list, I would be appreciative. > > Currently, I am deeply focused on the above, and: > > - 7.0 and IPv6 jails > - work/compliance within the scope of RFC 4861 & 4862 > - implementation regarding RFC 3484 > - how a user (granted, 'user' in this case fully understands that most > all hands on deck are not paid for their 'job') can find out when/if > drafts are being considered: > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-addr-select-ps-08.txt > I'd like to thank those who have emailed me off-list regarding my inquiries. I have been provided information regarding my general questions that large portions of certain specifications are either already in -current, or are in the process to be added to the tree. To those who responded: thank you. I'm ecstatic about implementing the new changes so I can compare them to the current standards and I-Ds. Nice to know that the underlying changes will aid in my IPv4 goals, but at the same time push forward my 'one small step' toward IPv6 compliance (even though I am still in a pocket). Steve From rea-fbsd at codelabs.ru Tue Jun 17 19:34:42 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Tue Jun 17 19:34:46 2008 Subject: Web100 port for FreeBSD Message-ID: <4GPbuliH1uAXi1/ssQ4h5J0HJ3g@EEu6nkWAZTlxOp7ENdKMY8AImHg> Good day. I had found some references to the old SoC project on porting Web100 Linux kernel patches to FreeBSD. It was said in the 2003 that some person was trying to push this activity, but the given link is dead: http://osdir.com/ml/freebsd.devel.net/2003-02/msg00134.html Were there any working patches or anything alike? Thanks! -- Eygene From dave at pioneerspirits.com Tue Jun 17 20:58:30 2008 From: dave at pioneerspirits.com (Dave Robison) Date: Tue Jun 17 20:58:33 2008 Subject: NAT crashing FreeBSD 7.x Message-ID: <48582132.7040103@pioneerspirits.com> Hiya, I posted this to -questions but didn't get any responses so I'm posting it again here. I'm having problems with NAT crashing my FreeBSD box. This never happened in 6.x but in 7.x it's predictable for me. Any time I use either of my two NICs for my internal net my FreeBSD box hangs and requires power cycling to reboot. My guess is that some option changed between 6.x and 7.x and I simply missed it, or that I have something configured completely improperly, but after hours of tinkering I've yet to fix the problem. Initially I figured it might be NAT in PPP which was causing the problem, so I backed it out and used NATD but the same thing happens to me. uname info: 7.0-STABLE FreeBSD 7.0-STABLE #0: Sun Jun 15 21:35:13 PDT 2008 my ipfw rules: 00100 0 0 check-state 00200 1678471 126337051 skipto 3000 ip from any to 69.229.113.78 in recv tun0 00210 0 0 deny log ip from any to any in recv vr0 03000 61 4548 divert 8668 ip from any to any via fxp0 03100 0 0 deny ip from 192.168.32.0/24 to any in recv vr0 *snip* My FreeBSD box runs PPP on vr0 and my lan runs on fxp0. I've switched them and the freeze-up continues. The host on my LAN is 192.168.32.10, my internal interface is 192.168.32.1 and my external interface is 69.229.113.78. my /usr/local/etc/natd.conf: #unregistered_only #log_ipfw_denied redirect_address 192.168.32.10 69.229.113.74 #punch_fw 25:50 interface fxp0 I commented out a few lines to test it bare-bones. No luck. I added these to my kernel config, which is otherwise a very standard GENERIC kernel config: options IPFIREWALL options IPDIVERT the related entries from /etc/rc.conf: ppp_enable="YES" ppp_mode="ddial" ppp_nat="NO" ppp_profile="sbc" gateway_enable="YES" my /etc/ppp/ppp.conf: default: set log Phase Chat LCP IPCP CCP tun command set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 192.168.32.0/24 sbc: set device PPPoE:vr0 set authname MYUSERNAME@sbcglobal.net set authkey MYPASSWORD set dial set login set mru 1492 set mtu 1492 accept lqr set crtscts off set speed sync enable dns add default HISADDR set log Phase Chat LCP IPCP CCP tun command set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 192.168.0.0/16 # NAT # nat enable yes nat log no # nat same_ports yes # nat unregistered_only yes nat addr 192.168.32.10 69.229.113.73 Again, NAT is turned off in PPP at the moment and I'm using /sbin/natd Machine connects to the net and works great until I try to use the LAN. the LAN works for a few seconds, maybe serving up a web page or two and then...freeze up. The box will keep running for days until I use the LAN at which point it freezes solid. I never saw the machine recover from this situation though there is a crash dump in /var/crash from late last night after I wasn't paying attention: # ls -lart /var/crash total 218618 -rw-r--r-- 1 root wheel 5 Feb 24 09:53 minfree drwxr-xr-x 25 root wheel 512 Jun 15 23:12 .. -rw------- 1 root wheel 462 Jun 15 23:12 info.0 -rw-r--r-- 1 root wheel 2 Jun 15 23:12 bounds drwxr-x--- 2 root wheel 512 Jun 15 23:12 . -rw------- 1 root wheel 225533952 Jun 15 23:12 vmcore.0 here is my dmesg: Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-STABLE #0: Sun Jun 15 21:35:13 PDT 2008 root@bigshed.com:/usr/obj/usr/src/sys/bigshed Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Sempron(tm) 3000+ (1999.79-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x6a0 Stepping = 0 Features=0x383fbff AMD Features=0xc0480800 real memory = 2080309248 (1983 MB) avail memory = 2025955328 (1932 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7bef0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 agp0: aperture size is 64M pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: mem 0xe4000000-0xe7ffffff,0xe8000000-0xe8ffffff irq 16 at device 0.0 on pci1 fxp0: port 0x9000-0x901f mem 0xeb100000-0xeb100fff,0xeb000000-0xeb0fffff irq 16 at device 8.0 on pci0 miibus0: on fxp0 nsphy0: PHY 1 on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:a0:c9:22:97:b4 fxp0: [ITHREAD] pci0: at device 11.0 (no driver attached) atapci0: port 0x9800-0x9807,0x9c00-0x9c03,0xa000-0xa007,0xa400-0xa403,0xa800-0xa80f,0xac00-0xacff irq 20 at device 15.0 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xb000-0xb00f at device 15.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] ata1: on atapci1 ata1: [ITHREAD] uhci0: port 0xb400-0xb41f at device 16.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xb800-0xb81f at device 16.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xbc00-0xbc1f at device 16.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xc000-0xc01f at device 16.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xeb102000-0xeb1020ff at device 16.4 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered isab0: at device 17.0 on pci0 isa0: on isab0 vr0: port 0xc800-0xc8ff mem 0xeb103000-0xeb1030ff irq 23 at device 18.0 on pci0 vr0: Quirks: 0x0 vr0: Revision: 0x78 miibus1: on vr0 ukphy0: PHY 1 on miibus1 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: Ethernet address: 00:00:00:00:00:10 vr0: [ITHREAD] acpi_tz0: on acpi0 acpi_tz0: _PSV value is absurd, ignored (-247.7C) acpi_tz0: _ACx value is absurd, ignored (-265.7C) sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] pmtimer0 on isa0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ugen0: on uhub1 umass0: on uhub3 Timecounter "TSC" frequency 1999790840 Hz quality 800 Timecounters tick every 1.000 msec ipfw2 initialized, divert enabled, nat loadable, rule-based forwarding disabled, default to deny, logging disabled acpi_tz0: _PSV value is absurd, ignored (-247.7C) acpi_tz0: _ACx value is absurd, ignored (-265.7C) acpi_tz0: _PSV value is absurd, ignored (-247.7C) acpi_tz0: _ACx value is absurd, ignored (-265.7C) acd0: CDRW at ata1-master UDMA33 ad4: 190782MB at ata2-master SATA150 ad6: 238475MB at ata3-master SATA150 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present da1 at umass-sim0 bus 0 target 0 lun 1 da1: Removable Direct Access SCSI-0 device da1: 1.000MB/s transfers da1: Attempt to query device size failed: NOT READY, Medium not present da2 at umass-sim0 bus 0 target 0 lun 2 da2: Removable Direct Access SCSI-0 device da2: 1.000MB/s transfers da2: Attempt to query device size failed: NOT READY, Medium not present da3 at umass-sim0 bus 0 target 0 lun 3 da3: Removable Direct Access SCSI-0 device da3: 1.000MB/s transfers da3: Attempt to query device size failed: NOT READY, Medium not present Trying to mount root from ufs:/dev/ad4s1a WARNING: / was not properly dismounted WARNING: /tmp was not properly dismounted WARNING: /var was not properly dismounted /var: mount pending error: blocks 12 files 3 WARNING: /disk2 was not properly dismounted WARNING: attempt to net_add_domain(netgraph) after domainfinalize() fxp0: link state changed to UP vr0: link state changed to UP any help, hints, clues or just a simple "how could you be so dumb, the answer is x..." would be greatly appreciated. Thanks for taking the time to read and consider this. Dave From crapsh at monkeybrains.net Tue Jun 17 21:27:11 2008 From: crapsh at monkeybrains.net (Rudy) Date: Tue Jun 17 21:27:16 2008 Subject: Seeking help understanding my "emX: watchdog timeout" messages In-Reply-To: <48535A11.4020003@monkeybrains.net> References: <20080516185813.H866@logos.sky.od.ua> <2a41acea0805160904g7dcf9f58rf69ca5d0612945cc@mail.gmail.com> <4853055C.2030303@MonkeyBrains.NET> <48535A11.4020003@monkeybrains.net> Message-ID: <48582C29.8030307@monkeybrains.net> I am getting these messages: Jun 17 08:53:14 example kernel: em2: watchdog timeout -- resetting Jun 17 08:53:14 example kernel: em2: link state changed to DOWN Jun 17 08:53:17 example kernel: em2: link state changed to UP Jun 17 11:07:38 example kernel: em2: watchdog timeout -- resetting Jun 17 11:07:38 example kernel: em2: link state changed to DOWN Jun 17 11:07:41 example kernel: em2: link state changed to UP on an interface that does about 100Mbps all day. [1] should I worry about it (only happens a couple of times a day)? [2] will setting dev.em.2.rx_int_delay help? couldn't find too much documentation on it... Best I could get: http://www.intel.com/support/network/sb/cs-009209.htm [3] what, in you best estimation, is causing these wathdog events? sysctl dev.em.2.stats=1 Jun 17 13:23:22 example kernel: em2: Excessive collisions = 0 Jun 17 13:23:22 example kernel: em2: Sequence errors = 0 Jun 17 13:23:22 example kernel: em2: Defer count = 0 Jun 17 13:23:22 example kernel: em2: Missed Packets = 81518 Jun 17 13:23:22 example kernel: em2: Receive No Buffers = 1226 Jun 17 13:23:22 example kernel: em2: Receive Length Errors = 0 Jun 17 13:23:22 example kernel: em2: Receive errors = 0 Jun 17 13:23:22 example kernel: em2: Crc errors = 0 Jun 17 13:23:22 example kernel: em2: Alignment errors = 0 Jun 17 13:23:22 example kernel: em2: Collision/Carrier extension errors = 0 Jun 17 13:23:22 example kernel: em2: RX overruns = 0 Jun 17 13:23:22 example kernel: em2: watchdog timeouts = 20 Jun 17 13:23:22 example kernel: em2: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK MSIX IRQ = 0 Jun 17 13:23:22 example kernel: em2: XON Rcvd = 0 Jun 17 13:23:22 example kernel: em2: XON Xmtd = 0 Jun 17 13:23:22 example kernel: em2: XOFF Rcvd = 0 Jun 17 13:23:22 example kernel: em2: XOFF Xmtd = 0 Jun 17 13:23:22 example kernel: em2: Good Packets Rcvd = 2515504832 Jun 17 13:23:22 example kernel: em2: Good Packets Xmtd = 4543057019 Jun 17 13:23:22 example kernel: em2: TSO Contexts Xmtd = 8 Jun 17 13:23:22 example kernel: em2: TSO Contexts Failed = 0 sysctl dev.em.2.debug=1 Jun 17 13:28:48 example kernel: em2: Adapter hardware address = 0xc4d91224 Jun 17 13:28:48 example kernel: em2: CTRL = 0x400c0241 RCTL = 0x8002 Jun 17 13:28:48 example kernel: em2: Packet buffer = Tx=16k Rx=32k Jun 17 13:28:48 example kernel: em2: Flow control watermarks high = 30720 low = 29220 Jun 17 13:28:48 example kernel: em2: tx_int_delay = 66, tx_abs_int_delay = 66 Jun 17 13:28:48 example kernel: em2: rx_int_delay = 0, rx_abs_int_delay = 66 Jun 17 13:28:48 example kernel: em2: fifo workaround = 0, fifo_reset_count = 0 Jun 17 13:28:48 example kernel: em2: hw tdh = 116, hw tdt = 116 Jun 17 13:28:48 example kernel: em2: hw rdh = 175, hw rdt = 174 Jun 17 13:28:48 example kernel: em2: Num Tx descriptors avail = 256 Jun 17 13:28:48 example kernel: em2: Tx Descriptors not avail1 = 20 Jun 17 13:28:48 example kernel: em2: Tx Descriptors not avail2 = 0 Jun 17 13:28:48 example kernel: em2: Std mbuf failed = 0 Jun 17 13:28:48 example kernel: em2: Std mbuf cluster failed = 0 Jun 17 13:28:48 example kernel: em2: Driver dropped packets = 0 Jun 17 13:28:48 example kernel: em2: Driver tx dma failure in encap = 0 sysctl dev.em.2 dev.em.2.%desc: Intel(R) PRO/1000 Network Connection 6.9.5 dev.em.2.%driver: em dev.em.2.%location: slot=0 function=0 dev.em.2.%pnpinfo: vendor=0x8086 device=0x10a4 subvendor=0x8086 subdevice=0x10a4 class=0x020000 dev.em.2.%parent: pci6 dev.em.2.debug: -1 dev.em.2.stats: -1 dev.em.2.rx_int_delay: 0 dev.em.2.tx_int_delay: 66 dev.em.2.rx_abs_int_delay: 66 dev.em.2.tx_abs_int_delay: 66 dev.em.2.rx_processing_limit: 100 Polling related sysctl settings: kern.polling.idlepoll_sleeping: 1 kern.polling.stalled: 82 kern.polling.suspect: 6266 kern.polling.phase: 0 kern.polling.enable: 1 kern.polling.handlers: 6 kern.polling.residual_burst: 0 kern.polling.pending_polls: 1 kern.polling.lost_polls: 371823 kern.polling.short_ticks: 4795 kern.polling.reg_frac: 20 kern.polling.user_frac: 33 kern.polling.idle_poll: 0 kern.polling.each_burst: 5 kern.polling.burst_max: 350 kern.polling.burst: 350 kern.clockrate: { hz = 2500, tick = 400, profhz = 1666, stathz = 333 } hadware is a quad Intel 1000 Pro PT card. Thanks!!!! Rudy From 4pr at legis.krsn.ru Wed Jun 18 15:20:04 2008 From: 4pr at legis.krsn.ru (4pr@legis.krsn.ru) Date: Wed Jun 18 15:20:12 2008 Subject: kern/122839: [multicast] FreeBSD 7 multicast routing problem Message-ID: <200806181520.m5IFK4B9066850@freefall.freebsd.org> The following reply was made to PR kern/122839; it has been noted by GNATS. From: 4pr@legis.krsn.ru To: bug-followup@FreeBSD.org, bms@FreeBSD.org, tomas@tutus.se, 4pr@legis.krsn.ru Cc: Subject: Re: kern/122839: [multicast] FreeBSD 7 multicast routing problem Date: Wed, 18 Jun 2008 22:47:37 +0800 --=_mixed 0051374DC725746C_= Content-Type: text/plain; charset="US-ASCII" Hello! Thanks for given ideas and your help! Using patch suggested by Tomas Svensson we have made our version of it: --- if_em.c.orig 2007-11-29 06:24:38.000000000 +0700 +++ if_em.c 2008-04-24 16:49:04.000000000 +0800 @@ -1080,7 +1080,7 @@ if (ifp->if_flags & IFF_UP) { if ((ifp->if_drv_flags & IFF_DRV_RUNNING)) { if ((ifp->if_flags ^ adapter->if_flags) & - IFF_PROMISC) { + (IFF_PROMISC | IFF_ALLMULTI)) { em_disable_promisc(adapter); em_set_promisc(adapter); } @@ -2379,12 +2379,14 @@ static void em_disable_promisc(struct adapter *adapter) { + struct ifnet *ifp = adapter->ifp; uint32_t reg_rctl; reg_rctl = E1000_READ_REG(&adapter->hw, E1000_RCTL); reg_rctl &= (~E1000_RCTL_UPE); - reg_rctl &= (~E1000_RCTL_MPE); + if (!(ifp->if_flags & IFF_ALLMULTI)) + reg_rctl &= (~E1000_RCTL_MPE); E1000_WRITE_REG(&adapter->hw, E1000_RCTL, reg_rctl); } Also we have made a patch for if_msk.c : --- if_msk.c.orig 2007-12-08 19:16:14.000000000 +0700 +++ if_msk.c 2008-04-24 17:51:02.000000000 +0800 @@ -558,11 +558,11 @@ bzero(mchash, sizeof(mchash)); mode = GMAC_READ_2(sc, sc_if->msk_port, GM_RX_CTRL); - mode |= GM_RXCR_UCF_ENA; if ((ifp->if_flags & (IFF_PROMISC | IFF_ALLMULTI)) != 0) { if ((ifp->if_flags & IFF_PROMISC) != 0) mode &= ~(GM_RXCR_UCF_ENA | GM_RXCR_MCF_ENA); else if ((ifp->if_flags & IFF_ALLMULTI) != 0) { + mode &= ~(GM_RXCR_MCF_ENA); mchash[0] = 0xffff; mchash[1] = 0xffff; } @@ -627,8 +627,12 @@ mode = GMAC_READ_2(sc, sc_if->msk_port, GM_RX_CTRL); if (ifp->if_flags & IFF_PROMISC) mode &= ~(GM_RXCR_UCF_ENA | GM_RXCR_MCF_ENA); - else + else { mode |= (GM_RXCR_UCF_ENA | GM_RXCR_MCF_ENA); + // ALLMULTI handling + if (ifp->if_flags & IFF_ALLMULTI) + mode &= ~(GM_RXCR_MCF_ENA); + } GMAC_WRITE_2(sc, sc_if->msk_port, GM_RX_CTRL, mode); } @@ -934,7 +938,7 @@ if ((ifp->if_flags & IFF_UP) != 0) { if ((ifp->if_drv_flags & IFF_DRV_RUNNING) != 0) { if (((ifp->if_flags ^ sc_if->msk_if_flags) - & IFF_PROMISC) != 0) { + & (IFF_PROMISC | IFF_ALLMULTI)) != 0) { msk_setpromisc(sc_if); msk_setmulti(sc_if); } Both patches solves for us described problem with multicast routing on FreeBSD7.0 But, if it is possible, as we are not too good with FreeBSD patching, cold somebody review and do a sanity check for our patches, just in case we have made a serios/simple mistekes? :) Thank you --=_mixed 0051374DC725746C_= Content-Type: application/octet-stream; name="if_em.c.diff" Content-Disposition: attachment; filename="if_em.c.diff" Content-Transfer-Encoding: base64 LS0tIGlmX2VtLmMub3JpZwkyMDA3LTExLTI5IDA2OjI0OjM4LjAwMDAwMDAwMCArMDcwMAorKysg aWZfZW0uYwkyMDA4LTA0LTI0IDE2OjQ5OjA0LjAwMDAwMDAwMCArMDgwMApAQCAtMTA4MCw3ICsx MDgwLDcgQEAKIAkJaWYgKGlmcC0+aWZfZmxhZ3MgJiBJRkZfVVApIHsKIAkJCWlmICgoaWZwLT5p Zl9kcnZfZmxhZ3MgJiBJRkZfRFJWX1JVTk5JTkcpKSB7CiAJCQkJaWYgKChpZnAtPmlmX2ZsYWdz IF4gYWRhcHRlci0+aWZfZmxhZ3MpICYKLQkJCQkgICAgSUZGX1BST01JU0MpIHsKKwkJCQkgICAg KElGRl9QUk9NSVNDIHwgSUZGX0FMTE1VTFRJKSkgewogCQkJCQllbV9kaXNhYmxlX3Byb21pc2Mo YWRhcHRlcik7CiAJCQkJCWVtX3NldF9wcm9taXNjKGFkYXB0ZXIpOwogCQkJCX0KQEAgLTIzNzks MTIgKzIzNzksMTQgQEAKIHN0YXRpYyB2b2lkCiBlbV9kaXNhYmxlX3Byb21pc2Moc3RydWN0IGFk YXB0ZXIgKmFkYXB0ZXIpCiB7CisJc3RydWN0IGlmbmV0CSppZnAgPSBhZGFwdGVyLT5pZnA7CiAJ dWludDMyX3QJcmVnX3JjdGw7CiAKIAlyZWdfcmN0bCA9IEUxMDAwX1JFQURfUkVHKCZhZGFwdGVy LT5odywgRTEwMDBfUkNUTCk7CiAKIAlyZWdfcmN0bCAmPSAgKH5FMTAwMF9SQ1RMX1VQRSk7Ci0J cmVnX3JjdGwgJj0gICh+RTEwMDBfUkNUTF9NUEUpOworCWlmICghKGlmcC0+aWZfZmxhZ3MgJiBJ RkZfQUxMTVVMVEkpKQorICAgIAkJcmVnX3JjdGwgJj0gICh+RTEwMDBfUkNUTF9NUEUpOwogCUUx MDAwX1dSSVRFX1JFRygmYWRhcHRlci0+aHcsIEUxMDAwX1JDVEwsIHJlZ19yY3RsKTsKIH0KIAo= --=_mixed 0051374DC725746C_= Content-Type: application/octet-stream; name="if_msk.c.diff" Content-Disposition: attachment; filename="if_msk.c.diff" Content-Transfer-Encoding: base64 LS0tIGlmX21zay5jLm9yaWcJMjAwNy0xMi0wOCAxOToxNjoxNC4wMDAwMDAwMDAgKzA3MDAKKysr IGlmX21zay5jCTIwMDgtMDQtMjQgMTc6NTE6MDIuMDAwMDAwMDAwICswODAwCkBAIC01NTgsMTEg KzU1OCwxMSBAQAogCiAJYnplcm8obWNoYXNoLCBzaXplb2YobWNoYXNoKSk7CiAJbW9kZSA9IEdN QUNfUkVBRF8yKHNjLCBzY19pZi0+bXNrX3BvcnQsIEdNX1JYX0NUUkwpOwotCW1vZGUgfD0gR01f UlhDUl9VQ0ZfRU5BOwogCWlmICgoaWZwLT5pZl9mbGFncyAmIChJRkZfUFJPTUlTQyB8IElGRl9B TExNVUxUSSkpICE9IDApIHsKIAkJaWYgKChpZnAtPmlmX2ZsYWdzICYgSUZGX1BST01JU0MpICE9 IDApCiAJCQltb2RlICY9IH4oR01fUlhDUl9VQ0ZfRU5BIHwgR01fUlhDUl9NQ0ZfRU5BKTsKIAkJ ZWxzZSBpZiAoKGlmcC0+aWZfZmxhZ3MgJiBJRkZfQUxMTVVMVEkpICE9IDApIHsKKwkJCW1vZGUg Jj0gfihHTV9SWENSX01DRl9FTkEpOwogCQkJbWNoYXNoWzBdID0gMHhmZmZmOwogCQkJbWNoYXNo WzFdID0gMHhmZmZmOwogCQl9CkBAIC02MjcsOCArNjI3LDEyIEBACiAJbW9kZSA9IEdNQUNfUkVB RF8yKHNjLCBzY19pZi0+bXNrX3BvcnQsIEdNX1JYX0NUUkwpOwogCWlmIChpZnAtPmlmX2ZsYWdz ICYgSUZGX1BST01JU0MpCiAJCW1vZGUgJj0gfihHTV9SWENSX1VDRl9FTkEgfCBHTV9SWENSX01D Rl9FTkEpOwotCWVsc2UKKwllbHNlIHsKIAkJbW9kZSB8PSAoR01fUlhDUl9VQ0ZfRU5BIHwgR01f UlhDUl9NQ0ZfRU5BKTsKKwkJLy8gQUxMTVVMVEkgaGFuZGxpbmcKKwkJaWYgKGlmcC0+aWZfZmxh Z3MgJiBJRkZfQUxMTVVMVEkpCisJCQltb2RlICY9IH4oR01fUlhDUl9NQ0ZfRU5BKTsKKwl9CiAJ R01BQ19XUklURV8yKHNjLCBzY19pZi0+bXNrX3BvcnQsIEdNX1JYX0NUUkwsIG1vZGUpOwogfQog CkBAIC05MzQsNyArOTM4LDcgQEAKIAkJaWYgKChpZnAtPmlmX2ZsYWdzICYgSUZGX1VQKSAhPSAw KSB7CiAJCQlpZiAoKGlmcC0+aWZfZHJ2X2ZsYWdzICYgSUZGX0RSVl9SVU5OSU5HKSAhPSAwKSB7 CiAJCQkJaWYgKCgoaWZwLT5pZl9mbGFncyBeIHNjX2lmLT5tc2tfaWZfZmxhZ3MpCi0JCQkJICAg ICYgSUZGX1BST01JU0MpICE9IDApIHsKKwkJCQkgICAgJiAoSUZGX1BST01JU0MgfCBJRkZfQUxM TVVMVEkpKSAhPSAwKSB7CiAJCQkJCW1za19zZXRwcm9taXNjKHNjX2lmKTsKIAkJCQkJbXNrX3Nl dG11bHRpKHNjX2lmKTsKIAkJCQl9Cg== --=_mixed 0051374DC725746C_=-- From kris at FreeBSD.org Wed Jun 18 15:32:05 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Wed Jun 18 15:32:08 2008 Subject: NAT crashing FreeBSD 7.x In-Reply-To: <48582132.7040103@pioneerspirits.com> References: <48582132.7040103@pioneerspirits.com> Message-ID: <48592A72.6050903@FreeBSD.org> Dave Robison wrote: > Hiya, > > I posted this to -questions but didn't get any responses so I'm posting > it again here. > > I'm having problems with NAT crashing my FreeBSD box. This never > happened in 6.x but in 7.x it's predictable for me. Any time I use > either of my two NICs for my internal net my FreeBSD box hangs and > requires power cycling to reboot. Take a look at the chapter on kernel debugging in the developers handbook. Add WITNESS to your kernel, then provoke the bug. If it doesn't catch any locking problems, follow the instructions about using DDB to collect debugging information. Kris From smithi at nimnet.asn.au Wed Jun 18 16:14:56 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Wed Jun 18 16:15:01 2008 Subject: Static NAT and PAT on 6.2 In-Reply-To: <1c01b5070806130659ufaa761ax18de48287c7064d1@mail.gmail.com> Message-ID: On Fri, 13 Jun 2008, Matt Brennan wrote: > Hi All, > > I am running FreeBSD 6.2-release. I have been running PAT via natd > and ipfw for some time now and it runs great. However, I continue to > try and employ static NAT on this router, and as soon as I do so all > other clients lose routing. My natd.conf is as below: > > unregistered_only > use_sockets > log_ipfw_denied > redirect_address 10.100.1.2 66.92.79.20 > alias_address 66.92.79.89 > > Whenever I run with this configuration all clients except the > static'ed one lose routing out of the building. I have tried switching > the order of the alias_address and redirect_address. Maybe folks need more information on your network topology; ifconfig, netstat -rn, say .. tcpdumps on the interface losing traffic? I haven't used redirect_address, but perhaps you need to specify target_address to disambiguate requests to other than alias_address? Stab in the dark, since it was my bright idea to refer you to -net :) cheers, Ian From martes at mgwigglesworth.com Wed Jun 18 17:03:10 2008 From: martes at mgwigglesworth.com (Martes G Wigglesworth) Date: Wed Jun 18 17:03:15 2008 Subject: Use lagg(4) or Use Layer-4 Load Balancing? Message-ID: <1213691523.22762.16.camel@localhost> Greetings all. I have been attempting to research what I have been informed is actually accomplished with layer-4 load balancing. I have seen many articles and reviews that indicate that lagg(4) will accomplish the teaming of multiple internet access sorces into a single logical pipe, however, I have tried this using a dumb switch two nic interfaces and this simply is not the case. Does anyone have any ideas of how to go about management of such a problem with reference to increasing bandwidth using multiple smaller sources to get the summation of all the sources as a logical backbone? As I said originally, I have now been informed that I would need a layer-4 solution, where lacp, and the lagg(4) driver work at the data link layer, hence the inclusion of a switch in virtually all examples that I have seen. I also would like to know why there is a "loadbalance" and "roundrobin" mode for the interface when there is neither an increase in bandwidth, nor, at least in loadbalance mode, any type of automatic aggretion of downed links. I am very new to this type of manipulation of using lagg, however, from my experience with it, there seems to be no real benefit to having the two modes listed above. They really seem to do nothing more than just spitt out the packets in a different way than fail-over and lacp, however, lacp would afford for all links to be used while using a 802.3ab compliant layer-2 device, so again, what exactly is the point of "roundrobin" and "loadbalance" when lacp should use all interfaces anyhow, and loadbalance doesn't even actually do what its name says? I am new and may not have enough cool equipment around, however, aside from using the fail-over mode for redundancy, and lacp on a supported switch, then if lagg(4) could really combine multiple sources into one for use as a larger overall backbone, then I should be able to get doulbed bandwidth using two separate ports on an unmanaged switch using some option on the lagg(4) driver, which is not the cast.(if this is wrong I would be happy to get the correct information, however I have a few network engineer references that say that you cannot do anything more than layer-2 lacp with appropriate equipment to create an isp-supported trunk) Even in the on-lamp interview the 7.0 developer implies that you can do what I am attempting to research however, it is not possible at layer 2 without an end-point. What is the real answer, and where should I look for further correct information about how to resolve this issue? (Create larger bandwidth backbone with smaller links summed together with some load balancing facility on freebsd) -- Martes G Wigglesworth M.G.Wigglesworth,LLC From thompsa at FreeBSD.org Wed Jun 18 17:20:57 2008 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Wed Jun 18 17:21:01 2008 Subject: Use lagg(4) or Use Layer-4 Load Balancing? In-Reply-To: <1213691523.22762.16.camel@localhost> References: <1213691523.22762.16.camel@localhost> Message-ID: <20080618172216.GA76058@citylink.fud.org.nz> On Tue, Jun 17, 2008 at 04:32:03AM -0400, Martes G Wigglesworth wrote: > Greetings all. > > I have been attempting to research what I have been informed is > actually accomplished with layer-4 load balancing. I have seen many > articles and reviews that indicate that lagg(4) will accomplish the > teaming of multiple internet access sorces into a single logical pipe, > however, I have tried this using a dumb switch two nic interfaces and > this simply is not the case. > > I am new and may not have enough cool equipment around, however, aside > from using the fail-over mode for redundancy, and lacp on a supported > switch, then if lagg(4) could really combine multiple sources into one > for use as a larger overall backbone, then I should be able to get > doulbed bandwidth using two separate ports on an unmanaged switch using > some option on the lagg(4) driver, which is not the cast.(if this is > wrong I would be happy to get the correct information, however I have a > few network engineer references that say that you cannot do anything > more than layer-2 lacp with appropriate equipment to create an > isp-supported trunk) Even in the on-lamp interview the 7.0 developer > implies that you can do what I am attempting to research however, it is > not possible at layer 2 without an end-point. How are you testing this? You need to have multiple IP flows in order to fully utilise the multiple links. See this snippet from the handbook (i'll put it in the man page too). "Since frame ordering is mandatory on Ethernet links then any traffic between two stations always flows over the same physical link limiting the maximum speed to that of one interface. The transmit algorithm attempts to use as much information as it can to distinguish different traffic flows and balance across the available interfaces." Does that answer your question, you will not get more speed on a single download. Andrew From biancalana at gmail.com Wed Jun 18 19:49:32 2008 From: biancalana at gmail.com (Alexandre Biancalana) Date: Wed Jun 18 19:49:35 2008 Subject: Use lagg(4) multiple switches Message-ID: <8e10486b0806181220y38fd0626qb88813a82f0eea5c@mail.gmail.com> Hi list, We have one machine with 3 nics configured with lagg(4). Each nic is connected to a different switch, but only one is in active mode. $ ifconfig -v lagg0 lagg0: flags=8843 metric 0 mtu 1500 options=19b ether 00:15:17:6f:f1:9e media: Ethernet autoselect status: active groups: lagg laggproto lacp lag id: [(8000,00-15-17-6F-F1-9E,00F0,0000,0000), (0001,00-1E-C9-86-9D-6F,0272,0000,0000)] laggport: local3 flags=1c state=3D [(8000,00-15-17-6F-F1-9E,00F0,8000,0001), (0001,00-1E-C9-86-9D-6F,0272,0001,0001)] laggport: local2 flags=18 state=3D [(8000,00-15-17-6F-F1-9E,00F0,8000,0003), (0001,00-1E-C9-86-9D-60,0272,0001,0001)] laggport: local1 flags=18 state=3D [(8000,00-15-17-6F-F1-9E,00F0,8000,0002), (0001,00-1E-4F-08-ED-3A,0272,0001,0001)] Is possible make all the nics work together ?? Att, From thompsa at FreeBSD.org Wed Jun 18 22:03:03 2008 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Wed Jun 18 22:03:07 2008 Subject: Use lagg(4) multiple switches In-Reply-To: <8e10486b0806181220y38fd0626qb88813a82f0eea5c@mail.gmail.com> References: <8e10486b0806181220y38fd0626qb88813a82f0eea5c@mail.gmail.com> Message-ID: <20080618220422.GB76058@citylink.fud.org.nz> On Wed, Jun 18, 2008 at 04:20:48PM -0300, Alexandre Biancalana wrote: > Hi list, > > We have one machine with 3 nics configured with lagg(4). Each nic is > connected to a different switch, but only one is in active mode. > > $ ifconfig -v lagg0 > lagg0: flags=8843 metric 0 mtu 1500 > options=19b > ether 00:15:17:6f:f1:9e > media: Ethernet autoselect > status: active > groups: lagg > laggproto lacp > lag id: [(8000,00-15-17-6F-F1-9E,00F0,0000,0000), > (0001,00-1E-C9-86-9D-6F,0272,0000,0000)] > laggport: local3 flags=1c state=3D > [(8000,00-15-17-6F-F1-9E,00F0,8000,0001), > (0001,00-1E-C9-86-9D-6F,0272,0001,0001)] > laggport: local2 flags=18 state=3D > [(8000,00-15-17-6F-F1-9E,00F0,8000,0003), > (0001,00-1E-C9-86-9D-60,0272,0001,0001)] > laggport: local1 flags=18 state=3D > [(8000,00-15-17-6F-F1-9E,00F0,8000,0002), > (0001,00-1E-4F-08-ED-3A,0272,0001,0001)] > > Is possible make all the nics work together ?? LACP can only work with one switch at a time. It will pick the path with the best priority/speed and will failover to a better path, but only one switch at a time. Andrew From auryn at zirakzigil.org Wed Jun 18 22:35:48 2008 From: auryn at zirakzigil.org (Giulio Ferro) Date: Wed Jun 18 22:35:51 2008 Subject: Problems with vlan + carp + alias Message-ID: <4859877A.3020300@zirakzigil.org> Scenario : freebsd 7.0 stable amd64 (compiled today), bce network interface Simply put, I'm trying to create multiple aliases on the same carp interface. I did this without vlans (on physical interfaces) and it always worked. Here's what I do: ---rc.conf ... ifconfig_bce0="inet 192.168.1.1 netmask 255.255.255.0" ifconfig_vlan10="inet 192.168.10.1 netmask 255.255.255.0 vlan 10 vlandev bce0" ifconfig_carp10="vhid 10 pass qweq 192.168.10.10 netmask 255.255.255.0" ifconfig_carp10_alias0="192.168.10.11 netmask 255.255.255.0" ifconfig_carp10_alias1="192.168.10.12 netmask 255.255.255.0" ifconfig_carp10_alias2="192.168.10.13 netmask 255.255.255.0" ifconfig_carp10_alias3="192.168.10.14 netmask 255.255.255.0" ifconfig_carp10_alias4="192.168.10.15 netmask 255.255.255.0" ifconfig_carp10_alias5="192.168.10.16 netmask 255.255.255.0" ifconfig_carp10_alias6="192.168.10.17 netmask 255.255.255.0" ifconfig_carp10_alias7="192.168.10.18 netmask 255.255.255.0" ifconfig_carp10_alias8="192.168.10.19 netmask 255.255.255.0" ifconfig_carp10_alias9="192.168.10.20 netmask 255.255.255.0" ... --- First of all, whenever I try to reload a carp configuration by /etc/rc.d/netif restart the system goes kernel panic. I always have to restart the server to load the new configuration. This is not the core of the problem, however. If I issue a ifconfig carp10 I can see all the aliases and the interface is in MASTER state. When I try to ping these addresses from another machine in the same vlan (10), I can only ping the vlan base address (192.168.10.10) and the first aliased address (192.168.10.11). All other aliases don't respond to external pings. If I try to inspect incoming packets with tcpdump : tcpdump -i vlan10 -n icmp I can see the packets coming in, but the other aliased addresses seem inactive. What is interesting is that an arp request actually takes places and is answered (all aliased ifs have the same mac address), but nobody respond to the ping but the first alias and the vlan base address. Does someone have any ideas? From hhw at pce-net.com Thu Jun 19 00:24:59 2008 From: hhw at pce-net.com (Han Hwei Woo) Date: Thu Jun 19 00:25:03 2008 Subject: Problems with vlan + carp + alias In-Reply-To: <4859877A.3020300@zirakzigil.org> References: <4859877A.3020300@zirakzigil.org> Message-ID: <4859A3A1.6070105@pce-net.com> Hi Giulio, Since the IP's are on the same subnet, you should try using a netmask of 255.255.255.255 on the aliases. Cheers, Han Hwei Woo Giulio Ferro wrote: > Scenario : freebsd 7.0 stable amd64 (compiled today), bce network > interface > > Simply put, I'm trying to create multiple aliases on the same carp > interface. > I did this without vlans (on physical interfaces) and it always worked. > > Here's what I do: > > ---rc.conf > ... > ifconfig_bce0="inet 192.168.1.1 netmask 255.255.255.0" > ifconfig_vlan10="inet 192.168.10.1 netmask 255.255.255.0 vlan 10 > vlandev bce0" > > ifconfig_carp10="vhid 10 pass qweq 192.168.10.10 netmask 255.255.255.0" > ifconfig_carp10_alias0="192.168.10.11 netmask 255.255.255.0" > ifconfig_carp10_alias1="192.168.10.12 netmask 255.255.255.0" > ifconfig_carp10_alias2="192.168.10.13 netmask 255.255.255.0" > ifconfig_carp10_alias3="192.168.10.14 netmask 255.255.255.0" > ifconfig_carp10_alias4="192.168.10.15 netmask 255.255.255.0" > ifconfig_carp10_alias5="192.168.10.16 netmask 255.255.255.0" > ifconfig_carp10_alias6="192.168.10.17 netmask 255.255.255.0" > ifconfig_carp10_alias7="192.168.10.18 netmask 255.255.255.0" > ifconfig_carp10_alias8="192.168.10.19 netmask 255.255.255.0" > ifconfig_carp10_alias9="192.168.10.20 netmask 255.255.255.0" > ... > --- > > First of all, whenever I try to reload a carp configuration by > /etc/rc.d/netif restart the system goes kernel panic. I always have > to restart the server to load the new configuration. This is not > the core of the problem, however. > > If I issue a > ifconfig carp10 > I can see all the aliases and the interface is in MASTER state. > > When I try to ping these addresses from another machine in the same > vlan (10), I can only ping the vlan base address (192.168.10.10) and the > first aliased address (192.168.10.11). All other aliases don't respond to > external pings. > > If I try to inspect incoming packets with tcpdump : > tcpdump -i vlan10 -n icmp > I can see the packets coming in, but the other aliased addresses seem > inactive. > > What is interesting is that an arp request actually takes places and > is answered > (all aliased ifs have the same mac address), but nobody respond to the > ping > but the first alias and the vlan base address. > > Does someone have any ideas? > > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From martes at mgwigglesworth.com Thu Jun 19 03:42:14 2008 From: martes at mgwigglesworth.com (Martes G Wigglesworth) Date: Thu Jun 19 03:42:50 2008 Subject: Use lagg(4) or Use Layer-4 Load Balancing? In-Reply-To: <20080618172216.GA76058@citylink.fud.org.nz> References: <1213691523.22762.16.camel@localhost> <20080618172216.GA76058@citylink.fud.org.nz> Message-ID: <1213846763.14151.1.camel@localhost> I was attempting to find good information on how to achieve a type of bonding using advanced routing on FreeBSD, such as with layer-4 routers, that can bond multiple sources into a single overall larger source for logical backbone creation for networks. On Wed, 2008-06-18 at 13:22 -0400, Andrew Thompson wrote: > On Tue, Jun 17, 2008 at 04:32:03AM -0400, Martes G Wigglesworth wrote: > > Greetings all. > > > > I have been attempting to research what I have been informed is > > actually accomplished with layer-4 load balancing. I have seen many > > articles and reviews that indicate that lagg(4) will accomplish the > > teaming of multiple internet access sorces into a single logical pipe, > > however, I have tried this using a dumb switch two nic interfaces and > > this simply is not the case. > > > > I am new and may not have enough cool equipment around, however, aside > > from using the fail-over mode for redundancy, and lacp on a supported > > switch, then if lagg(4) could really combine multiple sources into one > > for use as a larger overall backbone, then I should be able to get > > doulbed bandwidth using two separate ports on an unmanaged switch using > > some option on the lagg(4) driver, which is not the cast.(if this is > > wrong I would be happy to get the correct information, however I have a > > few network engineer references that say that you cannot do anything > > more than layer-2 lacp with appropriate equipment to create an > > isp-supported trunk) Even in the on-lamp interview the 7.0 developer > > implies that you can do what I am attempting to research however, it is > > not possible at layer 2 without an end-point. > > How are you testing this? You need to have multiple IP flows in order to > fully utilise the multiple links. See this snippet from the handbook > (i'll put it in the man page too). > > "Since frame ordering is mandatory on Ethernet links then any traffic > between two stations always flows over the same physical link limiting > the maximum speed to that of one interface. The transmit algorithm > attempts to use as much information as it can to distinguish different > traffic flows and balance across the available interfaces." > > > Does that answer your question, you will not get more speed on a single > download. > > > Andrew > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From auryn at zirakzigil.org Thu Jun 19 09:38:01 2008 From: auryn at zirakzigil.org (Giulio Ferro) Date: Thu Jun 19 09:38:07 2008 Subject: Problems with vlan + carp + alias In-Reply-To: <4859A3A1.6070105@pce-net.com> References: <4859877A.3020300@zirakzigil.org> <4859A3A1.6070105@pce-net.com> Message-ID: <485A28ED.9020103@zirakzigil.org> Han Hwei Woo wrote: > Hi Giulio, > > Since the IP's are on the same subnet, you should try using a netmask > of 255.255.255.255 on the aliases. > Hi Han, Sorry no, changing the mask to 255.255.255.255 of the aliases doesn't change the situation. Anyway exactly the same configuration works with non-vlan physical interfaces. Note: I can ping the aliased addresses on the local machine; I can't ping those addresses from other machine on the same vlan. Giulio. From remko at FreeBSD.org Thu Jun 19 10:30:04 2008 From: remko at FreeBSD.org (remko@FreeBSD.org) Date: Thu Jun 19 10:30:06 2008 Subject: kern/124753: net80211 discards power-save queue packets early Message-ID: <200806191030.m5JAU36i027140@freefall.freebsd.org> Synopsis: net80211 discards power-save queue packets early Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Thu Jun 19 10:29:47 UTC 2008 Responsible-Changed-Why: reassign to networking team. http://www.freebsd.org/cgi/query-pr.cgi?pr=124753 From primeroz.lists at googlemail.com Thu Jun 19 10:46:18 2008 From: primeroz.lists at googlemail.com (Primeroz lists) Date: Thu Jun 19 10:46:21 2008 Subject: Problems with vlan + carp + alias In-Reply-To: <485A28ED.9020103@zirakzigil.org> References: <4859877A.3020300@zirakzigil.org> <4859A3A1.6070105@pce-net.com> <485A28ED.9020103@zirakzigil.org> Message-ID: <55b8c6fe0806190330p225ec6d1g65f8424efeab9b41@mail.gmail.com> Hi , I think you should setup ALL the carp address as alias/32 , like this: ifconfig_carp10="vhid 10 pass qweq 192.168.10.10 netmask 255.255.255.255 " ifconfig_carp10_alias0="192.168.10.11 netmask 255.255.255.255 " ... ifconfig_carp10_aliasN="192.168.10.N netmask 255.255.255.255" and then please verify your routing table for everythin on 192.168.10 netstat -rn | grep 192.168.10 What you should have is 192.168.10/24 ...... vlan10 192.168.10.10 .... carp10 ... 192.168.10.N .... carp10 this is because the NETWORK range should be routed always through the parent interface (vlan10 in this case) while all the carp addresses has to be threated as alias. if you check now probably you will find that the 192.168.10/24 is routed through your carp interface ... and that's wrong. Ciao Francesco On Thu, Jun 19, 2008 at 10:37 AM, Giulio Ferro wrote: > Han Hwei Woo wrote: > >> Hi Giulio, >> >> Since the IP's are on the same subnet, you should try using a netmask of >> 255.255.255.255 on the aliases. >> >> > Hi Han, > Sorry no, changing the mask to 255.255.255.255 of the aliases doesn't > change the situation. > Anyway exactly the same configuration works with non-vlan physical > interfaces. > > Note: I can ping the aliased addresses on the local machine; I can't ping > those addresses from > other machine on the same vlan. > > > Giulio. > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From auryn at zirakzigil.org Thu Jun 19 11:06:58 2008 From: auryn at zirakzigil.org (Giulio Ferro) Date: Thu Jun 19 11:07:02 2008 Subject: Problems with vlan + carp + alias In-Reply-To: <55b8c6fe0806190330p225ec6d1g65f8424efeab9b41@mail.gmail.com> References: <4859877A.3020300@zirakzigil.org> <4859A3A1.6070105@pce-net.com> <485A28ED.9020103@zirakzigil.org> <55b8c6fe0806190330p225ec6d1g65f8424efeab9b41@mail.gmail.com> Message-ID: <485A3DC6.2030500@zirakzigil.org> Primeroz lists wrote: > Hi , > > I think you should setup ALL the carp address as alias/32 , like this: > > ifconfig_carp10="vhid 10 pass qweq 192.168.10.10 > netmask 255.255.255.255 " > ifconfig_carp10_alias0="192.168.10.11 netmask > 255.255.255.255 " > ... > ifconfig_carp10_aliasN="192.168.10.N netmask 255.255.255.255 > " > > and then please verify your routing table for everythin on 192.168.10 > > netstat -rn | grep 192.168.10 > > What you should have is > > 192.168.10/24 ...... vlan10 > 192.168.10.10 .... carp10 > ... > 192.168.10.N .... carp10 > > this is because the NETWORK range should be routed always through the > parent interface (vlan10 in this case) while all the carp addresses > has to be threated as alias. > > if you check now probably you will find that the 192.168.10/24 is > routed through your carp interface ... and that's wrong. > > Ciao > Francesco > Hi Primeroz, thanks for your answer. I set all the carp interfaces, both base and alias, to the 255.255.255.255 netmask as you suggested. This is my netstat now: ... 192.168.10.0/24 link#11 UC 0 0 vlan10 192.168.10.254 link#11 UHLW 2 0 vlan10 192.168.10.10 192.168.10.10 UH 0 0 carp10 192.168.10.11 192.168.10.11 UH 0 0 carp10 192.168.10.12 192.168.10.12 UH 0 0 carp10 ... As you see, the 192.168.10.0/24 is routed through the vlan10 interface, and this should be correct. As before, I can ping 192.168.10.10, but not 192.168.10.11 and above. Could this be a bug of carp with alias interfaces? Thanks again. Giulio. From primeroz.lists at googlemail.com Thu Jun 19 11:17:16 2008 From: primeroz.lists at googlemail.com (Primeroz lists) Date: Thu Jun 19 11:17:19 2008 Subject: Problems with vlan + carp + alias In-Reply-To: <485A3DC6.2030500@zirakzigil.org> References: <4859877A.3020300@zirakzigil.org> <4859A3A1.6070105@pce-net.com> <485A28ED.9020103@zirakzigil.org> <55b8c6fe0806190330p225ec6d1g65f8424efeab9b41@mail.gmail.com> <485A3DC6.2030500@zirakzigil.org> Message-ID: <55b8c6fe0806190417r440045e6ncf6e99945c453f10@mail.gmail.com> What is tcpdump showing for ping on 192.168.10.11 ? can you see echo reply exiting vlan10 interface ? what if you try from your server to "ping -S 192.168.10.11 192.168.10.254" ? Hi Primeroz, thanks for your answer. > I set all the carp interfaces, both base and alias, to the 255.255.255.255netmask > as you suggested. > This is my netstat now: > > ... > 192.168.10.0/24 link#11 UC 0 0 vlan10 > 192.168.10.254 link#11 UHLW 2 0 vlan10 > 192.168.10.10 192.168.10.10 UH 0 0 carp10 > 192.168.10.11 192.168.10.11 UH 0 0 carp10 > 192.168.10.12 192.168.10.12 UH 0 0 carp10 > ... > > As you see, the 192.168.10.0/24 is routed through the vlan10 interface, > and this should be correct. > > As before, I can ping 192.168.10.10, but not 192.168.10.11 and above. > > Could this be a bug of carp with alias interfaces? > > Thanks again. > Giulio. > From tony at crosswinds.net Thu Jun 19 12:03:24 2008 From: tony at crosswinds.net (Tony Holmes) Date: Thu Jun 19 12:03:31 2008 Subject: SCP/SFTP Brain Fart Message-ID: <20080619114541.GA9804@crosswinds.net> Ok, I'm having a n00b moment here. I have jails and dedicated servers set up with various FreeBSD flavours (4.11, 6.2, 7) on i386 and amd64. Some systems I have no problems with scp/sftping to. Others I get this: tony@devel ~ 7:49am > scp foo.tar.gz tony@admin:~/ Password: stty: stdin isn't a terminal Exit 1 Exit 1 I get this across all the flavours/archs so it appears to be a setup/config issue. I've compared ssh configs with the working systems, but I see nothing and am stymied. Tried googling and no luck finding any answers so I am now pleading for someone to help me and give me the pointy hat :) -- Tony Holmes Ph: (416) 993-1219 Founder and Senior Systems Architect Crosswinds Internet Communications Inc. From tony at crosswinds.net Thu Jun 19 13:43:38 2008 From: tony at crosswinds.net (Tony Holmes) Date: Thu Jun 19 13:43:43 2008 Subject: SCP/SFTP Brain Fart In-Reply-To: <200806191335.m5JDZheF081044@lurza.secnetix.de> References: <20080619114541.GA9804@crosswinds.net> <200806191335.m5JDZheF081044@lurza.secnetix.de> Message-ID: <20080619134338.GA11325@crosswinds.net> > It seems that your shell profile executes stty(1) even > for non-interactive shells. That is wrong. Make sure > that you shell profiles and rc files do not call stty > or produce any output for non-interactive sessions. > Such output confuses scp. So obvious! The offender: .login stty erase  This was a carry over from ages ago when my chosen terminal s/w didn't support the backspace mapping. Thank you and I will bear the pointy hat proudly! -- Tony Holmes Ph: (416) 993-1219 Founder and Senior Systems Architect Crosswinds Internet Communications Inc. From sepherosa at gmail.com Thu Jun 19 13:50:26 2008 From: sepherosa at gmail.com (Sepherosa Ziehau) Date: Thu Jun 19 13:50:28 2008 Subject: kern/124753: net80211 discards power-save queue packets early In-Reply-To: <200806191030.m5JAU36i027140@freefall.freebsd.org> References: <200806191030.m5JAU36i027140@freefall.freebsd.org> Message-ID: On Thu, Jun 19, 2008 at 6:30 PM, wrote: > Synopsis: net80211 discards power-save queue packets early > > Responsible-Changed-From-To: freebsd-i386->freebsd-net > Responsible-Changed-By: remko > Responsible-Changed-When: Thu Jun 19 10:29:47 UTC 2008 > Responsible-Changed-Why: > reassign to networking team. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=124753 In How-To-Repeat, you said: "Then associate a recent Windows Mobile 6.1 device to the FreeBSD box running hostapd ..." In Description, you said: "The WM6.1 device recv ps-poll's for packets every 20 seconds ..." AFAIK, STA sends ps-poll to AP; AP does not send ps-poll to STA. Why did your windows STA receive ps-poll from freebsd AP? Did you capture it by using 802.11 tap? And which freebsd driver were you using? Your problem looks like: - Either freebsd AP did not properly configure TIM in beacons, which could be easily found out by using 802.11 tap. But I highly suspect if you were using ath(4), TIM would be misconfigured. - Or your windows STA didn't process TIM according to 802.11 standard. Best Regards, sephe -- Live Free or Die From olli at lurza.secnetix.de Thu Jun 19 14:07:46 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Thu Jun 19 14:07:49 2008 Subject: SCP/SFTP Brain Fart In-Reply-To: <20080619114541.GA9804@crosswinds.net> Message-ID: <200806191335.m5JDZheF081044@lurza.secnetix.de> Tony Holmes wrote: > I have jails and dedicated servers set up with various FreeBSD flavours > (4.11, 6.2, 7) on i386 and amd64. > > Some systems I have no problems with scp/sftping to. Others I get this: > > tony@devel ~ > 7:49am > scp foo.tar.gz tony@admin:~/ > Password: > stty: stdin isn't a terminal > Exit 1 > Exit 1 > > I get this across all the flavours/archs so it appears to be a setup/config > issue. I've compared ssh configs with the working systems, but I see nothing > and am stymied. It seems that your shell profile executes stty(1) even for non-interactive shells. That is wrong. Make sure that you shell profiles and rc files do not call stty or produce any output for non-interactive sessions. Such output confuses scp. That is, when you enter this command: $ ssh tony@admin true | hd then you should not get any output from it. If you do get output, you need to fix your shell profile on the remote host. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind." -- Alan Kay, OOPSLA '97 From olli at lurza.secnetix.de Thu Jun 19 14:35:08 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Thu Jun 19 14:35:12 2008 Subject: CARP + multiple addresses In-Reply-To: <20080612191905.GK84454@server.vk2pj.dyndns.org> Message-ID: <200806191435.m5JEZ4xs083455@lurza.secnetix.de> Peter Jeremy wrote: > On 2008-Jun-12 17:26:25 +0200, Oliver Fromme wrote: > > So far it seems to work fine with CARP, but now it turned > > out that I need another address from a different subnet > > which also needs to access the database. What's the best > > way to do that? Add a second IP address to the existing > > carp interface, or create a new carp interface? Are there > > any pros and cons? > > I'm currently working towards something like this and intending to > have one CARP interface for each VLAN. What's the advantage of doing that, compared to putting all addresses on the same CARP interface? Meanwhile, in another thread on the -net list someone reported that there seems to be a bug when you put multiple VLANs on the same CARP inetrface. So that would be a good reason not to do it. > > And now I need to add an IP address from vlan202 which > > also needs to access the same database. I'm inclined to > > add 10.1.202.40/32 vhid 1 to the existing carp0 on both > > servers. I assume that the CARP interface goes to BACKUP > > when *any* of its IP addresses fail, right? Can anybody > > confirm this, please? > > My reading of the various documentation says that you are on the right > track but, by default, each CARP interface will fail over > independently. If you want them all to fail over together then you > should set net.inet.carp.preempt (see carp(4) and its first example) I've read it, but the problem is that I do not want the hosts to preempt each other. That's why I need to run with that sysctl off. However, if there are two CARP interfaces, and their VLANs are configured on the same physical interface (e.g. bge0), then they should always fail at the same time anyway, right? i.e. when bge0 goes down, both VLAN interfaces go down, so both CARP interfaces should switch to the other host. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "I have stopped reading Stephen King novels. Now I just read C code instead." -- Richard A. O'Keefe From olli at lurza.secnetix.de Thu Jun 19 15:04:46 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Thu Jun 19 15:05:05 2008 Subject: SCP/SFTP Brain Fart In-Reply-To: <20080619134338.GA11325@crosswinds.net> Message-ID: <200806191503.m5JF3QPW084849@lurza.secnetix.de> Tony Holmes wrote: > > It seems that your shell profile executes stty(1) even > > for non-interactive shells. That is wrong. Make sure > > that you shell profiles and rc files do not call stty > > or produce any output for non-interactive sessions. > > Such output confuses scp. > > So obvious! > > The offender: > > .login > > stty erase ^H > > This was a carry over from ages ago when my chosen terminal s/w didn't > support the backspace mapping. Ah, so you use csh or tcsh. The execution of profiles is somewhat broken in (t)csh, there is no separation between interactive and non-interactive shells. You can keep the stty statement in your .login file if you put it int oa conditional, like this: if ($?prompt) then stty erase ^H endif That works because the variable $prompt is unset for non- interactive (t)csh sessions. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "The last good thing written in C was Franz Schubert's Symphony number 9." -- Erwin Dieterich From if at xip.at Thu Jun 19 16:15:59 2008 From: if at xip.at (Ingo Flaschberger) Date: Thu Jun 19 16:16:03 2008 Subject: CARP + multiple addresses In-Reply-To: <200806191435.m5JEZ4xs083455@lurza.secnetix.de> References: <200806191435.m5JEZ4xs083455@lurza.secnetix.de> Message-ID: Hi, problems with carp: *) freebsd only allows 1 route -> with a routing-protocol at the ucarp-machine carp can not add the 2nd own route *) carp can/could not use more than 1 subnet *) carp can/could not bind to an interface *) in a router environment carp fails to add routes ... I decided to use ucarp but needed to modify it. see attached patch / scripts. I use ucarp now since 3 months in production. Kind regards, ingo flaschberger geschaeftsleitung --------------------------- netstorage-crossip-flat:fee powered by crossip communications gmbh --------------------------- sebastian kneipp gasse 1 a-1020 wien fix: +43-1-726 15 22-217 fax: +43-1-726 15 22-111 --------------------------- From jfvogel at gmail.com Thu Jun 19 17:55:46 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Thu Jun 19 17:55:48 2008 Subject: Seeking help understanding my "emX: watchdog timeout" messages In-Reply-To: <48582C29.8030307@monkeybrains.net> References: <20080516185813.H866@logos.sky.od.ua> <2a41acea0805160904g7dcf9f58rf69ca5d0612945cc@mail.gmail.com> <4853055C.2030303@MonkeyBrains.NET> <48535A11.4020003@monkeybrains.net> <48582C29.8030307@monkeybrains.net> Message-ID: <2a41acea0806191055w5e112b8bsa57a8db2b177adbe@mail.gmail.com> Watchdog reset is an indication that the TX completion did not happen within a reasonable time, it can the symptom of a variety of problems. You list a bunch of settings for polling, is this interface in POLLING mode? Jack On Tue, Jun 17, 2008 at 2:27 PM, Rudy wrote: > > > I am getting these messages: > Jun 17 08:53:14 example kernel: em2: watchdog timeout -- resetting > Jun 17 08:53:14 example kernel: em2: link state changed to DOWN > Jun 17 08:53:17 example kernel: em2: link state changed to UP > Jun 17 11:07:38 example kernel: em2: watchdog timeout -- resetting > Jun 17 11:07:38 example kernel: em2: link state changed to DOWN > Jun 17 11:07:41 example kernel: em2: link state changed to UP > on an interface that does about 100Mbps all day. > > [1] should I worry about it (only happens a couple of times a day)? > [2] will setting dev.em.2.rx_int_delay help? > couldn't find too much documentation on it... Best I could get: > http://www.intel.com/support/network/sb/cs-009209.htm > [3] what, in you best estimation, is causing these wathdog events? > > > sysctl dev.em.2.stats=1 > Jun 17 13:23:22 example kernel: em2: Excessive collisions = 0 > Jun 17 13:23:22 example kernel: em2: Sequence errors = 0 > Jun 17 13:23:22 example kernel: em2: Defer count = 0 > Jun 17 13:23:22 example kernel: em2: Missed Packets = 81518 > Jun 17 13:23:22 example kernel: em2: Receive No Buffers = 1226 > Jun 17 13:23:22 example kernel: em2: Receive Length Errors = 0 > Jun 17 13:23:22 example kernel: em2: Receive errors = 0 > Jun 17 13:23:22 example kernel: em2: Crc errors = 0 > Jun 17 13:23:22 example kernel: em2: Alignment errors = 0 > Jun 17 13:23:22 example kernel: em2: Collision/Carrier extension errors = 0 > Jun 17 13:23:22 example kernel: em2: RX overruns = 0 > Jun 17 13:23:22 example kernel: em2: watchdog timeouts = 20 > Jun 17 13:23:22 example kernel: em2: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK > MSIX IRQ = 0 > Jun 17 13:23:22 example kernel: em2: XON Rcvd = 0 > Jun 17 13:23:22 example kernel: em2: XON Xmtd = 0 > Jun 17 13:23:22 example kernel: em2: XOFF Rcvd = 0 > Jun 17 13:23:22 example kernel: em2: XOFF Xmtd = 0 > Jun 17 13:23:22 example kernel: em2: Good Packets Rcvd = 2515504832 > Jun 17 13:23:22 example kernel: em2: Good Packets Xmtd = 4543057019 > Jun 17 13:23:22 example kernel: em2: TSO Contexts Xmtd = 8 > Jun 17 13:23:22 example kernel: em2: TSO Contexts Failed = 0 > > sysctl dev.em.2.debug=1 > Jun 17 13:28:48 example kernel: em2: Adapter hardware address = 0xc4d91224 > Jun 17 13:28:48 example kernel: em2: CTRL = 0x400c0241 RCTL = 0x8002 > Jun 17 13:28:48 example kernel: em2: Packet buffer = Tx=16k Rx=32k > Jun 17 13:28:48 example kernel: em2: Flow control watermarks high = 30720 > low = 29220 > Jun 17 13:28:48 example kernel: em2: tx_int_delay = 66, tx_abs_int_delay = > 66 > Jun 17 13:28:48 example kernel: em2: rx_int_delay = 0, rx_abs_int_delay = > 66 > Jun 17 13:28:48 example kernel: em2: fifo workaround = 0, fifo_reset_count > = 0 > Jun 17 13:28:48 example kernel: em2: hw tdh = 116, hw tdt = 116 > Jun 17 13:28:48 example kernel: em2: hw rdh = 175, hw rdt = 174 > Jun 17 13:28:48 example kernel: em2: Num Tx descriptors avail = 256 > Jun 17 13:28:48 example kernel: em2: Tx Descriptors not avail1 = 20 > Jun 17 13:28:48 example kernel: em2: Tx Descriptors not avail2 = 0 > Jun 17 13:28:48 example kernel: em2: Std mbuf failed = 0 > Jun 17 13:28:48 example kernel: em2: Std mbuf cluster failed = 0 > Jun 17 13:28:48 example kernel: em2: Driver dropped packets = 0 > Jun 17 13:28:48 example kernel: em2: Driver tx dma failure in encap = 0 > > > sysctl dev.em.2 > dev.em.2.%desc: Intel(R) PRO/1000 Network Connection 6.9.5 > dev.em.2.%driver: em > dev.em.2.%location: slot=0 function=0 > dev.em.2.%pnpinfo: vendor=0x8086 device=0x10a4 subvendor=0x8086 > subdevice=0x10a4 class=0x020000 > dev.em.2.%parent: pci6 > dev.em.2.debug: -1 > dev.em.2.stats: -1 > dev.em.2.rx_int_delay: 0 > dev.em.2.tx_int_delay: 66 > dev.em.2.rx_abs_int_delay: 66 > dev.em.2.tx_abs_int_delay: 66 > dev.em.2.rx_processing_limit: 100 > > Polling related sysctl settings: > kern.polling.idlepoll_sleeping: 1 > kern.polling.stalled: 82 > kern.polling.suspect: 6266 > kern.polling.phase: 0 > kern.polling.enable: 1 > kern.polling.handlers: 6 > kern.polling.residual_burst: 0 > kern.polling.pending_polls: 1 > kern.polling.lost_polls: 371823 > kern.polling.short_ticks: 4795 > kern.polling.reg_frac: 20 > kern.polling.user_frac: 33 > kern.polling.idle_poll: 0 > kern.polling.each_burst: 5 > kern.polling.burst_max: 350 > kern.polling.burst: 350 > kern.clockrate: { hz = 2500, tick = 400, profhz = 1666, stathz = 333 } > > hadware is a quad Intel 1000 Pro PT card. > > Thanks!!!! > > Rudy > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From pisymbol at gmail.com Thu Jun 19 18:59:30 2008 From: pisymbol at gmail.com (Alexander Sack) Date: Thu Jun 19 18:59:34 2008 Subject: Network Instability when upgrading to 4GB of RAM In-Reply-To: <944074f30805022124n31e28fddkea80fcc78cbd8bc6@mail.gmail.com> References: <944074f30804191423v93d1acet9246269e4072d46a@mail.gmail.com> <944074f30805022124n31e28fddkea80fcc78cbd8bc6@mail.gmail.com> Message-ID: <18015461.post@talk.nabble.com> Paul Haddad wrote: > > All, > As a follow up to myself I installed an Intel PCIe NIC and disabled the on > board RTL based one and all my problems went away. Been running with 4GB > installed for a couple days now with absolutely no network issues. So > seems > like there's some problem with RTL NICs and >= 4GB of RAM. > -- > Paul Haddad (paul.haddad@gmail.com paul@pth.com) > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > I have the EXACT same issues. I'm sorry for arriving late to this thread but I was searching around and my onboard, re0, chip=0x816810ec, rev=0x01, gets Bad Packet Length on some ssh connections I have. Basically I notice this under some load (like while doing a portupgrade). I doubt its the memory, the notebook is brand spank'n new (I don't think its ECC RAM but it could be). Based on this post it seems that there maybe a bug in the RTL driver on 64-bit platforms? Anyone else see this? I may go try to track this down myself. Thanks! -aps -- View this message in context: http://www.nabble.com/Network-Instability-when-upgrading-to-4GB-of-RAM-tp16788164p18015461.html Sent from the freebsd-net mailing list archive at Nabble.com. From remko at FreeBSD.org Thu Jun 19 20:49:48 2008 From: remko at FreeBSD.org (remko@FreeBSD.org) Date: Thu Jun 19 20:49:50 2008 Subject: misc/124767: Wireless connection using iwi0 driver (Intel 2200 BG) keeps getting disconnected Message-ID: <200806192049.m5JKnm77042245@freefall.freebsd.org> Synopsis: Wireless connection using iwi0 driver (Intel 2200 BG) keeps getting disconnected Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Thu Jun 19 20:49:39 UTC 2008 Responsible-Changed-Why: Reassign to net team http://www.freebsd.org/cgi/query-pr.cgi?pr=124767 From sandra.johnson82 at yahoo.com Fri Jun 20 00:16:15 2008 From: sandra.johnson82 at yahoo.com (sandra200) Date: Fri Jun 20 00:16:17 2008 Subject: Unix friendly network testbench for FreeBSD? In-Reply-To: References: <4638C6B6.4050503@mac.com> Message-ID: <18020658.post@talk.nabble.com> Hello Good Day My name is sandra i saw your profile today at (nabble.com) and became intrested in you,i will also like to know you the more, and i want you to send an email to my email address, so i can give you my picture for you to know whom i believe we can move from here to next level I am waiting for your mail to my maill address (sandra.johnson82@yahoo.com ) Remeber the distance or colour does not matter but love matters alot in life with love sandra please reply to my email, (sandra.johnson82@yahoo.com) so i can give you my picture and will can move from here to next love. my lovely one, Remeber love and understading matters alot in life one love; Awaiting to hear from you soonest, Thanks and God bless you, Form sandra -- View this message in context: http://www.nabble.com/Unix-friendly-network-testbench-for-FreeBSD--tp10290378p18020658.html Sent from the freebsd-net mailing list archive at Nabble.com. From pyunyh at gmail.com Fri Jun 20 00:21:20 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Fri Jun 20 00:21:24 2008 Subject: Network Instability when upgrading to 4GB of RAM In-Reply-To: <18015461.post@talk.nabble.com> References: <944074f30804191423v93d1acet9246269e4072d46a@mail.gmail.com> <944074f30805022124n31e28fddkea80fcc78cbd8bc6@mail.gmail.com> <18015461.post@talk.nabble.com> Message-ID: <20080620001909.GB40128@cdnetworks.co.kr> On Thu, Jun 19, 2008 at 11:41:32AM -0700, Alexander Sack wrote: > > > > Paul Haddad wrote: > > > > All, > > As a follow up to myself I installed an Intel PCIe NIC and disabled the on > > board RTL based one and all my problems went away. Been running with 4GB > > installed for a couple days now with absolutely no network issues. So > > seems > > like there's some problem with RTL NICs and >= 4GB of RAM. > > -- > > Paul Haddad (paul.haddad@gmail.com paul@pth.com) > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > > > > I have the EXACT same issues. I'm sorry for arriving late to this thread > but I was searching around and my onboard, re0, chip=0x816810ec, rev=0x01, > gets Bad Packet Length on some ssh connections I have. Basically I notice > this under some load (like while doing a portupgrade). > > I doubt its the memory, the notebook is brand spank'n new (I don't think its > ECC RAM but it could be). Based on this post it seems that there maybe a > bug in the RTL driver on 64-bit platforms? Anyone else see this? I may go > try to track this down myself. re(4) had long standing bus_dma(9) bugs. I think I fixed most of bus_dma related bugs in 7-stable. Some users still suffer from instability issues but I guess it's different one that came from lack of documentation of PCIe based controllers. If you are not running 7-stable, try it 7-stable first and let me know how it goes. -- Regards, Pyun YongHyeon From peter at teamspeak-systems.de Fri Jun 20 08:56:24 2008 From: peter at teamspeak-systems.de (Peter Kirk) Date: Fri Jun 20 08:56:28 2008 Subject: UDP checksum invalid on FreeBSD7/x86 Message-ID: <200806201046.05530.peter@teamspeak-systems.de> Hi there, first of, this is my first posting to this list, hopfully it is the right place, if not please direct me, I was not being thick intentionally. I have a fresh installation of FreeBSD7 on x86, with no big changes to the system. Situation: Two PCs, one running linux and my own programs client application one running freebsd7 and my own programs server application The client and server of my program interchange UDP packets of various sizes. The problem I see is that small packets sent from the FreeBSD PC to the Linux PC are sent with an invalid UDP checksum (verified via tcpdump on the linux box). In my tests all packets with less than 30 bytes UDP payload had an invalid checksum set. All packets with more than 15 bytes had the correct checksum set. So, the "exact" number should be somewhere between 15 and 30 bytes. The receiving Linux box discards the packets with invalid checksums, which of course is problematic for my applications well-being. To "fix" the problem I did: sudo sysctl -w net.inet.udp.checksum=0 This doesn't seem to be a real fix, but more a work-around. If any more information (regarding my installation, my hardware or how my application uses the networking functions) is required, just ask. Thanks in advance for your responses. PS: I also tried with the client application on other operating systems than linux (e.g. win32), and the same problem occured, so this does seem to be a freebsd issue. Peter -- Today is the first day of the rest of your life. From bu7cher at yandex.ru Fri Jun 20 09:10:20 2008 From: bu7cher at yandex.ru (Andrey V. Elsukov) Date: Fri Jun 20 09:10:24 2008 Subject: UDP checksum invalid on FreeBSD7/x86 In-Reply-To: <200806201046.05530.peter@teamspeak-systems.de> References: <200806201046.05530.peter@teamspeak-systems.de> Message-ID: <485B73EE.6050707@yandex.ru> Peter Kirk wrote: > first of, this is my first posting to this list, hopfully it is the right > place, if not please direct me, I was not being thick intentionally. > > I have a fresh installation of FreeBSD7 on x86, with no big changes to the > system. Can you show `ifconfig -u` output? -- WBR, Andrey V. Elsukov From peter at teamspeak-systems.de Fri Jun 20 09:33:36 2008 From: peter at teamspeak-systems.de (Peter Kirk) Date: Fri Jun 20 09:33:40 2008 Subject: UDP checksum invalid on FreeBSD7/x86 In-Reply-To: <485B73EE.6050707@yandex.ru> References: <200806201046.05530.peter@teamspeak-systems.de> <485B73EE.6050707@yandex.ru> Message-ID: <200806201133.28357.peter@teamspeak-systems.de> On Friday 20 June 2008 11:10:06 Andrey V. Elsukov wrote: > > I have a fresh installation of FreeBSD7 on x86, with no big changes to > > the system. > > Can you show `ifconfig -u` output? re0: flags=8843 metric 0 mtu 1500 options=9b ether 00:19:66:59:85:7f inet6 fe80::219:66ff:fe59:857f%re0 prefixlen 64 scopeid 0x1 inet 192.168.1.13 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (1000baseTX ) status: active lo0: flags=8049 metric 0 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet 127.0.0.1 netmask 0xff000000 Peter -- Billy: Mom, you know that vase you said was handed down from generation to generation? Mom: Yes? Billy: Well, this generation dropped it. From bu7cher at yandex.ru Fri Jun 20 09:38:34 2008 From: bu7cher at yandex.ru (Andrey V. Elsukov) Date: Fri Jun 20 09:38:39 2008 Subject: UDP checksum invalid on FreeBSD7/x86 In-Reply-To: <200806201133.28357.peter@teamspeak-systems.de> References: <200806201046.05530.peter@teamspeak-systems.de> <485B73EE.6050707@yandex.ru> <200806201133.28357.peter@teamspeak-systems.de> Message-ID: <485B7A88.9080301@yandex.ru> Peter Kirk wrote: > On Friday 20 June 2008 11:10:06 Andrey V. Elsukov wrote: >>> I have a fresh installation of FreeBSD7 on x86, with no big changes to >>> the system. >> Can you show `ifconfig -u` output? > > re0: flags=8843 metric 0 mtu 1500 > options=9b It's problem in re(4) driver. Try to use `ifconfig re0 -rxcsum -txcsum`. You can add these parameters to your rc.conf. -- WBR, Andrey V. Elsukov From peter at teamspeak-systems.de Fri Jun 20 09:55:05 2008 From: peter at teamspeak-systems.de (Peter Kirk) Date: Fri Jun 20 09:55:09 2008 Subject: UDP checksum invalid on FreeBSD7/x86 In-Reply-To: <485B7A88.9080301@yandex.ru> References: <200806201046.05530.peter@teamspeak-systems.de> <200806201133.28357.peter@teamspeak-systems.de> <485B7A88.9080301@yandex.ru> Message-ID: <200806201154.56281.peter@teamspeak-systems.de> On Friday 20 June 2008 11:38:16 Andrey V. Elsukov wrote: > Peter Kirk wrote: > >> Can you show `ifconfig -u` output? > > > > re0: flags=8843 metric 0 mtu 1500 > > options=9b > > It's problem in re(4) driver. > Try to use `ifconfig re0 -rxcsum -txcsum`. You can add these > parameters to your rc.conf. In /etc/rc.conf I changed the line ifconfig_re0="inet 192.168.1.13 netmask 255.255.255.0" to ifconfig_re0="-rxcsum -txcsum inet 192.168.1.13 netmask 255.255.255.0" Now the problem no longer appears, even with "net.inet.udp.checksum=1". Thanks for answering this so promptly, hopefuly the re(4) driver can be fixed to avoid this kind of problem (or the -rxcsum -txcsum added automatically for this card). Peter -- Your manuscript is both good and original, but the part that is good is not original and the part that is original is not good. -- Samuel Johnson From salvador_d13 at yahoo.com.ph Fri Jun 20 12:52:26 2008 From: salvador_d13 at yahoo.com.ph (Diego Salvador) Date: Fri Jun 20 12:52:32 2008 Subject: [Queueing Packets with ALTQ on Gigabit Fiber Optic and Gigabit Ethernet] Message-ID: <52345.28040.qm@web76103.mail.sg1.yahoo.com> Hi, Is there any difference in handling packet queues with ALTQ if the network card is a Gigabit fiber network interface and a Gigabit Ethernet network interface with the same driver? For example (em) driver for Intel-based cards. I'm currently having a system configured with FreeBSD-6.2 RELEASE with PF and ALTQ enabled. This host is configured first with Intel 1-Gigabit Ethernet network card and when it receive big amount of traffic, I don't see any packet errors with netstat but when I switched to the 1-Gigabit fiber optic card, I could see packet errors with this interface. A big amount of traffic were bombarded on the interface around 800Mbps. Here's the sample packet errors received on the system with netstat. Gigabit Intel fiber interface ------------------------------------- # netstat -I em0 -w 1 input (em0) output packets errs bytes packets errs bytes colls 3260 149652 2547816 0 0 0 0 3257 150026 2547756 0 0 0 0 3258 150117 2543396 1 0 42 0 3259 150181 2549320 0 0 0 0 3256 149941 2543244 0 0 0 0 3370 149871 2636122 0 0 0 0 3255 149534 2544688 0 0 0 0 3255 150077 2543966 0 0 0 0 3260 150195 2549320 0 0 0 0 3259 149603 2547816 0 0 0 0 3258 149746 2546312 0 0 0 0 3258 149855 2547756 0 0 0 0 3261 149851 2549320 0 0 0 0 3255 150414 2545410 0 0 0 0 3250 149758 2542282 0 0 0 0 3255 149842 2545410 0 0 0 0 3259 149568 2547756 0 0 0 0 3255 149943 2545502 0 0 0 0 3261 149893 2548658 0 0 0 0 3257 149581 2545530 0 0 0 0 Thank you very much! Diego --------------------------------- Look for jobs - Yahoo! Philippines Search. From pisymbol at gmail.com Fri Jun 20 13:07:05 2008 From: pisymbol at gmail.com (Alexander Sack) Date: Fri Jun 20 13:07:07 2008 Subject: Network Instability when upgrading to 4GB of RAM In-Reply-To: <20080620001909.GB40128@cdnetworks.co.kr> References: <944074f30804191423v93d1acet9246269e4072d46a@mail.gmail.com> <944074f30805022124n31e28fddkea80fcc78cbd8bc6@mail.gmail.com> <18015461.post@talk.nabble.com> <20080620001909.GB40128@cdnetworks.co.kr> Message-ID: <18029156.post@talk.nabble.com> Pyun YongHyeon wrote: > > On Thu, Jun 19, 2008 at 11:41:32AM -0700, Alexander Sack wrote: > > > > > > > > Paul Haddad wrote: > > > > > > All, > > > As a follow up to myself I installed an Intel PCIe NIC and disabled > the on > > > board RTL based one and all my problems went away. Been running with > 4GB > > > installed for a couple days now with absolutely no network issues. So > > > seems > > > like there's some problem with RTL NICs and >= 4GB of RAM. > > > -- > > > Paul Haddad (paul.haddad@gmail.com paul@pth.com) > > > _______________________________________________ > > > freebsd-net@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" > > > > > > > > > > I have the EXACT same issues. I'm sorry for arriving late to this > thread > > but I was searching around and my onboard, re0, chip=0x816810ec, > rev=0x01, > > gets Bad Packet Length on some ssh connections I have. Basically I > notice > > this under some load (like while doing a portupgrade). > > > > I doubt its the memory, the notebook is brand spank'n new (I don't > think its > > ECC RAM but it could be). Based on this post it seems that there maybe > a > > bug in the RTL driver on 64-bit platforms? Anyone else see this? I > may go > > try to track this down myself. > > re(4) had long standing bus_dma(9) bugs. I think I fixed most of > bus_dma related bugs in 7-stable. Some users still suffer from > instability issues but I guess it's different one that came from > lack of documentation of PCIe based controllers. > If you are not running 7-stable, try it 7-stable first and let me > know how it goes. > > Pyun: Understood. I'm on a stock 7.0-RELEASE box. Let me upgrade to the latest 7.0-STABLE driver and will update this thread if I still see issues (if I do, I'll try to find some time to debug them). Thanks again! -aps -- View this message in context: http://www.nabble.com/Network-Instability-when-upgrading-to-4GB-of-RAM-tp16788164p18029156.html Sent from the freebsd-net mailing list archive at Nabble.com. From dfilter at FreeBSD.ORG Fri Jun 20 17:40:08 2008 From: dfilter at FreeBSD.ORG (dfilter service) Date: Fri Jun 20 17:40:10 2008 Subject: kern/114714: commit references a PR Message-ID: <200806201740.m5KHe8Rk004684@freefall.freebsd.org> The following reply was made to PR kern/114714; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/114714: commit references a PR Date: Fri, 20 Jun 2008 17:30:14 +0000 (UTC) thompsa 2008-06-20 17:26:34 UTC FreeBSD src repository Modified files: sbin/ifconfig ifconfig.8 ifconfig.c share/man/man4 gre.4 sys/net if_gre.c if_gre.h Log: SVN rev 179894 on 2008-06-20 17:26:34Z by thompsa Add support for the optional key in the GRE header. PR: kern/114714 Submitted by: Cristian KLEIN Revision Changes Path 1.148 +11 -1 src/sbin/ifconfig/ifconfig.8 1.137 +20 -0 src/sbin/ifconfig/ifconfig.c 1.8 +14 -2 src/share/man/man4/gre.4 1.49 +44 -3 src/sys/net/if_gre.c 1.15 +7 -0 src/sys/net/if_gre.h _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From thompsa at FreeBSD.org Fri Jun 20 17:49:31 2008 From: thompsa at FreeBSD.org (thompsa@FreeBSD.org) Date: Fri Jun 20 17:49:33 2008 Subject: kern/123961: [vr] [patch] Allow vr interface to handle vlans Message-ID: <200806201749.m5KHnVSW004775@freefall.freebsd.org> Synopsis: [vr] [patch] Allow vr interface to handle vlans State-Changed-From-To: open->patched State-Changed-By: thompsa State-Changed-When: Fri Jun 20 17:47:20 UTC 2008 State-Changed-Why: This has been handled by the bus_dma megaupdate to vr(4), thanks to Pyun. Not merged to RELENG_6 yet. http://www.freebsd.org/cgi/query-pr.cgi?pr=123961 From crapsh at monkeybrains.net Fri Jun 20 20:11:57 2008 From: crapsh at monkeybrains.net (Rudy) Date: Fri Jun 20 20:12:00 2008 Subject: Seeking help understanding my "emX: watchdog timeout" messages In-Reply-To: <2a41acea0806191055w5e112b8bsa57a8db2b177adbe@mail.gmail.com> References: <20080516185813.H866@logos.sky.od.ua> <2a41acea0805160904g7dcf9f58rf69ca5d0612945cc@mail.gmail.com> <4853055C.2030303@MonkeyBrains.NET> <48535A11.4020003@monkeybrains.net> <48582C29.8030307@monkeybrains.net> <2a41acea0806191055w5e112b8bsa57a8db2b177adbe@mail.gmail.com> Message-ID: <485C0F07.7000408@monkeybrains.net> Jack Vogel wrote: > Watchdog reset is an indication that the TX completion did not happen > within a reasonable time, it can the symptom of a variety of problems. > > You list a bunch of settings for polling, is this interface in POLLING > mode? > Yes, DEVICE_POLLING is in the kernel and kern.polling.enable=1. I did not issue a "ifconfig em2 polling" and I see it running, so I assume that it is in POLLING mode. em2: flags=8843 metric 0 mtu 1500 options=1db ether 00:15:17:78:99:72 inet 64.215.30.154 netmask 0xfffffffc broadcast 64.215.30.155 media: Ethernet autoselect (1000baseTX ) status: active Interestingly, I also get the watchdog timeouts on my em4 (motherboard 82573E NIC). In a 24 hour period, I see 8 'watchdog timeout' events. 4 on em2 and 4 on em4. Both are uplinks to different cisco switches which vlan those ports to fiber uplinks. Thank you for your time Jack, Rudy From jfvogel at gmail.com Fri Jun 20 20:55:55 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Fri Jun 20 20:55:59 2008 Subject: Seeking help understanding my "emX: watchdog timeout" messages In-Reply-To: <485C0F07.7000408@monkeybrains.net> References: <20080516185813.H866@logos.sky.od.ua> <2a41acea0805160904g7dcf9f58rf69ca5d0612945cc@mail.gmail.com> <4853055C.2030303@MonkeyBrains.NET> <48535A11.4020003@monkeybrains.net> <48582C29.8030307@monkeybrains.net> <2a41acea0806191055w5e112b8bsa57a8db2b177adbe@mail.gmail.com> <485C0F07.7000408@monkeybrains.net> Message-ID: <2a41acea0806201355y3b123462wc37280f28a9f4216@mail.gmail.com> On the 573 get me an eeprom dump: sysctl dev.em.4.debug=2 If you have having TX timeouts using polling, perhaps your system is so busy that its not running the cleanup routine in time, can you switch and run the interface in non-polled, in fact if possible using MSI?? Jack On Fri, Jun 20, 2008 at 1:11 PM, Rudy wrote: > Jack Vogel wrote: >> >> Watchdog reset is an indication that the TX completion did not happen >> within a reasonable time, it can the symptom of a variety of problems. >> >> You list a bunch of settings for polling, is this interface in POLLING >> mode? >> > > Yes, DEVICE_POLLING is in the kernel and kern.polling.enable=1. I did not > issue a > "ifconfig em2 polling" and I see it running, so I assume that it is in > POLLING mode. > > > em2: flags=8843 metric 0 mtu 1500 > > options=1db > ether 00:15:17:78:99:72 > inet 64.215.30.154 netmask 0xfffffffc broadcast 64.215.30.155 > media: Ethernet autoselect (1000baseTX ) > status: active > > Interestingly, I also get the watchdog timeouts on my em4 (motherboard > 82573E NIC). > > In a 24 hour period, I see 8 'watchdog timeout' events. 4 on em2 and 4 on > em4. Both are uplinks to different cisco switches which vlan those ports to > fiber uplinks. > > Thank you for your time Jack, > Rudy > From crapsh at monkeybrains.net Fri Jun 20 23:45:52 2008 From: crapsh at monkeybrains.net (Support (Rudy)) Date: Fri Jun 20 23:45:57 2008 Subject: Seeking help understanding my "emX: watchdog timeout" messages In-Reply-To: <2a41acea0806201355y3b123462wc37280f28a9f4216@mail.gmail.com> References: <20080516185813.H866@logos.sky.od.ua> <2a41acea0805160904g7dcf9f58rf69ca5d0612945cc@mail.gmail.com> <4853055C.2030303@MonkeyBrains.NET> <48535A11.4020003@monkeybrains.net> <48582C29.8030307@monkeybrains.net> <2a41acea0806191055w5e112b8bsa57a8db2b177adbe@mail.gmail.com> <485C0F07.7000408@monkeybrains.net> <2a41acea0806201355y3b123462wc37280f28a9f4216@mail.gmail.com> Message-ID: <485C412F.5000204@monkeybrains.net> Jack Vogel wrote: > On the 573 get me an eeprom dump: sysctl dev.em.4.debug=2 here are the dumps: em4: Jun 20 16:30:01 mango kernel: Jun 20 16:30:01 mango kernel: Interface EEPROM Dump: Jun 20 16:30:01 mango kernel: Offset Jun 20 16:30:01 mango kernel: 0x0000 3000 6748 5014 0d30 f746 00f4 ffff ffff Jun 20 16:30:01 mango kernel: 0x0010 ffff ffff 026b 108c 15d9 108c 8086 83df Jun 20 16:30:01 mango kernel: 0x0020 0008 2000 7e14 0048 1000 00d8 0000 2700 Jun 20 16:30:01 mango kernel: 0x0030 6cc9 3150 0722 040b 0984 0000 c000 0706 em2: Jun 20 16:31:07 mango kernel: Jun 20 16:31:07 mango kernel: Interface EEPROM Dump: Jun 20 16:31:07 mango kernel: Offset Jun 20 16:31:07 mango kernel: 0x0000 1500 7817 7299 0424 ffff 50a2 ffff ffff Jun 20 16:31:07 mango kernel: 0x0010 d473 1604 a42f 10a4 8086 10a4 8086 b165 Jun 20 16:31:07 mango kernel: 0x0020 0008 10a4 5800 0000 5001 0000 0000 0100 Jun 20 16:31:07 mango kernel: 0x0030 6cf6 37b0 07a6 8403 0783 0000 c303 0602 > If you have having TX timeouts using polling, perhaps your system > is so busy that its not running the cleanup routine in time, can you > switch and run the interface in non-polled, in fact if possible using > MSI?? I don't think the system is all that busy dual core 2.8Gz CPU... CPU mostly idle, and load is at 0.00. Here is the throughput on my busiest devices (lagg0 is em0 & em1): dev out in lagg0 67389 kbps 156781 kbps em2 54342 kbps 14284 kbps em4 93068 kbps 22433 kbps vlan6 22784 kbps 122790 kbps ------------------------ ------------------------------------------------------- little script to run to monitor throughput on devices ------------------------------------------------------- #!/bin/sh DEVS="lagg0 em2 em4 vlan6" # current_rate.sh # This script print out the current bw on each link. # Tue Dec 27 17:11:16 PST 2005, rudy measure_device_traffic () { # measure bytes of 2 seconds... bultiple by 4 to get bits per 1 second BITS=`netstat -I $InterfaceToCheck 1 | head -3 | tail -1 `; BITS_O=`echo $BITS | awk '{printf "%6d", $6 / 1024 * 8 }'`; BITS_I=`echo $BITS | awk '{printf "%6d", $3 / 1024 * 8 }'`; DEV_PAD=`echo $InterfaceToCheck | awk '{printf "%5s", $1}'` } ### Measure traffic, print! echo " dev out in" while : do for InterfaceToCheck in $DEVS; do measure_device_traffic echo "$DEV_PAD $BITS_O kbps $BITS_I kbps" done echo "------------------------" done From crapsh at monkeybrains.net Fri Jun 20 23:48:22 2008 From: crapsh at monkeybrains.net (Support (Rudy)) Date: Fri Jun 20 23:48:26 2008 Subject: Seeking help understanding my "emX: watchdog timeout" messages In-Reply-To: <2a41acea0806201355y3b123462wc37280f28a9f4216@mail.gmail.com> References: <20080516185813.H866@logos.sky.od.ua> <2a41acea0805160904g7dcf9f58rf69ca5d0612945cc@mail.gmail.com> <4853055C.2030303@MonkeyBrains.NET> <48535A11.4020003@monkeybrains.net> <48582C29.8030307@monkeybrains.net> <2a41acea0806191055w5e112b8bsa57a8db2b177adbe@mail.gmail.com> <485C0F07.7000408@monkeybrains.net> <2a41acea0806201355y3b123462wc37280f28a9f4216@mail.gmail.com> Message-ID: <485C41C5.4090706@monkeybrains.net> Jack Vogel wrote: > ... can you switch and run the interface in non-polled, in fact if possible using > MSI?? Do I have to do anything special for MSI? I see this in my dmesg: # dmesg | grep MSI em0: Using MSI interrupt em1: Using MSI interrupt em2: Using MSI interrupt em3: Using MSI interrupt em4: Using MSI interrupt em5: Using MSI interrupt From jfvogel at gmail.com Sat Jun 21 00:13:02 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Sat Jun 21 00:13:05 2008 Subject: Seeking help understanding my "emX: watchdog timeout" messages In-Reply-To: <485C41C5.4090706@monkeybrains.net> References: <20080516185813.H866@logos.sky.od.ua> <2a41acea0805160904g7dcf9f58rf69ca5d0612945cc@mail.gmail.com> <4853055C.2030303@MonkeyBrains.NET> <48535A11.4020003@monkeybrains.net> <48582C29.8030307@monkeybrains.net> <2a41acea0806191055w5e112b8bsa57a8db2b177adbe@mail.gmail.com> <485C0F07.7000408@monkeybrains.net> <2a41acea0806201355y3b123462wc37280f28a9f4216@mail.gmail.com> <485C41C5.4090706@monkeybrains.net> Message-ID: <2a41acea0806201713m7a083b9dr10894c8a0845df8e@mail.gmail.com> On Fri, Jun 20, 2008 at 4:48 PM, Support (Rudy) wrote: > Jack Vogel wrote: >> >> ... can you switch and run the interface in non-polled, in fact if >> possible using >> MSI?? > > Do I have to do anything special for MSI? I see this in my dmesg: > > # dmesg | grep MSI > em0: Using MSI interrupt > em1: Using MSI interrupt > em2: Using MSI interrupt > em3: Using MSI interrupt > em4: Using MSI interrupt > em5: Using MSI interrupt > > Nope, you already are setup, you just have to disable polling. Jack From pyunyh at gmail.com Sat Jun 21 00:21:53 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Sat Jun 21 00:21:58 2008 Subject: UDP checksum invalid on FreeBSD7/x86 In-Reply-To: <200806201154.56281.peter@teamspeak-systems.de> References: <200806201046.05530.peter@teamspeak-systems.de> <200806201133.28357.peter@teamspeak-systems.de> <485B7A88.9080301@yandex.ru> <200806201154.56281.peter@teamspeak-systems.de> Message-ID: <20080621001940.GD44099@cdnetworks.co.kr> On Fri, Jun 20, 2008 at 11:54:55AM +0200, Peter Kirk wrote: > On Friday 20 June 2008 11:38:16 Andrey V. Elsukov wrote: > > Peter Kirk wrote: > > >> Can you show `ifconfig -u` output? > > > > > > re0: flags=8843 metric 0 mtu 1500 > > > options=9b > > > > It's problem in re(4) driver. > > Try to use `ifconfig re0 -rxcsum -txcsum`. You can add these > > parameters to your rc.conf. > > In /etc/rc.conf I changed the line > ifconfig_re0="inet 192.168.1.13 netmask 255.255.255.0" > to > ifconfig_re0="-rxcsum -txcsum inet 192.168.1.13 netmask 255.255.255.0" > > Now the problem no longer appears, even with "net.inet.udp.checksum=1". Thanks > for answering this so promptly, hopefuly the re(4) driver can be fixed to > avoid this kind of problem (or the -rxcsum -txcsum added automatically for > this card). Try re(4) on 7-stable and let me know how it goes. Most checksum offload and bus_dma(9) related issues were fixed in 7-stable. -- Regards, Pyun YongHyeon From peter at teamspeak-systems.de Sat Jun 21 09:38:46 2008 From: peter at teamspeak-systems.de (Peter Kirk) Date: Sat Jun 21 09:38:50 2008 Subject: UDP checksum invalid on FreeBSD7/x86 In-Reply-To: <20080621001940.GD44099@cdnetworks.co.kr> References: <200806201046.05530.peter@teamspeak-systems.de> <200806201154.56281.peter@teamspeak-systems.de> <20080621001940.GD44099@cdnetworks.co.kr> Message-ID: <200806211049.32460.peter@teamspeak-systems.de> On Saturday 21 June 2008 02:19:40 Pyun YongHyeon wrote: > ?> Now the problem no longer appears, even with "net.inet.udp.checksum=1". > Thanks > for answering this so promptly, hopefuly the re(4) driver can be > fixed to > avoid this kind of problem (or the -rxcsum -txcsum added > automatically for > this card). > > Try re(4) on 7-stable and let me know how it goes. > Most checksum offload and bus_dma(9) related issues were fixed in > 7-stable. Sorry, I might not be in sync with "FreeBSD terms", but we installed FreeBSD-7 (the latest stable version), aren't I then already running 7-stable? uname -a says: FreeBSD FreeBSD32.zocker 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC 2008 root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 Peter -- If you think nobody cares if you're alive, try missing a couple of car payments. -- Earl Wilson From morganw at chemikals.org Sat Jun 21 12:51:00 2008 From: morganw at chemikals.org (Wes Morgan) Date: Sat Jun 21 12:51:05 2008 Subject: UDP checksum invalid on FreeBSD7/x86 In-Reply-To: <200806211049.32460.peter@teamspeak-systems.de> References: <200806201046.05530.peter@teamspeak-systems.de> <200806201154.56281.peter@teamspeak-systems.de> <20080621001940.GD44099@cdnetworks.co.kr> <200806211049.32460.peter@teamspeak-systems.de> Message-ID: On Sat, 21 Jun 2008, Peter Kirk wrote: > On Saturday 21 June 2008 02:19:40 Pyun YongHyeon wrote: >> ?> Now the problem no longer appears, even with "net.inet.udp.checksum=1". >> Thanks > for answering this so promptly, hopefuly the re(4) driver can be >> fixed to > avoid this kind of problem (or the -rxcsum -txcsum added >> automatically for > this card). >> >> Try re(4) on 7-stable and let me know how it goes. >> Most checksum offload and bus_dma(9) related issues were fixed in >> 7-stable. > > Sorry, I might not be in sync with "FreeBSD terms", but we installed FreeBSD-7 > (the latest stable version), aren't I then already running 7-stable? > uname -a says: > FreeBSD FreeBSD32.zocker 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 > 19:59:52 UTC 2008 root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC > i386 You are running the initial release for the 7-stable branch, which will not include the fixes committed to the tree since the release date. From gavin at FreeBSD.org Sat Jun 21 13:11:20 2008 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Sat Jun 21 13:11:23 2008 Subject: arm/121242: [ate] [patch] Promiscuous mode of if_ate (arm) doesn't work Message-ID: <200806211311.m5LDBJtP057319@freefall.freebsd.org> Synopsis: [ate] [patch] Promiscuous mode of if_ate (arm) doesn't work Responsible-Changed-From-To: freebsd-net->freebsd-arm Responsible-Changed-By: gavin Responsible-Changed-When: Sat Jun 21 13:10:35 UTC 2008 Responsible-Changed-Why: Over to -arm@ mailing list for consideration http://www.freebsd.org/cgi/query-pr.cgi?pr=121242 From agirling at denetron.com Sat Jun 21 16:30:37 2008 From: agirling at denetron.com (Andrew Girling) Date: Sat Jun 21 16:30:41 2008 Subject: [Queueing Packets with ALTQ on Gigabit Fiber Optic and Gigabit Ethernet] In-Reply-To: <52345.28040.qm@web76103.mail.sg1.yahoo.com> References: <52345.28040.qm@web76103.mail.sg1.yahoo.com> Message-ID: On Jun 20, 2008, at 8:38 AM, Diego Salvador wrote: > Hi, > > Is there any difference in handling packet queues with ALTQ if the > network card is > a Gigabit fiber network interface and a Gigabit Ethernet network > interface with the > same driver? For example (em) driver for Intel-based cards. I'm > currently having a > system configured with FreeBSD-6.2 RELEASE with PF and ALTQ enabled. > This > host is configured first with Intel 1-Gigabit Ethernet network card > and when it > receive big amount of traffic, I don't see any packet errors with > netstat but when I > switched to the 1-Gigabit fiber optic card, I could see packet > errors with this > interface. A big amount of traffic were bombarded on the interface > around > 800Mbps. > > Here's the sample packet errors received on the system with netstat. > > Gigabit Intel fiber interface > ------------------------------------- > # netstat -I em0 -w 1 > input (em0) output > packets errs bytes packets errs bytes colls > 3260 149652 2547816 0 0 0 0 > 3257 150026 2547756 0 0 0 0 > 3258 150117 2543396 1 0 42 0 > 3259 150181 2549320 0 0 0 0 > 3256 149941 2543244 0 0 0 0 > 3370 149871 2636122 0 0 0 0 > 3255 149534 2544688 0 0 0 0 > 3255 150077 2543966 0 0 0 0 > 3260 150195 2549320 0 0 0 0 > 3259 149603 2547816 0 0 0 0 > 3258 149746 2546312 0 0 0 0 > 3258 149855 2547756 0 0 0 0 > 3261 149851 2549320 0 0 0 0 > 3255 150414 2545410 0 0 0 0 > 3250 149758 2542282 0 0 0 0 > 3255 149842 2545410 0 0 0 0 > 3259 149568 2547756 0 0 0 0 > 3255 149943 2545502 0 0 0 0 > 3261 149893 2548658 0 0 0 0 > 3257 149581 2545530 0 0 0 0 > > Thank you very much! > > Diego Diego, This sounds like it may be a duplex mismatch. Have you tried verifying the speed and duplex on both ends of the fiber connection? A dump of "ifconfig em0" and information on where the device the circuit is connected to would be helpful. Is the circuit known to be working on other machines? Does the problem exist when you disable pf/ altq? Cheers, Andrew From crapsh at monkeybrains.net Sat Jun 21 19:50:59 2008 From: crapsh at monkeybrains.net (Rudy) Date: Sat Jun 21 19:51:04 2008 Subject: Seeking help understanding my "emX: watchdog timeout" messages In-Reply-To: <2a41acea0806201713m7a083b9dr10894c8a0845df8e@mail.gmail.com> References: <20080516185813.H866@logos.sky.od.ua> <2a41acea0805160904g7dcf9f58rf69ca5d0612945cc@mail.gmail.com> <4853055C.2030303@MonkeyBrains.NET> <48535A11.4020003@monkeybrains.net> <48582C29.8030307@monkeybrains.net> <2a41acea0806191055w5e112b8bsa57a8db2b177adbe@mail.gmail.com> <485C0F07.7000408@monkeybrains.net> <2a41acea0806201355y3b123462wc37280f28a9f4216@mail.gmail.com> <485C41C5.4090706@monkeybrains.net> <2a41acea0806201713m7a083b9dr10894c8a0845df8e@mail.gmail.com> Message-ID: <485D5B9E.8020908@monkeybrains.net> Jack Vogel wrote: > On Fri, Jun 20, 2008 at 4:48 PM, Support (Rudy) wrote: >> Jack Vogel wrote: >>> ... can you switch and run the interface in non-polled, in fact if >>> possible using >>> MSI?? At 5pm yesterday, I disabled polling. I've had about the same frequency of 'timeouts' Jun 21 09:28:29 mango kernel: em2: watchdog timeout -- resetting Jun 21 11:02:55 mango kernel: em2: watchdog timeout -- resetting Jun 21 11:38:18 mango kernel: em4: watchdog timeout -- resetting em2 and em4 are outbound heavy while the other emX on the box are inbound... I missed the boat with MSI. :) When did that become the people's choice over DEVICE_POLLING? Rudy From auryn at zirakzigil.org Sun Jun 22 08:43:17 2008 From: auryn at zirakzigil.org (Giulio Ferro) Date: Sun Jun 22 08:43:21 2008 Subject: Problems with vlan + carp + alias In-Reply-To: <55b8c6fe0806190417r440045e6ncf6e99945c453f10@mail.gmail.com> References: <4859877A.3020300@zirakzigil.org> <4859A3A1.6070105@pce-net.com> <485A28ED.9020103@zirakzigil.org> <55b8c6fe0806190330p225ec6d1g65f8424efeab9b41@mail.gmail.com> <485A3DC6.2030500@zirakzigil.org> <55b8c6fe0806190417r440045e6ncf6e99945c453f10@mail.gmail.com> Message-ID: <485E109C.9060705@zirakzigil.org> Primeroz lists wrote: > What is tcpdump showing for ping on 192.168.10.11 > ? can you see echo reply exiting vlan10 > interface ? > > what if you try from your server to "ping -S 192.168.10.11 > 192.168.10.254 " ? > > > First of all I'm sorry for the late reply. Yesterday I could do some more in-depth test to analyze this strange behavior of my firewall. The 192.168.10.0/24 range I used in the previous example isn't the real one, I just used it for simplicity?s sake. The true range, the one which has been assigned by the ISP to my customer is: x.y.z.128/27. (x.y.z corresponds to a true public IP address) I've deactivated the firewall, so we have one less thing to worry about: /etc/rc.d/pf stop This is a pure network configuration issue. Here is the relevant part in /etc/rc.conf: --------------------------------------------------- ... ifconfig_bce0="inet 192.168.26.1 netmask 255.255.255.0" ... cloned_interfaces="vlan5 vlan25 vlan30 vlan40 vlan128 carp5 carp25 carp30 carp40 carp128" ... ifconfig_vlan128="inet x.y.z.157 netmask 255.255.255.224 vlan 128 vlandev bce0" ... ifconfig_carp128="vhid 128 pass qweq x.y.z.132 netmask 255.255.255.255" ifconfig_carp128_alias0="x.y.z.133 netmask 255.255.255.255" ifconfig_carp128_alias1="x.y.z.134 netmask 255.255.255.255" ifconfig_carp128_alias2="x.y.z.135 netmask 255.255.255.255" ifconfig_carp128_alias3="x.y.z.136 netmask 255.255.255.255" ifconfig_carp128_alias4="x.y.z.137 netmask 255.255.255.255" ifconfig_carp128_alias5="x.y.z.138 netmask 255.255.255.255" ifconfig_carp128_alias6="x.y.z.139 netmask 255.255.255.255" ifconfig_carp128_alias7="x.y.z.140 netmask 255.255.255.255" ifconfig_carp128_alias8="x.y.z.141 netmask 255.255.255.255" ... defaultrouter="x.y.z.129" --------------------------------------------------- On my managed switch I've set 2 ports: 1) the one where the bce0 interface is plugged in : mode trunk with all the vlans above 2) the one where the ISP internet is plugged in : mode access with vlan 128 I've also set the ip interface of my switch to x.y.z.155 vlan 128 Here is the relevant part of netstat -rn on my machine --------------------------------------------------- default x.y.z.129 UGS 0 13966 vlan12 x.y.z/27 link#11 UC 0 0 vlan12 x.y.z.132 x.y.z.132 UH 0 0 carp12 x.y.z.133 x.y.z.133 UH 0 0 carp12 x.y.z.134 x.y.z.134 UH 0 0 carp12 x.y.z.135 x.y.z135 UH 0 0 carp12 x.y.z.136 x.y.z.136 UH 0 0 carp12 x.y.z.137 x.y.z.137 UH 0 0 carp12 x.y.z.138 x.y.z.138 UH 0 0 carp12 x.y.z.139 x.y.z.139 UH 0 0 carp12 x.y.z.140 x.y.z.140 UH 0 0 carp12 x.y.z.141 x.y.z.141 UH 0 0 carp12 x.y.z.155 00:1e:c9:90:4a:c0 UHLW 1 8 vlan12 1183 --------------------------------------------------- Here come the tests. 1) From the firewall : basic I can ping both the default gateway (x.y.z.129) and the switch interface (x.y.z.155) I can ping a generic internet address (a.b.c.d) With tcpdump I can see the packets leaving as x.y.z.157 and coming with the same address 2) from the switch : basic I can ping the firewall's vlan address (x.y.z.157) I can ping _ALL_ the carp interfaces, base and alias: ping x.y.z.157 -> OK ping x.y.z.132 -> OK ping x.y.z.133 -> OK ... ping x.y.z.141 -> OK 3) from the internet : basic From an external internet address I can ping the vlan address: ping x.y.z.157 -> OK 4) from the firewall : advanced From the firewall I can ping the switch address from one of the carp base and aliased address: ping -S x.y.z.132 x.y.z.155 -> OK ping -S x.y.z.133 x.y.z.155 -> OK I _cannot_ ping the default router from one of the carp addresses: ping -S x.y.z.132 x.y.z.129 -> NOT OK ping -S x.y.z.133 x.y.z.129 -> NOT OK By using tcpdump on the vlan128 interface I can see the packets _BOTH_ leaving and coming from the carp addresses. It just seems that the carp interfaces can't process the packets properly. 5) from the internet : advanced From an external internet address I _cannot_ ping the carp addresses (x.y.z.132 and up) As above, I can see the incoming packets with tcpdump -i vlan128 -n icmp Ok, that was long. I hope someone can help to shed light into this, to see whether this is a bug or not. I stress again that the _same_ configuration works as it should on a physical (non-vlan) interface. From jhary at unsane.co.uk Sun Jun 22 14:42:02 2008 From: jhary at unsane.co.uk (Vince Hoffman) Date: Sun Jun 22 14:42:05 2008 Subject: Use lagg(4) or Use Layer-4 Load Balancing? In-Reply-To: <1213846763.14151.1.camel@localhost> References: <1213691523.22762.16.camel@localhost> <20080618172216.GA76058@citylink.fud.org.nz> <1213846763.14151.1.camel@localhost> Message-ID: <485E647D.1030301@unsane.co.uk> Martes G Wigglesworth wrote: > I was attempting to find good information on how to achieve a type of > bonding using advanced routing on FreeBSD, such as with layer-4 routers, > that can bond multiple sources into a single overall larger source for > logical backbone creation for networks. > You could have a look at ng_one2many(4) I've never used it but it sounds like it could be what you are after according to the manpage. Vince > > On Wed, 2008-06-18 at 13:22 -0400, Andrew Thompson wrote: >> On Tue, Jun 17, 2008 at 04:32:03AM -0400, Martes G Wigglesworth wrote: >>> Greetings all. >>> >>> I have been attempting to research what I have been informed is >>> actually accomplished with layer-4 load balancing. I have seen many >>> articles and reviews that indicate that lagg(4) will accomplish the >>> teaming of multiple internet access sorces into a single logical pipe, >>> however, I have tried this using a dumb switch two nic interfaces and >>> this simply is not the case. >>> >>> I am new and may not have enough cool equipment around, however, aside >>> from using the fail-over mode for redundancy, and lacp on a supported >>> switch, then if lagg(4) could really combine multiple sources into one >>> for use as a larger overall backbone, then I should be able to get >>> doulbed bandwidth using two separate ports on an unmanaged switch using >>> some option on the lagg(4) driver, which is not the cast.(if this is >>> wrong I would be happy to get the correct information, however I have a >>> few network engineer references that say that you cannot do anything >>> more than layer-2 lacp with appropriate equipment to create an >>> isp-supported trunk) Even in the on-lamp interview the 7.0 developer >>> implies that you can do what I am attempting to research however, it is >>> not possible at layer 2 without an end-point. >> How are you testing this? You need to have multiple IP flows in order to >> fully utilise the multiple links. See this snippet from the handbook >> (i'll put it in the man page too). >> >> "Since frame ordering is mandatory on Ethernet links then any traffic >> between two stations always flows over the same physical link limiting >> the maximum speed to that of one interface. The transmit algorithm >> attempts to use as much information as it can to distinguish different >> traffic flows and balance across the available interfaces." >> >> >> Does that answer your question, you will not get more speed on a single >> download. >> >> >> Andrew >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From crapsh at monkeybrains.net Sun Jun 22 22:16:08 2008 From: crapsh at monkeybrains.net (Rudy) Date: Sun Jun 22 22:16:15 2008 Subject: Seeking help understanding my "emX: watchdog timeout" messages In-Reply-To: <485D5B9E.8020908@monkeybrains.net> References: <20080516185813.H866@logos.sky.od.ua> <2a41acea0805160904g7dcf9f58rf69ca5d0612945cc@mail.gmail.com> <4853055C.2030303@MonkeyBrains.NET> <48535A11.4020003@monkeybrains.net> <48582C29.8030307@monkeybrains.net> <2a41acea0806191055w5e112b8bsa57a8db2b177adbe@mail.gmail.com> <485C0F07.7000408@monkeybrains.net> <2a41acea0806201355y3b123462wc37280f28a9f4216@mail.gmail.com> <485C41C5.4090706@monkeybrains.net> <2a41acea0806201713m7a083b9dr10894c8a0845df8e@mail.gmail.com> <485D5B9E.8020908@monkeybrains.net> Message-ID: <485ECF20.6000607@monkeybrains.net> Reading if_em.h 77 * EM_TIDV - Transmit Interrupt Delay Value 78 * Valid Range: 0-65535 (0=off) 79 * Default Value: 64 80 * This value delays the generation of transmit interrupts in units of 81 * 1.024 microseconds. Transmit interrupt reduction can improve CPU 82 * efficiency if properly tuned for specific network traffic. If the 83 * system is reporting dropped transmits, this value may be set too high 84 * causing the driver to run out of available transmit descriptors. seems to indicate that 'dropped transmits' may be due to the 'tx_int_delay' being too high. So, I lowered the Transmit Interrupt Delay Values 33 useconds. I will report if this helps. Does anyone have experience using tuning these values? dev.em.2.tx_int_delay: 33 dev.em.2.tx_abs_int_delay: 33 The Intel docs explain the tx_int_delay vs the tx_abs_int_delay: "In [high traffic] situations, the absolute timer is the source of most device interrupts. Under light loads or brief bursts of traffic, the packet timers are the primary source of interrupts. In these situations, the packet timers determine the latency suffered by most packets. The packet timers also determine the minimum traffic rate required to trigger the absolute timer interrupts. For example, if the traffic rate is high enough to prevent the packet timer from ever expiring, then the GbE controller does not interrupt until the absolute timer has expired." That is why I picked a tx_abs_int_delay == tx_int_delay. The source code references running out of available transmit descriptors... Is there a way to bump up the number of available transmit descriptors or to change the packet buffer size? here is the dev.em.2.debug info: kernel: em2: Adapter hardware address = 0xc4d91224 kernel: em2: CTRL = 0x400c0241 RCTL = 0x8002 kernel: em2: Packet buffer = Tx=16k Rx=32k kernel: em2: Flow control watermarks high = 30720 low = 29220 kernel: em2: tx_int_delay = 32, tx_abs_int_delay = 32 kernel: em2: rx_int_delay = 0, rx_abs_int_delay = 66 kernel: em2: fifo workaround = 0, fifo_reset_count = 0 kernel: em2: hw tdh = 41, hw tdt = 41 kernel: em2: hw rdh = 130, hw rdt = 129 kernel: em2: Num Tx descriptors avail = 254 (Can I increase?) kernel: em2: Tx Descriptors not avail1 = 15 (Why not available?) kernel: em2: Tx Descriptors not avail2 = 0 kernel: em2: Std mbuf failed = 0 kernel: em2: Std mbuf cluster failed = 0 kernel: em2: Driver dropped packets = 0 kernel: em2: Driver tx dma failure in encap = 0 (not sure why tx_int_delay is 32 when I set it to 33... starts counting at 0?) Rudy Reference for if_em.h: http://fxr.watson.org/fxr/source/dev/em/if_em.h?v=FREEBSD7 Referenve for Absolute vs Packet timer: http://www.intel.com/design/network/applnots/ap450.pdf (page 12) From mav at FreeBSD.org Sun Jun 22 22:26:48 2008 From: mav at FreeBSD.org (mav@FreeBSD.org) Date: Sun Jun 22 22:26:50 2008 Subject: kern/123741: [netgraph] [panic] kernel panic due to netgraph mpd Message-ID: <200806222226.m5MMQl0I092726@freefall.freebsd.org> Synopsis: [netgraph] [panic] kernel panic due to netgraph mpd State-Changed-From-To: patched->closed State-Changed-By: mav State-Changed-When: Sun Jun 22 22:26:06 UTC 2008 State-Changed-Why: Patches merged, no more feedback received. http://www.freebsd.org/cgi/query-pr.cgi?pr=123741 From bugmaster at FreeBSD.org Mon Jun 23 11:06:58 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 23 11:07:24 2008 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200806231106.m5NB6wK0065034@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/92090 net [bge] bge0: watchdog timeout -- resetting f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau f kern/102344 net [ipf] Some packets do not pass through network interfa o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109733 net [bge] bge link state issues [regression] o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116328 net [bge]: Solid hang with bge interface o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117423 net [vlan] Duplicate IP on different interfaces o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119361 net [bge] bge(4) transmit performance problem o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122082 net [in_pcb] NULL pointer dereference in in_pcbdrop o kern/122195 net [ed] Alignment problems in if_ed f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix f kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar f conf/122858 net [nsswitch.conf] nsswitch in 7.0 is f*cked up o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 f kern/123172 net [bce] Watchdog timeout problems with if_bce o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123617 net [tcp] breaking connection when client downloading file o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123881 net [tcp] Turning on TCP blackholing causes slow localhost o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124540 net [tcp] RTM_MISS with the transit packets o kern/124753 net net80211 discards power-save queue packets early 90 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 o kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/95267 net packet drops periodically appear o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/112179 net [sis] [patch] sis driver for natsemi DP83815D autonego o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o bin/117339 net [patch] route(8): loading routing management commands o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/119432 net [arp] route add -host -iface causes arp e f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122068 net [ppp] ppp can not set the correct interface with pptpd p kern/122145 net error while compiling with device ath_rate_amrr o kern/122295 net [bge] bge Ierr rate increase (since 6.0R) [regression] o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122697 net [ath] Atheros card is not well supported o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge f kern/122839 net [multicast] FreeBSD 7 multicast routing problem o kern/122928 net [em] interface watchdog timeouts and stops receiving p o kern/123892 net [tap] [patch] No buffer space available p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o bin/124004 net ifconfig(8): Cannot assign both an IP and a MAC addres o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124609 net [ipsec] [panic] ipsec 'remainder too big' panic with p o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 54 problems total. From if at xip.at Mon Jun 23 11:35:06 2008 From: if at xip.at (Ingo Flaschberger) Date: Mon Jun 23 11:35:11 2008 Subject: CARP + multiple addresses In-Reply-To: References: <200806191435.m5JEZ4xs083455@lurza.secnetix.de> Message-ID: Patch was removed by mailinglist, use this link instead: http://xip.at/~transfer/ucarp-1.5_if.tar.bz2 Kind regards, ingo flaschberger geschaeftsleitung --------------------------- netstorage-crossip-flat:fee powered by crossip communications gmbh --------------------------- sebastian kneipp gasse 1 a-1020 wien fix: +43-1-726 15 22-217 fax: +43-1-726 15 22-111 --------------------------- On Thu, 19 Jun 2008, Ingo Flaschberger wrote: > Hi, > > problems with carp: > *) freebsd only allows 1 route > -> with a routing-protocol at the ucarp-machine > carp can not add the 2nd own route > *) carp can/could not use more than 1 subnet > *) carp can/could not bind to an interface > *) in a router environment carp fails to add routes > ... > > I decided to use ucarp but needed to modify it. see attached patch / scripts. > > I use ucarp now since 3 months in production. > > Kind regards, > ingo flaschberger > > geschaeftsleitung > --------------------------- > netstorage-crossip-flat:fee > powered by > crossip communications gmbh > --------------------------- > sebastian kneipp gasse 1 > a-1020 wien > fix: +43-1-726 15 22-217 > fax: +43-1-726 15 22-111 > --------------------------- From auryn at zirakzigil.org Mon Jun 23 19:59:59 2008 From: auryn at zirakzigil.org (Giulio Ferro) Date: Mon Jun 23 20:00:03 2008 Subject: Problem clarification (was: Problems with vlan + carp + alias) Message-ID: <486000B5.9090703@zirakzigil.org> After some more tests I've finally realized that the problem is with vlan and alias. I've taken carp out of the picture. (Please read my previous message on the topic to understand the scenario, I've reported it below) Here is what matters in /etc/rc.conf: ----------------------------------------------------------- ... ifconfig_bce0="inet 192.168.26.1 netmask 255.255.255.0" ... ifconfig_vlan128="inet x.y.z.132 netmask 255.255.255.224 vlan 128 vlandev bce0" ifconfig_vlan128_alias0="x.y.z.133 netmask 255.255.255.255" ifconfig_vlan128_alias1="x.y.z.134 netmask 255.255.255.255" ifconfig_vlan128_alias2="x.y.z.135 netmask 255.255.255.255" ifconfig_vlan128_alias3="x.y.z.136 netmask 255.255.255.255" ifconfig_vlan128_alias4="x.y.z.137 netmask 255.255.255.255" ifconfig_vlan128_alias5="x.y.z.138 netmask 255.255.255.255" ifconfig_vlan128_alias6="x.y.z.139 netmask 255.255.255.255" ifconfig_vlan128_alias7="x.y.z.140 netmask 255.255.255.255" ifconfig_vlan128_alias8="x.y.z.141 netmask 255.255.255.255" ... defaultrouter="x.y.z.129" ----------------------------------------------------------- netstat -rn ----------------------------------------------------------- default x.y.z.129 UGS 0 9869 vlan12 x.y.z.128/27 link#11 UC 0 0 vlan12 x.y.z.129 00:00:0c:07:ac:0a UHLW 2 52 vlan12 1107 x.y.z.130 00:d0:03:8a:9b:fc UHLW 1 0 vlan12 1147 x.y.z.131 00:d0:03:8a:9b:fd UHLW 1 0 vlan12 1144 x.y.z.133/32 link#11 UC 0 0 vlan12 x.y.z.134/32 link#11 UC 0 0 vlan12 x.y.z.135/32 link#11 UC 0 0 vlan12 x.y.z.136/32 link#11 UC 0 0 vlan12 x.y.z.137/32 link#11 UC 0 0 vlan12 x.y.z.138/32 link#11 UC 0 0 vlan12 x.y.z.139/32 link#11 UC 0 0 vlan12 x.y.z.140/32 link#11 UC 0 0 vlan12 x.y.z.141/32 link#11 UC 0 0 vlan12 ----------------------------------------------------------- ifconfig vlan128 ----------------------------------------------------------- vlan128: flags=8843 metric 0 mtu 1500 options=3 ether 00:1e:c9:ad:fa:c9 inet x.y.z.132 netmask 0xffffffe0 broadcast x.y.z.159 inet x.y.z.133 netmask 0xffffffff broadcast x.y.z.133 inet x.y.z.134 netmask 0xffffffff broadcast x.y.z.134 inet x.y.z.135 netmask 0xffffffff broadcast x.y.z.135 inet x.y.z.136 netmask 0xffffffff broadcast x.y.z.136 inet x.y.z.137 netmask 0xffffffff broadcast x.y.z.137 inet x.y.z.138 netmask 0xffffffff broadcast x.y.z.138 inet x.y.z.139 netmask 0xffffffff broadcast x.y.z.139 inet x.y.z.140 netmask 0xffffffff broadcast x.y.z.140 inet x.y.z.141 netmask 0xffffffff broadcast x.y.z.141 media: Ethernet autoselect (1000baseTX ) status: active vlan: 128 parent interface: bce0 ----------------------------------------------------------- Tests: No problem when I try to ping the default gateway from my fw No problem when I ping my fw from an external internet address Problems: - I cannot ping the router from one of the aliased address: ping -S x.y.z.133 x.y.z.129 - I cannot ping the aliased addresses from an external internet address Note : I can see the packets with tcpdump travelling from and to the aliased address. It seems the interface won't process them for some reason. This seems suspiciously like a bug to me... -------------------------------------------------------------------------------------- (previous message on vlan + carp +alias) -------------------------------------------------------------------------------------- Primeroz lists wrote: > What is tcpdump showing for ping on 192.168.10.11 > ? can you see echo reply exiting vlan10 > interface ? > > what if you try from your server to "ping -S 192.168.10.11 > 192.168.10.254 " ? > > > First of all I'm sorry for the late reply. Yesterday I could do some more in-depth test to analyze this strange behavior of my firewall. The 192.168.10.0/24 range I used in the previous example isn't the real one, I just used it for simplicity?s sake. The true range, the one which has been assigned by the ISP to my customer is: x.y.z.128/27. (x.y.z corresponds to a true public IP address) I've deactivated the firewall, so we have one less thing to worry about: /etc/rc.d/pf stop This is a pure network configuration issue. Here is the relevant part in /etc/rc.conf: --------------------------------------------------- ... ifconfig_bce0="inet 192.168.26.1 netmask 255.255.255.0" ... cloned_interfaces="vlan5 vlan25 vlan30 vlan40 vlan128 carp5 carp25 carp30 carp40 carp128" ... ifconfig_vlan128="inet x.y.z.157 netmask 255.255.255.224 vlan 128 vlandev bce0" ... ifconfig_carp128="vhid 128 pass qweq x.y.z.132 netmask 255.255.255.255" ifconfig_carp128_alias0="x.y.z.133 netmask 255.255.255.255" ifconfig_carp128_alias1="x.y.z.134 netmask 255.255.255.255" ifconfig_carp128_alias2="x.y.z.135 netmask 255.255.255.255" ifconfig_carp128_alias3="x.y.z.136 netmask 255.255.255.255" ifconfig_carp128_alias4="x.y.z.137 netmask 255.255.255.255" ifconfig_carp128_alias5="x.y.z.138 netmask 255.255.255.255" ifconfig_carp128_alias6="x.y.z.139 netmask 255.255.255.255" ifconfig_carp128_alias7="x.y.z.140 netmask 255.255.255.255" ifconfig_carp128_alias8="x.y.z.141 netmask 255.255.255.255" ... defaultrouter="x.y.z.129" --------------------------------------------------- On my managed switch I've set 2 ports: 1) the one where the bce0 interface is plugged in : mode trunk with all the vlans above 2) the one where the ISP internet is plugged in : mode access with vlan 128 I've also set the ip interface of my switch to x.y.z.155 vlan 128 Here is the relevant part of netstat -rn on my machine --------------------------------------------------- default x.y.z.129 UGS 0 13966 vlan12 x.y.z/27 link#11 UC 0 0 vlan12 x.y.z.132 x.y.z.132 UH 0 0 carp12 x.y.z.133 x.y.z.133 UH 0 0 carp12 x.y.z.134 x.y.z.134 UH 0 0 carp12 x.y.z.135 x.y.z135 UH 0 0 carp12 x.y.z.136 x.y.z.136 UH 0 0 carp12 x.y.z.137 x.y.z.137 UH 0 0 carp12 x.y.z.138 x.y.z.138 UH 0 0 carp12 x.y.z.139 x.y.z.139 UH 0 0 carp12 x.y.z.140 x.y.z.140 UH 0 0 carp12 x.y.z.141 x.y.z.141 UH 0 0 carp12 x.y.z.155 00:1e:c9:90:4a:c0 UHLW 1 8 vlan12 1183 --------------------------------------------------- Here come the tests. 1) From the firewall : basic I can ping both the default gateway (x.y.z.129) and the switch interface (x.y.z.155) I can ping a generic internet address (a.b.c.d) With tcpdump I can see the packets leaving as x.y.z.157 and coming with the same address 2) from the switch : basic I can ping the firewall's vlan address (x.y.z.157) I can ping _ALL_ the carp interfaces, base and alias: ping x.y.z.157 -> OK ping x.y.z.132 -> OK ping x.y.z.133 -> OK ... ping x.y.z.141 -> OK 3) from the internet : basic From an external internet address I can ping the vlan address: ping x.y.z.157 -> OK 4) from the firewall : advanced From the firewall I can ping the switch address from one of the carp base and aliased address: ping -S x.y.z.132 x.y.z.155 -> OK ping -S x.y.z.133 x.y.z.155 -> OK I _cannot_ ping the default router from one of the carp addresses: ping -S x.y.z.132 x.y.z.129 -> NOT OK ping -S x.y.z.133 x.y.z.129 -> NOT OK By using tcpdump on the vlan128 interface I can see the packets _BOTH_ leaving and coming from the carp addresses. It just seems that the carp interfaces can't process the packets properly. 5) from the internet : advanced From an external internet address I _cannot_ ping the carp addresses (x.y.z.132 and up) As above, I can see the incoming packets with tcpdump -i vlan128 -n icmp Ok, that was long. I hope someone can help to shed light into this, to see whether this is a bug or not. I stress again that the _same_ configuration works as it should on a physical (non-vlan) interface. From snb at freebsd.org Tue Jun 24 04:01:07 2008 From: snb at freebsd.org (Nick Barkas) Date: Tue Jun 24 04:01:32 2008 Subject: reference count bug in sys/netinet/in.c on 6.3 Message-ID: There was a bug in sys/netinet/in.c that was fixed in the RELENG_6 branch, in revision 1.85.2.10 (see http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/in.c.diff?r1=1.85.2.9;r2=1.85.2.10). But, this fix hasn't yet made it into RELENG_6_3. I had a machine panic on this bug, so I have patched the kernels on all of my 6.3 machines, but I am wondering if this fix might eventually get merged into RELENG_6_3 and perhaps get an errata update. There was talk about this on freebsd-stable a couple months ago: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2008-04/msg00158.html I have quite a few machines running 6.3 and they will likely continue to do so until it hits end of life. Most use GENERIC or SMP kernels, so I'd like to be able to install any future updates to their kernels using freebsd-update. I imagine I'm not the only one who wants to do this. So, any chance on this fix being applied to RELENG_6_3 so it is possible to apply it in the future with freebsd-update? Nick From linimon at FreeBSD.org Tue Jun 24 08:14:49 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue Jun 24 08:14:51 2008 Subject: kern/124904: [fxp] EEPROM corruption with Compaq NC3163 NIC Message-ID: <200806240814.m5O8Emu4025069@freefall.freebsd.org> Old Synopsis: EEPROM corruption with Compaq NC3163 NIC New Synopsis: [fxp] EEPROM corruption with Compaq NC3163 NIC Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Jun 24 08:14:04 UTC 2008 Responsible-Changed-Why: Reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=124904 From stefan.lambrev at moneybookers.com Tue Jun 24 12:58:34 2008 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Tue Jun 24 12:58:38 2008 Subject: jboss4 on freebsd Message-ID: <4860EF76.1050807@moneybookers.com> Greetings, I'm experimenting with jboss4 cluster under freebsd 7 (amd64). In my configuration I have 2 jboss instances which are in cluster and they communicate via separate network (used only for shared data) When I create some load on the application sometimes I see this error: 2008-06-24 14:46:21,602 ERROR [org.jgroups.protocols.UDP] failed sending message to 10.50.1.1:57680 (59800 bytes) java.io.IOException: No buffer space available It looks very much, that jboss can't handle properly such error as on linux there is no such thing as no network buffers ;) - http://wiki.freebsd.org/AvoidingLinuxisms But what really bothers me is that I see "No buffer space available" on very low network IO - input (em2) output packets errs bytes packets errs bytes colls 144 0 2203390 292 0 2072771 0 1568 0 2329764 63 0 9099 0 76 0 231562 34 0 148306 0 563 0 1152531 1009 0 1768748 0 1625 0 2601502 104 0 229728 0 65 0 467296 85 0 441566 0 464 0 680082 973 0 1439442 0 357 0 1940361 55 0 222484 0 1651 0 2827932 145 0 450265 0 E.g. traffic between 1-3MB/s. I'm using: em2: flags=8843 metric 0 mtu 9000 options=19b ether 00:15:17:60:04:c8 inet 10.3.3.117 netmask 0xffffff00 broadcast 10.3.3.255 media: Ethernet autoselect (1000baseTX ) status: active em2: port 0x2020-0x203f mem 0xb8820000-0xb883ffff,0xb8400000-0xb87fffff irq 18 at device 0.0 on pci5 em2: Using MSI interrupt em2: [FILTER] and my sysctl.conf is: kern.maxfiles=65000 kern.ipc.shmmax=67108864 kern.fallback_elf_brand=3 kern.threads.max_threads_per_proc=6000 kern.ipc.somaxconn=512 #jboss extra net.inet.udp.maxdgram=73728 kern.ipc.maxsockbuf=1048576 net.inet.udp.recvspace=147456 kern.ipc.maxsockets=49312 Any ideas how I can improve things? -- Best Wishes, Stefan Lambrev ICQ# 24134177 From stefan.lambrev at moneybookers.com Tue Jun 24 13:16:11 2008 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Tue Jun 24 13:16:19 2008 Subject: jboss4 on freebsd In-Reply-To: <4860F0FA.1010707@gtcomm.net> References: <4860EF76.1050807@moneybookers.com> <4860F0FA.1010707@gtcomm.net> Message-ID: <4860F395.1010000@moneybookers.com> Paul wrote: > kern.ipc.nmbclusters=128000 changed - no effect > > Check output from netstat -m, this shows network buffers. 770/8200/8970 mbufs in use (current/cache/total) 768/5426/6194/128000 mbuf clusters in use (current/cache/total/max) 768/5248 mbuf+clusters out of packet secondary zone in use (current/cache) 0/677/677/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 1728K/15610K/17338K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 73 requests for I/O initiated by sendfile 0 calls to protocol drain routines This output is in the same second as I see no buffer space available .. isn't this weird? > > > Stefan Lambrev wrote: >> Greetings, >> >> I'm experimenting with jboss4 cluster under freebsd 7 (amd64). >> In my configuration I have 2 jboss instances which are in cluster and >> they communicate via separate network (used only for shared data) >> When I create some load on the application sometimes I see this error: >> >> 2008-06-24 14:46:21,602 ERROR [org.jgroups.protocols.UDP] failed >> sending message to 10.50.1.1:57680 (59800 bytes) >> java.io.IOException: No buffer space available >> >> It looks very much, that jboss can't handle properly such error as on >> linux there is no such thing as no network buffers ;) - >> http://wiki.freebsd.org/AvoidingLinuxisms >> >> But what really bothers me is that I see "No buffer space available" >> on very low network IO - >> >> input (em2) output >> packets errs bytes packets errs bytes colls >> 144 0 2203390 292 0 2072771 0 >> 1568 0 2329764 63 0 9099 0 >> 76 0 231562 34 0 148306 0 >> 563 0 1152531 1009 0 1768748 0 >> 1625 0 2601502 104 0 229728 0 >> 65 0 467296 85 0 441566 0 >> 464 0 680082 973 0 1439442 0 >> 357 0 1940361 55 0 222484 0 >> 1651 0 2827932 145 0 450265 0 >> >> E.g. traffic between 1-3MB/s. >> >> I'm using: >> em2: flags=8843 metric 0 mtu >> 9000 >> >> options=19b >> ether 00:15:17:60:04:c8 >> inet 10.3.3.117 netmask 0xffffff00 broadcast 10.3.3.255 >> media: Ethernet autoselect (1000baseTX ) >> status: active >> >> em2: port 0x2020-0x203f >> mem 0xb8820000-0xb883ffff,0xb8400000-0xb87fffff irq 18 at device 0.0 >> on pci5 >> em2: Using MSI interrupt >> em2: [FILTER] >> >> and my sysctl.conf is: >> kern.maxfiles=65000 >> kern.ipc.shmmax=67108864 >> kern.fallback_elf_brand=3 >> kern.threads.max_threads_per_proc=6000 >> kern.ipc.somaxconn=512 >> #jboss extra >> net.inet.udp.maxdgram=73728 >> kern.ipc.maxsockbuf=1048576 >> net.inet.udp.recvspace=147456 >> kern.ipc.maxsockets=49312 >> >> Any ideas how I can improve things? >> > -- Best Wishes, Stefan Lambrev ICQ# 24134177 From _pppp at mail.ru Tue Jun 24 15:08:38 2008 From: _pppp at mail.ru (Dmitriy) Date: Tue Jun 24 15:08:42 2008 Subject: jboss4 on freebsd In-Reply-To: <4860EF76.1050807@moneybookers.com> References: <4860EF76.1050807@moneybookers.com> Message-ID: -----Original Message----- From: Stefan Lambrev To: freebsd-net@FreeBSD.org Date: Tue, 24 Jun 2008 15:58:30 +0300 Subject: jboss4 on freebsd > > Greetings, > > I'm experimenting with jboss4 cluster under freebsd 7 (amd64). > In my configuration I have 2 jboss instances which are in cluster and > they communicate via separate network (used only for shared data) > When I create some load on the application sometimes I see this error: > > 2008-06-24 14:46:21,602 ERROR [org.jgroups.protocols.UDP] failed sending > message to 10.50.1.1:57680 (59800 bytes) > java.io.IOException: No buffer space available > > It looks very much, that jboss can't handle properly such error as on > linux there is no such thing as no network buffers ;) - > http://wiki.freebsd.org/AvoidingLinuxisms > > But what really bothers me is that I see "No buffer space available" on > very low network IO - > > input (em2) output > packets errs bytes packets errs bytes colls > 144 0 2203390 292 0 2072771 0 > 1568 0 2329764 63 0 9099 0 > 76 0 231562 34 0 148306 0 > 563 0 1152531 1009 0 1768748 0 > 1625 0 2601502 104 0 229728 0 > 65 0 467296 85 0 441566 0 > 464 0 680082 973 0 1439442 0 > 357 0 1940361 55 0 222484 0 > 1651 0 2827932 145 0 450265 0 > > E.g. traffic between 1-3MB/s. > > I'm using: > em2: flags=8843 metric 0 mtu 9000 > options=19b > ether 00:15:17:60:04:c8 > inet 10.3.3.117 netmask 0xffffff00 broadcast 10.3.3.255 > media: Ethernet autoselect (1000baseTX ) > status: active > > em2: port 0x2020-0x203f mem > 0xb8820000-0xb883ffff,0xb8400000-0xb87fffff irq 18 at device 0.0 on pci5 > em2: Using MSI interrupt > em2: [FILTER] > > and my sysctl.conf is: > kern.maxfiles=65000 > kern.ipc.shmmax=67108864 > kern.fallback_elf_brand=3 > kern.threads.max_threads_per_proc=6000 > kern.ipc.somaxconn=512 > #jboss extra > net.inet.udp.maxdgram=73728 > kern.ipc.maxsockbuf=1048576 > net.inet.udp.recvspace=147456 > kern.ipc.maxsockets=49312 > > Any ideas how I can improve things? > I guess you get the error from the NIC driver. There 2 conditions which can trigger it: 1. if( adapter->num_tx_desc_avail < EM_TX_OP_THRESHOLD ) 2. if( nsegs > ( adapter->num_tx_desc_avail - 2 ) ) I have 2 suggestions how to fix your error: 1. try to disable TXCSUM ( #ifconfig em2 -txcsum ) 2. increase the number of transfer descriptors available if your hardware supports it: [man em(4) excerpt] Tunables can be set at the loader(8) prompt before booting the kernel or stored in loader.conf(5). hw.em.txd Number of transmit descriptors allocated by the driver. The default value is 256. The 82542 and 82543-based adapters can handle up to 256 descriptors, while others can have up to 4096. hw.em.tx_int_delay This value delays the generation of transmit interrupts in units of 1.024 microseconds. The default value is 64. hw.em.tx_abs_int_delay If hw.em.tx_int_delay is non-zero, this tunable limits the maxi- mum delay in which a transmit interrupt is generated. [/man] Regards, Dmitriy. From paul at gtcomm.net Tue Jun 24 15:24:41 2008 From: paul at gtcomm.net (Paul) Date: Tue Jun 24 15:24:48 2008 Subject: Route messages In-Reply-To: <4854EBF1.7020708@FreeBSD.org> References: <4852E23E.2040505@gtcomm.net> <4854EBF1.7020708@FreeBSD.org> Message-ID: <48611231.6000603@gtcomm.net> 2574 output packets discarded due to no route 2904 output datagrams fragmented 5808 fragments created not incrementing.. route monitor....: got message of size 160 on Tue Jun 24 10:59:04 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default got message of size 160 on Tue Jun 24 10:59:04 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default got message of size 160 on Tue Jun 24 10:59:04 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default got message of size 160 on Tue Jun 24 10:59:04 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default got message of size 160 on Tue Jun 24 10:59:04 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default got message of size 160 on Tue Jun 24 10:59:04 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default got message of size 160 on Tue Jun 24 10:59:04 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default got message of size 160 on Tue Jun 24 10:59:04 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default got message of size 160 on Tue Jun 24 10:59:04 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default I don't get it.. :/ I do have a default route.. grr. :P Must be something to do with GRE but I can't recreate it on -RELEASE, only -STABLE and I don't see any differences in -STABLE that might cause it except maybe the EM driver? But I don't see how that would do it.. The only difference in route.c from RELEASE to STABLE is : - * $FreeBSD: src/sys/net/route.c,v 1.120.2.1.2.1 2008/01/09 15:23:36 mux Exp $ + * $FreeBSD: src/sys/net/route.c,v 1.120.2.3 2008/03/05 20:33:46 jhb Exp $ */ #include "opt_inet.h" @@ -396,7 +396,7 @@ error = EHOSTUNREACH; done: if (rt) - rtfree(rt); + RTFREE_LOCKED(rt); out: if (error) rtstat.rts_badredirect++; Hrm.. what's a good way to disable the RT_MISS messages .. I guess ill have to add a check to see if msgtype=RTM_MISS and bypass the reporting... Is there a way to make it report what the source ip address it is trying to find a route for? Thanks Paul Bruce M. Simpson wrote: > Paul wrote: >> Get these with GRE tunnel on >> FreeBSD 7.0-STABLE FreeBSD 7.0-STABLE #5: Sun May 11 19:00:57 EDT >> 2008 :/usr/obj/usr/src/sys/ROUTER amd64 >> But do not get them with 7.0-RELEASE >> >> Any ideas what changed? :) Wish there was some sort of changelog.. >> # of messages per second seems consistent with packets per second on >> GRE interface.. >> No impact in routing, but definitely impact in cpu usage for all >> processes monitoring the route messages. > > RTM_MISS is actually fairly common when you don't have a default route. > > Messages which get enqueued don't necessarily get delivered -- and > very few processes actually listen to the routing socket actively like > this, so I wouldn't worry about it. > > If it's a real concern for you then you could try hacking in a sysctl > to tell the radix trie code not to issue RTM_MISS messages on the > routing socket. > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From julian at elischer.org Tue Jun 24 17:46:32 2008 From: julian at elischer.org (Julian Elischer) Date: Tue Jun 24 17:46:36 2008 Subject: jboss4 on freebsd In-Reply-To: <4860F395.1010000@moneybookers.com> References: <4860EF76.1050807@moneybookers.com> <4860F0FA.1010707@gtcomm.net> <4860F395.1010000@moneybookers.com> Message-ID: <48613304.7090204@elischer.org> Stefan Lambrev wrote: > > > Paul wrote: >> kern.ipc.nmbclusters=128000 > changed - no effect >> if this is udp or some datagram traffic then it is telling you that the interface queue has filled up.. >> Check output from netstat -m, this shows network buffers. > 770/8200/8970 mbufs in use (current/cache/total) > 768/5426/6194/128000 mbuf clusters in use (current/cache/total/max) > 768/5248 mbuf+clusters out of packet secondary zone in use (current/cache) > 0/677/677/12800 4k (page size) jumbo clusters in use > (current/cache/total/max) > 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) > 1728K/15610K/17338K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0/0/0 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 73 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > > This output is in the same second as I see no buffer space available .. > isn't this weird? >> >> >> Stefan Lambrev wrote: >>> Greetings, >>> >>> I'm experimenting with jboss4 cluster under freebsd 7 (amd64). >>> In my configuration I have 2 jboss instances which are in cluster and >>> they communicate via separate network (used only for shared data) >>> When I create some load on the application sometimes I see this error: >>> >>> 2008-06-24 14:46:21,602 ERROR [org.jgroups.protocols.UDP] failed >>> sending message to 10.50.1.1:57680 (59800 bytes) >>> java.io.IOException: No buffer space available >>> >>> It looks very much, that jboss can't handle properly such error as on >>> linux there is no such thing as no network buffers ;) - >>> http://wiki.freebsd.org/AvoidingLinuxisms >>> >>> But what really bothers me is that I see "No buffer space available" >>> on very low network IO - >>> >>> input (em2) output >>> packets errs bytes packets errs bytes colls >>> 144 0 2203390 292 0 2072771 0 >>> 1568 0 2329764 63 0 9099 0 >>> 76 0 231562 34 0 148306 0 >>> 563 0 1152531 1009 0 1768748 0 >>> 1625 0 2601502 104 0 229728 0 >>> 65 0 467296 85 0 441566 0 >>> 464 0 680082 973 0 1439442 0 >>> 357 0 1940361 55 0 222484 0 >>> 1651 0 2827932 145 0 450265 0 >>> >>> E.g. traffic between 1-3MB/s. >>> >>> I'm using: >>> em2: flags=8843 metric 0 mtu >>> 9000 >>> >>> options=19b >>> ether 00:15:17:60:04:c8 >>> inet 10.3.3.117 netmask 0xffffff00 broadcast 10.3.3.255 >>> media: Ethernet autoselect (1000baseTX ) >>> status: active >>> >>> em2: port 0x2020-0x203f >>> mem 0xb8820000-0xb883ffff,0xb8400000-0xb87fffff irq 18 at device 0.0 >>> on pci5 >>> em2: Using MSI interrupt >>> em2: [FILTER] >>> >>> and my sysctl.conf is: >>> kern.maxfiles=65000 >>> kern.ipc.shmmax=67108864 >>> kern.fallback_elf_brand=3 >>> kern.threads.max_threads_per_proc=6000 >>> kern.ipc.somaxconn=512 >>> #jboss extra >>> net.inet.udp.maxdgram=73728 >>> kern.ipc.maxsockbuf=1048576 >>> net.inet.udp.recvspace=147456 >>> kern.ipc.maxsockets=49312 >>> >>> Any ideas how I can improve things? >>> >> > From freebsd-lists-erik at erikosterholm.org Tue Jun 24 21:42:09 2008 From: freebsd-lists-erik at erikosterholm.org (Erik Osterholm) Date: Tue Jun 24 21:42:12 2008 Subject: Why isn't ALTQ in GENERIC? Message-ID: <20080624212639.GA41755@aleph.cepheid.org> Hi all, Can anyone tell me if there are good reasons for explicitly leaving ALTQ out of the kernel? More specific to my circumstances, if I'm building kernels to be installed on every machine we deploy, is it worth building a separate kernel for ALTQ for those few boxes which will require it? Are there performance issues? Stability issues? Ultimately, I'm just surprised that it's not available in GENERIC if there isn't a good reason, but I can't find any documentation for that reason. If you can answer the same question for IPSEC, that would be nice, too! Erik From max.laier at tm.uka.de Wed Jun 25 01:28:46 2008 From: max.laier at tm.uka.de (Max Laier) Date: Wed Jun 25 01:28:51 2008 Subject: Why isn't ALTQ in GENERIC? In-Reply-To: <20080624212639.GA41755@aleph.cepheid.org> References: <20080624212639.GA41755@aleph.cepheid.org> Message-ID: <4c5bca29cfc1cdd3efa81ffb2f815675.squirrel@router> Hi Erik, Am Di, 24.06.2008, 23:26, schrieb Erik Osterholm: > Can anyone tell me if there are good reasons for explicitly leaving > ALTQ out of the kernel? More specific to my circumstances, if I'm > building kernels to be installed on every machine we deploy, is it > worth building a separate kernel for ALTQ for those few boxes which > will require it? > > Are there performance issues? Stability issues? Ultimately, I'm just > surprised that it's not available in GENERIC if there isn't a good > reason, but I can't find any documentation for that reason. Short answer: Historical reasons. Whole stroy: When ALTQ was added there were both performance and stability concerns. For a long time we had a big #ifdef ALTQ in if_var.h to avoid one additional check for if_queue enqueue opperations. These are now gone and I personally don't see any issues that would prevent ALTQ from being in GENERIC. However, it's unclear which disceplines to turn on by default. I'd like to see ALTQ in GERNERIC, but I've been reluctant to make the change on my own. If we can get a quorum here, I'll reconsider it. > If you can answer the same question for IPSEC, that would be nice, > too! Size? -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From mgrooms at shrew.net Wed Jun 25 03:27:55 2008 From: mgrooms at shrew.net (mgrooms) Date: Wed Jun 25 03:27:59 2008 Subject: FreeBSD NAT-T patch integration Message-ID: <0efb44e3c6c6603e69207eb15fec2718@localhost> All, Is anyone currently looking at the IPsec NAT-T patches? I posted a similar question several months ago around the FAST_IPSEC + IPv6 integration time frame. Maybe now that things have settled a bit, this work can be reviewed and possibly committed? Thanks, -Matthew From freebsd at meijome.net Wed Jun 25 04:21:22 2008 From: freebsd at meijome.net (Norberto Meijome) Date: Wed Jun 25 04:21:26 2008 Subject: FreeBSD NAT-T patch integration In-Reply-To: <0efb44e3c6c6603e69207eb15fec2718@localhost> References: <0efb44e3c6c6603e69207eb15fec2718@localhost> Message-ID: <20080625135437.32e7a1f9@ayiin> On Tue, 24 Jun 2008 22:01:46 -0500 mgrooms wrote: > Is anyone currently looking at the IPsec NAT-T patches? I posted a similar > question several months ago around the FAST_IPSEC + IPv6 integration time > frame. Maybe now that things have settled a bit, this work can be reviewed > and possibly committed? +1 _________________________ {Beto|Norberto|Numard} Meijome "Truth has no special time of its own. Its hour is now -- always." Albert Schweitzer I speak for myself, not my employer. Contents may be hot. Slippery when wet. Reading disclaimers makes you go blind. Writing them is worse. You have been Warned. From mkasper at monzoon.net Wed Jun 25 08:20:04 2008 From: mkasper at monzoon.net (Manuel Kasper) Date: Wed Jun 25 08:20:07 2008 Subject: kern/122295: [bge] bge Ierr rate increase (since 6.0R) [regression] Message-ID: <200806250820.m5P8K30M010556@freefall.freebsd.org> The following reply was made to PR kern/122295; it has been noted by GNATS. From: "Manuel Kasper" To: Cc: Subject: Re: kern/122295: [bge] bge Ierr rate increase (since 6.0R) [regression] Date: Wed, 25 Jun 2008 09:48:29 +0200 We've been experiencing the same issue with BCM5704 B0 in HP ProLiant DL360 G4 servers. The Ierrs are correlated with packet loss (which is why we noticed the problem in the first place); however for us, the patch in completely fixes the problem and doesn't seem to introduce any problems with link state detection (cable disconnect/reconnect, changing link speed on remote end etc. all work fine). Also, OpenBSD already has essentially the same fix (with some dubious style changes) in its repository: The problem appears in both FreeBSD 6.3-RELEASE and 7.0-RELEASE. This is how things look without the fix (regardless of what link speed is used): ---- Router#ping 192.168.4.1 repeat 1000 size 1500 Type escape sequence to abort. Sending 1000, 1500-byte ICMP Echos to 192.168.4.1, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!! Success rate is 98 percent (983/1000), round-trip min/avg/max =3D 1/1/4 = ms ---- -> Pings from Cisco routers are especially likely to show the issue, as apparently mii_tick() and the pings from the Cisco occur synchronously for a while. TCP throughput isn't affected very much. Related dmesg output: bge0: mem 0xfdd70000-0xfdd7ffff irq 25 at device 2.0 on pci2 miibus1: on bge0 brgphy0: on miibus1 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge0: Ethernet address: 00:18:71:e4:xx:xx pciconf -lv: bge0@pci2:2:0: class=3D0x020000 card=3D0x00d00e11 chip=3D0x164814e4 = rev=3D0x10 hdr=3D0x00 vendor =3D 'Broadcom Corporation' device =3D 'BCM5704 NetXtreme Dual Gigabit Adapter' class =3D network subclass =3D ethernet From sullrich at gmail.com Wed Jun 25 15:15:29 2008 From: sullrich at gmail.com (Scott Ullrich) Date: Wed Jun 25 15:15:39 2008 Subject: FreeBSD NAT-T patch integration In-Reply-To: <20080625135437.32e7a1f9@ayiin> References: <0efb44e3c6c6603e69207eb15fec2718@localhost> <20080625135437.32e7a1f9@ayiin> Message-ID: On Tue, Jun 24, 2008 at 11:54 PM, Norberto Meijome wrote: > On Tue, 24 Jun 2008 22:01:46 -0500 > mgrooms wrote: > >> Is anyone currently looking at the IPsec NAT-T patches? I posted a similar >> question several months ago around the FAST_IPSEC + IPv6 integration time >> frame. Maybe now that things have settled a bit, this work can be reviewed >> and possibly committed? > > +1 Both m0n0wall and pfSense also use NAT-T. It sure would be nice to have it in FreeBSD so we can discontinue our patching every time we move to a newer FreeBSD revision. Scott From freebsd-net at transip.nl Wed Jun 25 18:01:13 2008 From: freebsd-net at transip.nl (Ali Niknam) Date: Wed Jun 25 18:01:18 2008 Subject: FreeBSD 7.0: sockets stuck in CLOSED state... Message-ID: <486283B0.3060805@transip.nl> Dear All, Recently i've been upgrading some of my machines from FreeBSD 6.x amd64 to FreeBSD 7.0 amd64. After upgrading I noticed a weird error/bug. It seems that after several thousand TCP connections some seem to hang in 'CLOSED' state. netstat -n gives: ... tcp4 0 0 1.2.3.4.* 4.5.6.7.42149 CLOSED tcp4 39 0 1.2.3.4.* 4.5.6.7.54103 CLOSED tcp4 35 0 1.2.3.4.* 4.5.6.7.41718 CLOSED tcp4 38 0 1.2.3.4.* 4.5.6.7.55618 CLOSED tcp4 41 0 1.2.3.4.* 4.5.6.7.44230 CLOSED tcp4 39 0 1.2.3.4.* 4.5.6.7.49439 CLOSED ... These never go away; they gradually increase and increase until the application starts giving errors (probably because some socket or filedescriptor limit is reached). When the application is killed these entries disappear. The application in question is a self written DNS server, multithreaded, and running fine for years without any troubles on both BSD 5.x as well as 6.x. Also 32bits as well as 64bits on 6.x. Ofcourse that doesn't mean that the application is error free, however, after doing extensive testing I really can not find anything wrong with the application itself, so I'm thinking maybe there's a change somewhere that causes this? I know that tcp/network has been completely redone... What basically happens in the application is this: - one main tcp thread runs an infinite while loop waiting for new connections to arrive - as soon as one arrives a new thread is spawned that handles the newly created stream - it reads some bytes, writes some bytes, then closes it - thread exits What appears to happen is this: after the new thread is spawned it tries to read 2 bytes (DNS tcp length information). It gets back 0 bytes (EOF) and therefore closes the sockets and calls pthread_exit. However in netstat that same stream oftenly appears to have bytes 'stuck' in the in queue... I really can't see how this can cause hanging sockets in 'CLOSED' state. Even if the incoming queue isnt read entirely a call to close should close it. Also I really can't find any documentation in netstat, or elsewhere, about the 'CLOSED' state... Any help would greatly be appreciated! Kind Regards, Ali Niknam From julian at elischer.org Wed Jun 25 18:36:04 2008 From: julian at elischer.org (Julian Elischer) Date: Wed Jun 25 18:36:08 2008 Subject: FreeBSD NAT-T patch integration In-Reply-To: References: <0efb44e3c6c6603e69207eb15fec2718@localhost> <20080625135437.32e7a1f9@ayiin> Message-ID: <48629020.8000207@elischer.org> Scott Ullrich wrote: > On Tue, Jun 24, 2008 at 11:54 PM, Norberto Meijome wrote: >> On Tue, 24 Jun 2008 22:01:46 -0500 >> mgrooms wrote: >> >>> Is anyone currently looking at the IPsec NAT-T patches? I posted a similar >>> question several months ago around the FAST_IPSEC + IPv6 integration time >>> frame. Maybe now that things have settled a bit, this work can be reviewed >>> and possibly committed? >> +1 > > Both m0n0wall and pfSense also use NAT-T. It sure would be nice to > have it in FreeBSD so we can discontinue our patching every time we > move to a newer FreeBSD revision. > > Scott > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" where is the patch? From sullrich at gmail.com Wed Jun 25 18:44:39 2008 From: sullrich at gmail.com (Scott Ullrich) Date: Wed Jun 25 18:44:43 2008 Subject: FreeBSD NAT-T patch integration In-Reply-To: <48629020.8000207@elischer.org> References: <0efb44e3c6c6603e69207eb15fec2718@localhost> <20080625135437.32e7a1f9@ayiin> <48629020.8000207@elischer.org> Message-ID: On Wed, Jun 25, 2008 at 2:36 PM, Julian Elischer wrote: > > > where is the patch? > > The version that we use in RELENG_7_0 is located here: http://cvs.pfsense.org/cgi-bin/cvsweb.cgi/tools/patches/RELENG_7_0/patch-natt-freebsd7-2008-03-11.diff?rev=1.1;content-type=text%2Fplain Thanks Julian! Scott From ali at transip.nl Wed Jun 25 18:46:12 2008 From: ali at transip.nl (Ali Niknam) Date: Wed Jun 25 18:46:16 2008 Subject: FreeBSD 7.0: sockets stuck in CLOSED state... In-Reply-To: References: <486283B0.3060805@transip.nl> Message-ID: <48628E13.40207@transip.nl> > This looks like an issue we used to have at work, where a streaming > application suddenly started getting kevents for sockets that had been > already closed. While that was happening, a netstat output looked just > like yours. We never tracked it down, as we moved to other projects :( > > Was that BSD 7.0 also? -- Transip BV | http://www.transip.nl/ We never let you down. From dudu at dudu.ro Wed Jun 25 18:46:46 2008 From: dudu at dudu.ro (Vlad GALU) Date: Wed Jun 25 18:46:50 2008 Subject: FreeBSD 7.0: sockets stuck in CLOSED state... In-Reply-To: <486283B0.3060805@transip.nl> References: <486283B0.3060805@transip.nl> Message-ID: On 6/25/08, Ali Niknam wrote: > Dear All, > > Recently i've been upgrading some of my machines from FreeBSD 6.x amd64 to > FreeBSD 7.0 amd64. > > After upgrading I noticed a weird error/bug. It seems that after several > thousand TCP connections some seem to hang in 'CLOSED' state. > > netstat -n gives: > ... > tcp4 0 0 1.2.3.4.* 4.5.6.7.42149 CLOSED > tcp4 39 0 1.2.3.4.* 4.5.6.7.54103 CLOSED > tcp4 35 0 1.2.3.4.* 4.5.6.7.41718 CLOSED > tcp4 38 0 1.2.3.4.* 4.5.6.7.55618 CLOSED > tcp4 41 0 1.2.3.4.* 4.5.6.7.44230 CLOSED > tcp4 39 0 1.2.3.4.* 4.5.6.7.49439 CLOSED > ... > > These never go away; they gradually increase and increase until the > application starts giving errors (probably because some socket or > filedescriptor limit is reached). When the application is killed these > entries disappear. > > The application in question is a self written DNS server, multithreaded, > and running fine for years without any troubles on both BSD 5.x as well as > 6.x. Also 32bits as well as 64bits on 6.x. > > Ofcourse that doesn't mean that the application is error free, however, > after doing extensive testing I really can not find anything wrong with the > application itself, so I'm thinking maybe there's a change somewhere that > causes this? I know that tcp/network has been completely redone... > > What basically happens in the application is this: > - one main tcp thread runs an infinite while loop waiting for new > connections to arrive > - as soon as one arrives a new thread is spawned that handles the newly > created stream > - it reads some bytes, writes some bytes, then closes it > - thread exits > > What appears to happen is this: after the new thread is spawned it tries to > read 2 bytes (DNS tcp length information). It gets back 0 bytes (EOF) and > therefore closes the sockets and calls pthread_exit. However in netstat that > same stream oftenly appears to have bytes 'stuck' in the in queue... > > I really can't see how this can cause hanging sockets in 'CLOSED' state. > Even if the incoming queue isnt read entirely a call to close should close > it. Also I really can't find any documentation in netstat, or elsewhere, > about the 'CLOSED' state... > > > Any help would greatly be appreciated! > > > Kind Regards, > > > Ali Niknam > _______________________________________________ This looks like an issue we used to have at work, where a streaming application suddenly started getting kevents for sockets that had been already closed. While that was happening, a netstat output looked just like yours. We never tracked it down, as we moved to other projects :( -- ~/.signature: no such file or directory From dudu at dudu.ro Wed Jun 25 18:55:43 2008 From: dudu at dudu.ro (Vlad GALU) Date: Wed Jun 25 18:55:47 2008 Subject: FreeBSD 7.0: sockets stuck in CLOSED state... In-Reply-To: <48628E13.40207@transip.nl> References: <486283B0.3060805@transip.nl> <48628E13.40207@transip.nl> Message-ID: On 6/25/08, Ali Niknam wrote: > > This looks like an issue we used to have at work, where a streaming > > application suddenly started getting kevents for sockets that had been > > already closed. While that was happening, a netstat output looked just > > like yours. We never tracked it down, as we moved to other projects :( > > > > > > > > Was that BSD 7.0 also? Yes. > > -- > Transip BV | http://www.transip.nl/ > We never let you down. > -- ~/.signature: no such file or directory From julian at elischer.org Wed Jun 25 19:34:43 2008 From: julian at elischer.org (Julian Elischer) Date: Wed Jun 25 19:34:48 2008 Subject: FreeBSD NAT-T patch integration In-Reply-To: References: <0efb44e3c6c6603e69207eb15fec2718@localhost> <20080625135437.32e7a1f9@ayiin> <48629020.8000207@elischer.org> Message-ID: <48629DE0.5000407@elischer.org> Scott Ullrich wrote: > On Wed, Jun 25, 2008 at 2:36 PM, Julian Elischer wrote: >> >> where is the patch? >> >> > > The version that we use in RELENG_7_0 is located here: > http://cvs.pfsense.org/cgi-bin/cvsweb.cgi/tools/patches/RELENG_7_0/patch-natt-freebsd7-2008-03-11.diff?rev=1.1;content-type=text%2Fplain > > Thanks Julian! I don't have time to do a lot of work on it, but if you can get me a patch that applies cleanly on -current and that you have tested, along with testing other cases (e.g. not compiled in) then I can give it a look over and if it looks ok I can commit it to -current and then MFC it back to 7 in a week's time or so. is it ABI compatible? > > Scott From rwatson at FreeBSD.org Wed Jun 25 19:35:32 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Wed Jun 25 19:35:37 2008 Subject: FreeBSD 7.0: sockets stuck in CLOSED state... In-Reply-To: <486283B0.3060805@transip.nl> References: <486283B0.3060805@transip.nl> Message-ID: <20080625195523.N29013@fledge.watson.org> On Wed, 25 Jun 2008, Ali Niknam wrote: > Recently i've been upgrading some of my machines from FreeBSD 6.x amd64 to > FreeBSD 7.0 amd64. > > After upgrading I noticed a weird error/bug. It seems that after several > thousand TCP connections some seem to hang in 'CLOSED' state. Sounds like there's a bug somewhere. Before we start trying to track it down, I'll tell you a little more about how this works so that we can interpret the output you're seeing. In FreeBSD, as with all UNIX/Berkeley sockets systems, each socket is actually represented by a set of data structures representing different layers of abstraction. At the top level of struct file, representing a file descriptor. Next down is struct socket, representing a socket. Then the protocol code has struct inpcb, representing a generic IP connection, and struct tcpcb (or struct tcptw once we enter TIMEWAIT), representing a TCP connection. Confusingly, these data structures don't always exist all at once. For example, if you close the file descriptor, freeing struct file, the socket and protocol state may persist for some time until the TCP connection closes (all data has been sent, or various other close modes). One important difference between FreeBSD 6.x and FreeBSD 7.x is that, in FreeBSD 7.x, we've reduced the degree to which these data structures exist in isolation. If you look at the mailing list threads discussing the change, you'll see it described as "strengthening invariants". The most important part of the change was making it an invariant that so->so_pcb, the pointer from the socket to the protocol layer state, always remains stable and valid. This had a number of benefits: because the pointer is always stable, it no longer requires locks to following, lowering overhead and improving parallelism. It also simplifies the code by removing lots of error handling, and improved code stability by avoiding the inevitable bugs associated with complex error handling. If you look at bug reports over the years, we've had quite a few panics reported (and fixed) in which the disappearance of protocol layer state, such as when a connection is reset while still in use by a process, and these are now all believed to be eliminated. So the code is faster, cleaner, and more stable. But there are a few interesting side effects. One is that we retain state at the TCP layer for longer than we used to. Specifically, if a TCP connection closes, the inpcb remains allocated until the file descriptor is closed (i.e., the application notices the connection has closed and invokes close() on the file descriptor). This has a few impacts: one is that TCP connections now appear in netstat in the CLOSED state for longer than before, and another is that open sockets that are associated with CLOSED TCP connections now count against the global resource limit on the number of simultaneous TCP connections. I say "longer than before", but I should be clear that, in practice, assuming all is working properly, there's no measurable behavioral change *except* for improved performance, cleanliness, and stability. This is because applications generally open a socket, run a protocol, and when the protocol wraps up, they then close() the file descriptor in order to close the connection. So, with that introduction, we're interested in resolving: (1) Is this an application bug (leaking file descriptors) that only manifests in 7.x due to changes in kernel state management, leading to the sockets being visible in netstat and counting against the resource limit? (2) Is this a *new* bug in TCP in 7.x, perhaps a result of the state-related changes I've described? (3) Is this an *old* bug in TCP that is only now manifesting because of the changes in kernel state management? The first is the easiest to resolve, as all we need to do is see whether the number of file descriptors for the application goes upwards in an improbable manner. You can use fstat, procstat, sockstat, or various other tools (such as lsof) to see whether the process is leaking file descriptors. You can also instrument your application to keep track of the file descriptor numbers being returned to see whether, perhaps, that number only goes up over time, and gets really big. If it turns out that your application *is* properly closing sockets, then we need to decide if perhaps we're looking at a race in close and state management. In particular, I'll need the output of "netstat -na", "vmstat -z", and "vmstat -m" from the machine once it's in its rather wedged-up state. It would be most helpful if you could actually shut down to single-user mode, killing all user processes, then waiting ten minutes, and capturing the output of those above commands to files that you can then e-mail to me. Without accusing you of having buggy code, I should say that I think there's a reasonable chance that what you're seeing is an interaction between an existing leak of resources in the application and the way the kernel state management has changed. The output from netstat pretty precisely matches that what you'd expect: lots of TCP connections in the CLOSED state reflecting a series of connections built by an application but then not properly discarded. Likewise, when the application is killed, all of the connections go away -- most likely because the file descriptors are all closed, allowing them to be garbage collected and connection state freed. If it is this sort of bug, then most likely you're missing a call to close() in a work loop somewhere, and in some exceptional case, you fall out of the loop without calling close(). If it turns out that you can get to single-user, wait ten minutes to make sure all the connections wind down, and there are still connections visible in netstat, then we may indeed be looking at a kernel bug, and the debugging information using netstat and vmstat will allow us to start to investigate. Robert N M Watson Computer Laboratory University of Cambridge > > netstat -n gives: > ... > tcp4 0 0 1.2.3.4.* 4.5.6.7.42149 CLOSED > tcp4 39 0 1.2.3.4.* 4.5.6.7.54103 CLOSED > tcp4 35 0 1.2.3.4.* 4.5.6.7.41718 CLOSED > tcp4 38 0 1.2.3.4.* 4.5.6.7.55618 CLOSED > tcp4 41 0 1.2.3.4.* 4.5.6.7.44230 CLOSED > tcp4 39 0 1.2.3.4.* 4.5.6.7.49439 CLOSED > ... > > These never go away; they gradually increase and increase until the > application starts giving errors (probably because some socket or > filedescriptor limit is reached). When the application is killed these > entries disappear. > > The application in question is a self written DNS server, multithreaded, and > running fine for years without any troubles on both BSD 5.x as well as 6.x. > Also 32bits as well as 64bits on 6.x. > > Ofcourse that doesn't mean that the application is error free, however, after > doing extensive testing I really can not find anything wrong with the > application itself, so I'm thinking maybe there's a change somewhere that > causes this? I know that tcp/network has been completely redone... > > What basically happens in the application is this: > - one main tcp thread runs an infinite while loop waiting for new > connections to arrive > - as soon as one arrives a new thread is spawned that handles the newly > created stream > - it reads some bytes, writes some bytes, then closes it > - thread exits > > What appears to happen is this: after the new thread is spawned it tries to > read 2 bytes (DNS tcp length information). It gets back 0 bytes (EOF) and > therefore closes the sockets and calls pthread_exit. However in netstat that > same stream oftenly appears to have bytes 'stuck' in the in queue... > > I really can't see how this can cause hanging sockets in 'CLOSED' state. Even > if the incoming queue isnt read entirely a call to close should close it. > Also I really can't find any documentation in netstat, or elsewhere, about > the 'CLOSED' state... > > > Any help would greatly be appreciated! > > > Kind Regards, > > > Ali Niknam > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From sullrich at gmail.com Wed Jun 25 19:50:28 2008 From: sullrich at gmail.com (Scott Ullrich) Date: Wed Jun 25 19:50:31 2008 Subject: FreeBSD NAT-T patch integration In-Reply-To: <20080625193208.M92670@swaggi.com> References: <0efb44e3c6c6603e69207eb15fec2718@localhost> <20080625135437.32e7a1f9@ayiin> <48629020.8000207@elischer.org> <48629DE0.5000407@elischer.org> <20080625193208.M92670@swaggi.com> Message-ID: On Wed, Jun 25, 2008 at 3:33 PM, Yuri Lukin wrote: > I believe the original author of the patch has one that should work with current: > > http://vanhu.free.fr/FreeBSD/ Even better. Looks like http://vanhu.free.fr/FreeBSD/patch-natt-freebsd-HEAD-2008-03-19.diff might be semi up to date. Thanks a million for assisting Julian, this is going to make a lot of folks happy! :) Scott From emss at free.fr Wed Jun 25 19:53:10 2008 From: emss at free.fr (Eric Masson) Date: Wed Jun 25 19:53:15 2008 Subject: FreeBSD NAT-T patch integration In-Reply-To: <48629020.8000207@elischer.org> (Julian Elischer's message of "Wed, 25 Jun 2008 11:36:16 -0700") References: <0efb44e3c6c6603e69207eb15fec2718@localhost> <20080625135437.32e7a1f9@ayiin> <48629020.8000207@elischer.org> Message-ID: <867icdfg0s.fsf@srvbsdnanssv.interne.kisoft-services.com> Julian Elischer writes: Hi, > where is the patch? It seems that the last patch to -current is available here : http://vanhu.free.fr/FreeBSD/patch-natt-freebsd-HEAD-2008-03-19.diff Maybe Yvan has a more recent patch available (CCed) -- Ce ne sont que des propositions. Je ne veux pas les faire passer en force. Je pense que si mes id?es doivent ?tre reprises, elles ne doivent pas passer au vote, pour plusieurs raison : -+- BC in : http://neuneu.ctw.cc - Neuneu sans vote et sans forcer -+- From bzeeb-lists at lists.zabbadoz.net Wed Jun 25 19:55:07 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Wed Jun 25 19:55:13 2008 Subject: FreeBSD NAT-T patch integration In-Reply-To: <48629DE0.5000407@elischer.org> References: <0efb44e3c6c6603e69207eb15fec2718@localhost> <20080625135437.32e7a1f9@ayiin> <48629020.8000207@elischer.org> <48629DE0.5000407@elischer.org> Message-ID: <20080625195246.N83875@maildrop.int.zabbadoz.net> On Wed, 25 Jun 2008, Julian Elischer wrote: Hi Julian, > I don't have time to do a lot of work on it, but if you can get me a patch > that applies cleanly on -current > and that you have tested, along with testing other cases (e.g. not compiled > in) > then I can give it a look over and if it looks ok I can commit it > to -current and then MFC it back to 7 in a week's time or so. if it would be that easy, it would have happened 2 years ago. -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From sullrich at gmail.com Wed Jun 25 19:56:19 2008 From: sullrich at gmail.com (Scott Ullrich) Date: Wed Jun 25 19:56:22 2008 Subject: FreeBSD NAT-T patch integration In-Reply-To: <20080625195246.N83875@maildrop.int.zabbadoz.net> References: <0efb44e3c6c6603e69207eb15fec2718@localhost> <20080625135437.32e7a1f9@ayiin> <48629020.8000207@elischer.org> <48629DE0.5000407@elischer.org> <20080625195246.N83875@maildrop.int.zabbadoz.net> Message-ID: On Wed, Jun 25, 2008 at 3:53 PM, Bjoern A. Zeeb wrote: > if it would be that easy, it would have happened 2 years ago. What can we as a community do to assist in making this easier and doable? Scott From lists at swaggi.com Wed Jun 25 20:09:40 2008 From: lists at swaggi.com (Yuri Lukin) Date: Wed Jun 25 20:09:43 2008 Subject: FreeBSD NAT-T patch integration In-Reply-To: <48629DE0.5000407@elischer.org> References: <0efb44e3c6c6603e69207eb15fec2718@localhost> <20080625135437.32e7a1f9@ayiin> <48629020.8000207@elischer.org> <48629DE0.5000407@elischer.org> Message-ID: <20080625193208.M92670@swaggi.com> On Wed, 25 Jun 2008 12:34:56 -0700, Julian Elischer wrote > Scott Ullrich wrote: > > On Wed, Jun 25, 2008 at 2:36 PM, Julian Elischer wrote: > >> > >> where is the patch? > >> > >> > > > > The version that we use in RELENG_7_0 is located here: > > http://cvs.pfsense.org/cgi-bin/cvsweb.cgi/tools/patches/RELENG_7_0/patch-natt-freebsd7-2008-03-11.diff?rev=1.1;content-type=text%2Fplain > > > > Thanks Julian! > > I don't have time to do a lot of work on it, but if you can get me a > patch that applies cleanly on -current > and that you have tested, along with testing other cases (e.g. not > compiled in) > then I can give it a look over and if it looks ok I can commit it > to -current and then MFC it back to 7 in a week's time or so. > is it ABI compatible? > > > > > Scott > I believe the original author of the patch has one that should work with current: http://vanhu.free.fr/FreeBSD/ From julian at elischer.org Wed Jun 25 20:24:41 2008 From: julian at elischer.org (Julian Elischer) Date: Wed Jun 25 20:24:46 2008 Subject: FreeBSD NAT-T patch integration In-Reply-To: References: <0efb44e3c6c6603e69207eb15fec2718@localhost> <20080625135437.32e7a1f9@ayiin> <48629020.8000207@elischer.org> <48629DE0.5000407@elischer.org> <20080625193208.M92670@swaggi.com> Message-ID: <4862A995.3090109@elischer.org> Scott Ullrich wrote: > On Wed, Jun 25, 2008 at 3:33 PM, Yuri Lukin wrote: >> I believe the original author of the patch has one that should work with current: >> >> http://vanhu.free.fr/FreeBSD/ > > Even better. > > Looks like http://vanhu.free.fr/FreeBSD/patch-natt-freebsd-HEAD-2008-03-19.diff > might be semi up to date. > > Thanks a million for assisting Julian, this is going to make a lot of > folks happy! :) do you have the ability to test this? > > Scott From sullrich at gmail.com Wed Jun 25 20:30:39 2008 From: sullrich at gmail.com (Scott Ullrich) Date: Wed Jun 25 20:30:42 2008 Subject: FreeBSD NAT-T patch integration In-Reply-To: <4862A995.3090109@elischer.org> References: <0efb44e3c6c6603e69207eb15fec2718@localhost> <20080625135437.32e7a1f9@ayiin> <48629020.8000207@elischer.org> <48629DE0.5000407@elischer.org> <20080625193208.M92670@swaggi.com> <4862A995.3090109@elischer.org> Message-ID: On Wed, Jun 25, 2008 at 4:24 PM, Julian Elischer wrote: > do you have the ability to test this? Absolutely. Is this the only thing from preventing it being merged into HEAD? Scott From brooks at freebsd.org Wed Jun 25 20:45:00 2008 From: brooks at freebsd.org (Brooks Davis) Date: Wed Jun 25 20:45:03 2008 Subject: FreeBSD NAT-T patch integration In-Reply-To: References: <0efb44e3c6c6603e69207eb15fec2718@localhost> <20080625135437.32e7a1f9@ayiin> <48629020.8000207@elischer.org> <48629DE0.5000407@elischer.org> <20080625193208.M92670@swaggi.com> <4862A995.3090109@elischer.org> Message-ID: <20080625204526.GA47809@lor.one-eyed-alien.net> On Wed, Jun 25, 2008 at 04:30:36PM -0400, Scott Ullrich wrote: > On Wed, Jun 25, 2008 at 4:24 PM, Julian Elischer wrote: > > do you have the ability to test this? > > Absolutely. Is this the only thing from preventing it being merged into HEAD? No. It's a large and complex patch an a subsystem (ipsec) that must not be broken. We're a bit shorthanded in this area, but people have been working on this for quite some time and IIRC aren't fully comfortable with the patch yet. -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080625/b6618e1e/attachment.pgp From auryn at zirakzigil.org Wed Jun 25 21:03:52 2008 From: auryn at zirakzigil.org (Giulio Ferro) Date: Wed Jun 25 21:03:57 2008 Subject: SOLVED (was Re: Problem clarification (was: Problems with vlan + carp + alias)) In-Reply-To: <486000B5.9090703@zirakzigil.org> References: <486000B5.9090703@zirakzigil.org> Message-ID: <4862B2AF.70202@zirakzigil.org> I finally got the problem, and it had nothing to do either with vlans or with carp. The firewall I was setting up was meant to replace an existing freebsd firewall which didn't use vlans (it had a lot of nics). The problem was that the network port where our ISP brings the internet connection still had the old aliased mac addresses in its arp cache. For some reason when I plugged in the new firewall, only the base non-aliased address was updated in the ISP switch arp cache (if someone can throw a guess at why, I'm eager to listen). The ISP router was still looking for the aliased addresses with the old macs, so it didn't find them. Moreover, I inadvertently put the vlan internet interface in promiscuous mode, so with tcpdump I also picked up those packets with wrong mac address which weren't meant for me. To make the story short, I called the technical customer care of the ISP and I requested them to reset the arp cache of the port. Done that, everything worked without a glitch. The new firewall is now up and running in production with vlan + carp. Everything seems fine. Thanks to everybody who answered my plea... :-) Giulio Ferro wrote: > After some more tests I've finally realized that the problem is with > vlan and alias. I've taken carp out of the picture. > > > (Please read my previous message on the topic to understand the scenario, > I've reported it below) > > Here is what matters in /etc/rc.conf: > > ----------------------------------------------------------- > ... > ifconfig_bce0="inet 192.168.26.1 netmask 255.255.255.0" > ... > ifconfig_vlan128="inet x.y.z.132 netmask 255.255.255.224 vlan 128 > vlandev bce0" > ifconfig_vlan128_alias0="x.y.z.133 netmask 255.255.255.255" > ifconfig_vlan128_alias1="x.y.z.134 netmask 255.255.255.255" > ifconfig_vlan128_alias2="x.y.z.135 netmask 255.255.255.255" > ifconfig_vlan128_alias3="x.y.z.136 netmask 255.255.255.255" > ifconfig_vlan128_alias4="x.y.z.137 netmask 255.255.255.255" > ifconfig_vlan128_alias5="x.y.z.138 netmask 255.255.255.255" > ifconfig_vlan128_alias6="x.y.z.139 netmask 255.255.255.255" > ifconfig_vlan128_alias7="x.y.z.140 netmask 255.255.255.255" > ifconfig_vlan128_alias8="x.y.z.141 netmask 255.255.255.255" > ... > defaultrouter="x.y.z.129" > ----------------------------------------------------------- > > netstat -rn > ----------------------------------------------------------- > default x.y.z.129 UGS 0 9869 vlan12 > x.y.z.128/27 link#11 UC 0 0 vlan12 > x.y.z.129 00:00:0c:07:ac:0a UHLW 2 52 vlan12 1107 > x.y.z.130 00:d0:03:8a:9b:fc UHLW 1 0 vlan12 1147 > x.y.z.131 00:d0:03:8a:9b:fd UHLW 1 0 vlan12 1144 > x.y.z.133/32 link#11 UC 0 0 vlan12 > x.y.z.134/32 link#11 UC 0 0 vlan12 > x.y.z.135/32 link#11 UC 0 0 vlan12 > x.y.z.136/32 link#11 UC 0 0 vlan12 > x.y.z.137/32 link#11 UC 0 0 vlan12 > x.y.z.138/32 link#11 UC 0 0 vlan12 > x.y.z.139/32 link#11 UC 0 0 vlan12 > x.y.z.140/32 link#11 UC 0 0 vlan12 > x.y.z.141/32 link#11 UC 0 0 vlan12 > ----------------------------------------------------------- > > ifconfig vlan128 > ----------------------------------------------------------- > vlan128: flags=8843 metric 0 > mtu 1500 > options=3 > ether 00:1e:c9:ad:fa:c9 > inet x.y.z.132 netmask 0xffffffe0 broadcast x.y.z.159 > inet x.y.z.133 netmask 0xffffffff broadcast x.y.z.133 > inet x.y.z.134 netmask 0xffffffff broadcast x.y.z.134 > inet x.y.z.135 netmask 0xffffffff broadcast x.y.z.135 > inet x.y.z.136 netmask 0xffffffff broadcast x.y.z.136 > inet x.y.z.137 netmask 0xffffffff broadcast x.y.z.137 > inet x.y.z.138 netmask 0xffffffff broadcast x.y.z.138 > inet x.y.z.139 netmask 0xffffffff broadcast x.y.z.139 > inet x.y.z.140 netmask 0xffffffff broadcast x.y.z.140 > inet x.y.z.141 netmask 0xffffffff broadcast x.y.z.141 > media: Ethernet autoselect (1000baseTX ) > status: active > vlan: 128 parent interface: bce0 > ----------------------------------------------------------- > > Tests: > No problem when I try to ping the default gateway from my fw > No problem when I ping my fw from an external internet address > > Problems: > - I cannot ping the router from one of the aliased address: > ping -S x.y.z.133 x.y.z.129 > - I cannot ping the aliased addresses from an external internet address > > Note : I can see the packets with tcpdump travelling from and to the > aliased > address. It seems the interface won't process them for some reason. > > This seems suspiciously like a bug to me... > > > -------------------------------------------------------------------------------------- > > (previous message on vlan + carp +alias) > -------------------------------------------------------------------------------------- > > > > Primeroz lists wrote: >> What is tcpdump showing for ping on 192.168.10.11 >> ? can you see echo reply exiting vlan10 >> interface ? >> >> what if you try from your server to "ping -S 192.168.10.11 >> 192.168.10.254 " ? >> >> >> > First of all I'm sorry for the late reply. Yesterday I could do some more > in-depth test to analyze this strange behavior of my firewall. > > The 192.168.10.0/24 range I used in the previous example isn't the real > one, I just used it for simplicity?s sake. > The true range, the one which has been assigned by the ISP to my customer > is: x.y.z.128/27. (x.y.z corresponds to a true public IP address) > > I've deactivated the firewall, so we have one less thing to worry about: > /etc/rc.d/pf stop > This is a pure network configuration issue. > > Here is the relevant part in /etc/rc.conf: > --------------------------------------------------- > ... > ifconfig_bce0="inet 192.168.26.1 netmask 255.255.255.0" > ... > cloned_interfaces="vlan5 vlan25 vlan30 vlan40 vlan128 carp5 carp25 > carp30 carp40 carp128" > ... > ifconfig_vlan128="inet x.y.z.157 netmask 255.255.255.224 vlan 128 > vlandev bce0" > ... > ifconfig_carp128="vhid 128 pass qweq x.y.z.132 netmask 255.255.255.255" > ifconfig_carp128_alias0="x.y.z.133 netmask 255.255.255.255" > ifconfig_carp128_alias1="x.y.z.134 netmask 255.255.255.255" > ifconfig_carp128_alias2="x.y.z.135 netmask 255.255.255.255" > ifconfig_carp128_alias3="x.y.z.136 netmask 255.255.255.255" > ifconfig_carp128_alias4="x.y.z.137 netmask 255.255.255.255" > ifconfig_carp128_alias5="x.y.z.138 netmask 255.255.255.255" > ifconfig_carp128_alias6="x.y.z.139 netmask 255.255.255.255" > ifconfig_carp128_alias7="x.y.z.140 netmask 255.255.255.255" > ifconfig_carp128_alias8="x.y.z.141 netmask 255.255.255.255" > ... > defaultrouter="x.y.z.129" > --------------------------------------------------- > > On my managed switch I've set 2 ports: > 1) the one where the bce0 interface is plugged in : mode trunk with > all the vlans above > 2) the one where the ISP internet is plugged in : mode access with > vlan 128 > > I've also set the ip interface of my switch to x.y.z.155 vlan 128 > > > Here is the relevant part of netstat -rn on my machine > --------------------------------------------------- > default x.y.z.129 UGS 0 13966 vlan12 > x.y.z/27 link#11 UC 0 0 vlan12 > x.y.z.132 x.y.z.132 UH 0 0 carp12 > x.y.z.133 x.y.z.133 UH 0 0 carp12 > x.y.z.134 x.y.z.134 UH 0 0 carp12 > x.y.z.135 x.y.z135 UH 0 0 carp12 > x.y.z.136 x.y.z.136 UH 0 0 carp12 > x.y.z.137 x.y.z.137 UH 0 0 carp12 > x.y.z.138 x.y.z.138 UH 0 0 carp12 > x.y.z.139 x.y.z.139 UH 0 0 carp12 > x.y.z.140 x.y.z.140 UH 0 0 carp12 > x.y.z.141 x.y.z.141 UH 0 0 carp12 > x.y.z.155 00:1e:c9:90:4a:c0 UHLW 1 8 vlan12 1183 > > --------------------------------------------------- > > > > Here come the tests. > 1) From the firewall : basic > I can ping both the default gateway (x.y.z.129) and the switch > interface (x.y.z.155) > I can ping a generic internet address (a.b.c.d) > With tcpdump I can see the packets leaving as x.y.z.157 and coming > with the same > address > > 2) from the switch : basic > I can ping the firewall's vlan address (x.y.z.157) > I can ping _ALL_ the carp interfaces, base and alias: > ping x.y.z.157 -> OK > ping x.y.z.132 -> OK > ping x.y.z.133 -> OK > ... > ping x.y.z.141 -> OK > > 3) from the internet : basic > From an external internet address I can ping the vlan address: > ping x.y.z.157 -> OK > > 4) from the firewall : advanced > From the firewall I can ping the switch address from one of the carp > base and aliased address: > ping -S x.y.z.132 x.y.z.155 -> OK > ping -S x.y.z.133 x.y.z.155 -> OK > > I _cannot_ ping the default router from one of the carp addresses: > ping -S x.y.z.132 x.y.z.129 -> NOT OK > ping -S x.y.z.133 x.y.z.129 -> NOT OK > By using tcpdump on the vlan128 interface I can see the packets > _BOTH_ leaving and coming from the carp addresses. It just seems > that the carp interfaces can't process the packets properly. > > 5) from the internet : advanced > From an external internet address I _cannot_ ping the carp addresses > (x.y.z.132 and up) > As above, I can see the incoming packets with > tcpdump -i vlan128 -n icmp > > > Ok, that was long. I hope someone can help to shed light into this, to > see > whether this is a bug or not. > I stress again that the _same_ configuration works as it should on a > physical > (non-vlan) interface. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From freebsd-net at transip.nl Wed Jun 25 21:47:53 2008 From: freebsd-net at transip.nl (Ali Niknam) Date: Wed Jun 25 21:47:59 2008 Subject: FreeBSD 7.0: sockets stuck in CLOSED state... In-Reply-To: <20080625195523.N29013@fledge.watson.org> References: <486283B0.3060805@transip.nl> <20080625195523.N29013@fledge.watson.org> Message-ID: <4862BCF5.4070900@transip.nl> Hi Robert, > Sounds like there's a bug somewhere. Before we start trying to track it [...] > So, with that introduction, we're interested in resolving: > Quite comprehensive indeed; thank you for all that information. I was not aware that there was a decoupling between the various parts of the abstractions, but now that I think of it, it's more or less logical I guess. > The first is the easiest to resolve, as all we need to do is see whether [...] > the file descriptor numbers being returned to see whether, perhaps, that > number only goes up over time, and gets really big. > My personal feeling is that it's a race condition; no idea why, but it feels that way. Maybe because it's such a small number as compared to the big amount of connections that takes place. I do not leak file descriptors as far as I can see, I can send you the information you ask for (netstat, sockstat, fstat, etc.) offlist if you like, or if you prefer, I can give you access to the machine, please let me know whichever you like. I'd like to reiterate that at this moment i'm not sure at all if it's my code, or kernel code. However I've seen, for my feeling, sufficient information to reasonably suspect that it _might_ be something outside my code :). > wedged-up state. It would be most helpful if you could actually shut > down to single-user mode, killing all user processes, then waiting ten > minutes, and capturing the output of those above commands to files that > you can then e-mail to me. > Because it's a live machine that would be very difficult. Maybe, if you really really need it that way and we can't find another way I can announce maintainance and do it in the middle of the night :). > Without accusing you of having buggy code, I should say that I think > there's a reasonable chance that what you're seeing is an interaction > between an existing leak of resources in the application and the way the > kernel state management has changed. The output from netstat pretty Yes that was the first thing I though of as well, however, especially one of the two applications is so simple that I would be ashamed to death if I still had a bug in there :). If it turns out that way: sssstttt ;). > precisely matches that what you'd expect: lots of TCP connections in the > CLOSED state reflecting a series of connections built by an application > but then not properly discarded. Likewise, when the application is > killed, all of the connections go away -- most likely because the file > descriptors are all closed, allowing them to be garbage collected and > connection state freed. If it is this sort of bug, then most likely > you're missing a call to close() in a work loop somewhere, and in some > exceptional case, you fall out of the loop without calling close(). > I will double check this once more, but honestly, i strongly doubt it... Also one other thing that I've noticed, is that it's always the input buffer that has bytes left; never the output buffer... Moreover, i've seen that close() reports EBADF, but due to the insane amount of connections I can not say for certain that that's when the connection goes into CLOSED state. The ip's do match, but it's very common for the same ip's to make numerous connections too. Kind Regards, Ali -- Transip BV | http://www.transip.nl/ We never let you down. From julian at elischer.org Thu Jun 26 00:03:59 2008 From: julian at elischer.org (Julian Elischer) Date: Thu Jun 26 00:04:05 2008 Subject: FreeBSD NAT-T patch integration In-Reply-To: <20080625195246.N83875@maildrop.int.zabbadoz.net> References: <0efb44e3c6c6603e69207eb15fec2718@localhost> <20080625135437.32e7a1f9@ayiin> <48629020.8000207@elischer.org> <48629DE0.5000407@elischer.org> <20080625195246.N83875@maildrop.int.zabbadoz.net> Message-ID: <4862DCFB.1050203@elischer.org> Bjoern A. Zeeb wrote: > On Wed, 25 Jun 2008, Julian Elischer wrote: > > Hi Julian, > >> I don't have time to do a lot of work on it, but if you can get me a >> patch that applies cleanly on -current >> and that you have tested, along with testing other cases (e.g. not >> compiled in) >> then I can give it a look over and if it looks ok I can commit it >> to -current and then MFC it back to 7 in a week's time or so. > > if it would be that easy, it would have happened 2 years ago. > I don't see anything in there that would stop a commit. Please be more specific? From mgrooms at shrew.net Thu Jun 26 00:14:03 2008 From: mgrooms at shrew.net (mgrooms) Date: Thu Jun 26 00:14:10 2008 Subject: FreeBSD NAT-T patch integration In-Reply-To: <48629DE0.5000407@elischer.org> References: <48629DE0.5000407@elischer.org> Message-ID: <7ec5b81263bb9dc933d392a8efb26136@localhost> On Wed, 25 Jun 2008 12:34:56 -0700, Julian Elischer wrote: > Scott Ullrich wrote: >> On Wed, Jun 25, 2008 at 2:36 PM, Julian Elischer > wrote: >>> >>> where is the patch? >>> >>> >> >> The version that we use in RELENG_7_0 is located here: >> > http://cvs.pfsense.org/cgi-bin/cvsweb.cgi/tools/patches/RELENG_7_0/patch-natt-freebsd7-2008-03-11.diff?rev=1.1;content-type=text%2Fplain >> >> Thanks Julian! > > I don't have time to do a lot of work on it, but if you can get me a > patch that applies cleanly on -current > and that you have tested, along with testing other cases (e.g. not > compiled in) > then I can give it a look over and if it looks ok I can commit it > to -current and then MFC it back to 7 in a week's time or so. > is it ABI compatible? > Julian, To my knowledge, here are the latest patch sets ... http://vanhu.free.fr/FreeBSD/patch-natt-freebsd6-2007-05-31.diff http://vanhu.free.fr/FreeBSD/patch-natt-freebsd7-2008-03-11.diff http://vanhu.free.fr/FreeBSD/patch-natt-freebsd-HEAD-2008-03-19.diff Thanks, -Matthew From julian at elischer.org Thu Jun 26 00:22:31 2008 From: julian at elischer.org (Julian Elischer) Date: Thu Jun 26 00:22:37 2008 Subject: FreeBSD NAT-T patch integration In-Reply-To: References: <0efb44e3c6c6603e69207eb15fec2718@localhost> <20080625135437.32e7a1f9@ayiin> <48629020.8000207@elischer.org> <48629DE0.5000407@elischer.org> <20080625195246.N83875@maildrop.int.zabbadoz.net> Message-ID: <4862E154.1000907@elischer.org> Scott Ullrich wrote: > On Wed, Jun 25, 2008 at 3:53 PM, Bjoern A. Zeeb > wrote: >> if it would be that easy, it would have happened 2 years ago. > > What can we as a community do to assist in making this easier and doable? that is the question.. NAT-T is a very useful feature, and not having it s a strike agains FreeBSD in a lot of eyes.. (It's needed for example to talk to ASA firewalls for VPN stuff I believe). Anyhow I looked at the patch briefly and haven't seen anything horrendously terrible in it.. I'll look a bit more later but it doesn't seem to interfere with unrelated code that I can see. > > Scott > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From freebsd-lists-erik at erikosterholm.org Thu Jun 26 01:38:02 2008 From: freebsd-lists-erik at erikosterholm.org (Erik Osterholm) Date: Thu Jun 26 01:38:06 2008 Subject: Why isn't ALTQ in GENERIC? In-Reply-To: <4c5bca29cfc1cdd3efa81ffb2f815675.squirrel@router> References: <20080624212639.GA41755@aleph.cepheid.org> <4c5bca29cfc1cdd3efa81ffb2f815675.squirrel@router> Message-ID: <20080626013801.GA83308@aleph.cepheid.org> On Wed, Jun 25, 2008 at 03:13:54AM +0200, Max Laier wrote: > Hi Erik, > > Am Di, 24.06.2008, 23:26, schrieb Erik Osterholm: > > Can anyone tell me if there are good reasons for explicitly leaving > > ALTQ out of the kernel? More specific to my circumstances, if I'm > > building kernels to be installed on every machine we deploy, is it > > worth building a separate kernel for ALTQ for those few boxes which > > will require it? > > > > Are there performance issues? Stability issues? Ultimately, I'm just > > surprised that it's not available in GENERIC if there isn't a good > > reason, but I can't find any documentation for that reason. > > Short answer: Historical reasons. > > Whole stroy: When ALTQ was added there were both performance and stability > concerns. For a long time we had a big #ifdef ALTQ in if_var.h to avoid > one additional check for if_queue enqueue opperations. These are now gone > and I personally don't see any issues that would prevent ALTQ from being > in GENERIC. However, it's unclear which disceplines to turn on by > default. I'd like to see ALTQ in GERNERIC, but I've been reluctant to > make the change on my own. If we can get a quorum here, I'll reconsider > it. Thanks for the explanation. I think that it would be nice to have in GENERIC, but my immediate concerns were for with the performance and stability. Thanks! Erik From lstewart at room52.net Thu Jun 26 02:31:35 2008 From: lstewart at room52.net (Lawrence Stewart) Date: Thu Jun 26 02:31:40 2008 Subject: FreeBSD 7.0: sockets stuck in CLOSED state... In-Reply-To: <4862BCF5.4070900@transip.nl> References: <486283B0.3060805@transip.nl> <20080625195523.N29013@fledge.watson.org> <4862BCF5.4070900@transip.nl> Message-ID: <4862FCBD.3090906@room52.net> Ali Niknam wrote: > Hi Robert, [snip] > > I will double check this once more, but honestly, i strongly doubt it... > > Also one other thing that I've noticed, is that it's always the input > buffer that has bytes left; never the output buffer... > > Moreover, i've seen that close() reports EBADF, but due to the insane > amount of connections I can not say for certain that that's when the > connection goes into CLOSED state. The ip's do match, but it's very > common for the same ip's to make numerous connections too. > To get a bit more detail about the state of the tcb and socket buffers at the time the connection is shut down, you can use my SIFTR tool, available from: http://caia.swin.edu.au/urp/newtcp/tools.html The readme should explain how to use it. Please keep the "ppl" sysctl at 1. Once you have some data collected for tcbs you know end up in the unexpected CLOSED state, have a look at the relevant fields in the SIFTR log file and let us know what you find. Might be useful if you send the log file through as well for me to have a quick look. Cheers, Lawrence From steve at ibctech.ca Thu Jun 26 03:18:55 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Thu Jun 26 03:18:57 2008 Subject: SOLVED (was Re: Problem clarification (was: Problems with vlan + carp + alias)) In-Reply-To: <4862B2AF.70202@zirakzigil.org> References: <486000B5.9090703@zirakzigil.org> <4862B2AF.70202@zirakzigil.org> Message-ID: <48630AA3.3000800@ibctech.ca> Giulio Ferro wrote: > I finally got the problem, and it had nothing to do either with vlans or > with carp. > > The firewall I was setting up was meant to replace an existing freebsd > firewall > which didn't use vlans (it had a lot of nics). > The problem was that the network port where our ISP brings the internet > connection > still had the old aliased mac addresses in its arp cache. Thank you Giulio (is it Gio?)... for replying everyone with a definitive conclusion. Thats fantastic for the followers of the thread, but the archives as well. > For some > reason when I > plugged in the new firewall, only the base non-aliased address was > updated in > the ISP switch arp cache (if someone can throw a guess at why, I'm eager > to listen). Well, you need to know what type of switch they had upstream, and why they weren't updating their ARP cache dynamically properly. Perhaps because their cache ttl was too long (due to the type of hardware, or administrative setting). I almost have to assume it wasn't a Cisco... only because I would have expected different behavior (less administrative setting) (this is my personal experience...I'm not trying to favour a brand in any way). Perhaps you could ask them to provide the command they issued to determine how they found the problem. Better yet, ask what type of device your box is connected to at their end of the VLAN. If you can find out what device they have at their end, it may almost be possible to non-destructively, and non-corruptively 'force' them to clear arp-cache remotely, and at the same time provide advice to the non-unscrupulous people who may run into this in the future. I'd be just as interested to know what they had at their end for hardware, as I have been waiting to hear what your resolution was throughout your time consuming troubleshooting... Steve From rwatson at FreeBSD.org Thu Jun 26 07:50:13 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Thu Jun 26 07:50:18 2008 Subject: FreeBSD 7.0: sockets stuck in CLOSED state... In-Reply-To: <4862BCF5.4070900@transip.nl> References: <486283B0.3060805@transip.nl> <20080625195523.N29013@fledge.watson.org> <4862BCF5.4070900@transip.nl> Message-ID: <20080626081831.V96707@fledge.watson.org> On Wed, 25 Jun 2008, Ali Niknam wrote: >> precisely matches that what you'd expect: lots of TCP connections in the >> CLOSED state reflecting a series of connections built by an application but >> then not properly discarded. Likewise, when the application is killed, all >> of the connections go away -- most likely because the file descriptors are >> all closed, allowing them to be garbage collected and connection state >> freed. If it is this sort of bug, then most likely you're missing a call >> to close() in a work loop somewhere, and in some exceptional case, you fall >> out of the loop without calling close(). > > I will double check this once more, but honestly, i strongly doubt it... > > Also one other thing that I've noticed, is that it's always the input buffer > that has bytes left; never the output buffer... > > Moreover, i've seen that close() reports EBADF, but due to the insane amount > of connections I can not say for certain that that's when the connection > goes into CLOSED state. The ip's do match, but it's very common for the same > ip's to make numerous connections too. I think the first logical step is to wait for the application to get into that state again, and then run procstat or fstat to dump the file descriptor away for the process. Presumably in the normal steady state, you expect to see a few IPC sockets (syslog, etc), a TCP listen socket, and some number of in-progress TCP sessions. The question, of course, is whether you see a lot more file descriptors than that, and in particular, ones that matched the CLOSED entries in netstat. If you find that there are lots of open file descriptors and they match up approximately with netstat, then it's an application bug that just manifests a bit differently in 7.x than in 6.x. On the other hand, if you see only a small number of open file descriptors, then we may be looking at something quite a bit more complicated. I would next seek to confirm the analysis that "they go away when the application is killed" -- do they really disappear at the very moment it exits, or do they kind of disappear over time and it just happens that by the time you run netstat after killing the application, they're gone. I.e., I'd try something like "netstat -na > file1 ; kill pid ; sleep 1 ; netstat -na > file2 ; diff -u file1 file2". If they really all go away in a large quantity the moment the process dies, then the reference model is working (i.e., they are freed), but perhaps references are being held onto in an unexpected way. For example, is the incomplete listen queue somehow getting filled with CLOSED sockets that are only garbage collected when close() is called on the listen socket? If we suspect that, we can actually test it by having your application close the listen socket and re-open it once in a while, and see if the CLOSED sockets fail to stack up. Speaking of which, I meant to ask: are you using accept filters, and if so, which one? Robert N M Watson Computer Laboratory University of Cambridge From vanhu_bsd at zeninc.net Thu Jun 26 08:12:27 2008 From: vanhu_bsd at zeninc.net (VANHULLEBUS Yvan) Date: Thu Jun 26 08:12:30 2008 Subject: FreeBSD NAT-T patch integration In-Reply-To: <7ec5b81263bb9dc933d392a8efb26136@localhost> References: <48629DE0.5000407@elischer.org> <7ec5b81263bb9dc933d392a8efb26136@localhost> Message-ID: <20080626075307.GA1401@zen.inc> On Wed, Jun 25, 2008 at 07:13:59PM -0500, mgrooms wrote: [...] > To my knowledge, here are the latest patch sets ... > > http://vanhu.free.fr/FreeBSD/patch-natt-freebsd6-2007-05-31.diff > http://vanhu.free.fr/FreeBSD/patch-natt-freebsd7-2008-03-11.diff > http://vanhu.free.fr/FreeBSD/patch-natt-freebsd-HEAD-2008-03-19.diff Yes: latest version of the patch will always be the file at that location with the most recent date. I have copies of repositories for HEAD, RELENG7 and RELENG6, and I can generate more up-to date patches if needed. I use patch for freebsd6 and freebsd7 in daily production, and can quite quickly test new versions if needed. I do NOT use directly the patch for HEAD actually, but should have a testing device for that soon. If some people have their own changes for those patches, please send them to me !!! What still lacks afaik in that patch: - support for NAT-OA. This is needed for transport mode when traffic is TCP (and when UDP traffic have a non zero checksum), such support needs some stuff in decapsulation process, complete support for NAT-OA payloads in PFKey, and complete support in userland. - Cleanup of PFKeyV2. Actually, NAT-T ports are not sent in a RFC compliant way (but it works). That cleanup needs also to be done in userland, and is on my TODO list (both kernel and userland). - Better detection of NAT-T support. Actually, ipsec-tools guess kernel support for NAT-T by checking some stuff in /usr/include. That just means you appliend the NAT-T patch, but that doesn't means you enabled NAT-T support in your kernel. Same problem exists for other implementations (at least Linux 2.6+ and NetBSD), a cleaner detection should also do "some checks" at runtime to ensure actual kernel really supports NAT-T. But that's an userland problem, and you can easilly force ipsec-tools compilation WITHOUT NAT-T support. Yvan. -- NETASQ http://www.netasq.com From rea-fbsd at codelabs.ru Thu Jun 26 09:53:45 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Thu Jun 26 09:53:49 2008 Subject: FreeBSD 7.0: sockets stuck in CLOSED state... In-Reply-To: <486283B0.3060805@transip.nl> References: <486283B0.3060805@transip.nl> Message-ID: <5A9ZR/wNTIFIXEvIi7qXj2foxBI@/2P5JkFFETcbMzHSQ1hIkFGHokc> Good day. Wed, Jun 25, 2008 at 07:43:12PM +0200, Ali Niknam wrote: > Recently i've been upgrading some of my machines from FreeBSD 6.x amd64 > to FreeBSD 7.0 amd64. > > After upgrading I noticed a weird error/bug. It seems that after several > thousand TCP connections some seem to hang in 'CLOSED' state. > > netstat -n gives: > ... > tcp4 0 0 1.2.3.4.* 4.5.6.7.42149 CLOSED > tcp4 39 0 1.2.3.4.* 4.5.6.7.54103 CLOSED > tcp4 35 0 1.2.3.4.* 4.5.6.7.41718 CLOSED > tcp4 38 0 1.2.3.4.* 4.5.6.7.55618 CLOSED > tcp4 41 0 1.2.3.4.* 4.5.6.7.44230 CLOSED > tcp4 39 0 1.2.3.4.* 4.5.6.7.49439 CLOSED > ... Just a quick "me too" message: I also used to see this on my 7.x machines. This was with Apache servers in the proxy setup: one Apache was listening to the external requests and routing them to the internal servers that are also running Apache. I refrained from such setup and traded front-end Apache to nginx -- CLOSED sockets gone away. I had already tried to debug this situation and Mike Silbersack helped me with patching the kernel. At that days his patches (that went into 7.x) helped, but with higher request rate to the Apache, they seem to be back again. I can try to setup the testbed and verify if I will still be able to reproduce them. Will it be needed? > These never go away; they gradually increase and increase until the > application starts giving errors (probably because some socket or > filedescriptor limit is reached). When the application is killed these > entries disappear. > > The application in question is a self written DNS server, multithreaded, > and running fine for years without any troubles on both BSD 5.x as well > as 6.x. Also 32bits as well as 64bits on 6.x. Mine was Apache 2.2.x with fork model, no threading. -- Eygene From harunaga at harunaga.ru Thu Jun 26 10:09:05 2008 From: harunaga at harunaga.ru (Daniil Harun) Date: Thu Jun 26 10:09:10 2008 Subject: patch for IPSEC_NAT_T Message-ID: <200806261609.01289.harunaga@harunaga.ru> Dear sirs! Sorry for my bad English! I ask to help me, if you have some spare time. I'm using the patch for support IPSEC NAT Traversal on FreeBSD 7.0.Will not work NAT-T with Windows XP in the real situation. #cd /usr/src/sys patch < patch-natt-freebsd7-2008-03-11.diff Kernel config (FreeBSD 7.0): options IPSEC options IPSEC_NAT_T device enc device crypto device cryptodev Racoon config: listen { isakmp 80.85.151.51 [500]; isakmp_natt 80.85.151.51 [4500]; } timer { natt_keepalive 10 sec; } remote anonymous { exchange_mode main; my_identifier asn1dn; certificate_type x509 "ipsec-server.crt" "ipsec-server.key"; peers_certfile "ipsec-client.crt"; passive on; generate_policy on; nat_traversal force; proposal_check obey; # obey, strict, or claim proposal { authentication_method rsasig; encryption_algorithm 3des; hash_algorithm sha1; dh_group 2; } } sainfo anonymous { pfs_group 2; lifetime time 10 min; encryption_algorithm 3des, rijndael; authentication_algorithm hmac_sha1; compression_algorithm deflate; } #ipfw show 00001 0 0 allow ip from any to any via enc0 65535 0 0 allow ip from any to any Configure and apply policies on the windows ipsec. A host with Windows XP has address 80.85.145.224. A host with FreeBSD has address 80.85.151.51. Ping FreeBSD on Windows XP and run tcpdump on FreeBSD. # tcpdump -npti fxp0 host 80.85.145.224 IP 80.85.145.224.500 > 80.85.151.51.500: isakmp: phase 1 I ident IP 80.85.151.51.500 > 80.85.145.224.500: isakmp: phase 1 R ident IP 80.85.145.224.500 > 80.85.151.51.500: isakmp: phase 1 I ident IP 80.85.151.51.500 > 80.85.145.224.500: isakmp: phase 1 R ident IP 80.85.145.224.4500 > 80.85.151.51.4500: NONESP-encap: isakmp: phase 1 I ident[E] IP 80.85.145.224 > 80.85.151.51: udp IP 80.85.151.51.4500 > 80.85.145.224.4500: NONESP-encap: isakmp: phase 1 R ident[E] IP 80.85.151.51.4500 > 80.85.145.224.4500: NONESP-encap: isakmp: phase 2/others R inf[E] IP 80.85.145.224.4500 > 80.85.151.51.4500: NONESP-encap: isakmp: phase 2/others I oakley-quick[E] IP 80.85.151.51.4500 > 80.85.145.224.4500: NONESP-encap: isakmp: phase 2/others R oakley-quick[E] IP 80.85.145.224.4500 > 80.85.151.51.4500: UDP-encap: ESP(spi=0x00a13e8f,seq=0x1), length 76 IP 80.85.145.224.4500 > 80.85.151.51.4500: NONESP-encap: isakmp: phase 2/others I oakley-quick[E] IP 80.85.145.224.4500 > 80.85.151.51.4500: UDP-encap: ESP(spi=0x00a13e8f,seq=0x2), length 76 IP 80.85.151.51.4500 > 80.85.145.224.4500: UDP-encap: ESP(spi=0xa9d7fa75,seq=0x1), length 76 IP 80.85.151.51.4500 > 80.85.145.224.4500: isakmp-nat-keep-alive IP 80.85.145.224.4500 > 80.85.151.51.4500: UDP-encap: ESP(spi=0x00a13e8f,seq=0x3), length 76 IP 80.85.151.51.4500 > 80.85.145.224.4500: UDP-encap: ESP(spi=0xa9d7fa75,seq=0x2), length 76 IP 80.85.145.224.4500 > 80.85.151.51.4500: UDP-encap: ESP(spi=0x00a13e8f,seq=0x4), length 76 IP 80.85.151.51.4500 > 80.85.145.224.4500: UDP-encap: ESP(spi=0xa9d7fa75,seq=0x3), length 76 IP 80.85.151.51.4500 > 80.85.145.224.4500: isakmp-nat-keep-alive # tcpdump -npti enc0 (authentic,confidential): SPI 0x0786ecb5: IP 80.85.145.224 > 80.85.151.51: ICMP echo request, id 512, seq 4608, length 40 (authentic,confidential): SPI 0x60fa28ee: IP 80.85.151.51 > 80.85.145.224: ICMP echo reply, id 512, seq 4608, length 40 (authentic,confidential): SPI 0x0786ecb5: IP 80.85.145.224 > 80.85.151.51: ICMP echo request, id 512, seq 4864, length 40 (authentic,confidential): SPI 0x60fa28ee: IP 80.85.151.51 > 80.85.145.224: ICMP echo reply, id 512, seq 4864, length 40 (authentic,confidential): SPI 0x0786ecb5: IP 80.85.145.224 > 80.85.151.51: ICMP echo request, id 512, seq 5120, length 40 (authentic,confidential): SPI 0x60fa28ee: IP 80.85.151.51 > 80.85.145.224: ICMP echo reply, id 512, seq 5120, length 40 # /usr/local/sbin/setkey -D 80.85.151.51[4500] 80.85.145.224[4500] esp-udp mode=transport spi=1074885652(0x40117414) reqid=0(0x00000000) E: 3des-cbc 2753f418 16ae6b2d 7db165b1 78489da4 84c61b5c 74ba0eab A: hmac-sha1 8dbb660d 8d461664 db9f2576 b1c51494 24bc72f3 seq=0x00000001 replay=4 flags=0x00000000 state=mature created: Jun 25 22:33:08 2008 current: Jun 25 22:33:14 2008 diff: 6(s) hard: 900(s) soft: 900(s) last: Jun 25 22:33:09 2008 hard: 0(s) soft: 0(s) current: 96(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 1 hard: 0 soft: 0 sadb_seq=1 pid=9531 refcnt=2 80.85.145.224[4500] 80.85.151.51[4500] esp-udp mode=transport spi=145306844(0x08a934dc) reqid=0(0x00000000) E: 3des-cbc 236d1e55 e194f00c a18ed711 081baab3 2692c6f5 6607f06e A: hmac-sha1 74971750 35c1ed4a 7f435f86 b17a4195 7d1aee61 seq=0x00000001 replay=4 flags=0x00000000 state=mature created: Jun 25 22:33:08 2008 current: Jun 25 22:33:14 2008 diff: 6(s) hard: 900(s) soft: 900(s) last: Jun 25 22:33:09 2008 hard: 0(s) soft: 0(s) current: 60(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 1 hard: 0 soft: 0 sadb_seq=0 pid=9531 refcnt=1 # /usr/local/sbin/setkey -DP 80.85.145.224[any] 80.85.151.51[any] any in ipsec esp/transport//require spid=3366 seq=1 pid=9532 refcnt=1 80.85.151.51[any] 80.85.145.224[any] any out ipsec esp/transport//require spid=3367 seq=0 pid=9532 refcnt=1 All works, UDP and TCP traffic passes through IPSEC. Normal working L2TP over IPSEC. # /usr/local/sbin/setkey -DP 80.85.145.224[any] 80.85.151.51[1701] udp in ipsec esp/transport//require spid=3368 seq=1 pid=9606 refcnt=1 80.85.151.51[1701] 80.85.145.224[any] udp out ipsec esp/transport//require spid=3369 seq=0 pid=9606 refcnt=1 But when the host is placed over NAT, everything stops working. After negotiates IKE and key additions to the database SA traffic does not pass. "tcpdump enc0" shows that traffic is decoded normaly, but then he does not processed, packets discarded. Counters ipfw to rule 1 does not grow. At FreeBSD 6.2 I have the same problem (FAST_IPSEC or KAME IPSEC). How to fix it? I would be happy to answer any! -- Best regards, Harun Daniil From vanhu_bsd at zeninc.net Thu Jun 26 11:47:55 2008 From: vanhu_bsd at zeninc.net (VANHULLEBUS Yvan) Date: Thu Jun 26 11:48:02 2008 Subject: patch for IPSEC_NAT_T In-Reply-To: <200806261609.01289.harunaga@harunaga.ru> References: <200806261609.01289.harunaga@harunaga.ru> Message-ID: <20080626114752.GA3121@zen.inc> On Thu, Jun 26, 2008 at 04:09:00PM +0600, Daniil Harun wrote: > Dear sirs! Hi. I forgot to reply your private mail this morning, but it's still better to have the question and the answer on a public ML, it may be useful for other people. > Sorry for my bad English! I ask to help me, if you have some spare time. > > I'm using the patch for support IPSEC NAT Traversal on FreeBSD 7.0.Will not > work NAT-T with Windows XP in the real situation. [....] > But when the host is placed over NAT, everything stops working. > After negotiates IKE and key additions to the database SA traffic does not > pass. "tcpdump enc0" shows that traffic is decoded normaly, but then he does > not processed, packets discarded. > Counters ipfw to rule 1 does not grow. At FreeBSD 6.2 I have the same problem > (FAST_IPSEC or KAME IPSEC). ESP transport with NAT-T may need NAT-OA support, which is not provided by the actual patch, nor by userland. "may", because checksums (which needs that NAT-OA payload to be correctly recomputed by the destination) are optionnal on UDP, and, afaik, L2TP is encapsulated in UDP datagrams. Looks like XP sets the checksums for UDP datagrams..... Yvan. -- NETASQ http://www.netasq.com From harunaga at harunaga.ru Thu Jun 26 13:44:41 2008 From: harunaga at harunaga.ru (Daniil Harun) Date: Thu Jun 26 13:44:45 2008 Subject: patch for IPSEC_NAT_T In-Reply-To: <20080626114752.GA3121@zen.inc> References: <200806261609.01289.harunaga@harunaga.ru> <20080626114752.GA3121@zen.inc> Message-ID: <200806261944.39032.harunaga@harunaga.ru> Hi! > > But when the host is placed over NAT, everything stops working. > > After negotiates IKE and key additions to the database SA traffic does > > not pass. "tcpdump enc0" shows that traffic is decoded normaly, but then > > he does not processed, packets discarded. > > Counters ipfw to rule 1 does not grow. At FreeBSD 6.2 I have the same > > problem (FAST_IPSEC or KAME IPSEC). > > ESP transport with NAT-T may need NAT-OA support, which is not > provided by the actual patch, nor by userland. > > "may", because checksums (which needs that NAT-OA payload to be > correctly recomputed by the destination) are optionnal on UDP, and, > afaik, L2TP is encapsulated in UDP datagrams. > > Looks like XP sets the checksums for UDP datagrams..... In such a case should help it: sysctl net.inet.udp.checksum=0 ? -- Best regards, Harun Daniil From gavin at FreeBSD.org Thu Jun 26 13:53:26 2008 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Thu Jun 26 13:53:34 2008 Subject: kern/125003: [gif] incorrect EtherIP header format. Message-ID: <200806261353.m5QDrQiu047519@freefall.freebsd.org> Old Synopsis: incorrect EtherIP header format. New Synopsis: [gif] incorrect EtherIP header format. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Thu Jun 26 13:52:03 UTC 2008 Responsible-Changed-Why: Over to maintainers http://www.freebsd.org/cgi/query-pr.cgi?pr=125003 From aragon at phat.za.net Thu Jun 26 14:55:51 2008 From: aragon at phat.za.net (Aragon Gouveia) Date: Thu Jun 26 14:55:57 2008 Subject: FreeBSD 7 routing/ppp changed? Message-ID: <20080626142913.GA11532@phat.za.net> Hi, I recently migrated a 6.2 system to 7.0-STABLE. One of the system's functions was a PPPoE gateway that performed Proxy ARP for its PPP clients. In 6.2 days when a connection was made the route entry for the PPP client showed: 192.168.9.245 192.168.9.2 UH 0 1 tun0 192.168.9.245 00:1b:78:37:d1:97 UHLS2 1 0 bge0 192.168.9.2 being the 6.2 system, and bge0 being its ethernet device. On the 7.0 system the route entry looks like this: 192.168.9.248 192.168.9.1 UGH 0 0 bge0 192.168.9.248 00:1f:29:78:25:9d UHLS2 1 0 bge0 And the PPPoE connection doesn't work. I have to manually remove the route entry and recreate it with the -interface argument to get things working. My PPP configs are the same on both machines as seen below. Is this a bug I need to PR? Thanks, Aragon <---ppp.conf---> default: set log Phase Chat LCP IPCP CCP tun command ident user-ppp VERSION (built COMPILATIONDATE) id: allow mode direct enable lqr echo proxy enable chap set ifaddr 192.168.9.1 192.168.9.241-192.168.9.254 accept dns set dns 192.168.9.1 <---grep pppoed /etc/rc.conf---> pppoed_enable="YES" pppoed_provider="id" pppoed_interface="bge0" From thompsa at FreeBSD.org Thu Jun 26 15:10:03 2008 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Thu Jun 26 15:10:08 2008 Subject: kern/125003: incorrect EtherIP header format. Message-ID: <200806261510.m5QFA3Uq053133@freefall.freebsd.org> The following reply was made to PR kern/125003; it has been noted by GNATS. From: Andrew Thompson To: Shunsuke SHINOMIYA Cc: bug-followup@FreeBSD.org Subject: Re: kern/125003: incorrect EtherIP header format. Date: Thu, 26 Jun 2008 07:34:24 -0700 Hi, It is unclear where the interoperability problem comes in. struct etherip_header { u_int8_t eip_ver; /* version/reserved */ u_int8_t eip_pad; /* required padding byte */ }; #define ETHERIP_VER_VERS_MASK 0x0f #define ETHERIP_VERSION 0x03 From rfc3378, 1. Prepend the 16-bit EtherIP header to the MAC frame. The EtherIP Version field MUST be set to 3 (three), and the EtherIP Reserved field MUST be set to 0 (zero). And the outgoing header is set to. eiphdr.eip_ver = ETHERIP_VERSION & ETHERIP_VER_VERS_MASK; eiphdr.eip_pad = 0; Which would conform to the requirement. Can you describe the problem you are seeing. regards, Andrew From petar at smokva.net Thu Jun 26 15:13:00 2008 From: petar at smokva.net (Petar Bogdanovic) Date: Thu Jun 26 15:13:07 2008 Subject: ath hostap: antenna diversity or not? Message-ID: <20080626151257.GA3767@pintail.smokva.net> Hi, in order to compare the performance between antenna-diversity on and off I did a quick test with the following sysctl settings: # antenna-diversity on dev.ath.0.diversity=1 # antenna-diversity off dev.ath.0.diversity=0 dev.ath.0.txantenna=1 dev.ath.0.rxantenna=2 The performance was pretty much the same but I noticed that the link-quality reported by my laptop was notable lower with enabled antenna-diversity (AD): ~ 43/70 (AD on) ~ 51/70 (AD off) I've read a few things about AD on Wikipedia and it seems to be a good technique to achieve a better signal quality but OTOH there are people who recommend turning it off to get a better signal quality. So whats actually true here? Thanks, Petar From hrs at FreeBSD.org Thu Jun 26 15:40:04 2008 From: hrs at FreeBSD.org (Hiroki Sato) Date: Thu Jun 26 15:40:09 2008 Subject: kern/125003: incorrect EtherIP header format. Message-ID: <200806261540.m5QFe4mL057273@freefall.freebsd.org> The following reply was made to PR kern/125003; it has been noted by GNATS. From: Hiroki Sato To: shino@fornext.org Cc: freebsd-bugs@FreeBSD.org, bug-followup@FreeBSD.org Subject: Re: kern/125003: incorrect EtherIP header format. Date: Fri, 27 Jun 2008 00:30:14 +0900 (JST) ----Security_Multipart(Fri_Jun_27_00_30_14_2008_807)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Shunsuke SHINOMIYA wrote in <20080626192225.9813.A2D40D1E@fornext.org>: sh> In current implementation, 0x03 is transmitted, and, next, 0x00 is sh> transmitted as version(3) and reserved(0x000) field. But I think that sh> 0x30 should be transmitted first from RFC3378. I don't understand why you think 0x30 is correct. -- | Hiroki SATO ----Security_Multipart(Fri_Jun_27_00_30_14_2008_807)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkhjtgYACgkQTyzT2CeTzy21ZQCfa0YYRixI0Sq5yb779GTsTtOX 9z0AoIdkDi+H/h2pSB30vTvZk60OwXIM =0Fi9 -----END PGP SIGNATURE----- ----Security_Multipart(Fri_Jun_27_00_30_14_2008_807)---- From mgrooms at shrew.net Thu Jun 26 17:05:16 2008 From: mgrooms at shrew.net (mgrooms) Date: Thu Jun 26 17:05:20 2008 Subject: patch for IPSEC_NAT_T In-Reply-To: References: Message-ID: <30025d295f8077e96bcb3f3a076c8bd1@localhost> On Thu, 26 Jun 2008 11:51:26 -0500, mgrooms wrote: > > ESP transport with NAT-T may need NAT-OA support, which is not > provided by the actual patch, nor by userland. > I checked in Timos patch for NAT-T original address support into ipsec-tools last December. This will be available in our 0.8 release. http://cvsweb.netbsd.org/bsdweb.cgi/src/crypto/dist/ipsec-tools/ChangeLog.diff?r1=1.139&r2=1.140 I believe we are just missing the kernel bits on FreeBSD. -Matthew From mgrooms at shrew.net Thu Jun 26 18:49:39 2008 From: mgrooms at shrew.net (mgrooms) Date: Thu Jun 26 18:49:44 2008 Subject: FreeBSD NAT-T patch integration In-Reply-To: <48ca67dd60c19f94b4f21bbe88854da7@localhost> References: <48ca67dd60c19f94b4f21bbe88854da7@localhost> Message-ID: <86c7b60b19e63e9188701611ac0f6f17@localhost> > On Wed, Jun 25, 2008 at 04:30:36PM -0400, Scott Ullrich wrote: >> On Wed, Jun 25, 2008 at 4:24 PM, Julian Elischer > wr= > ote: >> > do you have the ability to test this? >>=20 >> Absolutely. Is this the only thing from preventing it being merged > into= > HEAD? > > No. It's a large and complex patch an a subsystem (ipsec) that must not > be broken. We're a bit shorthanded in this area, but people have been > working on this for quite some time and IIRC aren't fully comfortable > with the patch yet. Every time the question of integrating the NAT-T patches is brought up, a post list this is usually where this thread dies. Forgive me for my persistence :) >From this thread and previous threads, its known that FreeBSD + NAT-T is being used in several production environments without issue. I use it myself to perform compatibility testing and have never encountered a problem with later versions of the patch. Not being a FreeBSD kernel developer, I can't comment on the correctness of the patch, only that it works well for me. So very respectfully, what needs to happen for this patch to be committed? FreeBSD is a great operating system with a great developer community. If the patch has been fully reviewed and problems have been found, what are they? If there is enough demand for this patch to be integrated, maybe other kernel developers would lend a hand in resolving the issues if they were made public. Both of the threads I started on this list were answered by developers willing to pitch in. If the patch hasn't been fully reviewed and its a lack of man hours required, again, maybe someone can lend a helping hand in this regard as well. Perhaps a full review with the intent to commit is happening right now but its just not public knowledge. A reply to this effect would silence annoying people like myself :) I'm not suggesting it should be MFCd tomorrow. A kernel source commit log occasionally suggests that a patch is being integrated so that it can receive more testing by the public at large. Maybe committing it to head is the best action to take? Its a compile time option for IPsec and another compile time option for NAT-T. Are we really talking about that much of a risk? I'm not trying to start a flame war here, but the patch has been floating around since before the 5.x days. There just seems to be a dark cloud hanging over it and I, and no doubt many others, really don't know why. Please help us understand these reasons and what can be done to help. Thanks, -Matthew From julian at elischer.org Thu Jun 26 19:44:36 2008 From: julian at elischer.org (Julian Elischer) Date: Thu Jun 26 19:44:39 2008 Subject: need help from pf developer(s) Message-ID: <4863F1B0.9060603@elischer.org> If you are one of the people that know and love pf, I'd like to speak to you on one side about testing pf with vimage.. (and making it work as I'm sure it doesn't). From julian at elischer.org Thu Jun 26 19:56:26 2008 From: julian at elischer.org (Julian Elischer) Date: Thu Jun 26 19:56:31 2008 Subject: FreeBSD NAT-T patch integration In-Reply-To: <86c7b60b19e63e9188701611ac0f6f17@localhost> References: <48ca67dd60c19f94b4f21bbe88854da7@localhost> <86c7b60b19e63e9188701611ac0f6f17@localhost> Message-ID: <4863F479.8010206@elischer.org> mgrooms wrote: >> On Wed, Jun 25, 2008 at 04:30:36PM -0400, Scott Ullrich wrote: >>> On Wed, Jun 25, 2008 at 4:24 PM, Julian Elischer >> wr= >> ote: >>>> do you have the ability to test this? >>> =20 >>> Absolutely. Is this the only thing from preventing it being merged >> into= >> HEAD? >> >> No. It's a large and complex patch an a subsystem (ipsec) that must not >> be broken. We're a bit shorthanded in this area, but people have been >> working on this for quite some time and IIRC aren't fully comfortable >> with the patch yet. > > Every time the question of integrating the NAT-T patches is brought up, a > post list this is usually where this thread dies. Forgive me for my > persistence :) > >>From this thread and previous threads, its known that FreeBSD + NAT-T is > being used in several production environments without issue. I use it > myself to perform compatibility testing and have never encountered a > problem with later versions of the patch. Not being a FreeBSD kernel > developer, I can't comment on the correctness of the patch, only that it > works well for me. So very respectfully, what needs to happen for this > patch to be committed? > > FreeBSD is a great operating system with a great developer community. If > the patch has been fully reviewed and problems have been found, what are > they? If there is enough demand for this patch to be integrated, maybe > other kernel developers would lend a hand in resolving the issues if they > were made public. Both of the threads I started on this list were answered > by developers willing to pitch in. If the patch hasn't been fully reviewed > and its a lack of man hours required, again, maybe someone can lend a > helping hand in this regard as well. Perhaps a full review with the intent > to commit is happening right now but its just not public knowledge. A reply > to this effect would silence annoying people like myself :) > > I'm not suggesting it should be MFCd tomorrow. A kernel source commit log > occasionally suggests that a patch is being integrated so that it can > receive more testing by the public at large. Maybe committing it to head is > the best action to take? Its a compile time option for IPsec and another > compile time option for NAT-T. Are we really talking about that much of a > risk? > > I'm not trying to start a flame war here, but the patch has been floating > around since before the 5.x days. There just seems to be a dark cloud > hanging over it and I, and no doubt many others, really don't know why. > Please help us understand these reasons and what can be done to help. I'm planning on committing it unless someone can provide a reason not to, as I've seen it working, needed it, and have not seen any bad byproducts. > > Thanks, > > -Matthew > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From auryn at zirakzigil.org Thu Jun 26 20:06:19 2008 From: auryn at zirakzigil.org (Giulio Ferro) Date: Thu Jun 26 20:06:23 2008 Subject: SOLVED (was Re: Problem clarification (was: Problems with vlan + carp + alias)) In-Reply-To: <48630AA3.3000800@ibctech.ca> References: <486000B5.9090703@zirakzigil.org> <4862B2AF.70202@zirakzigil.org> <48630AA3.3000800@ibctech.ca> Message-ID: <4863F6B3.4020308@zirakzigil.org> Steve Bertrand wrote: > Thank you Giulio (is it Gio?) No, it's Giulio (english Julius) :-) > >> For some reason when I >> plugged in the new firewall, only the base non-aliased address was >> updated in >> the ISP switch arp cache (if someone can throw a guess at why, I'm >> eager to listen). > > Well, you need to know what type of switch they had upstream, and why > they weren't updating their ARP cache dynamically properly. Perhaps > because their cache ttl was too long (due to the type of hardware, or > administrative setting). > The strange thing is that they actually updated their arp entry for the base (non aliased) address, but not the others. I guess what I could do was to "poison" their arp cache for each address with a "is-at" message. Is there a way to force the sending of these messages for all the addresses of an interface? > I almost have to assume it wasn't a Cisco... only because I would have > expected different behavior (less administrative setting) (this is my > personal experience...I'm not trying to favour a brand in any way). > > Perhaps you could ask them to provide the command they issued to > determine how they found the problem. Better yet, ask what type of > device your box is connected to at their end of the VLAN. It was me who finally realized what the problem was. All I asked them to do was to reset the arp cache of the interface, and I guess they did that by ios (or cli or whatever), not something I could do without logging in into their switch... > > If you can find out what device they have at their end, it may almost > be possible to non-destructively, and non-corruptively 'force' them to > clear arp-cache remotely, and at the same time provide advice to the > non-unscrupulous people who may run into this in the future. I guess I could have used utilities like ettercap to set their arp table right, and this is what another person should do, if they have no other way to operate that change... > > I'd be just as interested to know what they had at their end for > hardware, as I have been waiting to hear what your resolution was > throughout your time consuming troubleshooting... Thanks for your support :-) I've seen many cisco devices in that farm, so I guess that's the answer. I image (since I don't really know) that every ip interface should periodically issue "who-has" messages for the directly-connected addresses, so maybe the problem would have solved itself, but I didn't really know how long that would have taken, and I couldn't stop the services provided by my customer too long... Anyway all is well as it ends well.. Giulio. From auryn at zirakzigil.org Thu Jun 26 20:22:01 2008 From: auryn at zirakzigil.org (Giulio Ferro) Date: Thu Jun 26 20:22:05 2008 Subject: altq on vlan Message-ID: <4863FA62.2030703@zirakzigil.org> I've tried to set altq bandwidth control on a vlan interface, but this feature doesn't seem to be supported by the vlan driver. I've googled around and I've found that there should be a trivial patch to enable this feature: http://people.yandex-team.ru/~sem/FreeBSD/vlan+altq.patch If this is so trivial, why hasn't it been included in the freebsd source tree? Anyway has anybody tried that? How does that work? Are there other (better) patches around? Thanks in advance. From mgrooms at shrew.net Thu Jun 26 20:39:06 2008 From: mgrooms at shrew.net (mgrooms) Date: Thu Jun 26 20:39:10 2008 Subject: FreeBSD NAT-T patch integration In-Reply-To: <4863F479.8010206@elischer.org> References: <4863F479.8010206@elischer.org> Message-ID: On Thu, 26 Jun 2008 12:56:41 -0700, Julian Elischer wrote: > mgrooms wrote: >> >> I'm not trying to start a flame war here, but the patch has been > floating >> around since before the 5.x days. There just seems to be a dark cloud >> hanging over it and I, and no doubt many others, really don't know why. >> Please help us understand these reasons and what can be done to help. > Woops. I meant to say that it had been floating around since before the 6.x days. My bad. > I'm planning on committing it unless someone can provide a reason not > to, as I've seen it working, needed it, and have not seen any bad > byproducts. > I appreciate your offer to help. At the very least, I hope we will see a published list of technical hurdles that need to be overcome before the patch can be applied. Thanks again, -Matthew From gavin at FreeBSD.org Thu Jun 26 20:40:17 2008 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Thu Jun 26 20:40:20 2008 Subject: kern/125024: vr(4) does not see incoming multicast packets in non-promiscuous mode (broadcast is fine); breaks IPv6 Message-ID: <200806262040.m5QKeGco083237@freefall.freebsd.org> Old Synopsis: vr(4) does not see incoming multicast packets in non-promiscuous New Synopsis: vr(4) does not see incoming multicast packets in non-promiscuous mode (broadcast is fine); breaks IPv6 Responsible-Changed-From-To: gnats-admin->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Thu Jun 26 20:36:10 UTC 2008 Responsible-Changed-Why: Over to maintainers http://www.freebsd.org/cgi/query-pr.cgi?pr=125024 From paul at gtcomm.net Fri Jun 27 03:23:20 2008 From: paul at gtcomm.net (Paul) Date: Fri Jun 27 03:23:24 2008 Subject: Weirdness - FBSD 7, Routing, Packet generator, em taskq Message-ID: <48645D9E.7090303@gtcomm.net> I have a FreeBSD router set up with Full BGP routes and I'm doing some tests on using it for routing. 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #6: Thu Apr 17 18:11:49 EDT 2008 amd64 oddness..: Use a packet generator to generate random source ips and ports and send traffic through the router to a destination on the other side, single ip. What happens is the 'em0 taskq' starts to eat cpu... but the funny thing is immediately when I start the traffic (say, 100,000 pps) em0 taskq is about 15% cpu.. and then over the course of 2 minutes or so it climbs to 60% cpu.. This makes no sense.. The packets per second are continuous and it just routed 100kpps for 60 seconds with less cpu so why in the world would it slowly climb like that? It's an observation I suppose and I was hoping if someone could enlighten me on WHY.. :) I did test it on 3 different machines by the way. It even does this with just a handful of routes in the routing table , I tried that too just to rule that out. I don't remember Freebsd 4/5 doing this?? Thank you. Paul From yongari at FreeBSD.org Fri Jun 27 03:45:03 2008 From: yongari at FreeBSD.org (yongari@FreeBSD.org) Date: Fri Jun 27 03:45:05 2008 Subject: kern/125024: vr(4) does not see incoming multicast packets in non-promiscuous mode (broadcast is fine); breaks IPv6 Message-ID: <200806270345.m5R3j1BT036253@freefall.freebsd.org> Synopsis: vr(4) does not see incoming multicast packets in non-promiscuous mode (broadcast is fine); breaks IPv6 State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Fri Jun 27 03:43:26 UTC 2008 State-Changed-Why: Would you try patch at the following URL? http://people.freebsd.org/~yongari/vr/vr.cam.patch Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Fri Jun 27 03:43:26 UTC 2008 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=125024 From ml at t-b-o-h.net Fri Jun 27 04:30:21 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Fri Jun 27 04:30:24 2008 Subject: IPV6 problem : nd6_lookup: failed to add route for a neighbor Message-ID: <200806270430.m5R4U5Ib025336@himinbjorg.tucs-beachin-obx-house.com> Hi, Running 5.5 (And no "upgrade" messages please, I'm forced to, its out of my hands) and trying to bring up HE's IPV6. I've got it running on a 4.10 system (Ok, feel free to tell me to upgrade, this one is more a lazy issue.. But I am making progress. I bought new drives that'll be here next week so I can load 7.0 from scratch) with no worries at all. Piece of cake, has been for ages. But once I brought it all up, I got : kernel: nd6_lookup: failed to add route for a neighbor(2001:0470:0007:0028::0001), errno=17 and ALOT of them. Taking a quick look in Google, it seems that they claim its a prefix len issue, but I am running with a 128 prefix length even though it seems they say : Client IPv6 address: 2001:470:7:28::2/64 The script they suggest, and I used, is : ifconfig gif0 create ifconfig gif0 tunnel MYIP 216.66.22.2 ifconfig gif0 inet6 2001:470:7:28::2 2001:470:7:28::1 prefixlen 128 route -n add -inet6 default 2001:470:7:28::1 ifconfig gif0 up The tunnel came up, was passing traffic, but those messages were getting out of hand. I tried a prefixlen of 64, and I got: ifconfig: ioctl (SIOCAIFADDR): Invalid argument Sendmail seemed a bit cranky : Jun 26 23:53:19 MYHOST sendmail[17543]: gethostbyaddr(IPv6:2001:470:7:28::2) failed: 1 Suggestions where to start? Thanks, Tuc From shino at fornext.org Fri Jun 27 06:10:03 2008 From: shino at fornext.org (Shunsuke SHINOMIYA) Date: Fri Jun 27 06:10:05 2008 Subject: kern/125003: incorrect EtherIP header format. Message-ID: <200806270610.m5R6A3hR060682@freefall.freebsd.org> The following reply was made to PR kern/125003; it has been noted by GNATS. From: Shunsuke SHINOMIYA To: Hiroki Sato Cc: freebsd-bugs@FreeBSD.org, bug-followup@FreeBSD.org Subject: Re[2]: kern/125003: incorrect EtherIP header format. Date: Fri, 27 Jun 2008 15:00:45 +0900 > sh> In current implementation, 0x03 is transmitted, and, next, 0x00 is > sh> transmitted as version(3) and reserved(0x000) field. But I think tha= t > sh> 0x30 should be transmitted first from RFC3378. >=20 > I don't understand why you think 0x30 is correct. =46rom RFC3378 > In summary, the EtherIP Header has two fields: >=20 > Bits 0-3: Protocol version > Bits 4-15: Reserved for future use >=20 > 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > | | | > | VERSION | RESERVED | > | | | > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >=20 > Figure 2: EtherIP Header Format (in bits) >=20 , first octet(bit 0,MSB to 7) consists of VERSION and a part of RESERVED. And VERSION is high 4 bits of the octet. Am I misunderstanding this? --=20 Shunsuke SHINOMIYA From freebsd-net at transip.nl Fri Jun 27 06:49:37 2008 From: freebsd-net at transip.nl (Ali Niknam) Date: Fri Jun 27 06:49:41 2008 Subject: FreeBSD 7.0: sockets stuck in CLOSED state... In-Reply-To: <5A9ZR/wNTIFIXEvIi7qXj2foxBI@/2P5JkFFETcbMzHSQ1hIkFGHokc> References: <486283B0.3060805@transip.nl> <5A9ZR/wNTIFIXEvIi7qXj2foxBI@/2P5JkFFETcbMzHSQ1hIkFGHokc> Message-ID: <48648D70.50304@transip.nl> Hi Eygene, > Just a quick "me too" message: I also used to see this on my 7.x > machines. This was with Apache servers in the proxy setup: one I'm wondering: where these 32 bit, or 64 bit machines? > I had already tried to debug this situation and Mike Silbersack > helped me with patching the kernel. At that days his patches (that > went into 7.x) helped, but with higher request rate to the Apache, > they seem to be back again. I can try to setup the testbed and > verify if I will still be able to reproduce them. Will it be needed? > Well, if your machine was indeed 64 bit, I for one would be very interested in knowing if it also appears in 32 bit. Although perhaps a little far fetched a recent experience has made me aware that 64-bitness just might break things :) Kind Regards, Ali From peterjeremy at optushome.com.au Fri Jun 27 07:23:28 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Fri Jun 27 07:23:33 2008 Subject: SOLVED (was Re: Problem clarification (was: Problems with vlan + carp + alias)) In-Reply-To: <4863F6B3.4020308@zirakzigil.org> References: <486000B5.9090703@zirakzigil.org> <4862B2AF.70202@zirakzigil.org> <48630AA3.3000800@ibctech.ca> <4863F6B3.4020308@zirakzigil.org> Message-ID: <20080627072301.GZ50631@server.vk2pj.dyndns.org> On 2008-Jun-26 22:06:11 +0200, Giulio Ferro wrote: > I guess what I could do was to "poison" their arp cache for each >address with a "is-at" message. Is there a way to force the sending >of these messages for all the addresses of an interface? The kernel should send out gratuitous ARP requests whenever you assign an address to an interface. You could confirm that this is happening by tcpdumping the interface whilst you add aliases. Rummaging around in ports, you might find net/arping or net/p5-Net-ARP useful if you want to manually generate gratuitous ARP requests. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080627/e55bc0a4/attachment.pgp From 20080111.freebsd.org at ab.ote.we.lv Fri Jun 27 07:32:08 2008 From: 20080111.freebsd.org at ab.ote.we.lv (Eugene M. Kim) Date: Fri Jun 27 07:32:10 2008 Subject: kern/125024: vr(4) does not see incoming multicast packets in non-promiscuous mode (broadcast is fine); breaks IPv6 In-Reply-To: <200806270345.m5R3j1BT036253@freefall.freebsd.org> References: <200806270345.m5R3j1BT036253@freefall.freebsd.org> Message-ID: <48649776.9040509@ab.ote.we.lv> yongari@FreeBSD.org wrote: > Would you try patch at the following URL? > http://people.freebsd.org/~yongari/vr/vr.cam.patch Nope, didn't fix it (symptom's still the same)... ;_; Regards, Eugene From 20080111.freebsd.org at ab.ote.we.lv Fri Jun 27 07:44:57 2008 From: 20080111.freebsd.org at ab.ote.we.lv (Eugene M. Kim) Date: Fri Jun 27 07:44:59 2008 Subject: kern/125024: vr(4) does not see incoming multicast packets in non-promiscuous mode (broadcast is fine); breaks IPv6 In-Reply-To: <48649776.9040509@ab.ote.we.lv> References: <200806270345.m5R3j1BT036253@freefall.freebsd.org> <48649776.9040509@ab.ote.we.lv> Message-ID: <48649A77.6010402@ab.ote.we.lv> FWIW, I stumbled upon this while browsing through old -net archives... Apparently re(4) had a similar (same?) problem. http://lists.freebsd.org/pipermail/freebsd-stable/2007-April/034336.html http://lists.freebsd.org/pipermail/freebsd-stable/2007-April/034339.html Cheers, Eugene From pyunyh at gmail.com Fri Jun 27 07:51:59 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Fri Jun 27 07:52:03 2008 Subject: kern/125024: vr(4) does not see incoming multicast packets in non-promiscuous mode (broadcast is fine); breaks IPv6 In-Reply-To: <48649776.9040509@ab.ote.we.lv> References: <200806270345.m5R3j1BT036253@freefall.freebsd.org> <48649776.9040509@ab.ote.we.lv> Message-ID: <20080627074948.GC67753@cdnetworks.co.kr> On Fri, Jun 27, 2008 at 12:32:06AM -0700, Eugene M. Kim wrote: > yongari@FreeBSD.org wrote: > > Would you try patch at the following URL? > > http://people.freebsd.org/~yongari/vr/vr.cam.patch > > Nope, didn't fix it (symptom's still the same)... ;_; > I've updated patch again. There was a bug that disabled multicasting filter. Back out previous patch and try again. The URL is the same as before. > Regards, > Eugene -- Regards, Pyun YongHyeon From auryn at zirakzigil.org Fri Jun 27 07:52:29 2008 From: auryn at zirakzigil.org (Giulio Ferro) Date: Fri Jun 27 07:52:33 2008 Subject: altq on vlan In-Reply-To: <4863FA62.2030703@zirakzigil.org> References: <4863FA62.2030703@zirakzigil.org> Message-ID: <48649C31.90108@zirakzigil.org> Giulio Ferro wrote: > http://people.yandex-team.ru/~sem/FreeBSD/vlan+altq.patch Nope, this patch doesn't apply cleanly to freebsd 7... From pyunyh at gmail.com Fri Jun 27 07:59:19 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Fri Jun 27 07:59:23 2008 Subject: kern/125024: vr(4) does not see incoming multicast packets in non-promiscuous mode (broadcast is fine); breaks IPv6 In-Reply-To: <48649A77.6010402@ab.ote.we.lv> References: <200806270345.m5R3j1BT036253@freefall.freebsd.org> <48649776.9040509@ab.ote.we.lv> <48649A77.6010402@ab.ote.we.lv> Message-ID: <20080627075708.GD67753@cdnetworks.co.kr> On Fri, Jun 27, 2008 at 12:44:55AM -0700, Eugene M. Kim wrote: > FWIW, I stumbled upon this while browsing through old -net archives... > Apparently re(4) had a similar (same?) problem. > > http://lists.freebsd.org/pipermail/freebsd-stable/2007-April/034336.html > http://lists.freebsd.org/pipermail/freebsd-stable/2007-April/034339.html > I believe these were already fixed in CURRENT/stable. I think your issue is a regression of vr(4) overhauling. Since VT6105M supports perfect filtering on multicast frames with CAM I've added that hardware capability but it seems that CAM programming wasn't correct. > Cheers, > Eugene -- Regards, Pyun YongHyeon From rwatson at FreeBSD.org Fri Jun 27 08:14:57 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Fri Jun 27 08:15:01 2008 Subject: FreeBSD 7.0: sockets stuck in CLOSED state... In-Reply-To: <20080626081831.V96707@fledge.watson.org> References: <486283B0.3060805@transip.nl> <20080625195523.N29013@fledge.watson.org> <4862BCF5.4070900@transip.nl> <20080626081831.V96707@fledge.watson.org> Message-ID: <20080627090939.M78484@fledge.watson.org> On Thu, 26 Jun 2008, Robert Watson wrote: > I think the first logical step is to wait for the application to get into > that state again, and then run procstat or fstat to dump the file descriptor > away for the process. Presumably in the normal steady state, you expect to > see a few IPC sockets (syslog, etc), a TCP listen socket, and some number of > in-progress TCP sessions. The question, of course, is whether you see a lot > more file descriptors than that, and in particular, ones that matched the > CLOSED entries in netstat. If you find that there are lots of open file > descriptors and they match up approximately with netstat, then it's an > application bug that just manifests a bit differently in 7.x than in 6.x. > On the other hand, if you see only a small number of open file descriptors, > then we may be looking at something quite a bit more complicated. Just a public followup for those following the thread: Ali has sent me netstat and sockstat/fstat data. It looks like each of the TCP connections appear in the netstat output in the CLOSED state also appears in sockstat with a file descriptor. This suggests an bug in which file descriptors are occasionally leaked, perhaps early in their life cycle as there's a bit of data in the input buffer. However, it's unclear still if it's an application bug (occasionally missing a close() on an accepted file descriptor) or a kernel bug (accept() or close() misbehaving such that the application doesn't know the file descriptor is open, or has tried to close it but no succeeded). Ali mentioned in his e-mail that he was seeing EBADF on occasion from close(), which could mean a bug is causing the wrong file descriptor number to be passed in. If there's a kernel bug involved, then you could imagine it being along the lines of "accept(2) returns a file descriptor but also sets an error, so the application simply sees the error but the file descriptor remains installed in the process's file descriptor table", leading to the appearance of a leak. I've asked Ali to do a bit more debugging and tracing of the application to see if we can reach any conclusions about this. In particular, if he traces to a file all file descriptor numbers returned by accept(2), then we can later compare that file with the leaked descriptors present in netstat/sockstat and decide whether the application *should* have known they were open or not. I also spotted a bug in the netstat/sockstat output, unrelated, in which the port number of the inpcb is cleared when the connection closes, meaning that netstat shows '*' as the port number. This isn't really necessary, but does lead to potentially confusing output. Robert N M Watson Computer Laboratory University of Cambridge From 20080111.freebsd.org at ab.ote.we.lv Fri Jun 27 08:17:29 2008 From: 20080111.freebsd.org at ab.ote.we.lv (Eugene M. Kim) Date: Fri Jun 27 08:17:32 2008 Subject: kern/125024: vr(4) does not see incoming multicast packets in non-promiscuous mode (broadcast is fine); breaks IPv6 In-Reply-To: <20080627074948.GC67753@cdnetworks.co.kr> References: <200806270345.m5R3j1BT036253@freefall.freebsd.org> <48649776.9040509@ab.ote.we.lv> <20080627074948.GC67753@cdnetworks.co.kr> Message-ID: <4864A217.3040309@ab.ote.we.lv> Pyun YongHyeon wrote: > I've updated patch again. There was a bug that disabled > multicasting filter. Back out previous patch and try again. > The URL is the same as before. > > > Regards, > > Eugene > rtsol still doesn't work with vr0 being in non-promiscuous mode. However, apparently vr0 picked up router solicitations during system boot-up, as ifconfig shows the correct prefixes autoconfigured. It seems something goes wrong in between. 'o 'a Eugene From max at love2party.net Fri Jun 27 08:38:05 2008 From: max at love2party.net (Max Laier) Date: Fri Jun 27 08:38:11 2008 Subject: altq on vlan In-Reply-To: <4863FA62.2030703@zirakzigil.org> References: <4863FA62.2030703@zirakzigil.org> Message-ID: <200806271036.12195.max@love2party.net> On Thursday 26 June 2008 22:21:54 Giulio Ferro wrote: > I've tried to set altq bandwidth control on a vlan interface, but this > feature > doesn't seem to be supported by the vlan driver. > > I've googled around and I've found that there should be a trivial patch > to enable this feature: > http://people.yandex-team.ru/~sem/FreeBSD/vlan+altq.patch > > If this is so trivial, why hasn't it been included in the freebsd > source tree? > > Anyway has anybody tried that? How does that work? Are there other > (better) patches around? You don't need a patch at all. What you do is: Queue on the physical interface, classify on the vlan interface. It is broken to allow ALTQ on a virtual interface if you can do it otherwise. in pf.conf speak: If you have "ifconfig vlanX vlandev bge0 ..." altq on bge0 .... queue { vlan0, vlan1, ... } queue vlan0 ... { vlan0_foo, vlan0_bar, ... } queue vlan0_foo queue vlan0_bar ... pass on vlanX ... queue vlanX_foobar And there you go. No patch - whatsoever - required here. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From steve at ibctech.ca Fri Jun 27 12:14:58 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Fri Jun 27 12:15:02 2008 Subject: IPV6 problem : nd6_lookup: failed to add route for a neighbor In-Reply-To: <200806270430.m5R4U5Ib025336@himinbjorg.tucs-beachin-obx-house.com> References: <200806270430.m5R4U5Ib025336@himinbjorg.tucs-beachin-obx-house.com> Message-ID: <4864D9C9.2020207@ibctech.ca> Tuc at T-B-O-H.NET wrote: > Hi, > > Running 5.5 (And no "upgrade" messages please, I'm forced to, its > out of my hands) and trying to bring up HE's IPV6. > > I've got it running on a 4.10 system (Ok, feel free to tell me > to upgrade, this one is more a lazy issue.. But I am making progress. I > bought new drives that'll be here next week so I can load 7.0 from > scratch) with no worries at all. Piece of cake, has been for ages. > > But once I brought it all up, I got : > > kernel: nd6_lookup: failed to add route for a neighbor(2001:0470:0007:0028::0001), errno=17 > > and ALOT of them. Taking a quick look in Google, it seems that they claim > its a prefix len issue, but I am running with a 128 prefix length even though it seems > they say : > > Client IPv6 address: 2001:470:7:28::2/64 > > The script they suggest, and I used, is : > > ifconfig gif0 create > ifconfig gif0 tunnel MYIP 216.66.22.2 > ifconfig gif0 inet6 2001:470:7:28::2 2001:470:7:28::1 prefixlen 128 > route -n add -inet6 default 2001:470:7:28::1 > ifconfig gif0 up > > The tunnel came up, was passing traffic, but those messages were > getting out of hand. I tried a prefixlen of 64, and I got: ...hmmmm. I'm not certain here, but since /128 represents only a single address, I can understand why FreeBSD is getting confused. A /128 is an IP within its own solitary subnet, so I'd have to guess that you need a route to the remote end of the tunnel before you can set it as a default gateway. I've been needing to set up a few more tunnels, so I'll try one with FreeBSD this morning with the same setup you have to try to replicate the problem (on 7.0). > ifconfig: ioctl (SIOCAIFADDR): Invalid argument What was the command that you had entered when you received the above error? When you tried to change prefix length, did you destroy the existing tunnel first? > Sendmail seemed a bit cranky : > > Jun 26 23:53:19 MYHOST sendmail[17543]: gethostbyaddr(IPv6:2001:470:7:28::2) failed: 1 I believe this is a reverse DNS issue. From how I perceive that message, Sendmail is trying to retrieve a hostname based on that IP. Steve From rea-fbsd at codelabs.ru Fri Jun 27 12:21:10 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Fri Jun 27 12:21:15 2008 Subject: FreeBSD 7.0: sockets stuck in CLOSED state... In-Reply-To: <48648D70.50304@transip.nl> References: <486283B0.3060805@transip.nl> <5A9ZR/wNTIFIXEvIi7qXj2foxBI@/2P5JkFFETcbMzHSQ1hIkFGHokc> <48648D70.50304@transip.nl> Message-ID: Ali, good day. Fri, Jun 27, 2008 at 08:49:20AM +0200, Ali Niknam wrote: > > Just a quick "me too" message: I also used to see this on my 7.x > > machines. This was with Apache servers in the proxy setup: one > > I'm wondering: where these 32 bit, or 64 bit machines? amd64. > > I had already tried to debug this situation and Mike Silbersack > > helped me with patching the kernel. At that days his patches (that > > went into 7.x) helped, but with higher request rate to the Apache, > > they seem to be back again. I can try to setup the testbed and > > verify if I will still be able to reproduce them. Will it be needed? > > > > Well, if your machine was indeed 64 bit, I for one would be very > interested in knowing if it also appears in 32 bit. Have no i386 machines to test on, sorry. Moreover, I can not yet reproduce the problem on my amd64, but I am continuing experiments. -- Eygene Remember that it is hard to read the on-line manual while single-stepping the kernel. -- FreeBSD Developers handbook From steve at ibctech.ca Fri Jun 27 12:33:30 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Fri Jun 27 12:33:32 2008 Subject: SOLVED (was Re: Problem clarification (was: Problems with vlan + carp + alias)) In-Reply-To: <20080627072301.GZ50631@server.vk2pj.dyndns.org> References: <486000B5.9090703@zirakzigil.org> <4862B2AF.70202@zirakzigil.org> <48630AA3.3000800@ibctech.ca> <4863F6B3.4020308@zirakzigil.org> <20080627072301.GZ50631@server.vk2pj.dyndns.org> Message-ID: <4864DE21.2030109@ibctech.ca> Peter Jeremy wrote: > On 2008-Jun-26 22:06:11 +0200, Giulio Ferro wrote: >> I guess what I could do was to "poison" their arp cache for each >> address with a "is-at" message. Is there a way to force the sending >> of these messages for all the addresses of an interface? > > The kernel should send out gratuitous ARP requests whenever you assign > an address to an interface. You could confirm that this is happening > by tcpdumping the interface whilst you add aliases. > > Rummaging around in ports, you might find net/arping or net/p5-Net-ARP > useful if you want to manually generate gratuitous ARP requests. ping -S src_addr should do the trick too, however, that obviously doesn't scale very well, so it's probably only best to test with.. Steve From paul at gtcomm.net Fri Jun 27 13:02:58 2008 From: paul at gtcomm.net (Paul) Date: Fri Jun 27 13:03:01 2008 Subject: FreeBSD 7.0: sockets stuck in CLOSED state... In-Reply-To: References: <486283B0.3060805@transip.nl> <5A9ZR/wNTIFIXEvIi7qXj2foxBI@/2P5JkFFETcbMzHSQ1hIkFGHokc> <48648D70.50304@transip.nl> Message-ID: <4864E0FE.40708@gtcomm.net> I have the same 'problem' if that helps any.. Sockets stuck for over a month in CLOSED and they have a * for the port on the source IP. tcp4 0 0 67.1.1.1.* 67.1.1.2.1261 CLOSED 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #6: Thu Apr 17 18:11:49 EDT 2008 amd64 Doesn't seem to cause any issues though. Eygene Ryabinkin wrote: > Ali, good day. > > Fri, Jun 27, 2008 at 08:49:20AM +0200, Ali Niknam wrote: > >>> Just a quick "me too" message: I also used to see this on my 7.x >>> machines. This was with Apache servers in the proxy setup: one >>> >> I'm wondering: where these 32 bit, or 64 bit machines? >> > > amd64. > > >>> I had already tried to debug this situation and Mike Silbersack >>> helped me with patching the kernel. At that days his patches (that >>> went into 7.x) helped, but with higher request rate to the Apache, >>> they seem to be back again. I can try to setup the testbed and >>> verify if I will still be able to reproduce them. Will it be needed? >>> >>> >> Well, if your machine was indeed 64 bit, I for one would be very >> interested in knowing if it also appears in 32 bit. >> > > Have no i386 machines to test on, sorry. Moreover, I can not yet > reproduce the problem on my amd64, but I am continuing experiments. > From rea-fbsd at codelabs.ru Fri Jun 27 14:06:22 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Fri Jun 27 14:06:27 2008 Subject: FreeBSD 7.0: sockets stuck in CLOSED state... In-Reply-To: <4864E0FE.40708@gtcomm.net> References: <486283B0.3060805@transip.nl> <5A9ZR/wNTIFIXEvIi7qXj2foxBI@/2P5JkFFETcbMzHSQ1hIkFGHokc> <48648D70.50304@transip.nl> <4864E0FE.40708@gtcomm.net> Message-ID: Paul, good day. Fri, Jun 27, 2008 at 08:45:50AM -0400, Paul wrote: > I have the same 'problem' if that helps any.. Sockets stuck for over a > month in CLOSED and they have a * for the port on the source IP. > tcp4 0 0 67.1.1.1.* 67.1.1.2.1261 CLOSED > 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #6: Thu Apr 17 18:11:49 EDT 2008 > amd64 > Doesn't seem to cause any issues though. And what is listening to that port? Can you identify the application? Just for the record -- may be it will narrow down the search list. Robert Watson told us today at the morning that he spotted the bug that lead to the '*' instead of port number. Robert, can you post the patch -- it seems to be not yet committed, at least cvs-src list has no signs of it? By the way, is the patch touches in_pcbdrop() in /sys/netinet/in_pcb.c, removing instruction 'inp->inp_lport = 0;'? -- Eygene Remember that it is hard to read the on-line manual while single-stepping the kernel. -- FreeBSD Developers handbook From gnn at neville-neil.com Fri Jun 27 15:06:57 2008 From: gnn at neville-neil.com (George V. Neville-Neil) Date: Fri Jun 27 15:07:03 2008 Subject: FreeBSD NAT-T patch integration In-Reply-To: <4863F479.8010206@elischer.org> References: <48ca67dd60c19f94b4f21bbe88854da7@localhost> <86c7b60b19e63e9188701611ac0f6f17@localhost> <4863F479.8010206@elischer.org> Message-ID: At Thu, 26 Jun 2008 12:56:41 -0700, julian wrote: > > I'm planning on committing it unless someone can provide a reason not > to, as I've seen it working, needed it, and have not seen any bad > byproducts. > I'd be interested to know how you tested it. NAT-T and IPsec are non-trivial protocols/subsystems that can have far reaching impacts on the network stack. Also, are you planning to maintain it after committing it? The biggest problem with NAT-T hasn't been the code, it's been that the author, who is doing a great job on the code, has been too busy to maintain it anywhere but at work. That is not a slam on the person or the code, I have the highest respect for both, but it reflects and important reality of the situation. Unless you're stepping up to maintain it as well as commit it I think it should not be committed. I know the Bjoern has been working hard to pick up the IPsec stuff in his free time, and I value his input on this subject quite a bit. Best, George From gnn at freebsd.org Fri Jun 27 15:08:35 2008 From: gnn at freebsd.org (gnn@freebsd.org) Date: Fri Jun 27 15:08:40 2008 Subject: Weirdness - FBSD 7, Routing, Packet generator, em taskq In-Reply-To: <48645D9E.7090303@gtcomm.net> References: <48645D9E.7090303@gtcomm.net> Message-ID: At Thu, 26 Jun 2008 23:25:18 -0400, Paul wrote: > > I have a FreeBSD router set up with Full BGP routes and I'm doing some > tests on using it for routing. > > 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #6: Thu Apr 17 18:11:49 EDT 2008 > amd64 > > oddness..: > > Use a packet generator to generate random source ips and ports and send > traffic through the router to a destination on the other side, single ip. > What happens is the 'em0 taskq' starts to eat cpu... but the funny > thing is immediately when I start the traffic (say, 100,000 pps) em0 > taskq is about 15% cpu.. and then over the course of 2 minutes or so it > climbs to 60% cpu.. This makes no sense.. The packets per second are > continuous and it just routed 100kpps for 60 seconds with less cpu so > why in the world would it slowly climb like that? > > It's an observation I suppose and I was hoping if someone could > enlighten me on WHY.. :) I did test it on 3 different machines by the way. > It even does this with just a handful of routes in the routing table , I > tried that too just to rule that out. > I don't remember Freebsd 4/5 doing this?? > What are you using to measure the CPU time? Some tools take time to gather up enough samples. Also, have you tried to do any profiling on the kernel to see why this might be the case? http://www.watson.org/~robert/freebsd/netperf/profile/ Best, George From samm at os2.kiev.ua Fri Jun 27 15:30:14 2008 From: samm at os2.kiev.ua (Alex Samorukov) Date: Fri Jun 27 15:30:20 2008 Subject: kern/121257: [tcp] TSO + natd -> slow outgoing tcp traffic Message-ID: <200806271530.m5RFUD2V044569@freefall.freebsd.org> The following reply was made to PR kern/121257; it has been noted by GNATS. From: Alex Samorukov To: bug-followup@FreeBSD.org, vnovy@vnovy.net Cc: Subject: Re: kern/121257: [tcp] TSO + natd -> slow outgoing tcp traffic Date: Fri, 27 Jun 2008 16:48:15 +0200 I can approve the problem. I found VERY slow outgoing speed on my new server with natd, and the problem was with TSO flag on public interface. Freebsd 7.0/i386, em network driver From biancalana at gmail.com Fri Jun 27 16:58:05 2008 From: biancalana at gmail.com (Alexandre Biancalana) Date: Fri Jun 27 16:58:09 2008 Subject: altq on vlan In-Reply-To: <200806271036.12195.max@love2party.net> References: <4863FA62.2030703@zirakzigil.org> <200806271036.12195.max@love2party.net> Message-ID: <8e10486b0806270957y439087a5ia0d4689ad2f24ce8@mail.gmail.com> On 6/27/08, Max Laier wrote: > > > You don't need a patch at all. What you do is: Queue on the physical > interface, classify on the vlan interface. It is broken to allow ALTQ on > a virtual interface if you can do it otherwise. > > in pf.conf speak: > > If you have "ifconfig vlanX vlandev bge0 ..." > > altq on bge0 .... queue { vlan0, vlan1, ... } > queue vlan0 ... { vlan0_foo, vlan0_bar, ... } > queue vlan0_foo > queue vlan0_bar > ... > > pass on vlanX ... queue vlanX_foobar > > And there you go. No patch - whatsoever - required here. But the patch simplify the cases where you need one queue per vlan. From max at love2party.net Fri Jun 27 17:16:25 2008 From: max at love2party.net (Max Laier) Date: Fri Jun 27 17:16:30 2008 Subject: altq on vlan In-Reply-To: <8e10486b0806270957y439087a5ia0d4689ad2f24ce8@mail.gmail.com> References: <4863FA62.2030703@zirakzigil.org> <200806271036.12195.max@love2party.net> <8e10486b0806270957y439087a5ia0d4689ad2f24ce8@mail.gmail.com> Message-ID: <200806271914.30216.max@love2party.net> On Friday 27 June 2008 18:57:59 Alexandre Biancalana wrote: > On 6/27/08, Max Laier wrote: > > You don't need a patch at all. What you do is: Queue on the > > physical interface, classify on the vlan interface. It is broken to > > allow ALTQ on a virtual interface if you can do it otherwise. > > > > in pf.conf speak: > > > > If you have "ifconfig vlanX vlandev bge0 ..." > > > > altq on bge0 .... queue { vlan0, vlan1, ... } > > queue vlan0 ... { vlan0_foo, vlan0_bar, ... } > > queue vlan0_foo > > queue vlan0_bar > > ... > > > > pass on vlanX ... queue vlanX_foobar > > > > And there you go. No patch - whatsoever - required here. > > But the patch simplify the cases where you need one queue per vlan. NO! It is just wrong! There is no relation between vlan queues on the same physical interface and thus you can't guarantee anything! Can we please stop with this nonsense and not bring up the patch every other month. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From ml at t-b-o-h.net Fri Jun 27 17:28:08 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Fri Jun 27 17:28:11 2008 Subject: IPV6 problem : nd6_lookup: failed to add route for a neighbor In-Reply-To: <4864D9C9.2020207@ibctech.ca> Message-ID: <200806271727.m5RHRfAn033378@himinbjorg.tucs-beachin-obx-house.com> > > kernel: nd6_lookup: failed to add route for a neighbor(2001:0470:0007:0028::0001), errno=17 > > > > Client IPv6 address: 2001:470:7:28::2/64 > > > > The script they suggest, and I used, is : > > > > ifconfig gif0 create > > ifconfig gif0 tunnel MYIP 216.66.22.2 > > ifconfig gif0 inet6 2001:470:7:28::2 2001:470:7:28::1 prefixlen 128 > > route -n add -inet6 default 2001:470:7:28::1 > > ifconfig gif0 up > > > > The tunnel came up, was passing traffic, but those messages were > > getting out of hand. I tried a prefixlen of 64, and I got: > > ...hmmmm. I'm not certain here, but since /128 represents only a single > address, I can understand why FreeBSD is getting confused. A /128 is an > IP within its own solitary subnet, so I'd have to guess that you need a > route to the remote end of the tunnel before you can set it as a default > gateway. > Even though its a directly connected endpoint? I was going to ask if trying : route -n add -inet6 default gif0 might make it happier, but it seems route on FBSD 5.5 doesn't accept that format of command. :-/ I also saw suggestions to change the prefixlen to 127, but I get the sem ioctl issue. I don't want to say "But it works elsewhere", but... doing : ipv6_enable="YES" gif_interfaces="gif0" ipv6_defaultrouter="2001:470:1F00:FFFF::5E4" gifconfig_gif0="MYIP 64.71.128.82" ipv6_ifconfig_gif0="2001:470:1F00:FFFF::5E5 2001:470:1F00:FFFF::5E4 prefixlen 128" on a 4.10-STABLE system works fine... But I realize theres been alot of code work since that beast. > > I've been needing to set up a few more tunnels, so I'll try one with > FreeBSD this morning with the same setup you have to try to replicate > the problem (on 7.0). > Ok, thanks. I'm a bit confused also by something I found on the net... http://lists.freebsd.org/pipermail/freebsd-net/2006-May/010718.html Seemed to be a set of patches around this very issue. I've looked at a 7.0-STABLE system and I don't see those changes. But it could very well be that it was updated differently before finally getting into the codebase. I'm not sure how one goes about verifying it. CVSWEB? > > > ifconfig: ioctl (SIOCAIFADDR): Invalid argument > > What was the command that you had entered when you received the above > error? When you tried to change prefix length, did you destroy the > existing tunnel first? > Sorry. I tried : ifconfig gif0 inet6 2001:470:7:28::2 2001:470:7:28::1 prefixlen 64 I had destroyed the tunnel and started from scratch... > > > Sendmail seemed a bit cranky : > > > > Jun 26 23:53:19 MYHOST sendmail[17543]: gethostbyaddr(IPv6:2001:470:7:28::2) failed: 1 > > I believe this is a reverse DNS issue. From how I perceive that message, > Sendmail is trying to retrieve a hostname based on that IP. > Yea, not sure why I mentioned that. But in any case, not sure what to do to remedy the situation. Thanks, Tuc From paul at gtcomm.net Fri Jun 27 18:25:23 2008 From: paul at gtcomm.net (Paul) Date: Fri Jun 27 18:25:26 2008 Subject: FreeBSD 7.0: sockets stuck in CLOSED state... In-Reply-To: References: <486283B0.3060805@transip.nl> <5A9ZR/wNTIFIXEvIi7qXj2foxBI@/2P5JkFFETcbMzHSQ1hIkFGHokc> <48648D70.50304@transip.nl> <4864E0FE.40708@gtcomm.net> Message-ID: <48653108.4080806@gtcomm.net> Hi Eygene.. It happens with telnet :) A lot of my closed entries are from telnet so I can't really put a finger on any specific application :/ Eygene Ryabinkin wrote: > Paul, good day. > > Fri, Jun 27, 2008 at 08:45:50AM -0400, Paul wrote: > >> I have the same 'problem' if that helps any.. Sockets stuck for over a >> month in CLOSED and they have a * for the port on the source IP. >> tcp4 0 0 67.1.1.1.* 67.1.1.2.1261 CLOSED >> 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #6: Thu Apr 17 18:11:49 EDT 2008 >> amd64 >> Doesn't seem to cause any issues though. >> > > And what is listening to that port? Can you identify the application? > Just for the record -- may be it will narrow down the search list. > > Robert Watson told us today at the morning that he spotted the bug > that lead to the '*' instead of port number. Robert, can you post > the patch -- it seems to be not yet committed, at least cvs-src > list has no signs of it? > > By the way, is the patch touches in_pcbdrop() in /sys/netinet/in_pcb.c, > removing instruction 'inp->inp_lport = 0;'? > From rwatson at FreeBSD.org Fri Jun 27 18:33:31 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Fri Jun 27 18:33:35 2008 Subject: FreeBSD 7.0: sockets stuck in CLOSED state... In-Reply-To: References: <486283B0.3060805@transip.nl> <5A9ZR/wNTIFIXEvIi7qXj2foxBI@/2P5JkFFETcbMzHSQ1hIkFGHokc> <48648D70.50304@transip.nl> <4864E0FE.40708@gtcomm.net> Message-ID: <20080627193034.B32893@fledge.watson.org> On Fri, 27 Jun 2008, Eygene Ryabinkin wrote: > Paul, good day. > > Fri, Jun 27, 2008 at 08:45:50AM -0400, Paul wrote: >> I have the same 'problem' if that helps any.. Sockets stuck for over a >> month in CLOSED and they have a * for the port on the source IP. tcp4 0 0 >> 67.1.1.1.* 67.1.1.2.1261 CLOSED 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #6: >> Thu Apr 17 18:11:49 EDT 2008 amd64 Doesn't seem to cause any issues though. > > And what is listening to that port? Can you identify the application? Just > for the record -- may be it will narrow down the search list. > > Robert Watson told us today at the morning that he spotted the bug that lead > to the '*' instead of port number. Robert, can you post the patch -- it > seems to be not yet committed, at least cvs-src list has no signs of it? > > By the way, is the patch touches in_pcbdrop() in /sys/netinet/in_pcb.c, > removing instruction 'inp->inp_lport = 0;'? Hi Eygene, I've not yet had a chance to put the patch together; it does involve removing that line, but it's somewhat more complicated because inp_lport is used to signal whether or not the inpcb is still in various linked list. My current thinking is that I'd actually like to make it an explicit flag that indicates being on the lists so that we can have the port set non-zero yet no longer be on the lists (which would cause the closed connection to occupy the tuple). Robert N M Watson Computer Laboratory University of Cambridge From paul at gtcomm.net Fri Jun 27 18:34:47 2008 From: paul at gtcomm.net (Paul) Date: Fri Jun 27 18:34:53 2008 Subject: Weirdness - FBSD 7, Routing, Packet generator, em taskq In-Reply-To: References: <48645D9E.7090303@gtcomm.net> Message-ID: <48653340.8060301@gtcomm.net> I'm watching top -S -I -s1 -H This is just more of an observation.. I'm not having a problem with it, just wondering why it's doing it.. It's almost like most of the system processes in 'top' are a 3-5 minute average instead of an instant percentage. If this is intended behavior I simply wanted to know :) Curiousity Mainly. Also, isn't the emX taskq supposed to be using no cpu when polling is enabled? I'm trying to get em interface to take in 500kpps or more but it just won't do it. The max I can get is close to 400k and then it starts loading up on errors (out of receive buffers, rx overruns) mainly because the cpu is near 100% on em0 taskq. :( We need a SMP em driver for 7.0 :) No profiling yet... just messing around.. Intel Dual port pci-express nic , opteron 2212 , 7.0-stable now AMD64 seeing how much it will take before it errors out so I can figure out something to do with it.. :P Thanks :) Paul gnn@freebsd.org wrote: > At Thu, 26 Jun 2008 23:25:18 -0400, > Paul wrote: > >> I have a FreeBSD router set up with Full BGP routes and I'm doing some >> tests on using it for routing. >> >> 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #6: Thu Apr 17 18:11:49 EDT 2008 >> amd64 >> >> oddness..: >> >> Use a packet generator to generate random source ips and ports and send >> traffic through the router to a destination on the other side, single ip. >> What happens is the 'em0 taskq' starts to eat cpu... but the funny >> thing is immediately when I start the traffic (say, 100,000 pps) em0 >> taskq is about 15% cpu.. and then over the course of 2 minutes or so it >> climbs to 60% cpu.. This makes no sense.. The packets per second are >> continuous and it just routed 100kpps for 60 seconds with less cpu so >> why in the world would it slowly climb like that? >> >> It's an observation I suppose and I was hoping if someone could >> enlighten me on WHY.. :) I did test it on 3 different machines by the way. >> It even does this with just a handful of routes in the routing table , I >> tried that too just to rule that out. >> I don't remember Freebsd 4/5 doing this?? >> >> > > What are you using to measure the CPU time? Some tools take time to > gather up enough samples. Also, have you tried to do any profiling on > the kernel to see why this might be the case? > > http://www.watson.org/~robert/freebsd/netperf/profile/ > > Best, > George > > From biancalana at gmail.com Fri Jun 27 19:49:15 2008 From: biancalana at gmail.com (Alexandre Biancalana) Date: Fri Jun 27 19:49:18 2008 Subject: altq on vlan In-Reply-To: <200806271914.30216.max@love2party.net> References: <4863FA62.2030703@zirakzigil.org> <200806271036.12195.max@love2party.net> <8e10486b0806270957y439087a5ia0d4689ad2f24ce8@mail.gmail.com> <200806271914.30216.max@love2party.net> Message-ID: <8e10486b0806271249i3f395532k80c1d26ba0661d2c@mail.gmail.com> > > NO! It is just wrong! There is no relation between vlan queues on the > same physical interface and thus you can't guarantee anything! Can we > please stop with this nonsense and not bring up the patch every other > month. Understood !! From rwatson at FreeBSD.org Fri Jun 27 19:57:54 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Fri Jun 27 19:57:58 2008 Subject: FreeBSD 7.0: sockets stuck in CLOSED state... In-Reply-To: <4864E0FE.40708@gtcomm.net> References: <486283B0.3060805@transip.nl> <5A9ZR/wNTIFIXEvIi7qXj2foxBI@/2P5JkFFETcbMzHSQ1hIkFGHokc> <48648D70.50304@transip.nl> <4864E0FE.40708@gtcomm.net> Message-ID: <20080627205708.S40819@fledge.watson.org> On Fri, 27 Jun 2008, Paul wrote: > I have the same 'problem' if that helps any.. Sockets stuck for over a month > in CLOSED and they have a * for the port on the source IP. tcp4 0 0 > 67.1.1.1.* 67.1.1.2.1261 CLOSED 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #6: > Thu Apr 17 18:11:49 EDT 2008 amd64 Doesn't seem to cause any issues though. If you use "sockstat" to list the sockets open in processes, do any match the entry in netstat? If so, which? If you shut down that program, does the entry disappear from netstat? Robert N M Watson Computer Laboratory University of Cambridge > > > > Eygene Ryabinkin wrote: >> Ali, good day. >> >> Fri, Jun 27, 2008 at 08:49:20AM +0200, Ali Niknam wrote: >> >>>> Just a quick "me too" message: I also used to see this on my 7.x >>>> machines. This was with Apache servers in the proxy setup: one >>>> >>> I'm wondering: where these 32 bit, or 64 bit machines? >>> >> >> amd64. >> >> >>>> I had already tried to debug this situation and Mike Silbersack >>>> helped me with patching the kernel. At that days his patches (that >>>> went into 7.x) helped, but with higher request rate to the Apache, >>>> they seem to be back again. I can try to setup the testbed and >>>> verify if I will still be able to reproduce them. Will it be needed? >>>> >>>> >>> Well, if your machine was indeed 64 bit, I for one would be very >>> interested in knowing if it also appears in 32 bit. >>> >> >> Have no i386 machines to test on, sorry. Moreover, I can not yet >> reproduce the problem on my amd64, but I am continuing experiments. >> > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From fjwcash at gmail.com Fri Jun 27 20:27:14 2008 From: fjwcash at gmail.com (Freddie Cash) Date: Fri Jun 27 20:27:19 2008 Subject: Understanding where dummynet fits into an ipfw ruleset Message-ID: I'm trying to figure out how traffic shaping using dummynet fits into an ipfw ruleset. Mainly, I'm wondering where to put the "ipfw queue" rules (the ones that send the packets to dummynet), in relation to the packet filtering rules, or if it even matters. For instance, do the queue rules apply to all the rules in the set, or only to rules that follow after the queue rules (numerically)? Say I've got a firewall setup that does 1:1 NAT for a bunch of servers (allow incoming/outgoing traffic), as well as 1:many NAT for the workstations (allow outgoing) on the LAN. I want to add traffic shaping rules that give traffic from the workstations to specific IPs greater weight than general traffic from the workstations to the Internet (ie reserve 25% of the bandwidth for important services). Would I put the queue rules at the start of the ruleset or the end? Or in the middle, just above the rules for the workstations? Do I add them after all the bad packet checks and general deny rules that are at the top of the ruleset? Just wondering how the queue rules interact with the general packet filter rules, since they can have the same parameters. Thanks. -- Freddie Cash fjwcash@gmail.com From auryn at zirakzigil.org Fri Jun 27 21:00:03 2008 From: auryn at zirakzigil.org (Giulio Ferro) Date: Fri Jun 27 21:00:07 2008 Subject: SOLVED (was Re: Problem clarification (was: Problems with vlan + carp + alias)) In-Reply-To: <20080627072301.GZ50631@server.vk2pj.dyndns.org> References: <486000B5.9090703@zirakzigil.org> <4862B2AF.70202@zirakzigil.org> <48630AA3.3000800@ibctech.ca> <4863F6B3.4020308@zirakzigil.org> <20080627072301.GZ50631@server.vk2pj.dyndns.org> Message-ID: <486554CC.8050609@zirakzigil.org> Peter Jeremy wrote: > On 2008-Jun-26 22:06:11 +0200, Giulio Ferro wrote: > >> I guess what I could do was to "poison" their arp cache for each >> address with a "is-at" message. Is there a way to force the sending >> of these messages for all the addresses of an interface? >> > > The kernel should send out gratuitous ARP requests whenever you assign > an address to an interface. You could confirm that this is happening > by tcpdumping the interface whilst you add aliases. > > Rummaging around in ports, you might find net/arping or net/p5-Net-ARP > useful if you want to manually generate gratuitous ARP requests. > > I have bad news for you all: this doesn't seem to happen for alias interfaces. I've just tried to replicate what happened days ago. I've verified that only the base (non alias) interface sends proper is-at messages. The aliases don't.... I could't either ping from one of those addresses or ping to one of them until I isssued: arping -S aliased-address router-address The router didn't know the mac addresses had changed until then... Can anyone confirm this? From julian at elischer.org Fri Jun 27 21:41:50 2008 From: julian at elischer.org (Julian Elischer) Date: Fri Jun 27 21:41:54 2008 Subject: FreeBSD NAT-T patch integration In-Reply-To: References: <48ca67dd60c19f94b4f21bbe88854da7@localhost> <86c7b60b19e63e9188701611ac0f6f17@localhost> <4863F479.8010206@elischer.org> Message-ID: <48655EAD.6040905@elischer.org> George V. Neville-Neil wrote: > At Thu, 26 Jun 2008 12:56:41 -0700, > julian wrote: >> I'm planning on committing it unless someone can provide a reason not >> to, as I've seen it working, needed it, and have not seen any bad >> byproducts. >> > > I'd be interested to know how you tested it. NAT-T and IPsec are > non-trivial protocols/subsystems that can have far reaching impacts on > the network stack. Also, are you planning to maintain it after > committing it? The biggest problem with NAT-T hasn't been the code, > it's been that the author, who is doing a great job on the code, has > been too busy to maintain it anywhere but at work. That is not a slam > on the person or the code, I have the highest respect for both, but it > reflects and important reality of the situation. Unless you're > stepping up to maintain it as well as commit it I think it should not > be committed. I know the Bjoern has been working hard to pick up the > IPsec stuff in his free time, and I value his input on this subject > quite a bit. > > Best, > George NAT-T is needed for ipsec to work correctly with a bunch of vpn servers such as the cisco VPN server. It's been seen by dozens of people to do exactly that. It's added to every single pfsense and m0n0wall router out there. Code inspection also shows that it shouldn't compromise non-NAT_T sessions. so, It allows one to do things that many people need. It doesn't screw up existing applications (that I've ever heard of). The author is responsive and shows dedication. From cswiger at mac.com Fri Jun 27 21:50:38 2008 From: cswiger at mac.com (Chuck Swiger) Date: Fri Jun 27 21:50:42 2008 Subject: Understanding where dummynet fits into an ipfw ruleset In-Reply-To: References: Message-ID: <58383628-3A79-4271-B62D-C35CC06618F0@mac.com> On Jun 27, 2008, at 1:01 PM, Freddie Cash wrote: > Mainly, I'm wondering where to put the "ipfw queue" rules (the ones > that send the packets to dummynet), in relation to the packet > filtering rules, or if it even matters. > > For instance, do the queue rules apply to all the rules in the set, or > only to rules that follow after the queue rules (numerically)? That pretty depends on whether net.inet.ip.fw.one_pass sysctl is set: pipe pipe_nr Pass packet to a dummynet(4) ``pipe'' (for bandwidth limitation, delay, etc.). See the TRAFFIC SHAPER (DUMMYNET) CONFIGURATION Section for further information. The search terminates; however, on exit from the pipe and if the sysctl(8) variable net.inet.ip.fw.one_pass is not set, the packet is passed again to the firewall code starting from the next rule. > Would I put the queue rules at the start of the ruleset or the end? > Or in the middle, just above the rules for the workstations? Do I add > them after all the bad packet checks and general deny rules that are > at the top of the ruleset? > > Just wondering how the queue rules interact with the general packet > filter rules, since they can have the same parameters. It's reasonable to place the dummynet queue and pipe statements immediately after anti-spoofing checks, if net.inet.ip.fw.one_pass is false; that way, all traffic is shaped, including stuff that is later blocked by other IPFW statements. Since the inbound traffic has already passed through your external link(s) anyway, you might as well acknowledge that it has. If net.inet.ip.fw.one_pass is true, then you definitely want to apply your deny rules first, as once something matches a pipe rule, it's going to be passed. The tradeoff is that the accounting/fairness of traffic is less accurate but the firewall ruleset runs faster... -- -Chuck From fjwcash at gmail.com Fri Jun 27 22:01:29 2008 From: fjwcash at gmail.com (Freddie Cash) Date: Fri Jun 27 22:01:32 2008 Subject: Understanding where dummynet fits into an ipfw ruleset In-Reply-To: <58383628-3A79-4271-B62D-C35CC06618F0@mac.com> References: <58383628-3A79-4271-B62D-C35CC06618F0@mac.com> Message-ID: On Fri, Jun 27, 2008 at 2:37 PM, Chuck Swiger wrote: > On Jun 27, 2008, at 1:01 PM, Freddie Cash wrote: >> Mainly, I'm wondering where to put the "ipfw queue" rules (the ones >> that send the packets to dummynet), in relation to the packet >> filtering rules, or if it even matters. >> >> For instance, do the queue rules apply to all the rules in the set, or >> only to rules that follow after the queue rules (numerically)? > > That pretty depends on whether net.inet.ip.fw.one_pass sysctl is set: [snip man page snippet] >> Would I put the queue rules at the start of the ruleset or the end? >> Or in the middle, just above the rules for the workstations? Do I add >> them after all the bad packet checks and general deny rules that are >> at the top of the ruleset? >> >> Just wondering how the queue rules interact with the general packet >> filter rules, since they can have the same parameters. > > It's reasonable to place the dummynet queue and pipe statements immediately > after anti-spoofing checks, if net.inet.ip.fw.one_pass is false; that way, > all traffic is shaped, including stuff that is later blocked by other IPFW > statements. Since the inbound traffic has already passed through your > external link(s) anyway, you might as well acknowledge that it has. Makes sense. That's the bit that was messing me up (one_pass). I'm still working my head around how it (one_pass) integrates with all the rest (divert/natd, fwd, dummynet) in a single ruleset. Looking at sysctl output on a handful of systems, some of our firewalls has one_pass enabled, others don't. That's probably what's been tripping me up, as sometimes a ruleset worked, other times it didn't, depending on the FreeBSD release (4.x, 6.x, 7.x) the firewall started with. It's only recently that I've started standardising settings across firewalls with standard hardware configs, generic rc.conf/sysctl.conf, specific rc.conf.local, and so on. Which is why I'm asking. > If net.inet.ip.fw.one_pass is true, then you definitely want to apply your > deny rules first, as once something matches a pipe rule, it's going to be > passed. The tradeoff is that the accounting/fairness of traffic is less > accurate but the firewall ruleset runs faster... So, in this situation, the "allow" rules would be the queue rules? To add traffic shaping to the following, using one_pass=1: 100 allow ip from 1.1.1.1 to 2.2.2.2 in recv em0 200 allow ip from 1.1.1.1 to 2.2.2.2 out xmit em1 300 deny ip from any to 2.2.2.2 in recv em0 Would be: 100 queue 1 ip from 1.1.1.1 to 2.2.2.2 in recv em0 200 allow ip from 1.1.1.1 to 2.2.2.2 out xmit em1 300 deny ip from any to 2.2.2.2 in recv em0 Or am I way off here? :) -- Freddie Cash fjwcash@gmail.com From peterjeremy at optushome.com.au Fri Jun 27 22:27:53 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Fri Jun 27 22:27:58 2008 Subject: SOLVED (was Re: Problem clarification (was: Problems with vlan + carp + alias)) In-Reply-To: <486554CC.8050609@zirakzigil.org> References: <486000B5.9090703@zirakzigil.org> <4862B2AF.70202@zirakzigil.org> <48630AA3.3000800@ibctech.ca> <4863F6B3.4020308@zirakzigil.org> <20080627072301.GZ50631@server.vk2pj.dyndns.org> <486554CC.8050609@zirakzigil.org> Message-ID: <20080627222738.GD50631@server.vk2pj.dyndns.org> On 2008-Jun-27 22:59:56 +0200, Giulio Ferro wrote: >Peter Jeremy wrote: >> The kernel should send out gratuitous ARP requests whenever you assign >> an address to an interface. You could confirm that this is happening >> by tcpdumping the interface whilst you add aliases. >> >I have bad news for you all: this doesn't seem to happen for alias >interfaces. I've just tried to replicate what happened days >ago. I've verified that only the base (non alias) interface sends >proper is-at messages. The aliases don't.... I'm not seeing this on physical interfaces. I can't immediately verify this on VLAN interfaces but could at work next week. Adding 192.168.123.253 as an alias on FreeBSD 7.0-STABLE (mid May): 08:21:39.899113 00:0f:b0:74:9c:a3 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 192.168.123.253 tell 192.168.123.253 Adding 192.168.123.253 as an alias on FreeBSD 6.3-PRERELEASE: 08:24:21.077266 00:12:0e:20:2b:ad > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 192.168.123.253 tell 192.168.123.253 -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080627/d0717f7d/attachment.pgp From mgrooms at shrew.net Fri Jun 27 22:32:45 2008 From: mgrooms at shrew.net (mgrooms) Date: Fri Jun 27 22:32:50 2008 Subject: FreeBSD NAT-T patch integration In-Reply-To: References: Message-ID: <5cf41abb4dd14f4e24213575c348c114@localhost> On Fri, 27 Jun 2008 11:06:19 -0400, "George V. Neville-Neil" wrote: > At Thu, 26 Jun 2008 12:56:41 -0700, > julian wrote: >> >> I'm planning on committing it unless someone can provide a reason not >> to, as I've seen it working, needed it, and have not seen any bad >> byproducts. >> > > I'd be interested to know how you tested it. NAT-T and IPsec are > non-trivial protocols/subsystems that can have far reaching impacts on > the network stack. Also, are you planning to maintain it after > committing it? The biggest problem with NAT-T hasn't been the code, > it's been that the author, who is doing a great job on the code, has > been too busy to maintain it anywhere but at work. That is not a slam > on the person or the code, I have the highest respect for both, but it > reflects and important reality of the situation. Unless you're > stepping up to maintain it as well as commit it I think it should not > be committed. I know the Bjoern has been working hard to pick up the > IPsec stuff in his free time, and I value his input on this subject > quite a bit. > I have tested the patch with Cisco (PIX/ASA), Juniper (GT/SSG), Fortigate, Zywall, Linux and NetBSD to ensure interoperability. Mostly, the RFC and draft 2 versions of the protocol were exercised. What other kinds of tests would you like to see? Objections ... 1) NAT-T and IPsec are non-trivial protocols/subsystems The patch hasn't been reviewed enough? The patch hasn't been tested enough? An unresolved issue has been identified? 2) It can have far reaching impacts on the network stack The changes are not been sufficiently protected by the supplied kernel configuration option? 3) The author has been too busy to maintain it anywhere but at work What does this mean? Since you find his level of commitment unacceptable, what would be required for the patch to be accepted? Thanks, -Matthew From cswiger at mac.com Fri Jun 27 23:20:17 2008 From: cswiger at mac.com (Chuck Swiger) Date: Fri Jun 27 23:20:57 2008 Subject: Understanding where dummynet fits into an ipfw ruleset In-Reply-To: References: <58383628-3A79-4271-B62D-C35CC06618F0@mac.com> Message-ID: On Jun 27, 2008, at 3:01 PM, Freddie Cash wrote: [ ... ] >> If net.inet.ip.fw.one_pass is true, then you definitely want to >> apply your >> deny rules first, as once something matches a pipe rule, it's going >> to be >> passed. The tradeoff is that the accounting/fairness of traffic is >> less >> accurate but the firewall ruleset runs faster... > > So, in this situation, the "allow" rules would be the queue rules? > > To add traffic shaping to the following, using one_pass=1: > 100 allow ip from 1.1.1.1 to 2.2.2.2 in recv em0 > 200 allow ip from 1.1.1.1 to 2.2.2.2 out xmit em1 > 300 deny ip from any to 2.2.2.2 in recv em0 > > Would be: > 100 queue 1 ip from 1.1.1.1 to 2.2.2.2 in recv em0 > 200 allow ip from 1.1.1.1 to 2.2.2.2 out xmit em1 > 300 deny ip from any to 2.2.2.2 in recv em0 > > Or am I way off here? :) Hmm. If you have one_pass set, I believe that rule 200 would become superfluous. If it was off, rule 200 would be needed to permit traffic through. However, queue rulesets are used to classify traffic into different bins; then then get pulled out of the bins with packets waiting is proportion to the weights configured via something like: ipfw queue 1 config pipe 1 weight 10 ie, you have to attach queue(s) to a pipe for this classification or sorting to be meaningful. -- -Chuck From andrew at modulus.org Sat Jun 28 01:55:06 2008 From: andrew at modulus.org (Andrew Snow) Date: Sat Jun 28 01:55:10 2008 Subject: Weirdness - FBSD 7, Routing, Packet generator, em taskq In-Reply-To: <48653340.8060301@gtcomm.net> References: <48645D9E.7090303@gtcomm.net> <48653340.8060301@gtcomm.net> Message-ID: <486599BD.7030804@modulus.org> Firstly, tried turning off polling? Some of us have found it to be detrimental to performance on the more modern systems. Its use was more practical on older systems were servicing interrupts took alot of CPU power, but the "em" driver supports delaying interrupts until more packets have arrived - see the sysctls available on the em man page. So you're probably better of turning off polling and playing with these tunables, by calculating how many packets you're likely to be able to fit in the tx/rx descriptor array before you need to generate an interrupt. Secondly try pressing shift+c inside top to display "raw cpu usage" instead of the default "weighted cpu usage". Finally, is your test portraying realistic conditions? I am reminded that 1GB/s with 1500 MTU is only roughly 80,000 pps. - Andrew From mike at sentex.net Sat Jun 28 03:05:15 2008 From: mike at sentex.net (mike@sentex.net) Date: Sat Jun 28 03:05:20 2008 Subject: Route messages In-Reply-To: <4854EBF1.7020708@FreeBSD.org> References: <4852E23E.2040505@gtcomm.net> <4854EBF1.7020708@FreeBSD.org> Message-ID: On Sun, 15 Jun 2008 11:16:17 +0100, in sentex.lists.freebsd.net you wrote: >Paul wrote: >> Get these with GRE tunnel on >> FreeBSD 7.0-STABLE FreeBSD 7.0-STABLE #5: Sun May 11 19:00:57 EDT >> 2008 :/usr/obj/usr/src/sys/ROUTER amd64 >> But do not get them with 7.0-RELEASE >> >> Any ideas what changed? :) Wish there was some sort of changelog.. >> # of messages per second seems consistent with packets per second on >> GRE interface.. >> No impact in routing, but definitely impact in cpu usage for all >> processes monitoring the route messages. > >RTM_MISS is actually fairly common when you don't have a default route. > Hi, I am seeing this issue as well on a pair of recently deployed boxes, one running MPD and one acting as an area router in front of it. The MPD box has a default route and only has 400 routes or so. A steady stream of those messages, upwards of 500 per second. got message of size 96 on Fri Jun 27 22:25:42 2008 RTM_MISS: Lookup failed on this address: len 96, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default got message of size 96 on Fri Jun 27 22:25:42 2008 RTM_MISS: Lookup failed on this address: len 96, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default Is there a way to try and track down what is generating those messages ? Its eating up a fair bit of cpu with quagga (the zebra process specifically) ---Mike From silby at silby.com Sat Jun 28 04:14:57 2008 From: silby at silby.com (Mike Silbersack) Date: Sat Jun 28 04:15:01 2008 Subject: FreeBSD 7.0: sockets stuck in CLOSED state... In-Reply-To: <5A9ZR/wNTIFIXEvIi7qXj2foxBI@/2P5JkFFETcbMzHSQ1hIkFGHokc> References: <486283B0.3060805@transip.nl> <5A9ZR/wNTIFIXEvIi7qXj2foxBI@/2P5JkFFETcbMzHSQ1hIkFGHokc> Message-ID: <20080627224640.J20899@odysseus.silby.com> On Thu, 26 Jun 2008, Eygene Ryabinkin wrote: > I had already tried to debug this situation and Mike Silbersack > helped me with patching the kernel. At that days his patches (that > went into 7.x) helped, but with higher request rate to the Apache, > they seem to be back again. I can try to setup the testbed and > verify if I will still be able to reproduce them. Will it be needed? IIRC, the problem we found then had some interesting root causes, but the important point was the FreeBSD 7-prerelease was returning a different errno than FreeBSD 6 (and before) had been returning, which caused Apache to leak the FD. I wouldn't be at all surprised if there was a switched errno in some other error path that's causing similar problems. -Mike From smithi at nimnet.asn.au Sat Jun 28 06:14:36 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Sat Jun 28 06:14:40 2008 Subject: Understanding where dummynet fits into an ipfw ruleset In-Reply-To: Message-ID: On Fri, 27 Jun 2008, Chuck Swiger wrote: > On Jun 27, 2008, at 3:01 PM, Freddie Cash wrote: > [ ... ] > >> If net.inet.ip.fw.one_pass is true, then you definitely want to > >> apply your > >> deny rules first, as once something matches a pipe rule, it's going > >> to be > >> passed. The tradeoff is that the accounting/fairness of traffic is > >> less > >> accurate but the firewall ruleset runs faster... > > > > So, in this situation, the "allow" rules would be the queue rules? > > > > To add traffic shaping to the following, using one_pass=1: > > 100 allow ip from 1.1.1.1 to 2.2.2.2 in recv em0 > > 200 allow ip from 1.1.1.1 to 2.2.2.2 out xmit em1 > > 300 deny ip from any to 2.2.2.2 in recv em0 > > > > Would be: > > 100 queue 1 ip from 1.1.1.1 to 2.2.2.2 in recv em0 > > 200 allow ip from 1.1.1.1 to 2.2.2.2 out xmit em1 > > 300 deny ip from any to 2.2.2.2 in recv em0 > > > > Or am I way off here? :) > > Hmm. If you have one_pass set, I believe that rule 200 would become > superfluous. If it was off, rule 200 would be needed to permit > traffic through. I'm keen to be certain about this myself. I think that one_pass only affects the packet on the current pass, in this case on the incoming pass from ip_input at rule 100 above. So if one_pass is set, the packet is queued (and accepted in) and the search terminates, but with one_pass off, the packet is reinjected at rule 200 when it leaves the pipe after its limitation and/or delay, and would need to be specifically allowed. However I don't think that affects the outgoing pass, ie after routing the packet still has to go through the firewall again (from ip_output), so in this case it will be allowed if it's going out to 2.2.2.2 via em1, else is denied at rule 300. Another option might be to only apply pipe/queue actions to 'out' rules, but mixing that with both 1:many and 1:1 NAT will complicate matters .. > However, queue rulesets are used to classify traffic > into different bins; then then get pulled out of the bins with packets > waiting is proportion to the weights configured via something like: > > ipfw queue 1 config pipe 1 weight 10 > > ie, you have to attach queue(s) to a pipe for this classification or > sorting to be meaningful. Yes I suspect Freddie might want to use pipe rather than queue here too, if just for bandwidth limitation rather than weighted queueing by type of traffic? And is it only wanted for managing the inbound traffic? It's quite confusing at first that pipe and queue are both ipfw 'actions', and are also terms used as pipe and queue configuration parameters, as in a queue definition specifies a particular 'pipe pipe_nr' and that 'queue' is used to specify a pipe's queue size .. Caveat: I'm only using pipes so far, and on a bridge, not a router, where you only get one shot at allow/deny/pipe on packets incoming through bdg_forward, ie no 'out' rules, for bridged packets anyway. cheers, Ian From rehsack at web.de Sat Jun 28 11:35:24 2008 From: rehsack at web.de (Jens Rehsack) Date: Sat Jun 28 11:35:27 2008 Subject: unbreaking igmpproxy Message-ID: <48661D57.3040505@web.de> Hi all, last week I tried to configure my fbsd-router to enhance it to forward multicast traffic as read on http://un.geeig.net/openbsd-vdsl.html. Sure - it's OpenBSD, but I thought with a little work, I will make it run. But I wont :-( I tried even mrouted(8) but it wont work, because the PPPoE interface to the provider has a netmask of 255.255.255.255 (is it called "host route"?). By the way, I decided to go deeper into igmpproxy: I created a port (using the patches from Markus Friedl from the obsd port), compile, install on router and it delivers: (1) Note: joinMcGroup: 224.0.0.2 on fxp0 (2) Debu: building IGMP packet with datalen=0 (3) Info: sendto to 224.0.0.1 on 10.62.10.12; Errno(22): Invalid argument (4) Debu: SENT Membership query from 10.62.10.12 to 224.0.0.1 Line 2 is added by me, because I want to be sure, that there is no crap in the packet. The code which sends the packet looks like the code in mrouted, where igmpproxy is derived from: sendto(MRouterFD, send_buf, (size_t)sendsize, 0, (struct sockaddr *)&sdst, sizeof(sdst)); send(2) tells, the EINVAL wont be delivered by send or sendto etc. - but there is it. I've searched a bit and seen in sys/kern/uipc_socket.c a routine 'sosend_generic' which seems to handle those sendto calls. This function can return EINVAL when the iovec belonging to the write has negative bytes to handle (sendsize is length of IP header + length of IGMP header) or the mbuf has negative length (I didn't check if the mbuf is source or dest - I mean to remember from VxWorks, that it could be both). But both arguments, mbuf and uio, I cannot influence ... The second 'question' may be the same, maybe not ... The recvfrom() call seems to get scambled network data - but not all of them, just a few ... This is what tcpdump sees: 1. 988526 AF IPv4 (2), length 40: (tos 0xc0, ttl 1, id 40489, offset 0, flags [none], proto IGMP (2), length 36, options (RA)) 217.0.119.167 > 224.0.0.1: igmp query v3 0x0000: 0200 0000 46c0 0024 9e29 0000 0102 5541 ....F..$.)....UA 0x0010: d900 77a7 e000 0001 9404 0000 1164 ec8c ..w..........d.. 0x0020: 0000 0000 020f 0000 ........ And this igmpproxy receives through recvfrom(2): Debu: received 36 bytes on fd 4 Debu: received packet: 46 c0 0c 00 27 6e 00 00 01 02 cb fc d9 00 77 a7 e0 00 00 01 Warn: received packet from 217.0.119.167 shorter (36 bytes) than hdr+data length (24+3048) As you can see, the bytes 3-12 (count begins at 1) contains special refuse. But why only 3-12? Why are the first 2 bytes not scrambled at all? Ok, the IP version and length might be filled separately, but the ToS field is ok. The source and target addresses are ok - but the rest of the IP header? What is going on there? I really have no idea where to search next. The socket open looks ok (compared to the explanation in Stevens 'Network Programming' and 'TCP/IP illustrated' and looks very similar to the code in mrouted). This is all tested with FreeBSD-7.0 stable. I compiled the igmpproxy using standard flags (-O2 -fno-strict-aliasing) and using '-O -g3' - same behaviour. Of course I tried to find related resources using google and the freebsd search - but there was nothing what really affects this problem. Best regards, Jens From . at babolo.ru Sat Jun 28 11:41:18 2008 From: . at babolo.ru (.@babolo.ru) Date: Sat Jun 28 11:41:22 2008 Subject: altq on vlan In-Reply-To: <200806271914.30216.max@love2party.net> Message-ID: <1214651667.267043.71931.nullmailer@cicuta.babolo.ru> [ Charset ISO-8859-1 unsupported, converting... ] > On Friday 27 June 2008 18:57:59 Alexandre Biancalana wrote: > > On 6/27/08, Max Laier wrote: > > > You don't need a patch at all. What you do is: Queue on the > > > physical interface, classify on the vlan interface. It is broken to > > > allow ALTQ on a virtual interface if you can do it otherwise. > > > > > > in pf.conf speak: > > > > > > If you have "ifconfig vlanX vlandev bge0 ..." > > > > > > altq on bge0 .... queue { vlan0, vlan1, ... } > > > queue vlan0 ... { vlan0_foo, vlan0_bar, ... } > > > queue vlan0_foo > > > queue vlan0_bar > > > ... > > > > > > pass on vlanX ... queue vlanX_foobar > > > > > > And there you go. No patch - whatsoever - required here. > > > > But the patch simplify the cases where you need one queue per vlan. > > NO! It is just wrong! There is no relation between vlan queues on the > same physical interface and thus you can't guarantee anything! Can we > please stop with this nonsense and not bring up the patch every other > month. Remember vlan anoter end. Vlan queues on the same physical interface has sense. Let see typical vlan use: +--------+ 100M untagged vlan1 | |--------------.. +---------+ | | 100M untagged vlan2 1G | | 1G tagged | |---------------- --------+ FreeBSD +------------+ switch | 100M untagged vlan3 | | | |--------------.. +---------+ | | 100M untagged vlanN | |--------------- +--------+ There is noting interesting in common queue on 1G physical interface, the only right queues are that on vlans when number of vlans < 10. More of that, sum traffic on 1G tagged intervace is limited by incoming traffic from 1G external interface and so common queue on 1G tagged interface is not interesting even when number of vlans > 10. Sorry for bad English. From sergv326 at gmail.com Sat Jun 28 15:02:00 2008 From: sergv326 at gmail.com (serg vasilyev) Date: Sat Jun 28 15:02:03 2008 Subject: setfib with mpd - ifconfig on p-t-p link trouble Message-ID: Hi ! there's must be a restriction in ifconfig or in kernel that preventing from adding a multiple p-t-p interface with same destination address. i'm trying to build a test system with setfib and multiple mpd instances which are creating PPPoE connection to same destination gateway and run into problem with second p-t-p interface. mpd did not add an IP and gateway for it setfib 1 mpd1 -p /tmp/mpd1.pid -f mpd1.conf sleep 2 setfib 2 mpd2 -p /tmp/mpd2.pid -f mpd2.conf on a first interface ng0 i have both src ip and dst ip but on second i have nothing # ifconfig ng0 ng0: flags=88d1 mtu 1492 inet x.x.x.x --> y.y.y.y netmask 0xffffffff # ifconfig ng1 ng1: flags=88d1 mtu 1492 when i try to add ip's personally # ifconfig ng1 z.z.z.z y.y.y.y ifconfig: ioctl (SIOCAIFADDR) File exist How to remove the given restriction on an ifconfig or kernel or something else P.S. Sorry for my english... From hrs at FreeBSD.org Sat Jun 28 17:10:03 2008 From: hrs at FreeBSD.org (Hiroki Sato) Date: Sat Jun 28 17:10:06 2008 Subject: kern/125003: incorrect EtherIP header format. Message-ID: <200806281710.m5SHA3q7009792@freefall.freebsd.org> The following reply was made to PR kern/125003; it has been noted by GNATS. From: Hiroki Sato To: shino@fornext.org Cc: freebsd-bugs@FreeBSD.org, bug-followup@FreeBSD.org Subject: Re: kern/125003: incorrect EtherIP header format. Date: Sun, 29 Jun 2008 01:35:12 +0900 (JST) ----Security_Multipart(Sun_Jun_29_01_35_12_2008_272)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Shunsuke SHINOMIYA wrote in <200806270610.m5R6A3hR060682@freefall.freebsd.org>: sh> =46rom RFC3378 sh> > In summary, the EtherIP Header has two fields: sh> >=20 sh> > Bits 0-3: Protocol version sh> > Bits 4-15: Reserved for future use sh> >=20 sh> > 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 sh> > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ sh> > | | | sh> > | VERSION | RESERVED | sh> > | | | sh> > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ sh> >=20 sh> > Figure 2: EtherIP Header Format (in bits) sh> >=20 sh> sh> , first octet(bit 0,MSB to 7) consists of VERSION and a part of RESERVED. sh> And VERSION is high 4 bits of the octet. sh> Am I misunderstanding this? The VERSION is in bit 0-3 and LSB in this diagram is left. As Andrew also explained, these are the reasons why ETHERIP_VER_VERS_MASK is defined as 0x0f. Do you really have interoperability problem? If so, please let us know more detail information about it first. -- | Hiroki SATO ----Security_Multipart(Sun_Jun_29_01_35_12_2008_272)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkhmaEAACgkQTyzT2CeTzy12bwCfTQ2kE20quy6BU+vd9wYaNwS+ cxQAnA8yh2VRKHuRcxLZc459791hXOFY =a1zs -----END PGP SIGNATURE----- ----Security_Multipart(Sun_Jun_29_01_35_12_2008_272)---- From linimon at FreeBSD.org Sat Jun 28 17:50:33 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sat Jun 28 17:50:36 2008 Subject: kern/125079: [ppp] host routes added by ppp with gateway flag (regression) Message-ID: <200806281750.m5SHoWs6014271@freefall.freebsd.org> Old Synopsis: host routes added by ppp with gateway flag New Synopsis: [ppp] host routes added by ppp with gateway flag (regression) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Jun 28 17:49:57 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=125079 From bzeeb-lists at lists.zabbadoz.net Sat Jun 28 18:49:30 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Sat Jun 28 18:49:35 2008 Subject: FreeBSD NAT-T patch integration In-Reply-To: <5cf41abb4dd14f4e24213575c348c114@localhost> References: <5cf41abb4dd14f4e24213575c348c114@localhost> Message-ID: <20080628184119.W83875@maildrop.int.zabbadoz.net> Replying to the (randomly) last posting in this thread... Hi, okay, as patience seems to be a problem with some people and I do not want to say this on two fronts (public and internal) here are my comments. Yes, they will not be what you expect but seriously, as I said before in other contexts: IPsec is about security and not features. If you were worried about security you would have reviewed this patch in detail before, maybe side by side with the RFCs and contributed changes back to the author. So basically I know the hands that are seriously thinking about spending time on FreeBSD in-tree-IPsec in the not so distant future and have done in the past. The ten fingers attached to those hands are typing this email. I know others would really like to but cannot find the timeshare. I know others but they haven't yet committed themselves to anything but a hit-and-run stunt. Why in the future and not now? Basically because it's my free time, mostly evenings and weekends that I can spend on FreeBSD. If you want to change that, talk to my employer who'll happily let me work on FreeBSD if you pay for it;-) My current (private) project is called ``jails'' and I'll finish this first. The next project is IPsec again along with other security stuff and vimage reviews that not many people have committed themselves to either but lots of people crying for it. Where is FreeBSD with IPsec? I thought I'd say again what I said a few months back, which was "in a very good position" but to get back to that it'll take me a while. There are about a dozen serious PRs, lots of them came in late after 7 because people did not test their things after the transition, a batch of features, enhancements, patches on new stuff, and probably even more of I cannot think at the moment. I have 5 private (non public) `issues' about IPsec on my private list in addition to all this. IPsec is about security, so bug fixes first, then features. So what about NAT-T, which has been around for not as long as the jail patches I am working on at the moment? A lot of you are talking about "I have done testing". Right, good-good-scenario is what I get from the mails. Some say "this is mandatory to connect to vendor XYZ". Screw the vendor, if you have no NAT and still need it. I have (had) IPsecs to those boxes, since ~2000, and didn't need it if there was no NAT (why would I) - so please stop the propaganda/marketing or give the full facts. People ask about review. The reason it's not in (yet) is that I haven't had enough time to do the close line-by-line review and give all the feedback to Yvan. The reason for that, as I have stated multiple times before, is the lack of contiguous time. It needs to be contiguous - you cannot do this this Sunday and Thursday evening again having fought 10 different fires in the meantime. Why do I think this needs to be done? IPsec is about security and not about features. The current plan is (let me quote from a mail sent to Yvan on June 13: "Your patch will soon need more changes (due to FreeBSD changes) and chances are good that if you don't do that step for HEAD but force me to do it that you'll get the entire review." So you know my plan on this now. Some say "there are #ifdefs around the code - what's the problem committing but not enabling'. If the project is going to ship it, the project will have to maintain it, deal with the bugs, possibly issue SAs if there is a serious bug, have to make sure to keep ABI compatibilities for STABLE branches, ... that's a lot more hands than only mine if it gets there, so do not ask to screw others as well if you can avoid it. "But it works" - yes it does, as long as everyone behaves. You may find UDP packets eaten without any notice, you may have experienced panics, you may have found it work on one machine and not on the other, you may have tried to use it with FreeBSD base user space *oops* does not work but your setkey, libipsec, .. come from ipsec-tools anyway. You may.... Been there,... These days I am absolutely no longer worried about missing #ifdefs, style or other minor issues. What am I worried about? Go to line one, read again. After all this, let me say that the patch is good, else not that lot of people would use it (though I bet a lot do without knowing how and why;) and I really appreciate all the work done by Yvan and possibly others the patch was based on. But it's not finished yet. If you have read Yvan's mail this gives you an initial list. I'd say there is more missing to the RFCs and a bit more to FreeBSD and the line-by-line review but that's nothing most of you would probably `need' when saying "it works for me", "it works in our bundled software". That's why you have the patches. So what's the moral of the story? I have lately tried to explain to someone some aspects of what "to care" means. So if you know what "to care" means - the moral might be "If it's committed now - who cares?" Maybe it's - if I have to read another two dozen mails in this thread and another half a dozen internally it'll simply waste another of my Saturday afternoons. Bjoern -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From hrs at FreeBSD.org Sat Jun 28 18:58:50 2008 From: hrs at FreeBSD.org (hrs@FreeBSD.org) Date: Sat Jun 28 18:58:52 2008 Subject: kern/125003: [gif] incorrect EtherIP header format. Message-ID: <200806281858.m5SIwnMK019445@freefall.freebsd.org> Synopsis: [gif] incorrect EtherIP header format. State-Changed-From-To: open->feedback State-Changed-By: hrs State-Changed-When: Sat Jun 28 18:57:46 UTC 2008 State-Changed-Why: We need a detail about this issue from the PR originator. http://www.freebsd.org/cgi/query-pr.cgi?pr=125003 From crapsh at monkeybrains.net Sat Jun 28 20:30:44 2008 From: crapsh at monkeybrains.net (Rudy) Date: Sat Jun 28 20:30:49 2008 Subject: Seeking help understanding my "emX: watchdog timeout" messages In-Reply-To: <485ECF20.6000607@monkeybrains.net> References: <20080516185813.H866@logos.sky.od.ua> <2a41acea0805160904g7dcf9f58rf69ca5d0612945cc@mail.gmail.com> <4853055C.2030303@MonkeyBrains.NET> <48535A11.4020003@monkeybrains.net> <48582C29.8030307@monkeybrains.net> <2a41acea0806191055w5e112b8bsa57a8db2b177adbe@mail.gmail.com> <485C0F07.7000408@monkeybrains.net> <2a41acea0806201355y3b123462wc37280f28a9f4216@mail.gmail.com> <485C41C5.4090706@monkeybrains.net> <2a41acea0806201713m7a083b9dr10894c8a0845df8e@mail.gmail.com> <485D5B9E.8020908@monkeybrains.net> <485ECF20.6000607@monkeybrains.net> Message-ID: <48669F6F.1050005@monkeybrains.net> Continuing the emX thread... ---------------------------------------- #man 4 em hw.em.txd Number of transmit descriptors allocated by the driver. The default value is 256. The 82542 and 82543-based adapters can handle up to 256 descriptors, while others can have up to 4096. I just upped values in my loader.conf: hw.em.rxd=1024 hw.em.txd=1024 Thanks Dmitriy -- your reply on jboss gave me idea to try tuning that value. ---------------------------------------- I tried upping the rx_processing_limit on my active interfaces and that caused MORE watchdog timeout events. In fact, they started to happen on em0 and em1 (previously not throwing errors). dev.em.0.rx_processing_limit=200 dev.em.1.rx_processing_limit=200 dev.em.2.rx_processing_limit=200 dev.em.4.rx_processing_limit=200 I am going to keep those values in with the new hw.em.rxd settings and back them out if watchdog events persist. ---------------------------------------- Questions to EM users: Do you use POLLING or MSI Interrupts with FreeBSD 7.x and PCIe Ethernet adapters? Do you see watchdog timeout events on your Intel adapters? ---------------------------------------- I emailed Intel and asked for help. They referred me to this document (not very helpful): http://downloadmirror.intel.com/10957/ENG/README.txt I replied and asked if other users are reporting watchdog timeout events. The tech was less than helpful -- here was the response from adaptersuppor@mailbox.cps.intel.com: >> Please be aware that you are the first person who reports those ?watchdog timeouts?. >> >> Please note that this is an intermittent behavior, we have not been able to >> determine exactly when that issue happens, and to which exact adapter under >> which exact circumstances, in the moment that we have a problem we are able >> to recreate many times this will become a ?known issue? and most certainly >> it will be posted in our website under the adapters that has that issue. Dude! Take an ESL class. I also CC'd freebsdnic@mailbox.intel.com. ---------------------------------------- Last week I tried changing this setting: > dev.em.2.tx_int_delay: 33 > dev.em.2.tx_abs_int_delay: 33 They did not help. Rudy From vanhu_bsd at zeninc.net Sat Jun 28 21:13:03 2008 From: vanhu_bsd at zeninc.net (VANHULLEBUS Yvan) Date: Sat Jun 28 21:13:07 2008 Subject: FreeBSD NAT-T patch integration In-Reply-To: References: <48ca67dd60c19f94b4f21bbe88854da7@localhost> <86c7b60b19e63e9188701611ac0f6f17@localhost> <4863F479.8010206@elischer.org> Message-ID: <20080628211300.GA3310@zen.inc> On Fri, Jun 27, 2008 at 11:06:19AM -0400, George V. Neville-Neil wrote: > At Thu, 26 Jun 2008 12:56:41 -0700, > julian wrote: > > > > I'm planning on committing it unless someone can provide a reason not > > to, as I've seen it working, needed it, and have not seen any bad > > byproducts. > > > > I'd be interested to know how you tested it. I can answer that question: - We do have "non regression tests", which test every night that "it works" in a "good scenario", with a peers who runs quite the same kernel, with the same patch and the same userland. We do also some "bad scenarios" tests, but not as much as I would like actually (it's much more complex to test). - We do have THOUSANDS of customers who use it for years now. And customers are really not well nown to always generate "good scenarios".... Customers can do some mistakes, can use some very strange stacks for peers, can use a lots of other IPSec stacks for peers, can have *a lot* of peers (of course with various implementations, configurations, NAT or not, etc...) for the same gate, etc... And how do I know that it works ? Well, when it doesn't work, I do know it, quite quickly most of the time ! As Bjoern said in another mail, we're talking about security. Security is my job, security is what we provide to our customers, and even if some of our customers just don't understant what they do, some others do *really* understand things, and do *really* test devices, check if it works, and quickly reports us problems (and ask for quick solutions). > NAT-T and IPsec are > non-trivial protocols/subsystems that can have far reaching impacts on > the network stack. Yes. > Also, are you planning to maintain it after > committing it? I plan to do that. > The biggest problem with NAT-T hasn't been the code, > it's been that the author, Really ? > who is doing a great job on the code, Thank you.... > has > been too busy to maintain it anywhere but at work. That is not exact, and I'm really sorry if you understood that after our discussion at the last EuroBSDCon. First, you can check that I'm sending this mail on saturday evening, which is out of my work hours :-) Then I can for example confirm that I did the whole migration from RELENG6 to RELENG7 on my free time, just because I needed a working FreeBSD7 + NAT-T patch at home before I've been asked to do it at work. Yes, I'm doing most of IPSec / NAT-T stuff at work, but it is mainly because I'm *paid* for that !!! Let me tell this again: working on FreeBSD's IPSec stack (and on NAT-T, of course, adn also on ipsec-tools) is a part of my job. What I told you some months ago is that there are some things that I cannot really do at work, because it takes lot of time and because those things are more "code cleanups" than "new features" (we were talking about PFKey V2 cleanups related to NAT-T ports). And if I did not spend that time to do that cleanup, that's not because I don't have such time, that's because I was starting to fear that the patch may be never commited, so I wasn't sure to want to continue spending lots of time on a patch "for nothing". If Bjoern or you told me some months ago "do that cleanup and we'll commit the patch", it would already have been done, and we would have *all* saved some time ! And yes, I do also spend some parts of my free time on things that are not related to FreeBSD's IPSec (and, to be completely honest, on things which are not related at all to computers....). > That is not a slam > on the person or the code, I have the highest respect for both, but it > reflects and important reality of the situation. I feel that "the reality of the situation" is that FreeBSD's IPSec stack needs more people *working on it*, not more people wasting their time about why some work should or shouldn't be reported. That is not a slam on the persons who are still working on the IPsec stack, I have the highest respect for them, but it reflects an important reality of the situation... > Unless you're > stepping up to maintain it as well as commit it I think it should not > be committed. I know the Bjoern has been working hard to pick up the > IPsec stuff in his free time, and I value his input on this subject > quite a bit. You said it yourself: actually, FreeBSD's IPSec stack is just maintained by one person, which worked hard on it, which does a great job on it, but which can spend only some parts of his free time on it. That is a problem. Of course, the solution can NOT be to ask Bjoern to spend more time on it (well, Bjoern, do that if you want :-). The only other solution I see is to find a way to help people who want to help you.... Yvan. -- NETASQ http://www.netasq.com From julian at elischer.org Sat Jun 28 22:18:20 2008 From: julian at elischer.org (Julian Elischer) Date: Sat Jun 28 22:18:26 2008 Subject: setfib with mpd - ifconfig on p-t-p link trouble In-Reply-To: References: Message-ID: <4866B8BB.1040908@elischer.org> serg vasilyev wrote: > Hi ! > there's must be a restriction in ifconfig or in kernel that preventing from > adding a multiple p-t-p interface with same destination address. > i'm trying to build a test system with setfib and multiple mpd instances > which are creating PPPoE connection to same destination gateway and run into > problem with second p-t-p interface. > mpd did not add an IP and gateway for it this is a misunderstanding of what setfib does. You can only have one point to poitn interface with the same destination address. Having multiple routing tables does not automatically make it possible to have tow tunnels to the same place, (though theoretically maultipath routing might make this possible) because you still need to specify the remote address to specify the route's action. If you have multiple p2p links with the same remote address, you cannot specify which interface to use for a particular route. > > setfib 1 mpd1 -p /tmp/mpd1.pid -f mpd1.conf > sleep 2 > setfib 2 mpd2 -p /tmp/mpd2.pid -f mpd2.conf > > on a first interface ng0 i have both src ip and dst ip but on second i have > nothing > > # ifconfig ng0 > ng0: flags=88d1 mtu 1492 > inet x.x.x.x --> y.y.y.y netmask 0xffffffff > # ifconfig ng1 > ng1: flags=88d1 mtu 1492 > > when i try to add ip's personally > # ifconfig ng1 z.z.z.z y.y.y.y > ifconfig: ioctl (SIOCAIFADDR) File exist > > How to remove the given restriction on an ifconfig or kernel or something > else > P.S. Sorry for my english... you MAY be able to manually remove the link addresses from both routing tables after adding the first p2p link, and then add the second interface, and then remove the link address from the first fib, and add back the first link route from the first p3p link to teh first FIB. but I have not tested this. currently, adding an interface addres teh link layer route to ALL fibs, leaving it up to the admin to remove them from the fibs he does not want them in. This was a decision I took but the other option would have been to add it to only the 'current' fib, which would have been even more disruptive. ok I tested this with gre tunnels: ifconfig gre0 create ifconfig gre1 create ifconfig gre0 1.1.1.1 2.2.2.2 # remove conflicting routes setfib -0 route delete 2.2.2.2 setfib -1 route delete 2.2.2.2 #now set up the second link ifconfig gre1 3.3.3.3 2.2.2.2 # and remove the rotue we don't want setfib -0 route delete 2.2.2.2 # and replace it with the one we DO want, # (or one that is equivalent) setfib -0 route add 2.2.2.2 -iface gre0 wsa05:rjulian 34] ifconfig [...] gre0: flags=9011 mtu 1476 inet 1.1.1.1 --> 2.2.2.2 netmask 0xff000000 gre1: flags=9011 mtu 1476 inet 3.3.3.3 --> 2.2.2.2 netmask 0xff000000 wsa05:rjulian 35] setfib -0 netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif [...] 2.2.2.2 3.3.3.3 UH 0 0 gre1 [...] wsa05:rjulian 36] setfib -1 netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif [...] 2.2.2.2 gre0 UGHS 0 0 gre0 [...] wsa05:rjulian 37] which would do what you want. now to make mpd know how to do that :-) > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From julian at elischer.org Sat Jun 28 22:39:59 2008 From: julian at elischer.org (Julian Elischer) Date: Sat Jun 28 22:40:04 2008 Subject: setfib with mpd - ifconfig on p-t-p link trouble In-Reply-To: <4866B8BB.1040908@elischer.org> References: <4866B8BB.1040908@elischer.org> Message-ID: <4866BDCF.3020907@elischer.org> Julian Elischer wrote: > serg vasilyev wrote: >> Hi ! >> there's must be a restriction in ifconfig or in kernel that preventing >> from >> adding a multiple p-t-p interface with same destination address. >> i'm trying to build a test system with setfib and multiple mpd instances >> which are creating PPPoE connection to same destination gateway and >> run into >> problem with second p-t-p interface. >> mpd did not add an IP and gateway for it > > > this is a misunderstanding of what setfib does. > You can only have one point to poitn interface with the same > destination address. > Having multiple routing tables does not automatically make it > possible to have tow tunnels to the same place, > (though theoretically maultipath routing might make this possible) > because you still need to specify the remote address to specify > the route's action. If you have multiple p2p links with the same > remote address, you cannot specify which interface to use for a > particular route. > > >> >> setfib 1 mpd1 -p /tmp/mpd1.pid -f mpd1.conf >> sleep 2 >> setfib 2 mpd2 -p /tmp/mpd2.pid -f mpd2.conf >> >> on a first interface ng0 i have both src ip and dst ip but on second i >> have >> nothing >> >> # ifconfig ng0 >> ng0: flags=88d1 mtu 1492 >> inet x.x.x.x --> y.y.y.y netmask 0xffffffff >> # ifconfig ng1 >> ng1: flags=88d1 mtu 1492 >> >> when i try to add ip's personally >> # ifconfig ng1 z.z.z.z y.y.y.y >> ifconfig: ioctl (SIOCAIFADDR) File exist >> >> How to remove the given restriction on an ifconfig or kernel or >> something >> else >> P.S. Sorry for my english... > you MAY be able to manually remove the link addresses from both > routing tables after adding the first p2p link, > and then add the second interface, and then > remove the link address from the first fib, > and add back the first link route from the first p3p link to teh first FIB. > > but I have not tested this. > > currently, adding an interface addres teh link layer route to ALL fibs, > leaving it up to the admin to remove them from the fibs he does > not want them in. This was a decision I took but the other option would > have been to add it to only the 'current' fib, which would have > been even more disruptive. > > ok I tested this with gre tunnels: > > ifconfig gre0 create > ifconfig gre1 create > ifconfig gre0 1.1.1.1 2.2.2.2 > # remove conflicting routes > setfib -0 route delete 2.2.2.2 > setfib -1 route delete 2.2.2.2 > #now set up the second link > ifconfig gre1 3.3.3.3 2.2.2.2 > # and remove the rotue we don't want > setfib -0 route delete 2.2.2.2 > # and replace it with the one we DO want, > # (or one that is equivalent) > setfib -0 route add 2.2.2.2 -iface gre0 > > > wsa05:rjulian 34] ifconfig > [...] > gre0: flags=9011 mtu 1476 > inet 1.1.1.1 --> 2.2.2.2 netmask 0xff000000 > gre1: flags=9011 mtu 1476 > inet 3.3.3.3 --> 2.2.2.2 netmask 0xff000000 > > > wsa05:rjulian 35] setfib -0 netstat -rn > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif > [...] > 2.2.2.2 3.3.3.3 UH 0 0 gre1 > [...] > wsa05:rjulian 36] setfib -1 netstat -rn > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif > [...] > 2.2.2.2 gre0 UGHS 0 0 gre0 > [...] > wsa05:rjulian 37] > > which would do what you want. > now to make mpd know how to do that :-) actually setfib -1 route add 2.2.2.2 -iface gre0 -gateway 1.1.1.1 seems to do even better .. wsa05:rjulian 6] setfib -1 route add 2.2.2.2 -interface gre0 -gateway 1.1.1.1 add host 2.2.2.2: gateway gre0 wsa05:rjulian 7] setfib -1 netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif [...] 2.2.2.2 1.1.1.1 UHS 0 0 gre0 [...] wsa05:rjulian 8] > > >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From oberman at es.net Sun Jun 29 01:08:25 2008 From: oberman at es.net (Kevin Oberman) Date: Sun Jun 29 01:08:30 2008 Subject: FreeBSD NAT-T patch integration In-Reply-To: Your message of "Sat, 28 Jun 2008 23:13:00 +0200." <20080628211300.GA3310@zen.inc> Message-ID: <20080629005756.4BA1B4500E@ptavv.es.net> > Date: Sat, 28 Jun 2008 23:13:00 +0200 > From: VANHULLEBUS Yvan > Sender: owner-freebsd-net@freebsd.org > > On Fri, Jun 27, 2008 at 11:06:19AM -0400, George V. Neville-Neil wrote: > > At Thu, 26 Jun 2008 12:56:41 -0700, > > julian wrote: > > > > > > I'm planning on committing it unless someone can provide a reason not > > > to, as I've seen it working, needed it, and have not seen any bad > > > byproducts. > > > > > > > I'd be interested to know how you tested it. > > I can answer that question: > > - We do have "non regression tests", which test every night that "it > works" in a "good scenario", with a peers who runs quite the same > kernel, with the same patch and the same userland. > > We do also some "bad scenarios" tests, but not as much as I would like > actually (it's much more complex to test). > > > - We do have THOUSANDS of customers who use it for years now. And > customers are really not well nown to always generate "good > scenarios".... > > Customers can do some mistakes, can use some very strange stacks for > peers, can use a lots of other IPSec stacks for peers, can have *a > lot* of peers (of course with various implementations, configurations, > NAT or not, etc...) for the same gate, etc... > > And how do I know that it works ? > Well, when it doesn't work, I do know it, quite quickly most of the > time ! > > As Bjoern said in another mail, we're talking about security. > Security is my job, security is what we provide to our customers, and > even if some of our customers just don't understant what they do, some > others do *really* understand things, and do *really* test devices, > check if it works, and quickly reports us problems (and ask for quick > solutions). > > > > > NAT-T and IPsec are > > non-trivial protocols/subsystems that can have far reaching impacts on > > the network stack. > > Yes. > > > > Also, are you planning to maintain it after > > committing it? > > I plan to do that. > > > > The biggest problem with NAT-T hasn't been the code, > > it's been that the author, > > Really ? > > > > who is doing a great job on the code, > > Thank you.... > > > > has > > been too busy to maintain it anywhere but at work. > > That is not exact, and I'm really sorry if you understood that after > our discussion at the last EuroBSDCon. > > First, you can check that I'm sending this mail on saturday evening, > which is out of my work hours :-) > > Then I can for example confirm that I did the whole migration from > RELENG6 to RELENG7 on my free time, just because I needed a working > FreeBSD7 + NAT-T patch at home before I've been asked to do it at > work. > > Yes, I'm doing most of IPSec / NAT-T stuff at work, but it is mainly > because I'm *paid* for that !!! > Let me tell this again: working on FreeBSD's IPSec stack (and on > NAT-T, of course, adn also on ipsec-tools) is a part of my job. > > What I told you some months ago is that there are some things that I > cannot really do at work, because it takes lot of time and because > those things are more "code cleanups" than "new features" (we were > talking about PFKey V2 cleanups related to NAT-T ports). > > > And if I did not spend that time to do that cleanup, that's not > because I don't have such time, that's because I was starting to > fear that the patch may be never commited, so I wasn't sure to want to > continue spending lots of time on a patch "for nothing". > > If Bjoern or you told me some months ago "do that cleanup and we'll > commit the patch", it would already have been done, and we would have > *all* saved some time ! > > > And yes, I do also spend some parts of my free time on things that are > not related to FreeBSD's IPSec (and, to be completely honest, on > things which are not related at all to computers....). > > > > > That is not a slam > > on the person or the code, I have the highest respect for both, but it > > reflects and important reality of the situation. > > I feel that "the reality of the situation" is that FreeBSD's IPSec > stack needs more people *working on it*, not more people wasting their > time about why some work should or shouldn't be reported. > > That is not a slam on the persons who are still working on the IPsec > stack, I have the highest respect for them, but it reflects an > important reality of the situation... > > > > > Unless you're > > stepping up to maintain it as well as commit it I think it should not > > be committed. I know the Bjoern has been working hard to pick up the > > IPsec stuff in his free time, and I value his input on this subject > > quite a bit. > > You said it yourself: actually, FreeBSD's IPSec stack is just > maintained by one person, which worked hard on it, which does a great > job on it, but which can spend only some parts of his free time on it. > > That is a problem. > Of course, the solution can NOT be to ask Bjoern to spend more time on > it (well, Bjoern, do that if you want :-). > > The only other solution I see is to find a way to help people who want > to help you.... Thanks so much to folks like Bjorn and Yvan who spend the time to do some tough jobs like dealing with IPsec and being stubborn about committing things to security tools without very careful audit. In case you missed it, IPsec is about security, not features. And, in case you have never been involved in real security or crypto, security is really, really hard. No, no, it's much harder than that! While I'd love to see NAT-T, until someone who knows EXACTLY what the IPsec and NAT-T code is doing and what it is required to do can do the line by line review, it should NOT be committed. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080629/bf90f71f/attachment.pgp From crapsh at monkeybrains.net Sun Jun 29 03:24:51 2008 From: crapsh at monkeybrains.net (Rudy) Date: Sun Jun 29 03:24:56 2008 Subject: Seeking help understanding my "emX: watchdog timeout" messages In-Reply-To: <48669F6F.1050005@monkeybrains.net> References: <20080516185813.H866@logos.sky.od.ua> <2a41acea0805160904g7dcf9f58rf69ca5d0612945cc@mail.gmail.com> <4853055C.2030303@MonkeyBrains.NET> <48535A11.4020003@monkeybrains.net> <48582C29.8030307@monkeybrains.net> <2a41acea0806191055w5e112b8bsa57a8db2b177adbe@mail.gmail.com> <485C0F07.7000408@monkeybrains.net> <2a41acea0806201355y3b123462wc37280f28a9f4216@mail.gmail.com> <485C41C5.4090706@monkeybrains.net> <2a41acea0806201713m7a083b9dr10894c8a0845df8e@mail.gmail.com> <485D5B9E.8020908@monkeybrains.net> <485ECF20.6000607@monkeybrains.net> <48669F6F.1050005@monkeybrains.net> Message-ID: <4867007E.90409@monkeybrains.net> Rudy wrote: > I just upped values in my loader.conf: > hw.em.rxd=1024 > hw.em.txd=1024 Still getting watchdog timer events. :p Load is low: # ps axw | grep -v 0:0 PID TT STAT TIME COMMAND 10 ?? RL 325:37.05 [idle: cpu1] 11 ?? RL 344:33.83 [idle: cpu0] 13 ?? WL 1:12.35 [swi4: clock sio] 20 ?? DL 14:30.03 [em0 taskq] 21 ?? DL 6:20.68 [em1 taskq] 22 ?? DL 5:29.90 [em2 taskq] 24 ?? DL 12:57.23 [em4 taskq] 31 ?? DL 0:43.60 [dummynet] 1297 ?? Ss 0:11.18 /usr/local/sbin/zebra --daemon --retain -A 10.77.0.6 1303 ?? Ss 3:19.46 /usr/local/sbin/bgpd --daemon --retain -A 10.77.0.6 Trying a kernel rebuild without dummynet (as I am not using that).... - Rudy From fjwcash at gmail.com Sun Jun 29 05:34:15 2008 From: fjwcash at gmail.com (Freddie Cash) Date: Sun Jun 29 05:34:21 2008 Subject: Understanding where dummynet fits into an ipfw ruleset In-Reply-To: References: Message-ID: On Fri, Jun 27, 2008 at 11:14 PM, Ian Smith wrote: > On Fri, 27 Jun 2008, Chuck Swiger wrote: > > On Jun 27, 2008, at 3:01 PM, Freddie Cash wrote: > > [ ... ] > > >> If net.inet.ip.fw.one_pass is true, then you definitely want to > > >> apply your deny rules first, as once something matches a pipe > > >> rule, it's going to be passed. The tradeoff is that the > > >> accounting/fairness of traffic is less accurate but the firewall > > >> ruleset runs faster... > > > > > > So, in this situation, the "allow" rules would be the queue rules? > > > > > > To add traffic shaping to the following, using one_pass=1: > > > 100 allow ip from 1.1.1.1 to 2.2.2.2 in recv em0 > > > 200 allow ip from 1.1.1.1 to 2.2.2.2 out xmit em1 > > > 300 deny ip from any to 2.2.2.2 in recv em0 > > > > > > Would be: > > > 100 queue 1 ip from 1.1.1.1 to 2.2.2.2 in recv em0 > > > 200 allow ip from 1.1.1.1 to 2.2.2.2 out xmit em1 > > > 300 deny ip from any to 2.2.2.2 in recv em0 > > > > > > Or am I way off here? :) > > > > Hmm. If you have one_pass set, I believe that rule 200 would become > > superfluous. If it was off, rule 200 would be needed to permit > > traffic through. No, the rule is needed. Packets passing through the firewall go through the ruleset twice: once entering the external interface, and again leaving the internal interface (and vice versa). The first rule allows the packet in on the external interface, the second rule allows it out the internal interface, the third rule denies all other incoming traffic. > I'm keen to be certain about this myself. I think that one_pass only > affects the packet on the current pass, in this case on the incoming > pass from ip_input at rule 100 above. So if one_pass is set, the packet > is queued (and accepted in) and the search terminates, but with one_pass > off, the packet is reinjected at rule 200 when it leaves the pipe after > its limitation and/or delay, and would need to be specifically allowed. > > However I don't think that affects the outgoing pass, ie after routing > the packet still has to go through the firewall again (from ip_output), > so in this case it will be allowed if it's going out to 2.2.2.2 via em1, > else is denied at rule 300. > > Another option might be to only apply pipe/queue actions to 'out' rules, > but mixing that with both 1:many and 1:1 NAT will complicate matters .. > > However, queue rulesets are used to classify traffic > > into different bins; then then get pulled out of the bins with packets > > waiting is proportion to the weights configured via something like: > > > > ipfw queue 1 config pipe 1 weight 10 > > > > ie, you have to attach queue(s) to a pipe for this classification or > > sorting to be meaningful. Yes, I know that. I was just trying to use very simplified examples to understand how the traffic shaping works in conjunction with the packet filtering. I understand how the queueing works, and have used it successfully on routers that don't do packet filtering. It's adding it to existing packet filter rulesets that is making my head spin. :) > Yes I suspect Freddie might want to use pipe rather than queue here too, > if just for bandwidth limitation rather than weighted queueing by type > of traffic? And is it only wanted for managing the inbound traffic? No, I want to use queue. I want to create rules to "reserve" bandwidth for connections to important servers, as we're moving to more web-based applications, and I want to make sure students surfing the web don't impact office staff. There will be a single pipe, with two queues, one weighted at twice the value of the other. That way, if there is no staff traffic, the students get the whole pipe. If there is no student traffic, staff get the whole pipe. And if there's a mix, then staff traffic is prioritised ahead of student traffic. -- Freddie Cash fjwcash@gmail.com From fjwcash at gmail.com Sun Jun 29 05:36:12 2008 From: fjwcash at gmail.com (Freddie Cash) Date: Sun Jun 29 05:36:15 2008 Subject: Understanding where dummynet fits into an ipfw ruleset In-Reply-To: <1214609672.15425.25.camel@devstation> References: <1214609672.15425.25.camel@devstation> Message-ID: On Fri, Jun 27, 2008 at 4:34 PM, Martes Wigglesworth wrote: > It really does not matter, because the que has nothing to do with denial > of service unless you set it up that way. You just divert to the > dummynet pipe, or que and then the rest is handled by the mechanism. > The ipfw rule only works to augment the flow of traffic into the pipe, > or que. Just make sure you are not dropping any of the intended traffic > prior to a dummynet rule, because then you would be hendering the rule's > ability to shoot traffic to the que, or pipe. > > The dummynet manpage has some examples, and there are some good > tutorials on onlamp.com. > > Otherwise, I hate to say it but, "google it." Yes, I've read the dummynet and ipfw man pages. Yes, I've read articles on the 'Net. Yes, I've done google searches. And no, it still doesn't make sense how queue rules work with packet filter rules. Hence, why I'm asking here. > I have not done much with bandwidth shaping in about a year, so I am a > bit rusty as to the more complex setups however, it is one of the more > easy to remember methods so I think that I am correct, or at least not > far off of base. -- Freddie Cash fjwcash@gmail.com From smithi at nimnet.asn.au Sun Jun 29 06:22:41 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Sun Jun 29 06:22:45 2008 Subject: Understanding where dummynet fits into an ipfw ruleset In-Reply-To: Message-ID: On Sat, 28 Jun 2008, Freddie Cash wrote: > On Fri, Jun 27, 2008 at 11:14 PM, Ian Smith wrote: > > On Fri, 27 Jun 2008, Chuck Swiger wrote: > > > On Jun 27, 2008, at 3:01 PM, Freddie Cash wrote: > > > [ ... ] > > > >> If net.inet.ip.fw.one_pass is true, then you definitely want to > > > >> apply your deny rules first, as once something matches a pipe > > > >> rule, it's going to be passed. The tradeoff is that the > > > >> accounting/fairness of traffic is less accurate but the firewall > > > >> ruleset runs faster... > > > > > > > > So, in this situation, the "allow" rules would be the queue rules? > > > > > > > > To add traffic shaping to the following, using one_pass=1: > > > > 100 allow ip from 1.1.1.1 to 2.2.2.2 in recv em0 > > > > 200 allow ip from 1.1.1.1 to 2.2.2.2 out xmit em1 > > > > 300 deny ip from any to 2.2.2.2 in recv em0 > > > > > > > > Would be: > > > > 100 queue 1 ip from 1.1.1.1 to 2.2.2.2 in recv em0 > > > > 200 allow ip from 1.1.1.1 to 2.2.2.2 out xmit em1 > > > > 300 deny ip from any to 2.2.2.2 in recv em0 > > > > > > > > Or am I way off here? :) > > > > > > Hmm. If you have one_pass set, I believe that rule 200 would become > > > superfluous. If it was off, rule 200 would be needed to permit > > > traffic through. > > No, the rule is needed. Packets passing through the firewall go > through the ruleset twice: once entering the external interface, and > again leaving the internal interface (and vice versa). > > The first rule allows the packet in on the external interface, the > second rule allows it out the internal interface, the third rule > denies all other incoming traffic. Yes. So isn't that working? ipfw queue show? [ cut my longwinded explanation of what you just said above :] > > > However, queue rulesets are used to classify traffic > > > into different bins; then then get pulled out of the bins with packets > > > waiting is proportion to the weights configured via something like: > > > > > > ipfw queue 1 config pipe 1 weight 10 > > > > > > ie, you have to attach queue(s) to a pipe for this classification or > > > sorting to be meaningful. > > Yes, I know that. I was just trying to use very simplified examples > to understand how the traffic shaping works in conjunction with the > packet filtering. I understand how the queueing works, and have used > it successfully on routers that don't do packet filtering. It's > adding it to existing packet filter rulesets that is making my head > spin. :) And in your subsequent reply to martes@mgwigglesworth.com you said: > Yes, I've read the dummynet and ipfw man pages. Yes, I've read > articles on the 'Net. Yes, I've done google searches. And no, it > still doesn't make sense how queue rules work with packet filter > rules. Hence, why I'm asking here. It's not clear to me what's not working from your example rules above? Given using one_pass=1, that should go. And using one_pass=0, you should only need to also add as say rule 150: 150 allow ip from 1.1.1.1 to 2.2.2.2 in recv em0 > > Yes I suspect Freddie might want to use pipe rather than queue here too, > > if just for bandwidth limitation rather than weighted queueing by type > > of traffic? And is it only wanted for managing the inbound traffic? > > No, I want to use queue. I want to create rules to "reserve" > bandwidth for connections to important servers, as we're moving to > more web-based applications, and I want to make sure students surfing > the web don't impact office staff. There will be a single pipe, with > two queues, one weighted at twice the value of the other. That way, > if there is no staff traffic, the students get the whole pipe. If > there is no student traffic, staff get the whole pipe. And if there's > a mix, then staff traffic is prioritised ahead of student traffic. Ok; on rereading your original, I should have realised that. So with a similar set of rules for the other of staff/students that your above example deals with, and the right pipe and queue configs, what remains to do? Sorry to be thick, but I don't see why that wouldn't work .. cheers, Ian From rwatson at FreeBSD.org Sun Jun 29 06:42:25 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Jun 29 06:42:30 2008 Subject: Probably not a kernel bug (was: Re: FreeBSD 7.0: sockets stuck in CLOSED state...) In-Reply-To: <20080627090939.M78484@fledge.watson.org> References: <486283B0.3060805@transip.nl> <20080625195523.N29013@fledge.watson.org> <4862BCF5.4070900@transip.nl> <20080626081831.V96707@fledge.watson.org> <20080627090939.M78484@fledge.watson.org> Message-ID: <20080629073519.D10134@fledge.watson.org> On Fri, 27 Jun 2008, Robert Watson wrote: > I've asked Ali to do a bit more debugging and tracing of the application to > see if we can reach any conclusions about this. In particular, if he traces > to a file all file descriptor numbers returned by accept(2), then we can > later compare that file with the leaked descriptors present in > netstat/sockstat and decide whether the application *should* have known they > were open or not. Another public follow-up: Ali has been sending me debugging information privately due to the inclusion of application source code and IP addresses. Tracing of the application suggests that there is an application concurrency bug leading to one socket to be closed twice and another socket to be left open. The bug might be triggering in 7.x but not earlier releases because of the change to libthr, which can lead to more parallelism/asynchrony in the application. In conclusion: we currently believe that this report of sockets stuck in the CLOSED state is not the result of a kernel bug. If any further information comes to light, I will send a followup. Thanks, Robert N M Watson Computer Laboratory University of Cambridge From shino at fornext.org Sun Jun 29 07:30:05 2008 From: shino at fornext.org (Shunsuke SHINOMIYA) Date: Sun Jun 29 07:30:08 2008 Subject: kern/125003: incorrect EtherIP header format. Message-ID: <200806290730.m5T7U57d007972@freefall.freebsd.org> The following reply was made to PR kern/125003; it has been noted by GNATS. From: Shunsuke SHINOMIYA To: Andrew Thompson , Hiroki Sato Cc: freebsd-bugs@FreeBSD.org, bug-followup@FreeBSD.org Subject: Re[2]: kern/125003: incorrect EtherIP header format. Date: Sun, 29 Jun 2008 16:27:33 +0900 Hi, > It is unclear where the interoperability problem comes in. I'm sorry. A fix I submitted was a mistake. > Which would conform to the requirement. Can you describe the problem you > are seeing. FreeBSD's current implementation expects 0x03, 0x00 as EtherIP header, but another implementation(UNIVERGE IX2015, products by NEC, Japan) transmits 0x30, 0x00. Then FreeBSD box discards EtherIP packets. I read RFC3378 and thought 0x30, 0x00 is correct. The result of 'tcpdump -np -x proto etherip' at FreeBSD box is as follows. 192.168.2.37: FreeBSD box 192.168.2.128: IX2015 MAC addresses were replaced with ****. 16:02:40.952832 IP 192.168.2.128 > 192.168.2.37: etherip 344 0x0000: 4500 016c 0098 0000 4061 f2a3 c0a8 0280 0x0010: c0a8 0225 3000 **** **** **** **** **** ~~~~ EtherIP header by IX2015 snip 16:02:48.080826 IP 192.168.2.37 > 192.168.2.128: etherip 108 0x0000: 4500 0080 01f3 0000 1e61 1435 c0a8 0225 0x0010: c0a8 0280 0300 **** **** **** **** **** ~~~~ EtherIP header by FreeBSD snip -- Shunsuke SHINOMIYA From pyunyh at gmail.com Sun Jun 29 07:31:47 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Sun Jun 29 07:31:52 2008 Subject: kern/125024: vr(4) does not see incoming multicast packets in non-promiscuous mode (broadcast is fine); breaks IPv6 In-Reply-To: <4864A217.3040309@ab.ote.we.lv> References: <200806270345.m5R3j1BT036253@freefall.freebsd.org> <48649776.9040509@ab.ote.we.lv> <20080627074948.GC67753@cdnetworks.co.kr> <4864A217.3040309@ab.ote.we.lv> Message-ID: <20080629072932.GA76469@cdnetworks.co.kr> On Fri, Jun 27, 2008 at 01:17:27AM -0700, Eugene M. Kim wrote: > Pyun YongHyeon wrote: > >I've updated patch again. There was a bug that disabled > >multicasting filter. Back out previous patch and try again. > >The URL is the same as before. > > > > > Regards, > > > Eugene > > > > rtsol still doesn't work with vr0 being in non-promiscuous mode. > However, apparently vr0 picked up router solicitations during system > boot-up, as ifconfig shows the correct prefixes autoconfigured. It > seems something goes wrong in between. 'o 'a > Oops, I was accessing CAM mask register as 8bit register which should be 32bit! Try the patch at the following URL. http://people.freebsd.org/~yongari/vr/vr.cam.patch2 > Eugene -- Regards, Pyun YongHyeon From fjwcash at gmail.com Sun Jun 29 07:43:20 2008 From: fjwcash at gmail.com (Freddie Cash) Date: Sun Jun 29 07:43:23 2008 Subject: Understanding where dummynet fits into an ipfw ruleset In-Reply-To: References: Message-ID: On Sat, Jun 28, 2008 at 11:22 PM, Ian Smith wrote: > It's not clear to me what's not working from your example rules above? I never said anything wasn't working. I was just looking for information to better understand how things work together, and to get a general feeling of where the queue rules would have to go. > Given using one_pass=1, that should go. And using one_pass=0, you > should only need to also add as say rule 150: > > 150 allow ip from 1.1.1.1 to 2.2.2.2 in recv em0 I'm starting to better understand how one_pass affects things. And I think I get, now, where to put the queue rules. I won't be doing any of the actual testing or implementation until July. I was just looking for more info on how to set things up. > > > Yes I suspect Freddie might want to use pipe rather than queue here too, > > > if just for bandwidth limitation rather than weighted queueing by type > > > of traffic? And is it only wanted for managing the inbound traffic? > > > > No, I want to use queue. I want to create rules to "reserve" > > bandwidth for connections to important servers, as we're moving to > > more web-based applications, and I want to make sure students surfing > > the web don't impact office staff. There will be a single pipe, with > > two queues, one weighted at twice the value of the other. That way, > > if there is no staff traffic, the students get the whole pipe. If > > there is no student traffic, staff get the whole pipe. And if there's > > a mix, then staff traffic is prioritised ahead of student traffic. > > Ok; on rereading your original, I should have realised that. So with a > similar set of rules for the other of staff/students that your above > example deals with, and the right pipe and queue configs, what remains > to do? Sorry to be thick, but I don't see why that wouldn't work .. I never said it wouldn't (or didn't) work. :) -- Freddie Cash fjwcash@gmail.com From paul at gtcomm.net Sun Jun 29 08:02:28 2008 From: paul at gtcomm.net (Paul) Date: Sun Jun 29 08:02:32 2008 Subject: Freebsd IP Forwarding performance (question, and some info) [7-stable, current, em, smp] Message-ID: <4867420D.7090406@gtcomm.net> This is just a question but who can get more than 400k pps forwarding performance ? I have tested fbsd 6/7/8 so far with many different configs. (all using intel pci-ex nic and SMP) fbsd 7-stable/8(current) seem to be the fastest and always hit this ceiling of 400k pps. Soon as it hits that I get errors galore. Received no buffers, missed packets, rx overruns.. It's because 'em0 taskq' is 90% cpu or so.. Now, while this is happening I have two CPU's 100% idle, and the other two CPUs are about 60%/20% .. So why in the world can't it use more cpus? Simple test setup: packet generator on em0 destination out em1 have to have ip forwarding and fastforwarding on (fastforward definitely makes a big difference, another 100kpps or so, without it can barely hit 300k) Packets are TCP, randomized sources, randomized ports for src and dst, single destination ip. I even tried the yandex driver in FBSD6 but it could barely even get 200k pps and it had a lot of weird issues, and fbsd6 couldn't hit 400k pps by itself. I am not using polling, that seems to make no difference, i tried that too. So question. What can I do for more performance (SMP)? Are there any good kernel options? If I disable ip forwarding i can do 750kpps with no errors because it's not going anywhere..em0 taskq cpu usage is less than half of what it is when it's forwarding. so obviously the issue is somewhere in the forwarding path and fastforwarding greatly helps!! see below. forwarding off: input (em0) output packets errs bytes packets errs bytes colls 757223 0 46947830 1 0 226 0 753551 0 46720166 1 0 178 0 756359 0 46894262 1 0 178 0 757570 0 46969344 1 0 178 0 753724 0 46730830 1 0 178 0 745372 0 46213130 1 0 178 0 (I had to slow down the packet generation to about 420-430kpps) forwarding on: input (em0) output packets errs bytes packets errs bytes colls 285918 151029 17726936 460 0 25410 0 284929 146151 17665602 417 0 22642 0 284253 147000 17623690 442 0 23884 0 285438 147765 17697160 448 0 24316 0 286582 147171 17768088 456 0 24748 0 287194 147088 17806032 422 0 22912 0 285812 141713 17720348 440 0 23884 0 284958 137579 17667412 457 0 25104 0 fastforwarding on: input (em0) output packets errs bytes packets errs bytes colls 399795 22790 24787310 459 0 25130 0 397425 25254 24640354 434 0 23560 0 403223 26937 24999830 431 0 23452 0 396587 21431 24588398 467 0 25288 0 400970 25776 24860144 459 0 24910 0 397819 23657 24664782 432 0 23452 0 406222 27418 25185768 432 0 23506 0 406718 12407 25216520 461 0 25018 0 PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 171 ki31 0K 64K CPU1 1 29:24 100.00% {idle: cpu1} 11 root 171 ki31 0K 64K RUN 0 28:46 100.00% {idle: cpu0} 11 root 171 ki31 0K 64K CPU3 3 24:32 84.62% {idle: cpu3} 0 root -68 0 0K 128K CPU2 2 12:59 84.13% {em0 taskq} 0 root -68 0 0K 128K - 3 2:12 19.92% {em1 taskq} 11 root 171 ki31 0K 64K RUN 2 19:46 19.63% {idle: cpu2} Well if anything.. at least it's a good show of the difference fastforwarding makes!! :) I have options NO_ADAPTIVE_MUTEXES ## Improve routing performance? options STOP_NMI # Stop CPUS using NMI instead of IPI no IPV6 no firewall loaded no netgraph HZ is 4000 em driver is 4096 on receive buffers using VLAN devices (em1 output) Tested on Xeon and Opteron processor Don't have exact results. Above results are dual opteron 2212 with freebsd current FreeBSD 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sat Jun 28 23:37:39 CDT 2008 Well I'm curious of the results of others.. Thanks for reading!! :) From hrs at FreeBSD.org Sun Jun 29 08:22:35 2008 From: hrs at FreeBSD.org (hrs@FreeBSD.org) Date: Sun Jun 29 08:22:40 2008 Subject: kern/125003: [gif] incorrect EtherIP header format. Message-ID: <200806290822.m5T8MYdw019531@freefall.freebsd.org> Synopsis: [gif] incorrect EtherIP header format. State-Changed-From-To: feedback->open State-Changed-By: hrs State-Changed-When: Sun Jun 29 08:21:04 UTC 2008 State-Changed-Why: We have a concrete case now. http://www.freebsd.org/cgi/query-pr.cgi?pr=125003 From andrew at modulus.org Sun Jun 29 09:07:32 2008 From: andrew at modulus.org (Andrew Snow) Date: Sun Jun 29 09:07:35 2008 Subject: Freebsd IP Forwarding performance (question, and some info) [7-stable, current, em, smp] In-Reply-To: <4867420D.7090406@gtcomm.net> References: <4867420D.7090406@gtcomm.net> Message-ID: <48675095.7020008@modulus.org> The "em" driver currently only has a single worker/queue so will only use one CPU to process packets. However I remember reading that multi-threaded version of the driver is being worked on and is "coming soon", but there is no known ETA yet. I see you mentioned that you played with the receive descriptors and set that to 4096, which is good if your chipset supports it. But I can't see that you mentioned playing around with hw.em.rx_int_delay or tx_int_delay - have you tried this? By default rx_int_delay is disabled but it has the capability to lower CPU consumption if you enable it and it works on your chipset. By my reckoning, if you are aiming for a million pps, thats microsecond per packet, so you can afford to increase the delay quite alot, try 50 or 100 or even more? - Andrew From hrs at FreeBSD.org Sun Jun 29 10:00:17 2008 From: hrs at FreeBSD.org (Hiroki Sato) Date: Sun Jun 29 10:00:19 2008 Subject: kern/125003: incorrect EtherIP header format. Message-ID: <200806291000.m5TA0GGr027434@freefall.freebsd.org> The following reply was made to PR kern/125003; it has been noted by GNATS. From: Hiroki Sato To: shino@fornext.org Cc: thompsa@FreeBSD.org, freebsd-bugs@FreeBSD.org, bug-followup@FreeBSD.org, hrs@FreeBSD.org Subject: Re: kern/125003: incorrect EtherIP header format. Date: Sun, 29 Jun 2008 18:57:11 +0900 (JST) ----Security_Multipart(Sun_Jun_29_18_57_11_2008_878)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Shunsuke SHINOMIYA wrote in <20080629150108.6783.A2D40D1E@fornext.org>: sh> FreeBSD's current implementation expects 0x03, 0x00 as EtherIP header, sh> but another implementation(UNIVERGE IX2015, products by NEC, Japan) sh> transmits 0x30, 0x00. Then FreeBSD box discards EtherIP packets. Could you let me know if the following patch solves your symptom or not? It can be applied to 8.x and 7.x: http://people.allbsd.org/~hrs/FreeBSD/gif.diff -- | Hiroki SATO ----Security_Multipart(Sun_Jun_29_18_57_11_2008_878)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkhnXHcACgkQTyzT2CeTzy1/SgCgueGgx06kNVVrgyR5Ryf2K+0I XJ0AnRbtkaW72joKYjyqGF/jVkKeRWAm =IsCy -----END PGP SIGNATURE----- ----Security_Multipart(Sun_Jun_29_18_57_11_2008_878)---- From if at xip.at Sun Jun 29 10:56:25 2008 From: if at xip.at (Ingo Flaschberger) Date: Sun Jun 29 10:56:30 2008 Subject: Freebsd IP Forwarding performance (question, and some info) [7-stable, current, em, smp] In-Reply-To: <4867420D.7090406@gtcomm.net> References: <4867420D.7090406@gtcomm.net> Message-ID: Dear Paul, tried interface polling? what hardware system? how are the nic's connected? Kind regards, ingo flaschberger geschaeftsleitung --------------------------- netstorage-crossip-flat:fee powered by crossip communications gmbh --------------------------- sebastian kneipp gasse 1 a-1020 wien fix: +43-1-726 15 22-217 fax: +43-1-726 15 22-111 --------------------------- On Sun, 29 Jun 2008, Paul wrote: > This is just a question but who can get more than 400k pps forwarding > performance ? > I have tested fbsd 6/7/8 so far with many different configs. (all using intel > pci-ex nic and SMP) > fbsd 7-stable/8(current) seem to be the fastest and always hit this ceiling > of 400k pps. Soon as it hits that I get errors galore. > Received no buffers, missed packets, rx overruns.. It's because 'em0 taskq' > is 90% cpu or so.. > Now, while this is happening I have two CPU's 100% idle, and the other two > CPUs are about 60%/20% .. > So why in the world can't it use more cpus? Simple test setup: > packet generator on em0 > destination out em1 > have to have ip forwarding and fastforwarding on (fastforward definitely > makes a big difference, another 100kpps or so, without it can barely hit > 300k) > Packets are TCP, randomized sources, randomized ports for src and dst, single > destination ip. > I even tried the yandex driver in FBSD6 but it could barely even get 200k pps > and it had a lot of weird issues, and fbsd6 couldn't hit 400k pps by itself. > I am not using polling, that seems to make no difference, i tried that too. > So question. What can I do for more performance (SMP)? Are there any good > kernel options? > If I disable ip forwarding i can do 750kpps with no errors because it's not > going anywhere..em0 taskq cpu usage is less than half of what it is when it's > forwarding. so obviously the issue is somewhere in the forwarding path and > fastforwarding greatly helps!! see below. > forwarding off: > input (em0) output > packets errs bytes packets errs bytes colls > 757223 0 46947830 1 0 226 0 > 753551 0 46720166 1 0 178 0 > 756359 0 46894262 1 0 178 0 > 757570 0 46969344 1 0 178 0 > 753724 0 46730830 1 0 178 0 > 745372 0 46213130 1 0 178 0 > > > (I had to slow down the packet generation to about 420-430kpps) > forwarding on: > input (em0) output > packets errs bytes packets errs bytes colls > 285918 151029 17726936 460 0 25410 0 > 284929 146151 17665602 417 0 22642 0 > 284253 147000 17623690 442 0 23884 0 > 285438 147765 17697160 448 0 24316 0 > 286582 147171 17768088 456 0 24748 0 > 287194 147088 17806032 422 0 22912 0 > 285812 141713 17720348 440 0 23884 0 > 284958 137579 17667412 457 0 25104 0 > > fastforwarding on: > > input (em0) output > packets errs bytes packets errs bytes colls > 399795 22790 24787310 459 0 25130 0 > 397425 25254 24640354 434 0 23560 0 > 403223 26937 24999830 431 0 23452 0 > 396587 21431 24588398 467 0 25288 0 > 400970 25776 24860144 459 0 24910 0 > 397819 23657 24664782 432 0 23452 0 > 406222 27418 25185768 432 0 23506 0 > 406718 12407 25216520 461 0 25018 0 > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 11 root 171 ki31 0K 64K CPU1 1 29:24 100.00% {idle: cpu1} > 11 root 171 ki31 0K 64K RUN 0 28:46 100.00% {idle: cpu0} > 11 root 171 ki31 0K 64K CPU3 3 24:32 84.62% {idle: cpu3} > 0 root -68 0 0K 128K CPU2 2 12:59 84.13% {em0 taskq} > 0 root -68 0 0K 128K - 3 2:12 19.92% {em1 taskq} > 11 root 171 ki31 0K 64K RUN 2 19:46 19.63% {idle: cpu2} > > > > Well if anything.. at least it's a good show of the difference fastforwarding > makes!! :) > I have > options NO_ADAPTIVE_MUTEXES ## Improve routing performance? > options STOP_NMI # Stop CPUS using NMI instead of IPI > no IPV6 > no firewall loaded > no netgraph > HZ is 4000 > em driver is 4096 on receive buffers > using VLAN devices (em1 output) > Tested on Xeon and Opteron processor > Don't have exact results. > Above results are dual opteron 2212 with freebsd current > FreeBSD 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sat Jun 28 23:37:39 CDT 2008 > Well I'm curious of the results of others.. > > Thanks for reading!! :) > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From jbut at swin.edu.au Sun Jun 29 11:30:30 2008 From: jbut at swin.edu.au (Jason But) Date: Sun Jun 29 11:30:35 2008 Subject: Code release of ipfw NAT support for SCTP in FreeBSD-8 Message-ID: <486765C7.1010409@swin.edu.au> The Centre for Advanced Internet Architectures (CAIA - http://caia.swin.edu.au) is proud to announce the release of alias_sctp version 0.1, a SCTP NAT patch to FreeBSD 8.x. Alias_sctp provides SCTP NAT functionality to the ipfw/ipfw_nat/libalias suite. It is part of the CAIA SONATA project (http://caia.swin.edu.au/urp/sonata). The code has been intentionally kept as separate as possible from the base modules to aid testing and debugging, and make it easier to port to other systems. This project has been made possible in part by a grant from the Cisco University Research Program Fund at Community Foundation Silicon Valley. We welcome and value feedback and comments. Please forward feedback to dahayes@swin.edu.au and jbut@swin.edu.au Download patch from http://caia.swin.edu.au/urp/sonata/downloads.html Features of alias_sctp version 0.1: - Basic configuration through "ipfw nat ... config" commands. - Forwarding of incoming SCTP associations through "ipfw nat ... redirect_addr ..." commands. - A variety of log levels (currently #define, but sysctl in version 0.2). - Stateful SCTP association management. 12345678901234567890123456789012345678901234567890123456789012345678901234567890 - Tested on single-homed hosts, but should work when the multi-homed host is on the global side of the NAT (same mechanism for address translation). - Dynamic hash table size allocation (currently #define, but sysctl in version 0.2). - Initial testing has been for up to 10000 concurrent flows arriving and leaving at about 2000/second. Tested for periods of up to 72 hours. Features in the pipline for further releases: - Sysctl interface for logging, timeouts, hash table size. Status - mostly complete. - Port forwarding and load sharing. Status - mostly complete. - Support for, soon to be specified, enhancements of SCTP to aid interworking with NATs. - New AddIP ASCONF chunks. Status - preliminary coding and investigation. (Requires finalised standards to be completed) - AbortM and ErrorM NAT originated messages. Status - preliminary coding, with work starting on the ipfw send interface - IPv6 support. Status - preliminary investigation. - Global IP address tracing. Status - preliminary investigation. Other tasks: - Exaustive testing of the various configurations and scenarios. - Stress and load testing. - Performance analysis. Jason -- ---------- Dr. Jason But Lecturer Telecommunications Engineering Academic Group Faculty of Information and Communication Technologies Swinburne University of Technology http://www.swinburne.edu.au/ict/telecommshome.htm From shino at fornext.org Sun Jun 29 11:40:04 2008 From: shino at fornext.org (Shunsuke SHINOMIYA) Date: Sun Jun 29 11:40:05 2008 Subject: kern/125003: incorrect EtherIP header format. Message-ID: <200806291140.m5TBe3QL040356@freefall.freebsd.org> The following reply was made to PR kern/125003; it has been noted by GNATS. From: Shunsuke SHINOMIYA To: Hiroki Sato Cc: thompsa@FreeBSD.org, freebsd-bugs@FreeBSD.org, bug-followup@FreeBSD.org Subject: Re[2]: kern/125003: incorrect EtherIP header format. Date: Sun, 29 Jun 2008 20:38:51 +0900 --------_4867660B00000000A846_MULTIPART_MIXED_ Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi, > Could you let me know if the following patch solves your symptom or > not? It can be applied to 8.x and 7.x: > > http://people.allbsd.org/~hrs/FreeBSD/gif.diff Thank you. I applied your patch to RELENG_6_3 and modified netinet6/in6_gif.c manually(because of tab expansion?). I had 2 problems. One is syntax error around `eip_ver:4,' when BYTE_ORDER is LITTELE_ENDIAN. Another one is 2 octet padding for struct etherip_header. To solve this, I specified __packed attribute for this structure. Attached patch based on yours is for RELENG_6_3. Patched implementation works well with IX2015. 192.168.2.37: FreeBSD box 192.168.2.128: IX2015 20:22:55.540804 IP 192.168.2.128 > 192.168.2.37: etherip 76 0x0000: 4500 0060 076b 0000 4061 ecdc c0a8 0280 0x0010: c0a8 0225 3000 **** **** **** **** **** 0x0020: **** 0800 4500 003c 0cc0 0000 8001 a82e 0x0030: c0a8 0281 c0a8 0201 0800 4753 0001 0608 0x0040: 6162 6364 6566 6768 696a 6b6c 6d6e 6f70 0x0050: 7172 20:22:55.541815 IP 192.168.2.37 > 192.168.2.128: etherip 76 0x0000: 4500 0060 3511 0000 1e61 e136 c0a8 0225 0x0010: c0a8 0280 3000 **** **** **** **** **** 0x0020: **** 0800 4500 003c 319b 0000 4001 c353 0x0030: c0a8 0201 c0a8 0281 0000 4f53 0001 0608 0x0040: 6162 6364 6566 6768 696a 6b6c 6d6e 6f70 0x0050: 7172 -- Shunsuke SHINOMIYA --------_4867660B00000000A846_MULTIPART_MIXED_ Content-Type: application/octet-stream; name="gif6.diff" Content-Disposition: attachment; filename="gif6.diff" Content-Transfer-Encoding: base64 LS0tIG5ldC9pZl9naWYuaC5vcmlnCTIwMDYtMDItMDEgMDA6NTY6NDYuMDAwMDAwMDAwICswOTAw CisrKyBuZXQvaWZfZ2lmLmgJMjAwOC0wNi0yOSAxOTozNjo0MC4wMDAwMDAwMDAgKzA5MDAKQEAg LTkzLDEyICs5MywxNyBAQAogI2RlZmluZQlNVEFHX0dJRl9DQUxMRUQJMAogCiBzdHJ1Y3QgZXRo ZXJpcF9oZWFkZXIgewotCXVfaW50OF90IGVpcF92ZXI7CS8qIHZlcnNpb24vcmVzZXJ2ZWQgKi8K LQl1X2ludDhfdCBlaXBfcGFkOwkvKiByZXF1aXJlZCBwYWRkaW5nIGJ5dGUgKi8KLX07Ci0jZGVm aW5lIEVUSEVSSVBfVkVSX1ZFUlNfTUFTSyAgIDB4MGYKLSNkZWZpbmUgRVRIRVJJUF9WRVJfUlNW RF9NQVNLICAgMHhmMAotI2RlZmluZSBFVEhFUklQX1ZFUlNJT04gICAgICAgICAweDAzCisjaWYg QllURV9PUkRFUiA9PSBMSVRUTEVfRU5ESUFOCisJdV9pbnQJZWlwX3Jlc3ZsOjQsCS8qIHJlc2Vy dmVkICAqLworCQllaXBfdmVyOjQ7CS8qIHZlcnNpb24gKi8KKyNlbmRpZgorI2lmIEJZVEVfT1JE RVIgPT0gQklHX0VORElBTgorCXVfaW50CWVpcF92ZXI6NCwJLyogdmVyc2lvbiAqLworCQllaXBf cmVzdmw6NDsJLyogcmVzZXJ2ZWQgICovCisjZW5kaWYKKwl1X2ludDhfdCBlaXBfcmVzdmg7CS8q IHJlc2VydmVkICAqLworfSBfX3BhY2tlZDsKKyNkZWZpbmUgRVRIRVJJUF9WRVJTSU9OICAgICAg ICAgMHgzCiAKIC8qIFByb3RvdHlwZXMgKi8KIHZvaWQgZ2lmX2lucHV0KHN0cnVjdCBtYnVmICos IGludCwgc3RydWN0IGlmbmV0ICopOwotLS0gbmV0aW5ldC9pbl9naWYuYy5vcmlnCTIwMDYtMDIt MDEgMDA6NTY6NDYuMDAwMDAwMDAwICswOTAwCisrKyBuZXRpbmV0L2luX2dpZi5jCTIwMDgtMDYt MjkgMTk6MjI6NDguMDAwMDAwMDAwICswOTAwCkBAIC0xNDcsOCArMTQ3LDkgQEAKICNlbmRpZiAv KiBJTkVUNiAqLwogCWNhc2UgQUZfTElOSzoKICAJCXByb3RvID0gSVBQUk9UT19FVEhFUklQOwot IAkJZWlwaGRyLmVpcF92ZXIgPSBFVEhFUklQX1ZFUlNJT04gJiBFVEhFUklQX1ZFUl9WRVJTX01B U0s7Ci0gCQllaXBoZHIuZWlwX3BhZCA9IDA7CisgCQllaXBoZHIuZWlwX3ZlciA9IEVUSEVSSVBf VkVSU0lPTjsKKyAJCWVpcGhkci5laXBfcmVzdmwgPSAwOworIAkJZWlwaGRyLmVpcF9yZXN2aCA9 IDA7CiAgCQkvKiBwcmVwZW5kIEV0aGVybmV0LWluLUlQIGhlYWRlciAqLwogIAkJTV9QUkVQRU5E KG0sIHNpemVvZihzdHJ1Y3QgZXRoZXJpcF9oZWFkZXIpLCBNX0RPTlRXQUlUKTsKICAJCWlmICht ICYmIG0tPm1fbGVuIDwgc2l6ZW9mKHN0cnVjdCBldGhlcmlwX2hlYWRlcikpCi0tLSBuZXRpbmV0 Ni9pbjZfZ2lmLmMub3JpZwkyMDA2LTAyLTAxIDAwOjU2OjQ3LjAwMDAwMDAwMCArMDkwMAorKysg bmV0aW5ldDYvaW42X2dpZi5jCTIwMDgtMDYtMjkgMTk6MjQ6NDkuMDAwMDAwMDAwICswOTAwCkBA IC0xNDAsOCArMTQwLDkgQEAKICNlbmRpZgogCWNhc2UgQUZfTElOSzoKICAJCXByb3RvID0gSVBQ Uk9UT19FVEhFUklQOwotIAkJZWlwaGRyLmVpcF92ZXIgPSBFVEhFUklQX1ZFUlNJT04gJiBFVEhF UklQX1ZFUl9WRVJTX01BU0s7Ci0gCQllaXBoZHIuZWlwX3BhZCA9IDA7CisgCQllaXBoZHIuZWlw X3ZlciA9IEVUSEVSSVBfVkVSU0lPTjsKKyAJCWVpcGhkci5laXBfcmVzdmwgPSAwOworIAkJZWlw aGRyLmVpcF9yZXN2aCA9IDA7CiAgCQkvKiBwcmVwZW5kIEV0aGVybmV0LWluLUlQIGhlYWRlciAq LwogIAkJTV9QUkVQRU5EKG0sIHNpemVvZihzdHJ1Y3QgZXRoZXJpcF9oZWFkZXIpLCBNX0RPTlRX QUlUKTsKICAJCWlmIChtICYmIG0tPm1fbGVuIDwgc2l6ZW9mKHN0cnVjdCBldGhlcmlwX2hlYWRl cikpCg== --------_4867660B00000000A846_MULTIPART_MIXED_-- From ali at transip.nl Sun Jun 29 11:58:27 2008 From: ali at transip.nl (Ali Niknam) Date: Sun Jun 29 11:58:31 2008 Subject: Probably not a kernel bug (was: Re: FreeBSD 7.0: sockets stuck in CLOSED state...) In-Reply-To: <20080629073519.D10134@fledge.watson.org> References: <486283B0.3060805@transip.nl> <20080625195523.N29013@fledge.watson.org> <4862BCF5.4070900@transip.nl> <20080626081831.V96707@fledge.watson.org> <20080627090939.M78484@fledge.watson.org> <20080629073519.D10134@fledge.watson.org> Message-ID: <486778CE.4000103@transip.nl> Hi Guys, > Another public follow-up: Ali has been sending me debugging information > privately due to the inclusion of application source code and IP > addresses. Tracing of the application suggests that there is an > application concurrency bug leading to one socket to be closed twice and > another socket to be left open. The bug might be triggering in 7.x but > not earlier releases because of the change to libthr, which can lead to > more parallelism/asynchrony in the application. > After more testing I can with almost absolute certainty conclude that it is indeed an application bug. Reasons that it did not manifest itself earlier most probably are due to the much increased performance of BSD 7, making a certain race condition likely where it once was improbable. I want to thank all who've helped track this issue down! Kind Regards, Ali From paul at gtcomm.net Sun Jun 29 15:24:24 2008 From: paul at gtcomm.net (Paul) Date: Sun Jun 29 15:24:29 2008 Subject: Freebsd IP Forwarding performance (question, and some info) [7-stable, current, em, smp] In-Reply-To: References: <4867420D.7090406@gtcomm.net> Message-ID: <4867A9A1.9070507@gtcomm.net> Polling makes no difference.. It uses the cpus in a slightly different way but the pps rate is similar.. I tried different HZ settings, I edited kern_poll so i could have a burst max of 8000.. Polling doesn't do anything any more. The only thing I noticed it does is lower the latency on packets when the cpu is idle (i.e. not many pps going through) Hardware system is dual opteron 2212 with intel pci express server NIC dual port. em0: Flow control watermarks high = 30720 low = 29220 em0: tx_int_delay = 66, tx_abs_int_delay = 66 em0: rx_int_delay = 64, rx_abs_int_delay = 98 em0: fifo workaround = 0, fifo_reset_count = 0 input (em0) output packets errs bytes packets errs bytes colls 384700 32541 23851406 457 0 24876 0 385543 25403 23903670 459 0 24910 0 383906 24245 23802188 435 0 23738 0 383656 25182 23786676 427 0 23128 0 em0: tx_int_delay = 66, tx_abs_int_delay = 66 em0: rx_int_delay = 0, rx_abs_int_delay = 98 em0: fifo workaround = 0, fifo_reset_count = 0 input (em0) output packets errs bytes packets errs bytes colls 393787 11217 24414800 461 0 25012 0 390227 16909 24194076 439 0 23776 0 389938 15321 24176158 433 0 23506 0 388685 19562 24098474 449 0 24370 0 392908 11242 24360300 465 0 25234 0 387329 19426 24014402 440 0 23938 0 Ingo Flaschberger wrote: > Dear Paul, > > tried interface polling? > > what hardware system? how are the nic's connected? > > Kind regards, > ingo flaschberger > > geschaeftsleitung > --------------------------- > netstorage-crossip-flat:fee > powered by > crossip communications gmbh > --------------------------- > sebastian kneipp gasse 1 > a-1020 wien > fix: +43-1-726 15 22-217 > fax: +43-1-726 15 22-111 > --------------------------- > On Sun, 29 Jun 2008, Paul wrote: > >> This is just a question but who can get more than 400k pps forwarding >> performance ? >> I have tested fbsd 6/7/8 so far with many different configs. (all >> using intel pci-ex nic and SMP) >> fbsd 7-stable/8(current) seem to be the fastest and always hit this >> ceiling of 400k pps. Soon as it hits that I get errors galore. >> Received no buffers, missed packets, rx overruns.. It's because 'em0 >> taskq' is 90% cpu or so.. >> Now, while this is happening I have two CPU's 100% idle, and the >> other two CPUs are about 60%/20% .. >> So why in the world can't it use more cpus? Simple test setup: >> packet generator on em0 >> destination out em1 >> have to have ip forwarding and fastforwarding on (fastforward >> definitely makes a big difference, another 100kpps or so, without it >> can barely hit 300k) >> Packets are TCP, randomized sources, randomized ports for src and >> dst, single destination ip. >> I even tried the yandex driver in FBSD6 but it could barely even get >> 200k pps and it had a lot of weird issues, and fbsd6 couldn't hit >> 400k pps by itself. >> I am not using polling, that seems to make no difference, i tried >> that too. >> So question. What can I do for more performance (SMP)? Are there any >> good kernel options? >> If I disable ip forwarding i can do 750kpps with no errors because >> it's not going anywhere..em0 taskq cpu usage is less than half of >> what it is when it's forwarding. so obviously the issue is somewhere >> in the forwarding path and fastforwarding greatly helps!! see below. >> forwarding off: >> input (em0) output >> packets errs bytes packets errs bytes colls >> 757223 0 46947830 1 0 226 0 >> 753551 0 46720166 1 0 178 0 >> 756359 0 46894262 1 0 178 0 >> 757570 0 46969344 1 0 178 0 >> 753724 0 46730830 1 0 178 0 >> 745372 0 46213130 1 0 178 0 >> >> >> (I had to slow down the packet generation to about 420-430kpps) >> forwarding on: >> input (em0) output >> packets errs bytes packets errs bytes colls >> 285918 151029 17726936 460 0 25410 0 >> 284929 146151 17665602 417 0 22642 0 >> 284253 147000 17623690 442 0 23884 0 >> 285438 147765 17697160 448 0 24316 0 >> 286582 147171 17768088 456 0 24748 0 >> 287194 147088 17806032 422 0 22912 0 >> 285812 141713 17720348 440 0 23884 0 >> 284958 137579 17667412 457 0 25104 0 >> >> fastforwarding on: >> >> input (em0) output >> packets errs bytes packets errs bytes colls >> 399795 22790 24787310 459 0 25130 0 >> 397425 25254 24640354 434 0 23560 0 >> 403223 26937 24999830 431 0 23452 0 >> 396587 21431 24588398 467 0 25288 0 >> 400970 25776 24860144 459 0 24910 0 >> 397819 23657 24664782 432 0 23452 0 >> 406222 27418 25185768 432 0 23506 0 >> 406718 12407 25216520 461 0 25018 0 >> >> PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND >> 11 root 171 ki31 0K 64K CPU1 1 29:24 100.00% {idle: cpu1} >> 11 root 171 ki31 0K 64K RUN 0 28:46 100.00% {idle: cpu0} >> 11 root 171 ki31 0K 64K CPU3 3 24:32 84.62% {idle: cpu3} >> 0 root -68 0 0K 128K CPU2 2 12:59 84.13% {em0 taskq} >> 0 root -68 0 0K 128K - 3 2:12 19.92% {em1 taskq} >> 11 root 171 ki31 0K 64K RUN 2 19:46 19.63% {idle: cpu2} >> >> >> >> Well if anything.. at least it's a good show of the difference >> fastforwarding makes!! :) >> I have >> options NO_ADAPTIVE_MUTEXES ## Improve routing performance? >> options STOP_NMI # Stop CPUS using NMI instead >> of IPI >> no IPV6 >> no firewall loaded >> no netgraph >> HZ is 4000 >> em driver is 4096 on receive buffers >> using VLAN devices (em1 output) >> Tested on Xeon and Opteron processor >> Don't have exact results. >> Above results are dual opteron 2212 with freebsd current >> FreeBSD 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sat Jun 28 23:37:39 CDT >> 2008 Well I'm curious of the results of others.. >> >> Thanks for reading!! :) >> >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > From mike at sentex.net Sun Jun 29 15:40:00 2008 From: mike at sentex.net (Mike Tancsa) Date: Sun Jun 29 15:40:05 2008 Subject: Freebsd IP Forwarding performance (question, and some info) [7-stable, current, em, smp] In-Reply-To: <4867420D.7090406@gtcomm.net> References: <4867420D.7090406@gtcomm.net> Message-ID: <200806291539.m5TFdvCO075285@lava.sentex.ca> At 04:04 AM 6/29/2008, Paul wrote: >This is just a question but who can get more than 400k pps >forwarding performance ? >I have tested fbsd 6/7/8 so far with many different configs. (all >using intel pci-ex nic and SMP) >fbsd 7-stable/8(current) seem to be the fastest and always hit this >ceiling of 400k pps. Soon as it hits that I get errors galore. In your testing of current, or even RELENG_7, did you ever solve the problem of http://www.freebsd.org/cgi/query-pr.cgi?pr=123621&cat=kern that you also ran into in a previous thread ? I wonder if the generation of all those seemingly bogus RTM_MISS messages is hampering performance. ---Mike From max at love2party.net Sun Jun 29 15:45:15 2008 From: max at love2party.net (Max Laier) Date: Sun Jun 29 15:45:21 2008 Subject: altq on vlan In-Reply-To: <1214651667.267043.71931.nullmailer@cicuta.babolo.ru> References: <1214651667.267043.71931.nullmailer@cicuta.babolo.ru> Message-ID: <200806291743.15021.max@love2party.net> On Saturday 28 June 2008 13:14:27 .@babolo.ru wrote: > [ Charset ISO-8859-1 unsupported, converting... ] > > > On Friday 27 June 2008 18:57:59 Alexandre Biancalana wrote: > > > On 6/27/08, Max Laier wrote: > > > > You don't need a patch at all. What you do is: Queue on the > > > > physical interface, classify on the vlan interface. It is broken > > > > to allow ALTQ on a virtual interface if you can do it otherwise. > > > > > > > > in pf.conf speak: > > > > > > > > If you have "ifconfig vlanX vlandev bge0 ..." > > > > > > > > altq on bge0 .... queue { vlan0, vlan1, ... } > > > > queue vlan0 ... { vlan0_foo, vlan0_bar, ... } > > > > queue vlan0_foo > > > > queue vlan0_bar > > > > ... > > > > > > > > pass on vlanX ... queue vlanX_foobar > > > > > > > > And there you go. No patch - whatsoever - required here. > > > > > > But the patch simplify the cases where you need one queue per vlan. > > > > NO! It is just wrong! There is no relation between vlan queues on > > the same physical interface and thus you can't guarantee anything! > > Can we please stop with this nonsense and not bring up the patch > > every other month. > > Remember vlan anoter end. > > Vlan queues on the same physical interface has sense. > > Let see typical vlan use: > +--------+ 100M untagged vlan1 > | |--------------.. > +---------+ | | 100M untagged vlan2 > 1G | | 1G tagged | |---------------- > --------+ FreeBSD +------------+ switch | 100M untagged vlan3 > | | | |--------------.. > +---------+ | | 100M untagged vlanN > | |--------------- > +--------+ > > There is noting interesting in common queue on 1G physical interface, > the only right queues are that on vlans when number of > vlans < 10. > > More of that, sum traffic on 1G tagged intervace is limited > by incoming traffic from 1G external interface and > so common queue on 1G tagged interface is not > interesting even when number of vlans > 10. Sorry, but you are completely off track here. If you use one queue per vlan one vlan can easily DoS the rest, because once a packet has passed the queue in the vlan it falls into a common queue with all the others and - as you correctly point out - there is no guarantee that a 1G interface can really sent at 1G all the time. The vlan queues, however, will not get any feedback from the parent about it's real send speed. E.g. a vlan sending *a lot* of tiny packets will dominate the 1G link and thus DoS any other vlan that sends big packets. This you can prevent with a common queue. Now please ... let this die, it's stupid! -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From paul at gtcomm.net Sun Jun 29 16:46:34 2008 From: paul at gtcomm.net (Paul) Date: Sun Jun 29 16:46:37 2008 Subject: Freebsd IP Forwarding performance (question, and some info) [7-stable, current, em, smp] In-Reply-To: <200806291539.m5TFdvCO075285@lava.sentex.ca> References: <4867420D.7090406@gtcomm.net> <200806291539.m5TFdvCO075285@lava.sentex.ca> Message-ID: <4867BCE3.2000909@gtcomm.net> [RTM_MISS information added] I have noticed something weird.. It doesn't generate the RTM_MISS with all traffic... Check this out.. flooding packets through the router 11:29:56.147177 IP (tos 0x0, ttl 255, id 51487, offset 0, flags [none], proto TCP (6), length 40) 87.42.160.8.8195 > 10.3.9.50.623: ., cksum 0x999e (incorrect (-> 0xb7e6), 2714784062:2714784062(0) ack 1638282847 win 16384 11:29:56.147182 IP (tos 0x0, ttl 255, id 22197, offset 0, flags [none], proto TCP (6), length 40) 43.253.49.61.13857 > 10.3.9.50.6232: ., cksum 0x51b4 (incorrect (-> 0xeb52), 2685378913:2685378913(0) ack 3576016642 win 16384 11:29:56.147186 IP (tos 0x0, ttl 255, id 19160, offset 0, flags [none], proto TCP (6), length 40) 148.198.237.1.31784 > 10.3.9.50.63: ., cksum 0x7d2b (incorrect (-> 0xcedf), 2790811715:2790811715(0) ack 3733955172 win 16384 11:29:56.147190 IP (tos 0x0, ttl 255, id 45483, offset 0, flags [none], proto TCP (6), length 40) 50.140.153.13.23035 > 10.3.9.50.324: ., cksum 0x5e56 (incorrect (-> 0xdb81), 2403102209:2403102209(0) ack 923149825 win 16384 11:29:56.147194 IP (tos 0x0, ttl 255, id 53653, offset 0, flags [none], proto TCP (6), length 40) 215.20.25.100.18066 > 10.3.9.50.6232: ., cksum 0x592b (incorrect (-> 0x9f26), 3678810149:3678810149(0) ack 916597768 win 16384 11:29:56.147198 IP (tos 0x0, ttl 255, id 25330, offset 0, flags [none], proto TCP (6), length 40) 30.216.125.43.23715 > 10.3.9.50.5325: ., cksum 0x7d62 (incorrect (-> 0xdbb8), 4058239037:4058239037(0) ack 1225812033 win 16384 11:29:56.147210 IP (tos 0x0, ttl 255, id 56031, offset 0, flags [none], proto TCP (6), length 40) 92.202.56.54.1180 > 10.3.9.50.623: ., cksum 0x45fb (incorrect (-> 0xc35d), 1051146817:1051146817(0) ack 1914442290 win 16384 11:29:56.147214 IP (tos 0x0, ttl 255, id 17414, offset 0, flags [none], proto TCP (6), length 40) 243.139.107.120.22763 > 10.3.9.50.63: ., cksum 0x3f12 (incorrect (-> 0x983d), 343363109:343363109(0) ack 2790458180 win 16384 11:29:56.147219 IP (tos 0x0, ttl 255, id 15785, offset 0, flags [none], proto TCP (6), length 40) 193.30.160.14.19071 > 10.3.9.50.324: ., cksum 0x0021 (incorrect (-> 0x3f33), 3909194617:3909194617(0) ack 1335272554 win 16384 11:29:56.147223 IP (tos 0x0, ttl 255, id 36379, offset 0, flags [none], proto TCP (6), length 40) 93.46.193.34.22779 > 10.3.9.50.5325: ., cksum 0x2f95 (incorrect (-> 0x2fb6), 1506935083:1506935083(0) ack 2882181640 win 16384 11:29:56.147228 IP (tos 0x0, ttl 255, id 43639, offset 0, flags [none], proto TCP (6), length 40) 50.78.186.1.1437 > 10.3.9.50.623: ., cksum 0xba44 (incorrect (-> 0xe9d9), 3585077271:3585077271(0) ack 1754157076 win 16384 11:29:56.147232 IP (tos 0x0, ttl 255, id 31282, offset 0, flags [none], proto TCP (6), length 40) 230.61.232.98.9799 > 10.3.9.50.6232: ., cksum 0xe26a (incorrect (-> 0x9caf), 2184338509:2184338509(0) ack 1881236495 win 16384 11:29:56.147242 IP (tos 0x0, ttl 255, id 18266, offset 0, flags [none], proto TCP (6), length 40) 185.133.224.35.18694 > 10.3.9.50.63: ., cksum 0x5bb9 (incorrect (-> 0x3e24), 1265308989:1265308989(0) ack 898540886 win 16384 11:29:56.147247 IP (tos 0x0, ttl 255, id 63295, offset 0, flags [none], proto TCP (6), length 40) 60.149.107.97.14907 > 10.3.9.50.324: ., cksum 0x75ac (incorrect (-> 0xd165), 680418413:680418413(0) ack 1399770970 win 16384 11:29:56.147264 IP (tos 0x0, ttl 255, id 44265, offset 0, flags [none], proto TCP (6), length 40) 226.37.11.125.16380 > 10.3.9.50.5325: ., cksum 0xb763 (incorrect (-> 0x2d10), 1640245563:1640245563(0) ack 3534655349 win 16384 11:29:56.147276 IP (tos 0x0, ttl 255, id 62142, offset 0, flags [none], proto TCP (6), length 40) 76.66.176.108.8173 > 10.3.9.50.623: ., cksum 0xf66b (incorrect (-> 0xadcf), 1200243821:1200243821(0) ack 398846984 win 16384 11:29:56.147281 IP (tos 0x0, ttl 255, id 60663, offset 0, flags [none], proto TCP (6), length 40) 241.35.125.100.4600 > 10.3.9.50.324: ., cksum 0x7299 (incorrect (-> 0x63e8), 4145462333:4145462333(0) ack 1113096518 win 16384 11:29:56.147286 IP (tos 0x0, ttl 255, id 55417, offset 0, flags [none], proto TCP (6), length 40) 152.7.87.5.14990 > 10.3.9.50.6232: ., cksum 0xd955 (incorrect (-> 0xcfc1), 892720934:892720934(0) ack 1334374150 win 16384 ^C11:29:56.147290 IP (tos 0x0, ttl 255, id 29468, offset 0, flags [none], proto TCP (6), length 40) 246.253.188.115.23425 > 10.3.9.50.63: ., cksum 0xf14e (incorrect (-> 0xcaa4), 1030196069:1030196069(0) ack 2661620567 win 16384 these generate RTM_MISS for what looks like every packet : got message of size 160 on Sun Jun 29 11:31:04 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default got message of size 160 on Sun Jun 29 11:31:04 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default got message of size 160 on Sun Jun 29 11:31:04 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default got message of size 160 on Sun Jun 29 11:31:04 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default got message of size 160 on Sun Jun 29 11:31:04 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default got message of size 160 on Sun Jun 29 11:31:04 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default got message of size 160 on Sun Jun 29 11:31:04 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default And then these packets: 11:32:50.540714 IP (tos 0x0, ttl 128, id 60717, offset 0, flags [DF], proto TCP (6), length 48) 199.253.132.217.1145 > 10.3.9.50.1230: S, cksum 0xe22a (correct), 2254729531:2254729531(0) win 16384 11:32:50.540719 IP (tos 0x0, ttl 128, id 29798, offset 0, flags [DF], proto TCP (6), length 48) 128.201.66.139.1074 > 10.3.9.50.1076: S, cksum 0xbc56 (correct), 699104812:699104812(0) win 16384 11:32:50.540737 IP (tos 0x0, ttl 128, id 24548, offset 0, flags [DF], proto TCP (6), length 48) 64.6.56.150.1137 > 10.3.9.50.1065: S, cksum 0x3d9f (correct), 3231494262:3231494262(0) win 16384 11:32:50.540742 IP (tos 0x0, ttl 128, id 24872, offset 0, flags [DF], proto TCP (6), length 48) 209.236.188.202.1119 > 10.3.9.50.1137: S, cksum 0xb4bb (correct), 3403159757:3403159757(0) win 16384 11:32:50.540746 IP (tos 0x0, ttl 128, id 7860, offset 0, flags [DF], proto TCP (6), length 48) 193.42.23.202.1147 > 10.3.9.50.1047: S, cksum 0x7900 (correct), 2067225130:2067225130(0) win 16384 11:32:50.540751 IP (tos 0x0, ttl 128, id 6369, offset 0, flags [DF], proto TCP (6), length 48) 198.222.98.165.1070 > 10.3.9.50.1197: S, cksum 0x8245 (correct), 1566580196:1566580196(0) win 16384 11:32:50.540759 IP (tos 0x0, ttl 128, id 29494, offset 0, flags [DF], proto TCP (6), length 48) 194.32.233.216.1217 > 10.3.9.50.1035: S, cksum 0x0036 (correct), 608655014:608655014(0) win 16384 11:32:50.540772 IP (tos 0x0, ttl 128, id 57975, offset 0, flags [DF], proto TCP (6), length 48) 205.206.20.208.1220 > 10.3.9.50.1232: S, cksum 0x52fc (correct), 1339728095:1339728095(0) win 16384 11:32:50.540777 IP (tos 0x0, ttl 128, id 5551, offset 0, flags [DF], proto TCP (6), length 48) 4.42.66.89.1142 > 10.3.9.50.1178: S, cksum 0xaa57 (correct), 1309337587:1309337587(0) win 16384 11:32:50.540781 IP (tos 0x0, ttl 128, id 64726, offset 0, flags [DF], proto TCP (6), length 48) 208.166.197.140.1052 > 10.3.9.50.1084: S, cksum 0x4dfd (correct), 3514659298:3514659298(0) win 16384 11:32:50.540786 IP (tos 0x0, ttl 128, id 51126, offset 0, flags [DF], proto TCP (6), length 48) 206.67.34.143.1071 > 10.3.9.50.1100: S, cksum 0xbf84 (correct), 3369643581:3369643581(0) win 16384 11:32:50.540790 IP (tos 0x0, ttl 128, id 59088, offset 0, flags [DF], proto TCP (6), length 48) 210.246.25.177.1277 > 10.3.9.50.1205: S, cksum 0x7080 (correct), 1667720615:1667720615(0) win 16384 11:32:50.540795 IP (tos 0x0, ttl 128, id 2326, offset 0, flags [DF], proto TCP (6), length 48) 129.251.33.231.1154 > 10.3.9.50.1195: S, cksum 0x28e5 (correct), 312297303:312297303(0) win 16384 11:32:50.540799 IP (tos 0x0, ttl 128, id 8268, offset 0, flags [DF], proto TCP (6), length 48) 216.84.213.152.1115 > 10.3.9.50.1027: S, cksum 0x7a81 (correct), 2232908292:2232908292(0) win 16384 11:32:50.540803 IP (tos 0x0, ttl 128, id 15857, offset 0, flags [DF], proto TCP (6), length 48) 199.228.246.182.1053 > 10.3.9.50.1053: S, cksum 0xe187 (correct), 376795414:376795414(0) win 16384 11:32:50.540808 IP (tos 0x0, ttl 128, id 33924, offset 0, flags [DF], proto TCP (6), length 48) 128.92.244.80.1060 > 10.3.9.50.1148: S, cksum 0xc4e1 (correct), 2038527032:2038527032(0) win 16384 11:32:50.540812 IP (tos 0x0, ttl 128, id 12114, offset 0, flags [DF], proto TCP (6), length 48) 64.118.145.169.1252 > 10.3.9.50.1148: S, cksum 0xb270 (correct), 3489780214:3489780214(0) win 16384 11:32:50.540816 IP (tos 0x0, ttl 128, id 23385, offset 0, flags [DF], proto TCP (6), length 48) 211.212.238.186.1217 > 10.3.9.50.1083: S, cksum 0xc082 (correct), 2887120836:2887120836(0) win 16384 11:32:50.540821 IP (tos 0x0, ttl 128, id 10979, offset 0, flags [DF], proto TCP (6), length 48) 24.119.38.75.1088 > 10.3.9.50.1027: S, cksum 0xee10 (correct), 3079816000:3079816000(0) win 16384 11:32:50.540830 IP (tos 0x0, ttl 128, id 44562, offset 0, flags [DF], proto TCP (6), length 48) 193.99.52.25.1249 > 10.3.9.50.1047: S, cksum 0x9ef4 (correct), 1263552303:1263552303(0) win 16384 11:32:50.540835 IP (tos 0x0, ttl 128, id 45332, offset 0, flags [DF], proto TCP (6), length 48) 209.168.140.136.1275 > 10.3.9.50.1053: S, cksum 0x03b5 (correct), 1521904180:1521904180(0) win 16384 11:32:50.540840 IP (tos 0x0, ttl 128, id 10244, offset 0, flags [DF], proto TCP (6), length 48) 198.114.145.88.1214 > 10.3.9.50.1083: S, cksum 0x51a9 (correct), 2907689003:2907689003(0) win 16384 I get no RTM MISS. So this absoutely makes no sense?? It should not depend on the TYPE of packet at ALL. It's just forwarding IP regardless of what's in the TCP header so why on earth would the tcp header many any difference to how it routes.. It should not even be looking at the tcp header unless I have a firewall turned on or any type of rules that would filter based on tcp options. Forwarding a packet doesn't require looking at TCP option bits or even TCP port numbers. I suppose it could be checking the mss or trying to calculate checksums but I would prefer it didn't even do that :/ Raw performance is all I care about at this point, I don't even need to use any firewall at all. It's also funny to notice, that tcpdump does not see those packets as TCP.. tcpdump -n -i em0 tcp does not show either of my 'floods' tcpdump -n -i em1 tcp shows my floods tcpdump -n -i em0 shows them all.. and they say TCP ..lol :) Weird I tell ya! So the bottom line is, why do one type of packet generate RTM_MISS and another doesn't? I haven't confirmed this, but I don't think it does it on 7.0-RELEASE, only 7.0-STABLE and CURRENT. I will try and confirm though. Paul Mike Tancsa wrote: > At 04:04 AM 6/29/2008, Paul wrote: >> This is just a question but who can get more than 400k pps forwarding >> performance ? >> I have tested fbsd 6/7/8 so far with many different configs. (all >> using intel pci-ex nic and SMP) >> fbsd 7-stable/8(current) seem to be the fastest and always hit this >> ceiling of 400k pps. Soon as it hits that I get errors galore. > > In your testing of current, or even RELENG_7, did you ever solve the > problem of > > http://www.freebsd.org/cgi/query-pr.cgi?pr=123621&cat=kern > that you also ran into in a previous thread ? I wonder if the > generation of all those seemingly bogus RTM_MISS messages is hampering > performance. > > ---Mike > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From rwatson at FreeBSD.org Sun Jun 29 17:02:50 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Jun 29 17:02:58 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <20080524111715.T64552@fledge.watson.org> References: <20080524111715.T64552@fledge.watson.org> Message-ID: <20080629180126.F90836@fledge.watson.org> On Sat, 24 May 2008, Robert Watson wrote: > Just as a reminder, we've just about reached the one month date before > IFF_NEEDSGIANT drivers are disabled in the build. You can find a > description of the general problem and list of specific drivers below. > > As USB work is on-going, I will *not* disable the USB drivers at this time, > but all other drivers in the list below will be disabled on 26 June. They > will remain in the tree, easily accessible for patch distribution and > re-enabling, until October, when any remaining non-MPSAFE drivers will be > deleted in 8.x. FreeBSD 8.0 will not ship with compatibility shims to > support non-MPSAFE network device drivers. An FYI on the state of things here: in the last month, John has updated a number of device drivers to be MPSAFE, and the USB work remains in-flight. I'm holding fire a bit on disabling IFF_NEEDSGIANT while things settle and I catch up on driver state, and will likely send out an update next week regarding which device drivers remain on the kill list, and generally what the status of this project is. Robert N M Watson Computer Laboratory University of Cambridge > > Robert N M Watson Computer Laboratory University of Cambridge > > ---------- Forwarded message ---------- > Date: Sun, 3 Feb 2008 20:59:05 +0000 (GMT) > From: Robert Watson > To: arch@FreeBSD.org > Subject: 8.0 network stack MPsafety goals (fwd) > > > Only a few days after predicted, this is a reminder that IFF_NEEDSGIANT > network drivers are going to stop working in the forseeable future. Please > review the attached driver list, and if you depend on or care about a > Giant-dependent device driver, take action to make sure it doesn't remain on > the list in a month's time! > > (As far as I'm aware, the list has not changed since my December posting.) > > Robert N M Watson > Computer Laboratory > University of Cambridge > > ---------- Forwarded message ---------- > Date: Mon, 24 Dec 2007 10:43:28 +0000 (GMT) > From: Robert Watson > To: arch@FreeBSD.org > Subject: 8.0 network stack MPsafety goals > > > Dear all: > > With the 7.0 release around the corner, many developers are starting to think > about (and in quite a few cases, work on) their goals for 8.0. One of our > on-going kernel projects has been the elimination of the Giant lock, and that > project has transformed into one of optimizating behavior on increasing > numbers of processors. > > In 7.0, despite the noteworth accomplishment of eliminating debug.mpsasfenet > and conditional network stack Gian acquisition, we were unable to fully > eliminate the IFF_NEEDSGIANT flag, which controls the conditional acquisition > of the Giant lock around non-MPSAFE network device drivers. Primarily these > drivers are aging ISA network device drivers, although there are some > exceptions, such as the USB stack. > > This e-mail proposes the elimination of the IFF_NEEDSGIANT flag and > associated infrastructure in FreeBSD 8.0, meaning that all network device > drivers must be able to operate without the Giant lock (largely the case > already). Remaining drivers using the IFF_NEEDSGIANT flag must either be > updated, or less ideally, removed. I propose the following schedule: > > Date Goals > ---- ----- > 26 Dec 2007 Post proposed schedule for flag and infrastructure removal > Post affected driver list > > 26 Jan 2008 Repost proposed schedule for flag and infrastructure removal > Post updated affected driver list > > 26 Feb 2008 Adjust boot-time printf for affect drivers to generate a loud > warning. > Post updated affected driver list > > 26 May 2008 Post HEADS UP of impending driver disabling > Post updated affected driver list > > 26 Jun 2008 Disable build of all drivers requiring IFF_NEEDSGIANT > Post updated affected driver list > > 26 Sep 2008 Post HEADS up of impending driver removal > Post updated affected driver list > > 26 Oct 2008 Delete source of all drivers requiring IFF_NEEDSGIANT > Remove flag and infrastructure > > Here is a list of potentially affected drivers: > > Name Bus Man page description > --- --- -------------------- > ar ISA/PCI synchronous Digi/Arnet device driver > arl ISA Aironet Arlan 655 wireless network adapter driver > awi PCCARD AMD PCnetMobile IEEE 802.11 PCMCIA wireless network > driver > axe USB ASIX Electronics AX88172 USB Ethernet driver > cdce USB USB Communication Device Class Ethernet driver > cnw PCCARD Netwave AirSurfer wireless network driver > cs ISA/PCCARD Ethernet device driver > cue USB CATC USB-EL1210A USB Ethernet driver > ex ISA/PCCARD Ethernet device driver for the Intel EtherExpress > Pro/10 and Pro/10+ > fe CBUS/ISA/PCCARD Fujitsu MB86960A/MB86965A based Ethernet adapters > ic I2C I2C bus system > ie ISA Ethernet device driver > kue USB Kawasaki LSI KL5KUSB101B USB Ethernet driver > oltr ISA/PCI Olicom Token Ring device driver > plip PPBUS printer port Internet Protocol driver > ppp TTY point to point protocol network interface > ray PCCARD Raytheon Raylink/Webgear Aviator PCCard driver > rue USB RealTek RTL8150 USB to Fast Ethernet controller > driver > rum USB Ralink Technology USB IEEE 802.11a/b/g wireless > network device > sbni ISA/PCI Granch SBNI12 leased line modem driver > sbsh PCI Granch SBNI16 SHDSL modem device driver > sl TTY slip network interface > snc ISA/PCCARD National Semiconductor DP8393X SONIC Ethernet adapter > driver > sr ISA/PCI synchronous RISCom/N2 / WANic 400/405 device driver > udav USB Davicom DM9601 USB Ethernet driver > ural USB Ralink Technology RT2500USB IEEE 802.11 driver > xe PCCARD Xircom PCMCIA Ethernet device driver > zyd USB ZyDAS ZD1211/ZD1211B USB IEEE 802.11b/g wireless > network device > > In some cases, the requirement for Giant is a property of a subsystem the > driver depends on as the driver itself; for example, the tty subsystem for > SLIP and PPP, and the USB subsystem for a number of USB ethernet and wireless > drivers. With most of a year before to go on the proposed schedule, my hope > is that we will have lots of time to address these issues, but wanted to get > a roadmap out from a network protocol stack architecture perspective so that > device driver and subsystem authors could have a schedule in mind. > > FYI, the following drivers also reference IFF_NEEDSGIANT, but only in order > to provide their own conditional MPSAFEty, which can be removed without > affecting device driver functionality (I believe): > > Name Bus Man page description > --- --- -------------------- > ce PCI driver for synchronous Cronyx Tau-PCI/32 WAN adapters > cp PCI driver for synchronous Cronyx Tau-PCI WAN adapters > ctau ISA driver for synchronous Cronyx Tau WAN adapters > cx ISA driver for synchronous/asynchronous Cronyx Sigma WAN > adapters > > Developers and users of the above drivers are heavily encouraged to update > the drivers to remove dependence on Giant, and/or make other contingency > plans. > > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From paul at gtcomm.net Sun Jun 29 18:29:30 2008 From: paul at gtcomm.net (Paul) Date: Sun Jun 29 18:29:34 2008 Subject: Freebsd IP Forwarding performance (question, and some info) [7-stable, current, em, smp] In-Reply-To: <4867BCE3.2000909@gtcomm.net> References: <4867420D.7090406@gtcomm.net> <200806291539.m5TFdvCO075285@lava.sentex.ca> <4867BCE3.2000909@gtcomm.net> Message-ID: <4867D503.6080101@gtcomm.net> Other interesting behavior: netstat -rs hitting up arrow and enter to get repeated views of it: [root@irc-router1 /usr/src/sys/net]# netstat -rs routing: 0 bad routing redirects 0 dynamically created routes 0 new gateways due to redirects 25691 destinations found unreachable 0 uses of a wildcard route 0 routes not in table but not freed [root@router1 /usr/src/sys/net]# netstat -rs routing: 0 bad routing redirects 0 dynamically created routes 0 new gateways due to redirects 27879 destinations found unreachable 0 uses of a wildcard route 0 routes not in table but not freed [root@router1 /usr/src/sys/net]# netstat -rs routing: 0 bad routing redirects 0 dynamically created routes 0 new gateways due to redirects 30256 destinations found unreachable 0 uses of a wildcard route 0 routes not in table but not freed [root@router1 /usr/src/sys/net]# netstat -rs routing: 0 bad routing redirects 0 dynamically created routes 0 new gateways due to redirects 32699 destinations found unreachable 0 uses of a wildcard route 0 routes not in table but not freed [root@router1 /usr/src/sys/net]# netstat -rs routing: 0 bad routing redirects 0 dynamically created routes 0 new gateways due to redirects 4294936832 destinations found unreachable 0 uses of a wildcard route 0 routes not in table but not freed [root@router1 /usr/src/sys/net]# netstat -rs routing: 0 bad routing redirects 0 dynamically created routes 0 new gateways due to redirects 4294941139 destinations found unreachable 0 uses of a wildcard route 0 routes not in table but not freed [root@router1 /usr/src/sys/net]# after 32768 it jumps to close to a 32 bit number limit and then after adding a few more it goes back to zero.. This doesn't happen on 7.0-RELEASE but it happens on 7.0-STABLE and -CURRENT Whatever is generating the RTM_MISS is incrementing this also. There's a lot of differences in the /net dir from release to stable but most are in bridging/gif/lagg etc. Route.c the only difference is -RELEASE +STABLE - rtfree(rt); + RTFREE_LOCKED(rt); Must be generating it from somewhere else? Paul wrote: > > [RTM_MISS information added] > > I have noticed something weird.. It doesn't generate the RTM_MISS with > all traffic... > Check this out.. > flooding packets through the router > 11:29:56.147177 IP (tos 0x0, ttl 255, id 51487, offset 0, flags > [none], proto TCP (6), length 40) 87.42.160.8.8195 > 10.3.9.50.623: ., > cksum 0x999e (incorrect (-> 0xb7e6), 2714784062:2714784062(0) ack > 1638282847 win 16384 > 11:29:56.147182 IP (tos 0x0, ttl 255, id 22197, offset 0, flags > [none], proto TCP (6), length 40) 43.253.49.61.13857 > 10.3.9.50.6232: > ., cksum 0x51b4 (incorrect (-> 0xeb52), 2685378913:2685378913(0) ack > 3576016642 win 16384 > 11:29:56.147186 IP (tos 0x0, ttl 255, id 19160, offset 0, flags > [none], proto TCP (6), length 40) 148.198.237.1.31784 > 10.3.9.50.63: > ., cksum 0x7d2b (incorrect (-> 0xcedf), 2790811715:2790811715(0) ack > 3733955172 win 16384 > 11:29:56.147190 IP (tos 0x0, ttl 255, id 45483, offset 0, flags > [none], proto TCP (6), length 40) 50.140.153.13.23035 > 10.3.9.50.324: > ., cksum 0x5e56 (incorrect (-> 0xdb81), 2403102209:2403102209(0) ack > 923149825 win 16384 > 11:29:56.147194 IP (tos 0x0, ttl 255, id 53653, offset 0, flags > [none], proto TCP (6), length 40) 215.20.25.100.18066 > > 10.3.9.50.6232: ., cksum 0x592b (incorrect (-> 0x9f26), > 3678810149:3678810149(0) ack 916597768 win 16384 > 11:29:56.147198 IP (tos 0x0, ttl 255, id 25330, offset 0, flags > [none], proto TCP (6), length 40) 30.216.125.43.23715 > > 10.3.9.50.5325: ., cksum 0x7d62 (incorrect (-> 0xdbb8), > 4058239037:4058239037(0) ack 1225812033 win 16384 > 11:29:56.147210 IP (tos 0x0, ttl 255, id 56031, offset 0, flags > [none], proto TCP (6), length 40) 92.202.56.54.1180 > 10.3.9.50.623: > ., cksum 0x45fb (incorrect (-> 0xc35d), 1051146817:1051146817(0) ack > 1914442290 win 16384 > 11:29:56.147214 IP (tos 0x0, ttl 255, id 17414, offset 0, flags > [none], proto TCP (6), length 40) 243.139.107.120.22763 > > 10.3.9.50.63: ., cksum 0x3f12 (incorrect (-> 0x983d), > 343363109:343363109(0) ack 2790458180 win 16384 > 11:29:56.147219 IP (tos 0x0, ttl 255, id 15785, offset 0, flags > [none], proto TCP (6), length 40) 193.30.160.14.19071 > 10.3.9.50.324: > ., cksum 0x0021 (incorrect (-> 0x3f33), 3909194617:3909194617(0) ack > 1335272554 win 16384 > 11:29:56.147223 IP (tos 0x0, ttl 255, id 36379, offset 0, flags > [none], proto TCP (6), length 40) 93.46.193.34.22779 > 10.3.9.50.5325: > ., cksum 0x2f95 (incorrect (-> 0x2fb6), 1506935083:1506935083(0) ack > 2882181640 win 16384 > 11:29:56.147228 IP (tos 0x0, ttl 255, id 43639, offset 0, flags > [none], proto TCP (6), length 40) 50.78.186.1.1437 > 10.3.9.50.623: ., > cksum 0xba44 (incorrect (-> 0xe9d9), 3585077271:3585077271(0) ack > 1754157076 win 16384 > 11:29:56.147232 IP (tos 0x0, ttl 255, id 31282, offset 0, flags > [none], proto TCP (6), length 40) 230.61.232.98.9799 > 10.3.9.50.6232: > ., cksum 0xe26a (incorrect (-> 0x9caf), 2184338509:2184338509(0) ack > 1881236495 win 16384 > 11:29:56.147242 IP (tos 0x0, ttl 255, id 18266, offset 0, flags > [none], proto TCP (6), length 40) 185.133.224.35.18694 > 10.3.9.50.63: > ., cksum 0x5bb9 (incorrect (-> 0x3e24), 1265308989:1265308989(0) ack > 898540886 win 16384 > 11:29:56.147247 IP (tos 0x0, ttl 255, id 63295, offset 0, flags > [none], proto TCP (6), length 40) 60.149.107.97.14907 > 10.3.9.50.324: > ., cksum 0x75ac (incorrect (-> 0xd165), 680418413:680418413(0) ack > 1399770970 win 16384 > 11:29:56.147264 IP (tos 0x0, ttl 255, id 44265, offset 0, flags > [none], proto TCP (6), length 40) 226.37.11.125.16380 > > 10.3.9.50.5325: ., cksum 0xb763 (incorrect (-> 0x2d10), > 1640245563:1640245563(0) ack 3534655349 win 16384 > 11:29:56.147276 IP (tos 0x0, ttl 255, id 62142, offset 0, flags > [none], proto TCP (6), length 40) 76.66.176.108.8173 > 10.3.9.50.623: > ., cksum 0xf66b (incorrect (-> 0xadcf), 1200243821:1200243821(0) ack > 398846984 win 16384 > 11:29:56.147281 IP (tos 0x0, ttl 255, id 60663, offset 0, flags > [none], proto TCP (6), length 40) 241.35.125.100.4600 > 10.3.9.50.324: > ., cksum 0x7299 (incorrect (-> 0x63e8), 4145462333:4145462333(0) ack > 1113096518 win 16384 > 11:29:56.147286 IP (tos 0x0, ttl 255, id 55417, offset 0, flags > [none], proto TCP (6), length 40) 152.7.87.5.14990 > 10.3.9.50.6232: > ., cksum 0xd955 (incorrect (-> 0xcfc1), 892720934:892720934(0) ack > 1334374150 win 16384 > ^C11:29:56.147290 IP (tos 0x0, ttl 255, id 29468, offset 0, flags > [none], proto TCP (6), length 40) 246.253.188.115.23425 > > 10.3.9.50.63: ., cksum 0xf14e (incorrect (-> 0xcaa4), > 1030196069:1030196069(0) ack 2661620567 win 16384 > > these generate RTM_MISS for what looks like every packet : > > got message of size 160 on Sun Jun 29 11:31:04 2008 > RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno > 0, flags: > locks: inits: > sockaddrs: > default > > got message of size 160 on Sun Jun 29 11:31:04 2008 > RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno > 0, flags: > locks: inits: > sockaddrs: > default > > got message of size 160 on Sun Jun 29 11:31:04 2008 > RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno > 0, flags: > locks: inits: > sockaddrs: > default > > got message of size 160 on Sun Jun 29 11:31:04 2008 > RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno > 0, flags: > locks: inits: > sockaddrs: > default > > got message of size 160 on Sun Jun 29 11:31:04 2008 > RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno > 0, flags: > locks: inits: > sockaddrs: > default > > got message of size 160 on Sun Jun 29 11:31:04 2008 > RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno > 0, flags: > locks: inits: > sockaddrs: > default > > got message of size 160 on Sun Jun 29 11:31:04 2008 > RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno > 0, flags: > locks: inits: > sockaddrs: > default > > > And then these packets: > > 11:32:50.540714 IP (tos 0x0, ttl 128, id 60717, offset 0, flags [DF], > proto TCP (6), length 48) 199.253.132.217.1145 > 10.3.9.50.1230: S, > cksum 0xe22a (correct), 2254729531:2254729531(0) win 16384 1460,nop,[bad opt]> > 11:32:50.540719 IP (tos 0x0, ttl 128, id 29798, offset 0, flags [DF], > proto TCP (6), length 48) 128.201.66.139.1074 > 10.3.9.50.1076: S, > cksum 0xbc56 (correct), 699104812:699104812(0) win 16384 1460,nop,[bad opt]> > 11:32:50.540737 IP (tos 0x0, ttl 128, id 24548, offset 0, flags [DF], > proto TCP (6), length 48) 64.6.56.150.1137 > 10.3.9.50.1065: S, cksum > 0x3d9f (correct), 3231494262:3231494262(0) win 16384 1460,nop,[bad opt]> > 11:32:50.540742 IP (tos 0x0, ttl 128, id 24872, offset 0, flags [DF], > proto TCP (6), length 48) 209.236.188.202.1119 > 10.3.9.50.1137: S, > cksum 0xb4bb (correct), 3403159757:3403159757(0) win 16384 1460,nop,[bad opt]> > 11:32:50.540746 IP (tos 0x0, ttl 128, id 7860, offset 0, flags [DF], > proto TCP (6), length 48) 193.42.23.202.1147 > 10.3.9.50.1047: S, > cksum 0x7900 (correct), 2067225130:2067225130(0) win 16384 1460,nop,[bad opt]> > 11:32:50.540751 IP (tos 0x0, ttl 128, id 6369, offset 0, flags [DF], > proto TCP (6), length 48) 198.222.98.165.1070 > 10.3.9.50.1197: S, > cksum 0x8245 (correct), 1566580196:1566580196(0) win 16384 1460,nop,[bad opt]> > 11:32:50.540759 IP (tos 0x0, ttl 128, id 29494, offset 0, flags [DF], > proto TCP (6), length 48) 194.32.233.216.1217 > 10.3.9.50.1035: S, > cksum 0x0036 (correct), 608655014:608655014(0) win 16384 1460,nop,[bad opt]> > 11:32:50.540772 IP (tos 0x0, ttl 128, id 57975, offset 0, flags [DF], > proto TCP (6), length 48) 205.206.20.208.1220 > 10.3.9.50.1232: S, > cksum 0x52fc (correct), 1339728095:1339728095(0) win 16384 1460,nop,[bad opt]> > 11:32:50.540777 IP (tos 0x0, ttl 128, id 5551, offset 0, flags [DF], > proto TCP (6), length 48) 4.42.66.89.1142 > 10.3.9.50.1178: S, cksum > 0xaa57 (correct), 1309337587:1309337587(0) win 16384 1460,nop,[bad opt]> > 11:32:50.540781 IP (tos 0x0, ttl 128, id 64726, offset 0, flags [DF], > proto TCP (6), length 48) 208.166.197.140.1052 > 10.3.9.50.1084: S, > cksum 0x4dfd (correct), 3514659298:3514659298(0) win 16384 1460,nop,[bad opt]> > 11:32:50.540786 IP (tos 0x0, ttl 128, id 51126, offset 0, flags [DF], > proto TCP (6), length 48) 206.67.34.143.1071 > 10.3.9.50.1100: S, > cksum 0xbf84 (correct), 3369643581:3369643581(0) win 16384 1460,nop,[bad opt]> > 11:32:50.540790 IP (tos 0x0, ttl 128, id 59088, offset 0, flags [DF], > proto TCP (6), length 48) 210.246.25.177.1277 > 10.3.9.50.1205: S, > cksum 0x7080 (correct), 1667720615:1667720615(0) win 16384 1460,nop,[bad opt]> > 11:32:50.540795 IP (tos 0x0, ttl 128, id 2326, offset 0, flags [DF], > proto TCP (6), length 48) 129.251.33.231.1154 > 10.3.9.50.1195: S, > cksum 0x28e5 (correct), 312297303:312297303(0) win 16384 1460,nop,[bad opt]> > 11:32:50.540799 IP (tos 0x0, ttl 128, id 8268, offset 0, flags [DF], > proto TCP (6), length 48) 216.84.213.152.1115 > 10.3.9.50.1027: S, > cksum 0x7a81 (correct), 2232908292:2232908292(0) win 16384 1460,nop,[bad opt]> > 11:32:50.540803 IP (tos 0x0, ttl 128, id 15857, offset 0, flags [DF], > proto TCP (6), length 48) 199.228.246.182.1053 > 10.3.9.50.1053: S, > cksum 0xe187 (correct), 376795414:376795414(0) win 16384 1460,nop,[bad opt]> > 11:32:50.540808 IP (tos 0x0, ttl 128, id 33924, offset 0, flags [DF], > proto TCP (6), length 48) 128.92.244.80.1060 > 10.3.9.50.1148: S, > cksum 0xc4e1 (correct), 2038527032:2038527032(0) win 16384 1460,nop,[bad opt]> > 11:32:50.540812 IP (tos 0x0, ttl 128, id 12114, offset 0, flags [DF], > proto TCP (6), length 48) 64.118.145.169.1252 > 10.3.9.50.1148: S, > cksum 0xb270 (correct), 3489780214:3489780214(0) win 16384 1460,nop,[bad opt]> > 11:32:50.540816 IP (tos 0x0, ttl 128, id 23385, offset 0, flags [DF], > proto TCP (6), length 48) 211.212.238.186.1217 > 10.3.9.50.1083: S, > cksum 0xc082 (correct), 2887120836:2887120836(0) win 16384 1460,nop,[bad opt]> > 11:32:50.540821 IP (tos 0x0, ttl 128, id 10979, offset 0, flags [DF], > proto TCP (6), length 48) 24.119.38.75.1088 > 10.3.9.50.1027: S, cksum > 0xee10 (correct), 3079816000:3079816000(0) win 16384 1460,nop,[bad opt]> > 11:32:50.540830 IP (tos 0x0, ttl 128, id 44562, offset 0, flags [DF], > proto TCP (6), length 48) 193.99.52.25.1249 > 10.3.9.50.1047: S, cksum > 0x9ef4 (correct), 1263552303:1263552303(0) win 16384 1460,nop,[bad opt]> > 11:32:50.540835 IP (tos 0x0, ttl 128, id 45332, offset 0, flags [DF], > proto TCP (6), length 48) 209.168.140.136.1275 > 10.3.9.50.1053: S, > cksum 0x03b5 (correct), 1521904180:1521904180(0) win 16384 1460,nop,[bad opt]> > 11:32:50.540840 IP (tos 0x0, ttl 128, id 10244, offset 0, flags [DF], > proto TCP (6), length 48) 198.114.145.88.1214 > 10.3.9.50.1083: S, > cksum 0x51a9 (correct), 2907689003:2907689003(0) win 16384 1460,nop,[bad opt]> > > I get no RTM MISS. So this absoutely makes no sense?? It should not > depend on the TYPE of packet at ALL. It's just forwarding IP > regardless of what's in the TCP header so why on earth would the tcp > header many any difference to how it routes.. It should not even be > looking at the tcp header unless I have a firewall turned on or any > type of rules that would filter based on tcp options. Forwarding a > packet doesn't require looking at TCP option bits or even TCP port > numbers. I suppose it could be checking the mss or trying to > calculate checksums but I would prefer it didn't even do that :/ Raw > performance is all I care about at this point, I don't even need to > use any firewall at all. > It's also funny to notice, that tcpdump does not see those packets as > TCP.. > tcpdump -n -i em0 tcp > does not show either of my 'floods' > tcpdump -n -i em1 tcp > shows my floods > tcpdump -n -i em0 > shows them all.. and they say TCP ..lol :) Weird I tell ya! > > So the bottom line is, why do one type of packet generate RTM_MISS and > another doesn't? > I haven't confirmed this, but I don't think it does it on 7.0-RELEASE, > only 7.0-STABLE and CURRENT. > I will try and confirm though. > > Paul > > > > Mike Tancsa wrote: >> At 04:04 AM 6/29/2008, Paul wrote: >>> This is just a question but who can get more than 400k pps >>> forwarding performance ? >>> I have tested fbsd 6/7/8 so far with many different configs. (all >>> using intel pci-ex nic and SMP) >>> fbsd 7-stable/8(current) seem to be the fastest and always hit this >>> ceiling of 400k pps. Soon as it hits that I get errors galore. >> >> In your testing of current, or even RELENG_7, did you ever solve the >> problem of >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=123621&cat=kern >> that you also ran into in a previous thread ? I wonder if the >> generation of all those seemingly bogus RTM_MISS messages is >> hampering performance. >> >> ---Mike >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From mike at sentex.net Sun Jun 29 18:39:56 2008 From: mike at sentex.net (Mike Tancsa) Date: Sun Jun 29 18:40:00 2008 Subject: Freebsd IP Forwarding performance (question, and some info) [7-stable, current, em, smp] In-Reply-To: <4867BCE3.2000909@gtcomm.net> References: <4867420D.7090406@gtcomm.net> <200806291539.m5TFdvCO075285@lava.sentex.ca> <4867BCE3.2000909@gtcomm.net> Message-ID: <200806291839.m5TIdrFs075883@lava.sentex.ca> At 12:48 PM 6/29/2008, Paul wrote: >[RTM_MISS information added] > >I have noticed something weird.. It doesn't generate the RTM_MISS >with all traffic... Does turning off tso and or chksum offload make a difference ? ---Mike From julian at elischer.org Sun Jun 29 20:06:46 2008 From: julian at elischer.org (Julian Elischer) Date: Sun Jun 29 20:06:51 2008 Subject: FreeBSD NAT-T patch integration In-Reply-To: <20080629005756.4BA1B4500E@ptavv.es.net> References: <20080629005756.4BA1B4500E@ptavv.es.net> Message-ID: <4867EB67.1020900@elischer.org> Kevin Oberman wrote: >> Date: Sat, 28 Jun 2008 23:13:00 +0200 >> From: VANHULLEBUS Yvan >> Sender: owner-freebsd-net@freebsd.org >> >> On Fri, Jun 27, 2008 at 11:06:19AM -0400, George V. Neville-Neil wrote: >>> At Thu, 26 Jun 2008 12:56:41 -0700, >>> julian wrote: >>>> I'm planning on committing it unless someone can provide a reason not >>>> to, as I've seen it working, needed it, and have not seen any bad >>>> byproducts. >>>> >>> I'd be interested to know how you tested it. >> I can answer that question: >> >> - We do have "non regression tests", which test every night that "it >> works" in a "good scenario", with a peers who runs quite the same >> kernel, with the same patch and the same userland. >> >> We do also some "bad scenarios" tests, but not as much as I would like >> actually (it's much more complex to test). >> >> >> - We do have THOUSANDS of customers who use it for years now. And >> customers are really not well nown to always generate "good >> scenarios".... >> >> Customers can do some mistakes, can use some very strange stacks for >> peers, can use a lots of other IPSec stacks for peers, can have *a >> lot* of peers (of course with various implementations, configurations, >> NAT or not, etc...) for the same gate, etc... >> >> And how do I know that it works ? >> Well, when it doesn't work, I do know it, quite quickly most of the >> time ! >> >> As Bjoern said in another mail, we're talking about security. >> Security is my job, security is what we provide to our customers, and >> even if some of our customers just don't understant what they do, some >> others do *really* understand things, and do *really* test devices, >> check if it works, and quickly reports us problems (and ask for quick >> solutions). >> >> >> >>> NAT-T and IPsec are >>> non-trivial protocols/subsystems that can have far reaching impacts on >>> the network stack. >> Yes. >> >> >>> Also, are you planning to maintain it after >>> committing it? >> I plan to do that. >> >> >>> The biggest problem with NAT-T hasn't been the code, >>> it's been that the author, >> Really ? >> >> >>> who is doing a great job on the code, >> Thank you.... >> >> >>> has >>> been too busy to maintain it anywhere but at work. >> That is not exact, and I'm really sorry if you understood that after >> our discussion at the last EuroBSDCon. >> >> First, you can check that I'm sending this mail on saturday evening, >> which is out of my work hours :-) >> >> Then I can for example confirm that I did the whole migration from >> RELENG6 to RELENG7 on my free time, just because I needed a working >> FreeBSD7 + NAT-T patch at home before I've been asked to do it at >> work. >> >> Yes, I'm doing most of IPSec / NAT-T stuff at work, but it is mainly >> because I'm *paid* for that !!! >> Let me tell this again: working on FreeBSD's IPSec stack (and on >> NAT-T, of course, adn also on ipsec-tools) is a part of my job. >> >> What I told you some months ago is that there are some things that I >> cannot really do at work, because it takes lot of time and because >> those things are more "code cleanups" than "new features" (we were >> talking about PFKey V2 cleanups related to NAT-T ports). >> >> >> And if I did not spend that time to do that cleanup, that's not >> because I don't have such time, that's because I was starting to >> fear that the patch may be never commited, so I wasn't sure to want to >> continue spending lots of time on a patch "for nothing". >> >> If Bjoern or you told me some months ago "do that cleanup and we'll >> commit the patch", it would already have been done, and we would have >> *all* saved some time ! >> >> >> And yes, I do also spend some parts of my free time on things that are >> not related to FreeBSD's IPSec (and, to be completely honest, on >> things which are not related at all to computers....). >> >> >> >>> That is not a slam >>> on the person or the code, I have the highest respect for both, but it >>> reflects and important reality of the situation. >> I feel that "the reality of the situation" is that FreeBSD's IPSec >> stack needs more people *working on it*, not more people wasting their >> time about why some work should or shouldn't be reported. >> >> That is not a slam on the persons who are still working on the IPsec >> stack, I have the highest respect for them, but it reflects an >> important reality of the situation... >> >> >> >>> Unless you're >>> stepping up to maintain it as well as commit it I think it should not >>> be committed. I know the Bjoern has been working hard to pick up the >>> IPsec stuff in his free time, and I value his input on this subject >>> quite a bit. >> You said it yourself: actually, FreeBSD's IPSec stack is just >> maintained by one person, which worked hard on it, which does a great >> job on it, but which can spend only some parts of his free time on it. >> >> That is a problem. >> Of course, the solution can NOT be to ask Bjoern to spend more time on >> it (well, Bjoern, do that if you want :-). >> >> The only other solution I see is to find a way to help people who want >> to help you.... > > Thanks so much to folks like Bjorn and Yvan who spend the time to do > some tough jobs like dealing with IPsec and being stubborn about > committing things to security tools without very careful audit. > > In case you missed it, IPsec is about security, not features. And, in > case you have never been involved in real security or crypto, security > is really, really hard. > > No, no, it's much harder than that! > > While I'd love to see NAT-T, until someone who knows EXACTLY what the > IPsec and NAT-T code is doing and what it is required to do can do the > line by line review, it should NOT be committed. so, you don't think that this is rather a slap in teh face of the person who wrote this, and who's job is to do security related work in a proffesional context? "This requires a someone who knows what they are doing, and despite the fact that you do this for a living, I arbitrarlily exclude you from that category"? From oberman at es.net Sun Jun 29 20:32:39 2008 From: oberman at es.net (Kevin Oberman) Date: Sun Jun 29 20:32:44 2008 Subject: FreeBSD NAT-T patch integration In-Reply-To: Your message of "Sun, 29 Jun 2008 13:07:03 PDT." <4867EB67.1020900@elischer.org> Message-ID: <20080629203236.78F6245047@ptavv.es.net> > Date: Sun, 29 Jun 2008 13:07:03 -0700 > From: Julian Elischer > Sender: owner-freebsd-net@freebsd.org > > Kevin Oberman wrote: > >> Date: Sat, 28 Jun 2008 23:13:00 +0200 > >> From: VANHULLEBUS Yvan > >> Sender: owner-freebsd-net@freebsd.org > >> > >> On Fri, Jun 27, 2008 at 11:06:19AM -0400, George V. Neville-Neil wrote: > >>> At Thu, 26 Jun 2008 12:56:41 -0700, > >>> julian wrote: > >>>> I'm planning on committing it unless someone can provide a reason not > >>>> to, as I've seen it working, needed it, and have not seen any bad > >>>> byproducts. > >>>> > >>> I'd be interested to know how you tested it. > >> I can answer that question: > >> > >> - We do have "non regression tests", which test every night that "it > >> works" in a "good scenario", with a peers who runs quite the same > >> kernel, with the same patch and the same userland. > >> > >> We do also some "bad scenarios" tests, but not as much as I would like > >> actually (it's much more complex to test). > >> > >> > >> - We do have THOUSANDS of customers who use it for years now. And > >> customers are really not well nown to always generate "good > >> scenarios".... > >> > >> Customers can do some mistakes, can use some very strange stacks for > >> peers, can use a lots of other IPSec stacks for peers, can have *a > >> lot* of peers (of course with various implementations, configurations, > >> NAT or not, etc...) for the same gate, etc... > >> > >> And how do I know that it works ? > >> Well, when it doesn't work, I do know it, quite quickly most of the > >> time ! > >> > >> As Bjoern said in another mail, we're talking about security. > >> Security is my job, security is what we provide to our customers, and > >> even if some of our customers just don't understant what they do, some > >> others do *really* understand things, and do *really* test devices, > >> check if it works, and quickly reports us problems (and ask for quick > >> solutions). > >> > >> > >> > >>> NAT-T and IPsec are > >>> non-trivial protocols/subsystems that can have far reaching impacts on > >>> the network stack. > >> Yes. > >> > >> > >>> Also, are you planning to maintain it after > >>> committing it? > >> I plan to do that. > >> > >> > >>> The biggest problem with NAT-T hasn't been the code, > >>> it's been that the author, > >> Really ? > >> > >> > >>> who is doing a great job on the code, > >> Thank you.... > >> > >> > >>> has > >>> been too busy to maintain it anywhere but at work. > >> That is not exact, and I'm really sorry if you understood that after > >> our discussion at the last EuroBSDCon. > >> > >> First, you can check that I'm sending this mail on saturday evening, > >> which is out of my work hours :-) > >> > >> Then I can for example confirm that I did the whole migration from > >> RELENG6 to RELENG7 on my free time, just because I needed a working > >> FreeBSD7 + NAT-T patch at home before I've been asked to do it at > >> work. > >> > >> Yes, I'm doing most of IPSec / NAT-T stuff at work, but it is mainly > >> because I'm *paid* for that !!! > >> Let me tell this again: working on FreeBSD's IPSec stack (and on > >> NAT-T, of course, adn also on ipsec-tools) is a part of my job. > >> > >> What I told you some months ago is that there are some things that I > >> cannot really do at work, because it takes lot of time and because > >> those things are more "code cleanups" than "new features" (we were > >> talking about PFKey V2 cleanups related to NAT-T ports). > >> > >> > >> And if I did not spend that time to do that cleanup, that's not > >> because I don't have such time, that's because I was starting to > >> fear that the patch may be never commited, so I wasn't sure to want to > >> continue spending lots of time on a patch "for nothing". > >> > >> If Bjoern or you told me some months ago "do that cleanup and we'll > >> commit the patch", it would already have been done, and we would have > >> *all* saved some time ! > >> > >> > >> And yes, I do also spend some parts of my free time on things that are > >> not related to FreeBSD's IPSec (and, to be completely honest, on > >> things which are not related at all to computers....). > >> > >> > >> > >>> That is not a slam > >>> on the person or the code, I have the highest respect for both, but it > >>> reflects and important reality of the situation. > >> I feel that "the reality of the situation" is that FreeBSD's IPSec > >> stack needs more people *working on it*, not more people wasting their > >> time about why some work should or shouldn't be reported. > >> > >> That is not a slam on the persons who are still working on the IPsec > >> stack, I have the highest respect for them, but it reflects an > >> important reality of the situation... > >> > >> > >> > >>> Unless you're > >>> stepping up to maintain it as well as commit it I think it should not > >>> be committed. I know the Bjoern has been working hard to pick up the > >>> IPsec stuff in his free time, and I value his input on this subject > >>> quite a bit. > >> You said it yourself: actually, FreeBSD's IPSec stack is just > >> maintained by one person, which worked hard on it, which does a great > >> job on it, but which can spend only some parts of his free time on it. > >> > >> That is a problem. > >> Of course, the solution can NOT be to ask Bjoern to spend more time on > >> it (well, Bjoern, do that if you want :-). > >> > >> The only other solution I see is to find a way to help people who want > >> to help you.... > > > > Thanks so much to folks like Bjorn and Yvan who spend the time to do > > some tough jobs like dealing with IPsec and being stubborn about > > committing things to security tools without very careful audit. > > > > In case you missed it, IPsec is about security, not features. And, in > > case you have never been involved in real security or crypto, security > > is really, really hard. > > > > No, no, it's much harder than that! > > > > While I'd love to see NAT-T, until someone who knows EXACTLY what the > > IPsec and NAT-T code is doing and what it is required to do can do the > > line by line review, it should NOT be committed. > > so, you don't think that this is rather a slap in teh face of the > person who wrote this, and who's job is to do security related work in > a proffesional context? > > "This requires a someone who knows what they are doing, and despite > the fact that you do this for a living, I arbitrarlily exclude you > from that category"? Not at all. No one should both write and vet security code. It takes two pairs of eyes connected to two brains to write and check code. I don't care how competent the programmer. This is a good rule for all code, but is too "expensive" for most code. Can you imagine how few updates would ever be checked in if every one needed a line-by-line vetting before a commit was allowed? Security code really an exception. It simply has to be right and I heartily approve of the care being taken by both Bjorn and Yvan. I feel both are doing exactly the right thing, much as I'd with they could do it faster. This is how you avoid potential disasters like the recent Debian openssh screw-up. (Just a small change that looked fine, but broke security done by a single programmer and never vetted). -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080629/a1d162c4/attachment.pgp From gavin at FreeBSD.org Sun Jun 29 22:04:22 2008 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Sun Jun 29 22:04:24 2008 Subject: kern/125010: [vr] ripd: multicast join failed, interface vr0 not running Message-ID: <200806292204.m5TM4LSe094636@freefall.freebsd.org> Old Synopsis: vr driver: ripd: multicast join failed, interface vr0 not running New Synopsis: [vr] ripd: multicast join failed, interface vr0 not running Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Sun Jun 29 22:03:30 UTC 2008 Responsible-Changed-Why: Over to maintainers http://www.freebsd.org/cgi/query-pr.cgi?pr=125010 From mgrooms at shrew.net Sun Jun 29 22:33:13 2008 From: mgrooms at shrew.net (Matthew Grooms) Date: Sun Jun 29 22:33:17 2008 Subject: FreeBSD NAT-T patch integration In-Reply-To: <4867B2B3.3090208@shrew.net> References: <4867B2B3.3090208@shrew.net> Message-ID: <48680DB8.708@shrew.net> > Thanks so much to folks like Bjorn and Yvan who spend the time to do > some tough jobs like dealing with IPsec and being stubborn about > committing things to security tools without very careful audit. > Seconded. > In case you missed it, IPsec is about security, not features. And, in > case you have never been involved in real security or crypto, security > is really, really hard. > > No, no, it's much harder than that! > > While I'd love to see NAT-T, until someone who knows EXACTLY what the > IPsec and NAT-T code is doing and what it is required to do can do the > line by line review, it should NOT be committed. Well, none of my emails advocated applying the patch without a complete review. I asked what the state of the review and testing process was and, in the opinion of my betters, if the patch could kindly be applied. Additionally, if the holdup was related to a lack of time available to the IPsec maintainers, what could be done to assist in getting this patch integrated. As for Yvans commitment, I would think that 3 years spent maintaining a patch on a moving target more than demonstrates it. I'm also a bit surprised to see that the request I made was categorized as impatient crying. But programmer hide tends to be thicker than most and opinions always vary. I won't deny that there has been a few misconceptions about what NAT-T is good for and what is involved in NAT-T packet processing. I'm not a BSD kernel hacker, but I have written a full IPv4 IPsec implementation as well as a key daemon from scratch that includes NAT-T support. For portability reasons, this involved emulating the PF_KEY interface on platforms that don't provide one natively so I am quite familiar with that component as well. No, NAT-T isn't required to interoperate with any particular vendor IPsec in the vanilla sense. It is required to work around issues that arise when at least one peer is behind a NAT device. Its particularly agonizing when you are trying to act as a IPsec remote access client. Without NAT-T, you will quickly experience why its been adopted almost universally. As the author of a port that attempts to offer this style of connectivity, I have a vested interest in seeing this functionality present in FreeBSD which explains my persistence :) How complex is IPsec NAT-T? The concept behind it is pretty simple. You wrap ESP in UDP so it traverses NAT more easily. The IKE traffic is multiplexed on the same port so you only issue keep-alives from userland to refresh a single NAT state. Most of the complexity related to negotiating NAT-T support, detecting the presence of a NAT and setting up the SA options are handled by the IKE daemon. Kernel side changes for a tunnel-only implementation, like Yvans, can be more or less summed up like so ... 1) A key daemon needs to be able to set a socket option that signifies how packets will be multiplexed on a bound port. This helps the IPsec layer qualify which packets need to be dropped, processed as ESP or passed on to IKE via the socket layer. 2) The PF_KEY system needs to be extended so that IPsec knows which SAs are NAT-T enabled and what UDP port values are to be used. 3) UDP headers, and non-isakmp markers for old versions of NAT-T, need to be added or removed from ESP packets when they are processed using a NAT-T enabled SA. After which, they are processed normally. Yes, the devil is in the detail but the details in the patch should be self evident. To coin a popular phrase on this list, IPsec is about security. If you look at Yvans patch, it doesn't do anything to fundamentally change the way ESP payloads are constructed or interpreted. It mostly just inserts or removes a UDP header where appropriate. If your not familiar with PF_KEY, the other parts of the patch may take a bit longer to evaluate. I'm not trying to downplay the expertise or experience that both gnn and bjorn bring to FreeBSD. I just don't think it would take a world class IPsec kernel hacker to review Yvans work competently. RFC3948 is literally 10 pages if you skip the end credits. The draft versions are considerably shorter. Again, opinions may vary. So the horse seems dead so Ill stop flogging it. If it takes another 6 months or more to get this reviewed, I won't complain. If/when the time comes, I have a half dozen commercial gateways and lots of Linix *BSD on the far side of a NAT if anyone would like additional testing. One last thing. I admit that I can't qualify how feasible this is, but it may be beneficial to split out the portion of the patch required to set the UDP socket options and commit that first. If this can be done in benign way, it would probably make a lot of people happier. Applying a patch that only requires rebuilding the kernel is a lot less annoying than having to perform a full buildworld. -Matthew From if at xip.at Sun Jun 29 23:06:17 2008 From: if at xip.at (Ingo Flaschberger) Date: Sun Jun 29 23:06:22 2008 Subject: Freebsd IP Forwarding performance (question, and some info) [7-stable, current, em, smp] In-Reply-To: <4867A9A1.9070507@gtcomm.net> References: <4867420D.7090406@gtcomm.net> <4867A9A1.9070507@gtcomm.net> Message-ID: Dear Paul, does the em-task jump from cpu to cpu? (mp-systems are not really better for forwarding performance). try once with only 1 cpu. bye, Ingo From paul at gtcomm.net Sun Jun 29 23:24:52 2008 From: paul at gtcomm.net (Paul) Date: Sun Jun 29 23:24:56 2008 Subject: Freebsd IP Forwarding performance (question, and some info) [7-stable, current, em, smp] In-Reply-To: References: <4867420D.7090406@gtcomm.net> <4867A9A1.9070507@gtcomm.net> Message-ID: <48681A3D.9040509@gtcomm.net> Yes it does but it seems to use a lot more of one cpu than the others so It's really not SMP.. Can I stop it from doing this with some setting? Why can't there be 4 taskq's? Also with full internet table I can't even do 100kpps without errors.. I don't get it :/ I could do 300kpps on a p3 and now I have a 3ghz xeon and 2.2ghz opteron brand new hardware and can barely get more than that.. Doesn't make sense to me. Ingo Flaschberger wrote: > Dear Paul, > > does the em-task jump from cpu to cpu? > (mp-systems are not really better for forwarding performance). > > try once with only 1 cpu. > > bye, > Ingo > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From if at xip.at Mon Jun 30 00:16:37 2008 From: if at xip.at (Ingo Flaschberger) Date: Mon Jun 30 00:16:41 2008 Subject: Freebsd IP Forwarding performance (question, and some info) [7-stable, current, em, smp] In-Reply-To: <48681A3D.9040509@gtcomm.net> References: <4867420D.7090406@gtcomm.net> <4867A9A1.9070507@gtcomm.net> <48681A3D.9040509@gtcomm.net> Message-ID: Dear Paul, > Yes it does but it seems to use a lot more of one cpu than the others so It's > really not SMP.. Can I stop it from doing this with some setting? > Why can't there be 4 taskq's? it is possible, but it need to be coded. hz 4000 is also too high, use 1000-2000 http://www.tancsa.com/blast.html > Also with full internet table I can't even do 100kpps without errors.. I > don't get it :/ I could do 300kpps on a p3 and now I have a 3ghz xeon and > 2.2ghz opteron brand new hardware and can barely get more than that.. > Doesn't make sense to me. have you tested with freebsd 6? or try dragonfly? Kind regards, Ingo Flaschberger From yongari at FreeBSD.org Mon Jun 30 00:25:29 2008 From: yongari at FreeBSD.org (yongari@FreeBSD.org) Date: Mon Jun 30 00:25:34 2008 Subject: kern/125010: [vr] ripd: multicast join failed, interface vr0 not running Message-ID: <200806300025.m5U0PTu4007669@freefall.freebsd.org> Synopsis: [vr] ripd: multicast join failed, interface vr0 not running State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Mon Jun 30 00:24:17 UTC 2008 State-Changed-Why: Would you show me the dmesg output related with vr(4)? There is a bug in multicasting filter handing on VT6105M(VIA Rhine III). If the hardware is VT6105M, please try the patch at the following URL. http://people.freebsd.org/~yongari/vr/vr.cam.patch2 Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Mon Jun 30 00:24:17 UTC 2008 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=125010 From mike at sentex.net Mon Jun 30 00:34:45 2008 From: mike at sentex.net (Mike Tancsa) Date: Mon Jun 30 00:34:49 2008 Subject: Freebsd IP Forwarding performance (question, and some info) [7-stable, current, em, smp] In-Reply-To: References: <4867420D.7090406@gtcomm.net> <4867A9A1.9070507@gtcomm.net> <48681A3D.9040509@gtcomm.net> Message-ID: <200806300034.m5U0YfsF077111@lava.sentex.ca> At 08:16 PM 6/29/2008, Ingo Flaschberger wrote: >Dear Paul, > >>Yes it does but it seems to use a lot more of one cpu than the >>others so It's really not SMP.. Can I stop it from doing this with >>some setting? >>Why can't there be 4 taskq's? > >it is possible, but it need to be coded. > >hz 4000 is also too high, use 1000-2000 >http://www.tancsa.com/blast.html Those are very old test results using a fairly different em driver than whats in the tree. You might look at http://people.yandex-team.ru/~wawa/ on RELENG_6. I havent tested it, but supposedly its optimized for forwarding on SMP hardware ---Mike From paul at gtcomm.net Mon Jun 30 00:50:37 2008 From: paul at gtcomm.net (Paul) Date: Mon Jun 30 00:50:42 2008 Subject: Freebsd IP Forwarding performance (question, and some info) [7-stable, current, em, smp] In-Reply-To: References: <4867420D.7090406@gtcomm.net> <4867A9A1.9070507@gtcomm.net> <48681A3D.9040509@gtcomm.net> Message-ID: <48682E57.8040509@gtcomm.net> Well who wants to code it ? I would gladly pay someone to make it work the way I want. :) It needs to be able to do line rate gig-e with 64 byte packets and 250k routes. FBSD6 is definitely slower. Haven't tried dragonfly. Thanks Ingo Flaschberger wrote: > Dear Paul, > >> Yes it does but it seems to use a lot more of one cpu than the others >> so It's really not SMP.. Can I stop it from doing this with some >> setting? >> Why can't there be 4 taskq's? > > it is possible, but it need to be coded. > > hz 4000 is also too high, use 1000-2000 > http://www.tancsa.com/blast.html > >> Also with full internet table I can't even do 100kpps without >> errors.. I don't get it :/ I could do 300kpps on a p3 and now I have >> a 3ghz xeon and 2.2ghz opteron brand new hardware and can barely get >> more than that.. Doesn't make sense to me. > > have you tested with freebsd 6? > or try dragonfly? > > Kind regards, > Ingo Flaschberger > > From paul at gtcomm.net Mon Jun 30 00:53:48 2008 From: paul at gtcomm.net (Paul) Date: Mon Jun 30 00:53:53 2008 Subject: Freebsd IP Forwarding performance (question, and some info) [7-stable, current, em, smp] In-Reply-To: <200806300034.m5U0YfsF077111@lava.sentex.ca> References: <4867420D.7090406@gtcomm.net> <4867A9A1.9070507@gtcomm.net> <48681A3D.9040509@gtcomm.net> <200806300034.m5U0YfsF077111@lava.sentex.ca> Message-ID: <48682F15.6070707@gtcomm.net> I tried this.. I put 6-STABLE (6.3), using default driver was slower than FBSD7 I tried yandex driver 1.36 and it was even worse.. It would make the machine unresponsive and drop more packets than the default driver. It would make 'top' show cpu's were 300% idle and a command such as 'w' would take 5 minutes to respond so obviously something is wrong with this driver :/ In the em taskq does it do all the routing also? Can the received packets be accepted with em0 taskq and dumped into another multi threaded thing which will do the routing and send it to the output taskq? Mike Tancsa wrote: > At 08:16 PM 6/29/2008, Ingo Flaschberger wrote: >> Dear Paul, >> >>> Yes it does but it seems to use a lot more of one cpu than the >>> others so It's really not SMP.. Can I stop it from doing this with >>> some setting? >>> Why can't there be 4 taskq's? >> >> it is possible, but it need to be coded. >> >> hz 4000 is also too high, use 1000-2000 >> http://www.tancsa.com/blast.html > > > Those are very old test results using a fairly different em driver > than whats in the tree. > > You might look at > http://people.yandex-team.ru/~wawa/ > on RELENG_6. I havent tested it, but supposedly its optimized for > forwarding on SMP hardware > > ---Mike > From andrew at modulus.org Mon Jun 30 01:21:17 2008 From: andrew at modulus.org (Andrew Snow) Date: Mon Jun 30 01:21:32 2008 Subject: FreeBSD NAT-T patch integration In-Reply-To: <48680DB8.708@shrew.net> References: <4867B2B3.3090208@shrew.net> <48680DB8.708@shrew.net> Message-ID: <486834F5.8080307@modulus.org> I've just started moving a medium IPSEC+gif VPN to one based on OpenVPN. OpenVPN solved all my problems with IPSEC: * does not require kernel modules or recompiles * works over UDP by default (and optionally TCP) + only requires a single IP port at each end * supports compression out of the box * supports bridging as well as tunneling Despite that, I didn't have to give up features or performance: * fast and secure enough (authentication, replay prevention) * very easy to configure & manage via either CLI/config files * supports both preshared keys or standard TLS+certs * also works on linux and windows. * supports hardware acceleration via openssl engines FWIW, I will probably never go back to IPSEC after this. - Andrew From if at xip.at Mon Jun 30 01:44:19 2008 From: if at xip.at (Ingo Flaschberger) Date: Mon Jun 30 01:44:22 2008 Subject: Freebsd IP Forwarding performance (question, and some info) [7-stable, current, em, smp] In-Reply-To: <48682F15.6070707@gtcomm.net> References: <4867420D.7090406@gtcomm.net> <4867A9A1.9070507@gtcomm.net> <48681A3D.9040509@gtcomm.net> <200806300034.m5U0YfsF077111@lava.sentex.ca> <48682F15.6070707@gtcomm.net> Message-ID: Dear Paul, > I tried this.. I put 6-STABLE (6.3), using default driver was slower than > FBSD7 have you set the rx/tx buffers? /boot/loader.conf hw.em.rxd=4096 hw.em.txd=4096 bye, Ingo From paul at gtcomm.net Mon Jun 30 02:48:18 2008 From: paul at gtcomm.net (Paul) Date: Mon Jun 30 02:48:25 2008 Subject: Freebsd IP Forwarding performance (question, and some info) [7-stable, current, em, smp] In-Reply-To: References: <4867420D.7090406@gtcomm.net> <4867A9A1.9070507@gtcomm.net> <48681A3D.9040509@gtcomm.net> <200806300034.m5U0YfsF077111@lava.sentex.ca> <48682F15.6070707@gtcomm.net> Message-ID: <486849E9.6010405@gtcomm.net> The higher I set the buffer the worse it is.. 256 and 512 I get about 50-60k more pps than i do with 2048 or 4096.. You would think it would be the other way around but obviously there is some contention going on. :/ I'm sticking with 512 for now, as it seems to make it worse with anything higher. Keep in mind, i'm using random source ips, random source and destination ports.. Although that should have zero impact on the amount of PPS it can route but for some reason it seems to.. ? Any ideas on that one? A single stream one source ip/port to one destination ip/port seems to use less cpu, although I haven't generated the same pps with that yet.. I am going to test it soon Ingo Flaschberger wrote: > Dear Paul, > >> I tried this.. I put 6-STABLE (6.3), using default driver was slower >> than FBSD7 > > have you set the rx/tx buffers? > > /boot/loader.conf > hw.em.rxd=4096 > hw.em.txd=4096 > > bye, > Ingo > From lab at gta.com Mon Jun 30 04:27:46 2008 From: lab at gta.com (Larry Baird) Date: Mon Jun 30 04:27:50 2008 Subject: FreeBSD NAT-T patch integration In-Reply-To: <108528.171316.50257@localhost> Message-ID: <20080630040103.94730.qmail@mailgate.gta.com> > And how do I know that it works ? > Well, when it doesn't work, I do know it, quite quickly most of the > time ! I have to chime in here. I did most of the initial porting of the NAT-T patches from Kame IPSec to FAST_IPSEC. I did look at every line of code during this process. I found no security problems during the port. Like Yvan, my company uses the NAT-T patches commercially. Like he says, if it had problems, we would hear about it. If the patches don't get commited, I highly suspect Yvan or myself would try to keep the patches up todate. So far I have done FAST_IPSEC pacthes for FreeBSD 4,5,6. Yvan did 7 and 8 by himself. Keeping up gets to be a pain after a while. I do plan to look at the FreeBSD 7 patches soon, but it sure would be nice to see it commited. Larry -- ------------------------------------------------------------------------ Larry Baird | http://www.gta.com Global Technology Associates, Inc. | Orlando, FL Email: lab@gta.com | TEL 407-380-0220, FAX 407-380-6080 From rwatson at FreeBSD.org Mon Jun 30 08:27:12 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Jun 30 08:27:17 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <20080629180126.F90836@fledge.watson.org> References: <20080524111715.T64552@fledge.watson.org> <20080629180126.F90836@fledge.watson.org> Message-ID: <20080630091033.P3968@fledge.watson.org> On Sun, 29 Jun 2008, Robert Watson wrote: > An FYI on the state of things here: in the last month, John has updated a > number of device drivers to be MPSAFE, and the USB work remains in-flight. > I'm holding fire a bit on disabling IFF_NEEDSGIANT while things settle and I > catch up on driver state, and will likely send out an update next week > regarding which device drivers remain on the kill list, and generally what > the status of this project is. Here's the revised list of drivers that will have their build disabled in the next week (subject to an appropriate block of time for me): Name Bus Man page description ---- --- -------------------- ar ISA/PCI synchronous Digi/Arnet device driver arl ISA Aironet Arlan 655 wireless network adapter driver cnw ISA Netwave AirSurfer wireless network driver ic I2C I2C bus system oltr ISA/PCI Olicom Token Ring device driver plip PPBUS printer port Internet Protocol driver ppp TTY point to point protocol network interface ray PCCARD Raytheon Raylink/Webgear Aviator PCCard driver sbni ISA/PCI Granch SBNI12 leased line modem driver sbsh PCI Granch SBNI16 SHDSL modem device driver sl TTY slip network interface snc ISA/PCCARD National Semiconductor DP8393X SONIC Ethernet adapter driver sppp TTY point to point protocol network layer for synchronous lines sr ISA/PCI synchronous RISCom/N2 / WANic 400/405 device driver Obviously, if necessary work is done to remove the IFF_NEEDSGIANT requirement from a driver, it will be pulled from the list, and I'll do an IFF_NEEDSGIANT scan before pulling the plug. Drivers will remain in the tree but disconnected for about a month before being removed from HEAD. Thanks greatly to John and others who have worked hard to reduce the size of the list in the last year! The following USB drivers will remain enabled due to on-going USB work that should eliminate IFF_NEEDSGIANT: Name Bus Man page description ---- --- -------------------- axe USB ASIX Electronics AX88172 USB Ethernet driver cdce USB USB Communication Device Class Ethernet driver cue USB CATC USB-EL1210A USB Ethernet driver kue USB Kawasaki LSI KL5KUSB101B USB Ethernet driver rue USB RealTek RTL8150 USB to Fast Ethernet controller rum USB Ralink Technology USB IEEE 802.11a/b/g wireless network device udav USB Davicom DM9601 USB Ethernet driver ural USB Ralink Technology RT2500USB IEEE 802.11 driver zyd USB ZyDAS ZD1211/ZD1211B USB IEEE 802.11b/g wireless network device The following drivers reference IFF_NEEDSGIANT but only when running in an optional non-MPSAFE mode; that optional mode will be removed but the drivers will remain: Name Bus Man page description ---- --- -------------------- ce PCI driver for synchronous Cronyx Tau-PCI/32 WAN adapters cp PCI driver for synchronous Cronyx Tau-PCI WAN adapters ctau ISA driver for synchronous Cronyx Tau WAN adapters cx ISA driver for synchronous/asynchronous Cronyx Sigma WAN adapters Robert N M Watson Computer Laboratory University of Cambridge From stefan.lambrev at moneybookers.com Mon Jun 30 09:11:45 2008 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Mon Jun 30 09:11:49 2008 Subject: if_bridge turns off checksum offload of members? Message-ID: <4868A34C.6030304@moneybookers.com> Greetings, I just noticed, that when I add em network card to bridge the checksum offload is turned off. I even put in my rc.conf: ifconfig_em0="rxcsum up" ifconfig_em1="rxcsum up" but after reboot both em0 and em1 have this feature disabled. Is this expected behavior? Should I care about csum in bridge mode? I noticed that enabling checksum offload manually improve things little btw. Also I'm experimenting with bridge performance and with today's 7-stable I can't reach the results from my previous test with 7-current (before few months) The best that bridge can do today is just 720kpps (just incoming) vs 1000kpps with sources from few months ago. I'm using the same hardware and same configuration so I'm not sure why -stable is slower. -- Best Wishes, Stefan Lambrev ICQ# 24134177 From pyunyh at gmail.com Mon Jun 30 10:18:43 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Mon Jun 30 10:18:46 2008 Subject: if_bridge turns off checksum offload of members? In-Reply-To: <4868A34C.6030304@moneybookers.com> References: <4868A34C.6030304@moneybookers.com> Message-ID: <20080630101629.GD79537@cdnetworks.co.kr> On Mon, Jun 30, 2008 at 12:11:40PM +0300, Stefan Lambrev wrote: > Greetings, > > I just noticed, that when I add em network card to bridge the checksum > offload is turned off. > I even put in my rc.conf: > ifconfig_em0="rxcsum up" > ifconfig_em1="rxcsum up" > but after reboot both em0 and em1 have this feature disabled. > > Is this expected behavior? Should I care about csum in bridge mode? > I noticed that enabling checksum offload manually improve things little btw. > AFAIK this is intended one, bridge(4) turns off Tx side checksum offload by default. I think disabling Tx checksum offload is required as not all members of a bridge may be able to do checksum offload. The same is true for TSO but it seems that bridge(4) doesn't disable it. If all members of bridge have the same hardware capability I think bridge(4) may not need to disable Tx side hardware assistance. I guess bridge(4) can scan every interface capabilities in a member and can decide what hardware assistance can be activated instead of blindly turning off Tx side hardware assistance. > Also I'm experimenting with bridge performance and with today's 7-stable > I can't reach > the results from my previous test with 7-current (before few months) > > The best that bridge can do today is just 720kpps (just incoming) vs > 1000kpps with sources from few months ago. > I'm using the same hardware and same configuration so I'm not sure why > -stable is slower. > > -- > > Best Wishes, > Stefan Lambrev > ICQ# 24134177 > -- Regards, Pyun YongHyeon From bugmaster at FreeBSD.org Mon Jun 30 11:07:01 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 30 11:07:16 2008 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200806301107.m5UB703A095818@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/92090 net [bge] bge0: watchdog timeout -- resetting f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau f kern/102344 net [ipf] Some packets do not pass through network interfa o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109733 net [bge] bge link state issues [regression] o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116328 net [bge]: Solid hang with bge interface o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117423 net [vlan] Duplicate IP on different interfaces o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119361 net [bge] bge(4) transmit performance problem o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122082 net [in_pcb] NULL pointer dereference in in_pcbdrop o kern/122195 net [ed] Alignment problems in if_ed f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix f kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar f conf/122858 net [nsswitch.conf] nsswitch in 7.0 is f*cked up o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 f kern/123172 net [bce] Watchdog timeout problems with if_bce o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123617 net [tcp] breaking connection when client downloading file o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123881 net [tcp] Turning on TCP blackholing causes slow localhost o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124540 net [tcp] RTM_MISS with the transit packets o kern/124753 net net80211 discards power-save queue packets early o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/125079 net [ppp] host routes added by ppp with gateway flag (regr 92 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 o kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/95267 net packet drops periodically appear o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/112179 net [sis] [patch] sis driver for natsemi DP83815D autonego o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o bin/117339 net [patch] route(8): loading routing management commands o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/119432 net [arp] route add -host -iface causes arp e f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122068 net [ppp] ppp can not set the correct interface with pptpd p kern/122145 net error while compiling with device ath_rate_amrr o kern/122295 net [bge] bge Ierr rate increase (since 6.0R) [regression] o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122697 net [ath] Atheros card is not well supported o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge f kern/122839 net [multicast] FreeBSD 7 multicast routing problem o kern/122928 net [em] interface watchdog timeouts and stops receiving p o kern/123892 net [tap] [patch] No buffer space available p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o bin/124004 net ifconfig(8): Cannot assign both an IP and a MAC addres o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124609 net [ipsec] [panic] ipsec 'remainder too big' panic with p o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/125003 net [gif] incorrect EtherIP header format. 55 problems total. From stefan.lambrev at moneybookers.com Mon Jun 30 11:32:23 2008 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Mon Jun 30 11:32:26 2008 Subject: Freebsd IP Forwarding performance (question, and some info) [7-stable, current, em, smp] In-Reply-To: <486849E9.6010405@gtcomm.net> References: <4867420D.7090406@gtcomm.net> <4867A9A1.9070507@gtcomm.net> <48681A3D.9040509@gtcomm.net> <200806300034.m5U0YfsF077111@lava.sentex.ca> <48682F15.6070707@gtcomm.net> <486849E9.6010405@gtcomm.net> Message-ID: <4868C442.7030406@moneybookers.com> Paul wrote: > The higher I set the buffer the worse it is.. 256 and 512 I get about > 50-60k more pps than i do with 2048 or 4096.. You > would think it would be the other way around but obviously there is > some contention going on. :/ Looks like in bridge mode hw.em.rxd=512 and hw.em.txd=512 yields best results also. reducing or increasing those leads to worse performance. btw is there any news with hwpmc for new CPUs ? last time I checked was real pain to get it working with core2 CPUs :( > I'm sticking with 512 for now, as it seems to make it worse with > anything higher. > Keep in mind, i'm using random source ips, random source and > destination ports.. Although that should have zero impact on the > amount of PPS it can route but for some reason it seems to.. ? Any > ideas on that one? A single stream one source ip/port to one > destination ip/port seems to use less cpu, although I haven't > generated the same pps with that yet.. I am going to test it soon > > Ingo Flaschberger wrote: >> Dear Paul, >> >>> I tried this.. I put 6-STABLE (6.3), using default driver was >>> slower than FBSD7 >> >> have you set the rx/tx buffers? >> >> /boot/loader.conf >> hw.em.rxd=4096 >> hw.em.txd=4096 >> >> bye, >> Ingo >> > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- Best Wishes, Stefan Lambrev ICQ# 24134177 From gavin at FreeBSD.org Mon Jun 30 11:37:51 2008 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Mon Jun 30 11:37:53 2008 Subject: kern/124160: connect() function loops indefinitely Message-ID: <200806301137.m5UBboEp003430@freefall.freebsd.org> Synopsis: connect() function loops indefinitely Responsible-Changed-From-To: gavin->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Mon Jun 30 11:36:12 UTC 2008 Responsible-Changed-Why: Over to maintainers. http://www.freebsd.org/cgi/query-pr.cgi?pr=124160 From steve at ibctech.ca Mon Jun 30 13:37:09 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Mon Jun 30 13:37:16 2008 Subject: IPV6 problem : nd6_lookup: failed to add route for a neighbor In-Reply-To: <200806270430.m5R4U5Ib025336@himinbjorg.tucs-beachin-obx-house.com> References: <200806270430.m5R4U5Ib025336@himinbjorg.tucs-beachin-obx-house.com> Message-ID: <4868E183.2070504@ibctech.ca> Tuc at T-B-O-H.NET wrote: > But once I brought it all up, I got : > > kernel: nd6_lookup: failed to add route for a neighbor(2001:0470:0007:0028::0001), errno=17 With your exact configuration between two 7.0 boxes, I see no indication of this error whatsoever, with the /128 prefix. > The tunnel came up, was passing traffic, but those messages were > getting out of hand. I tried a prefixlen of 64, and I got: > > ifconfig: ioctl (SIOCAIFADDR): Invalid argument When I attempted to recreate the tunnel with any prefix length other than 128, the same ifconfig error appeared as above. It appears as though when creating a gif tunnel, the only IPv6 prefix length that is valid as far as ifconfig is concerned is /128 even though the link's prefix is /64 even in 7. Steve From ml at t-b-o-h.net Mon Jun 30 15:20:12 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Mon Jun 30 15:20:19 2008 Subject: [freebsd-net] Re: IPV6 problem : nd6_lookup: failed to add route for a neighbor In-Reply-To: <4868E183.2070504@ibctech.ca> Message-ID: <200806301519.m5UFJsOe072577@himinbjorg.tucs-beachin-obx-house.com> > > Tuc at T-B-O-H.NET wrote: > > > But once I brought it all up, I got : > > > > kernel: nd6_lookup: failed to add route for a neighbor(2001:0470:0007:0028::0001), errno=17 > > With your exact configuration between two 7.0 boxes, I see no indication > of this error whatsoever, with the /128 prefix. > Possibly because of : http://lists.freebsd.org/pipermail/freebsd-net/2006-May/010718.html http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/93220 which wouldn't apply to me due to my version. > > > The tunnel came up, was passing traffic, but those messages were > > getting out of hand. I tried a prefixlen of 64, and I got: > > > > ifconfig: ioctl (SIOCAIFADDR): Invalid argument > > When I attempted to recreate the tunnel with any prefix length other > than 128, the same ifconfig error appeared as above. It appears as > though when creating a gif tunnel, the only IPv6 prefix length that is > valid as far as ifconfig is concerned is /128 even though the link's > prefix is /64 even in 7. > It seems if I just did : ifconfig gif0 inet6 2001:470:7:28::2/64 instead of : ifconfig gif0 inet6 2001:470:7:28::2 2001:470:7:28::1 prefixlen 128 It "got happy". I haven't seen any of the messages yet, and so far no issues I can readily see. Tuc From 20080111.freebsd.org at ab.ote.we.lv Mon Jun 30 19:18:55 2008 From: 20080111.freebsd.org at ab.ote.we.lv (Eugene M. Kim) Date: Mon Jun 30 19:19:21 2008 Subject: kern/125024: vr(4) does not see incoming multicast packets in non-promiscuous mode (broadcast is fine); breaks IPv6 In-Reply-To: <20080629072932.GA76469@cdnetworks.co.kr> References: <200806270345.m5R3j1BT036253@freefall.freebsd.org> <48649776.9040509@ab.ote.we.lv> <20080627074948.GC67753@cdnetworks.co.kr> <4864A217.3040309@ab.ote.we.lv> <20080629072932.GA76469@cdnetworks.co.kr> Message-ID: <48693193.1020404@ab.ote.we.lv> Than you! The new patch fixed the problem. I'll put it under test for a few more days and let you know if any regression is seen. Cheers, Eugene Pyun YongHyeon wrote: > On Fri, Jun 27, 2008 at 01:17:27AM -0700, Eugene M. Kim wrote: > > Pyun YongHyeon wrote: > > >I've updated patch again. There was a bug that disabled > > >multicasting filter. Back out previous patch and try again. > > >The URL is the same as before. > > > > > > > Regards, > > > > Eugene > > > > > > > rtsol still doesn't work with vr0 being in non-promiscuous mode. > > However, apparently vr0 picked up router solicitations during system > > boot-up, as ifconfig shows the correct prefixes autoconfigured. It > > seems something goes wrong in between. 'o 'a > > > > Oops, I was accessing CAM mask register as 8bit register which > should be 32bit! Try the patch at the following URL. > > http://people.freebsd.org/~yongari/vr/vr.cam.patch2 > > > Eugene > From mike at sentex.net Mon Jun 30 19:44:43 2008 From: mike at sentex.net (Mike Tancsa) Date: Mon Jun 30 19:44:48 2008 Subject: Freebsd IP Forwarding performance (question, and some info) [7-stable, current, em, smp] In-Reply-To: <4867420D.7090406@gtcomm.net> References: <4867420D.7090406@gtcomm.net> Message-ID: <200806301944.m5UJifJD081781@lava.sentex.ca> At 04:04 AM 6/29/2008, Paul wrote: >This is just a question but who can get more than 400k pps >forwarding performance ? OK, I setup 2 boxes on either end of a RELENG_7 box from about May 7th just now, to see with 2 boxes blasting across it how it would work. *However*, this is with no firewall loaded and, I must enable ip fast forwarding. Without that enabled, the box just falls over. even at 20Kpps, I start seeing all sorts of messages spewing to route -n monitor got message of size 96 on Mon Jun 30 15:39:10 2008 RTM_MISS: Lookup failed on this address: len 96, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: default I am starting to wonder if those messages are the results of corrupted packets the machine just cant keep up with ? CPU is CPU: Intel(R) Xeon(R) CPU 3070 @ 2.66GHz (2660.01-MHz 686-class CPU) input (Total) output packets errs bytes packets errs bytes colls 611945 0 77892098 611955 0 77013002 0 616727 0 78215508 616742 0 77303454 0 617066 0 78162130 617082 0 77238434 0 618238 0 78302314 618225 0 77377582 0 617035 0 78141000 617038 0 77215672 0 617625 0 78225600 617588 0 77301734 0 616190 0 78017320 616165 0 77091774 0 615583 0 78064130 615628 0 77152800 0 617662 0 78254388 617658 0 77332340 0 618000 0 78269912 617950 0 77344554 0 617248 0 78183136 617315 0 77259588 0 617325 0 78204566 617289 0 77282094 0 618391 0 78337734 618357 0 77413756 0 616025 0 78116070 616082 0 77203116 0 To generate the packets, I am just using /usr/src/tools/tools/netblast on 2 endpoints starting at about the same time # ./netblast 10.10.1.2 500 100 40 start: 1214854131.083679919 finish: 1214854171.084668592 send calls: 20139141 send errors: 0 approx send rate: 503478 approx error rate: 0 # ./netblast 10.10.1.3 500 10 40 start: 1214854273.882202815 finish: 1214854313.882319031 send calls: 23354971 send errors: 18757223 approx send rate: 114943 approx error rate: 0 The box in the middle doing the forwarding 1[spare-r7]# ifconfig -u em0: flags=8843 metric 0 mtu 1500 options=19b ether 00:1b:21:08:32:a8 inet 10.20.1.1 netmask 0xffffff00 broadcast 10.20.1.255 media: Ethernet autoselect (1000baseTX ) status: active em1: flags=8843 metric 0 mtu 1500 options=9b ether 00:1b:21:08:32:a9 inet 192.168.43.193 netmask 0xffffff00 broadcast 192.168.43.255 media: Ethernet autoselect (100baseTX ) status: active em3: flags=8843 metric 0 mtu 1500 options=19b ether 00:30:48:90:4c:ff inet 10.10.1.1 netmask 0xffffff00 broadcast 10.10.1.255 media: Ethernet autoselect (1000baseTX ) status: active lo0: flags=8049 metric 0 mtu 16384 inet 127.0.0.1 netmask 0xff000000 I am going to try a few more tests with and without, firewall rules etc as well as an updated kernel to RELENG_7 as of today and see how that goes. ---Mike From 20080111.freebsd.org at ab.ote.we.lv Mon Jun 30 20:12:51 2008 From: 20080111.freebsd.org at ab.ote.we.lv (Eugene M. Kim) Date: Mon Jun 30 20:12:53 2008 Subject: bridge(4) and IPv6 link-local address Message-ID: <48693E39.4080104@ab.ote.we.lv> Hello, A quick question: Is bridge(4) supposed /not/ to automatically configure an IPv6 link-local address? I'm trying to use it to bridge a wired segment and a wireless segment, and router advertisement over bridge0 wouldn't work because, with bridge0 lacking a LL address, the router uses a non-LL address as the source address for RA packets, which then is ignored as invalid by other IPv6 nodes. Cheers, Eugene From paul at gtcomm.net Mon Jun 30 21:03:37 2008 From: paul at gtcomm.net (Paul) Date: Mon Jun 30 21:03:42 2008 Subject: Freebsd IP Forwarding performance (question, and some info) [7-stable, current, em, smp] In-Reply-To: <200806301944.m5UJifJD081781@lava.sentex.ca> References: <4867420D.7090406@gtcomm.net> <200806301944.m5UJifJD081781@lava.sentex.ca> Message-ID: <48694A9D.1030001@gtcomm.net> With hours and days of tweaking i can't even get 500k pps :/ no firewall no anything else.. What is your kernel config? Sysctl configs? My machine i'm testing on is dual opteron 2212 , with intel 2 port 82571 nic.. Using 7-STABLE and I tried 6-stable and -current I get the RTM_MISS with 7 and current but only with certain types of packets at a certain rate.. :/ I can not get more than 500kpps.. i tried everything I could think of... lowering the rx descriptors on EM to 512 instead of 2048 gave me some more.. I was stuck at 400kpps until i changed those and i lowered the rx processing limit. My tests are going incoming em0 and outgoing em1 in one direction only and it has major errors when em0 taskq gets close to 80% cpu.. I am pretty disappointed that it maxes out a little over 400kpps and even then it gets some errors here and there , mainly missed packets due to no buffer and rx overruns (dev.em.0.stats=1) Mike Tancsa wrote: > At 04:04 AM 6/29/2008, Paul wrote: >> This is just a question but who can get more than 400k pps forwarding >> performance ? > > > OK, I setup 2 boxes on either end of a RELENG_7 box from about May 7th > just now, to see with 2 boxes blasting across it how it would work. > *However*, this is with no firewall loaded and, I must enable ip fast > forwarding. Without that enabled, the box just falls over. > > even at 20Kpps, I start seeing all sorts of messages spewing to route > -n monitor > > > got message of size 96 on Mon Jun 30 15:39:10 2008 > RTM_MISS: Lookup failed on this address: len 96, pid: 0, seq 0, errno > 0, flags: > locks: inits: > sockaddrs: > default > > I am starting to wonder if those messages are the results of corrupted > packets the machine just cant keep up with ? > > > CPU is > > CPU: Intel(R) Xeon(R) CPU 3070 @ 2.66GHz (2660.01-MHz > 686-class CPU) > > > input (Total) output > packets errs bytes packets errs bytes colls > 611945 0 77892098 611955 0 77013002 0 > 616727 0 78215508 616742 0 77303454 0 > 617066 0 78162130 617082 0 77238434 0 > 618238 0 78302314 618225 0 77377582 0 > 617035 0 78141000 617038 0 77215672 0 > 617625 0 78225600 617588 0 77301734 0 > 616190 0 78017320 616165 0 77091774 0 > 615583 0 78064130 615628 0 77152800 0 > 617662 0 78254388 617658 0 77332340 0 > 618000 0 78269912 617950 0 77344554 0 > 617248 0 78183136 617315 0 77259588 0 > 617325 0 78204566 617289 0 77282094 0 > 618391 0 78337734 618357 0 77413756 0 > 616025 0 78116070 616082 0 77203116 0 > > > To generate the packets, I am just using > /usr/src/tools/tools/netblast on 2 endpoints starting at about the > same time > > # ./netblast 10.10.1.2 500 100 40 > > start: 1214854131.083679919 > finish: 1214854171.084668592 > send calls: 20139141 > send errors: 0 > approx send rate: 503478 > approx error rate: 0 > > > # ./netblast 10.10.1.3 500 10 40 > > start: 1214854273.882202815 > finish: 1214854313.882319031 > send calls: 23354971 > send errors: 18757223 > approx send rate: 114943 > approx error rate: 0 > > The box in the middle doing the forwarding > > 1[spare-r7]# ifconfig -u > em0: flags=8843 metric 0 mtu 1500 > > options=19b > ether 00:1b:21:08:32:a8 > inet 10.20.1.1 netmask 0xffffff00 broadcast 10.20.1.255 > media: Ethernet autoselect (1000baseTX ) > status: active > em1: flags=8843 metric 0 mtu 1500 > options=9b > ether 00:1b:21:08:32:a9 > inet 192.168.43.193 netmask 0xffffff00 broadcast 192.168.43.255 > media: Ethernet autoselect (100baseTX ) > status: active > em3: flags=8843 metric 0 mtu 1500 > > options=19b > ether 00:30:48:90:4c:ff > inet 10.10.1.1 netmask 0xffffff00 broadcast 10.10.1.255 > media: Ethernet autoselect (1000baseTX ) > status: active > lo0: flags=8049 metric 0 mtu 16384 > inet 127.0.0.1 netmask 0xff000000 > > > I am going to try a few more tests with and without, firewall rules > etc as well as an updated kernel to RELENG_7 as of today and see how > that goes. > > ---Mike > > From bzeeb-lists at lists.zabbadoz.net Mon Jun 30 22:15:09 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Mon Jun 30 22:15:13 2008 Subject: bridge(4) and IPv6 link-local address In-Reply-To: <48693E39.4080104@ab.ote.we.lv> References: <48693E39.4080104@ab.ote.we.lv> Message-ID: <20080630220842.X83875@maildrop.int.zabbadoz.net> On Mon, 30 Jun 2008, Eugene M. Kim wrote: Hi, > A quick question: Is bridge(4) supposed /not/ to automatically configure an > IPv6 link-local address? yes there is a check for this in the code and if remoed (tried that lately) more things go wrong. > I'm trying to use it to bridge a wired segment and a wireless segment, and > router advertisement over bridge0 wouldn't work because, with bridge0 lacking > a LL address, the router uses a non-LL address as the source address for RA > packets, which then is ignored as invalid by other IPv6 nodes. yes, seem something similar lately but ETIMEOUT on debugging. The problem basically was: lan bridge ath --- wlan client the LL address was on the "lan" interface. ping6 LL on lan from wlan client did not work. I could see the packets being bridged and visible on all interfaces and even the router on lan noticed them but there was no reply going to the client. ping6 from the bridge ``box'' to the wlan client and everything was fine as nd was seeded. Removing the check we ended up with the same LL address on both bridge and the lan interface if I can remember correctly and you do not want that... it's a bit tricky and there is something that does not work as expected, right. If you find the time to debug it I'll happily test patches;-) -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From steve at ibctech.ca Mon Jun 30 22:18:25 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Mon Jun 30 22:18:28 2008 Subject: Freebsd IP Forwarding performance (question, and some info) [7-stable, current, em, smp] In-Reply-To: <200806301944.m5UJifJD081781@lava.sentex.ca> References: <4867420D.7090406@gtcomm.net> <200806301944.m5UJifJD081781@lava.sentex.ca> Message-ID: <48695BA6.7060207@ibctech.ca> Mike Tancsa wrote: > At 04:04 AM 6/29/2008, Paul wrote: >> This is just a question but who can get more than 400k pps forwarding >> performance ? > > > OK, I setup 2 boxes on either end of a RELENG_7 box from about May 7th > just now, to see with 2 boxes blasting across it how it would work. > *However*, this is with no firewall loaded and, I must enable ip fast > forwarding. Without that enabled, the box just falls over. > > even at 20Kpps, I start seeing all sorts of messages spewing to route -n > monitor > > > got message of size 96 on Mon Jun 30 15:39:10 2008 > RTM_MISS: Lookup failed on this address: len 96, pid: 0, seq 0, errno 0, > flags: > locks: inits: > sockaddrs: > default Mike, Is the monitor running on the 7.0 box in the middle you are testing? I set up the same configuration, and even with almost no load (< 1Kpps) can replicate these error messages by making the remote IP address (in your case 'default', disappear (ie: unplug the cable, DDoS etc). ...to further, I can even replicate the problem at a single packet per second by trying to ping an IP address that I know for fact that the router can not get to. Do you see these error messages if you set up a loopback address with an IP on the router, and effectively chop your test environment in half? In your case, can the router in the middle actually get to a default gateway for external addresses (when I perform the test, your 'default' is substituted with the IP I am trying to reach, so I am only assuming that 'default' is implying default gateway). Steve From thompsa at FreeBSD.org Mon Jun 30 23:03:05 2008 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Mon Jun 30 23:03:09 2008 Subject: if_bridge turns off checksum offload of members? In-Reply-To: <20080630101629.GD79537@cdnetworks.co.kr> References: <4868A34C.6030304@moneybookers.com> <20080630101629.GD79537@cdnetworks.co.kr> Message-ID: <20080630230426.GI60479@citylink.fud.org.nz> On Mon, Jun 30, 2008 at 07:16:29PM +0900, Pyun YongHyeon wrote: > On Mon, Jun 30, 2008 at 12:11:40PM +0300, Stefan Lambrev wrote: > > Greetings, > > > > I just noticed, that when I add em network card to bridge the checksum > > offload is turned off. > > I even put in my rc.conf: > > ifconfig_em0="rxcsum up" > > ifconfig_em1="rxcsum up" > > but after reboot both em0 and em1 have this feature disabled. > > > > Is this expected behavior? Should I care about csum in bridge mode? > > I noticed that enabling checksum offload manually improve things little btw. > > > > AFAIK this is intended one, bridge(4) turns off Tx side checksum > offload by default. I think disabling Tx checksum offload is > required as not all members of a bridge may be able to do checksum > offload. The same is true for TSO but it seems that bridge(4) > doesn't disable it. It should be added. > If all members of bridge have the same hardware capability I think > bridge(4) may not need to disable Tx side hardware assistance. I > guess bridge(4) can scan every interface capabilities in a member > and can decide what hardware assistance can be activated instead of > blindly turning off Tx side hardware assistance. Yes, it could me smarter in this regard. The other thing to note is that unless you are manipulating the packets as they pass the bridge the checksums are unaffected and do not get recalculated anyway. Andrew From jhb at freebsd.org Mon Jun 30 23:10:23 2008 From: jhb at freebsd.org (John Baldwin) Date: Mon Jun 30 23:10:27 2008 Subject: HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd)) In-Reply-To: <20080629180126.F90836@fledge.watson.org> References: <20080524111715.T64552@fledge.watson.org> <20080629180126.F90836@fledge.watson.org> Message-ID: <200806301517.22173.jhb@freebsd.org> On Sunday 29 June 2008 01:02:49 pm Robert Watson wrote: > > On Sat, 24 May 2008, Robert Watson wrote: > > > Just as a reminder, we've just about reached the one month date before > > IFF_NEEDSGIANT drivers are disabled in the build. You can find a > > description of the general problem and list of specific drivers below. > > > > As USB work is on-going, I will *not* disable the USB drivers at this time, > > but all other drivers in the list below will be disabled on 26 June. They > > will remain in the tree, easily accessible for patch distribution and > > re-enabling, until October, when any remaining non-MPSAFE drivers will be > > deleted in 8.x. FreeBSD 8.0 will not ship with compatibility shims to > > support non-MPSAFE network device drivers. > > An FYI on the state of things here: in the last month, John has updated a > number of device drivers to be MPSAFE, and the USB work remains in-flight. > I'm holding fire a bit on disabling IFF_NEEDSGIANT while things settle and I > catch up on driver state, and will likely send out an update next week > regarding which device drivers remain on the kill list, and generally what the > status of this project is. Pending someone testing them real soon, I will be axeing at least sbsh, sbni, snc, and cnw this week (I had someone e-mail who said they would test the arl(4) pages). I still want to work on if_plip (which means locking ppbus) and if_ic (iicbus). I started working on locking iicbus recently FWIW. Aside from USB that leaves ray(4) (which does tsleep() all over the place including in interrupt handlers.. this couldn't have worked on 4.x all that well) and the various Cronyx drivers which interface with netgraph. Someone who knows netgraph can probably step up to lock those. Could also ask rik@ directly about the Cronyx drivers (cx, ctau, and cp). -- John Baldwin