Re: TCP options order changed in FreeBSD 7, incompatible with some routers
On Wed, 12 Mar 2008, Bjoern A. Zeeb wrote: On Tue, 11 Mar 2008, d.s. al coda wrote: - FreeBSD 7 has (there is of course an aligning nop after the eol, which tcpdump skips) Which is a bug (the nop after the EOL) that I recently fixed in HEAD. I am still curious to know if it's only ordering or the invalid padding or both that keeps clients from connecting. The problem is getting hands on such a problematic "client". Bjoern, can you get that fix MFC'd ASAP? I've e-mailed a tcpdump developer asking how we can enhance it so that it prints out <..., eol, nop> so that we can detect such errors more easily in the future. I wish I had paid more attention to that part of the previous thread on this topic! -Mike ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: TCP options order changed in FreeBSD 7, incompatible with some routers
On Wed, 12 Mar 2008, Mike Silbersack wrote:
I think we will need to fix tcpdump before trying to finish diagnosing this
problem. We were missing key information before.
-Mike
Hm, that was far easier than expected. Patch attached.
Here's what the two tcpdumps show now:
6.3:
IP A > B : S 2575736483:2575736483(0) ack 1762868649 win 65535
7.0:
IP A > B : S 3304309835:3304309835(0) ack 710421411 win 65535
That makes the problem quite a bit more clear. Anyone working on this
issue should apply this patch ASAP.
-Mike--- print-tcp.c.old 2008-03-12 23:21:52.0 -0500
+++ print-tcp.c 2008-03-12 23:24:50.0 -0500
@@ -637,8 +637,10 @@
if (datalen != len)
(void)printf("[len %d]", len);
ch = ',';
+#if 0
if (opt == TCPOPT_EOL)
break;
+#endif
}
putchar('>');
}
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: TCP options order changed in FreeBSD 7, incompatible with some routers
On Tue, 11 Mar 2008, d.s. al coda wrote: - FreeBSD 7 has (there is of course an aligning nop after the eol, which tcpdump skips) Jake Rizzo sent me some updated tcpdumps comparing 6.3 vs 7.0, and that aligning NOP that tcpdump (and wireshark) omit seems to be the only difference. Here's what Jake's 6.3 dump shows: IP A > B : S 2575736483:2575736483(0) ack 1762868649 win 65535 And the actual option data is: 02 04 05 b4 04 02 00 00 <- ends with two EOLs For 7.0: IP A > B : S 3304309835:3304309835(0) ack 710421411 win 65535 And the actual option data is: 02 04 05 64 04 02 00 01 <- ends with a NOP after the EOL I think we will need to fix tcpdump before trying to finish diagnosing this problem. We were missing key information before. -Mike ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FYI: inpcb/pcbinfo mutex -> rwlock at some point in the mid-distant future
Robert Watson wrote: One of those issues is that we need to demonstrate to ourselves that exclusive access contention is managed as well with rwlocks as with sleep mutexes, as these locks would continue to be fairly highly contended in TCP. The other issue is that rwlocks don't support full priority propagation for reader access, although Jeff Roberson has recently improved fairness to writers with many readers. Don't forget that p4 bms_netdev contains a number of optimizations for the multicast paths -- there are lock acquisitions which are quite often unnecessary, or whose granularity is too high for the data structure(s) which need to be shared. BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VLAN trunking and fragmentation
On Wed, Mar 12, 2008 at 10:22:34PM +0100, Giulio Ferro wrote: > Sam Leffler wrote: > >You failed to provide the output of ifconfig on your running system. > >Be sure any checksum offload is disabled (should be by the bridge). > > > >Sam > My bad. > > I switched off checksum offload in /etc/rc.conf like this: > ifconfig_re0="inet 192.168.60.1 netmask 255.255.255.0 -rxcsum -txcsum" > (same thing on the other machine) > > Now my ifconfig on PC #1 is : > - > # ifconfig re0 > re0: flags=8843 metric 0 mtu 1500 >options=98 >ether 00:14:c1:40:c2:e8 >inet 192.168.60.1 netmask 0xff00 broadcast 192.168.60.255 >media: Ethernet autoselect (1000baseTX ) >status: active > > # ifconfig vlan0 > vlan0: flags=8843 metric 0 mtu 1500 >ether 00:14:c1:40:c2:e8 >inet 192.168.100.1 netmask 0xff00 broadcast 192.168.100.255 >media: Ethernet autoselect (1000baseTX ) >status: active >vlan: 10 parent interface: re0 > - > > on PC #2 : > - > # ifconfig re0 > re0: flags=8843 metric 0 mtu 1500 >options=98 >ether 00:15:8a:00:48:80 >inet 192.168.60.2 netmask 0xff00 broadcast 192.168.60.255 >media: Ethernet autoselect (1000baseTX ) >status: active > > # ifconfig vlan0 > vlan0: flags=8843 metric 0 mtu 1500 >ether 00:15:8a:00:48:80 >inet 192.168.100.2 netmask 0xff00 broadcast 192.168.100.255 >media: Ethernet autoselect (1000baseTX ) >status: active >vlan: 10 parent interface: re0 > - > > > > Any packet greater than 1472 which gets fragmented doesn't pass through: > command : ping -c 1 -s 1473 192.168.100.2 > > on the sending machine: > - > # tcpdump -i re0 -n -vvv not tcp and not stp > > 23:11:07.649600 IP (tos 0x0, ttl 64, id 399, offset 0, flags [+], proto > ICMP (1), length 1500) 192.168.100.1 > 192.168.100.2: ICMP echo request, > id 19972, seq 0, length 1480 > 23:11:07.649605 IP (tos 0x0, ttl 64, id 399, offset 1480, flags [none], > proto ICMP (1), length 21) 192.168.100.1 > 192.168.100.2: icmp > - > > > Whereas on the receiving machine I don't get any packet. > To rule out other possible issues, would you try the following files on your box? http://people.freebsd.org/~yongari/re/if_re.c http://people.freebsd.org/~yongari/re/if_rereg.h -- Regards, Pyun YongHyeon ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [Wireless] Can't connect to wlan
Yousif Hassan wrote: On Wed, 2008-03-12 at 08:06 +1030, Benjamin Close wrote: Alphons "Fonz" van Werven wrote: Mel wrote: Do the recent patches by Andrew make a difference? http://people.freebsd.org/~thompsa/wpi_head.diff http://people.freebsd.org/~thompsa/wpi_releng7.diff (ccing freebsd-net) Ben, I had a go with this patch today on top of 7.0-RELEASE. The good: - Switching off the radio and back on finally works - nice work. - Scanning seems faster (but see caveat below) - Association is MUCH faster (mind you, I don't use an encrypted AP). - The "failed to align memory" stuff when the driver loads up - fixed. - The fact that it reloaded in the kernel even if I manually kldunloaded if_wpi.ko - fixed The slightly wonky: - As reported by someone else: wpi0: timeout resetting Tx ring 1 wpi0: timeout resetting Tx ring 3 wpi0: timeout resetting Tx ring 4 appear on startup and occasionally on kldload - however they don't appear to adversely affect too much The ugly: - I can only do an ifconfig wpi0 scan every OTHER time - in between successful attempts, I get wpi0: fatal firmware error wpi0: timeout resetting Tx ring (or: timeout resetting Tx ring 0) wpi0: link state changed to DOWN This wouldn't be so bad since it works every other time, but the problem is that every time I do a scan, it sets the link state down, causing the connection to drop - doesn't seem normal. Of course then it comes right back up but the network interruption is not so great. Hmm - what else? The whole thing seems - livelier. I need to run some throughput benchmarks but traffic to/from the card on my local network seems faster and more responsive. Hopefully this isn't the placebo effect. ;) Great work to you & rest of team on this patch... it's more than usable at this point! wpi doesn't yet support background scan so doing an explicit scan from the command line will disconnect you from any ap you care connected to. It shouldn't be hard to add bgscan--but that's easy for me to say :) Sam ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/121374: [ipsec] SP refcnt increases with each packet in ipv6 with new IPSEC
> Synopsis: [ipsec] SP refcnt increases with each packet in ipv6 with new IPSEC > > Wait for feedback if the patch presented is fine. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=121374 Ok, I've tested this patch. Exchanging packets through a policy works after a fashion, but after sending one packet the kernel deletes the policy, presumably because the refcnt goes to 0: hostB# setkey -DP hostA[any] hostB[any] any in ipsec esp/transport//require spid=22 seq=1 pid=1037 refcnt=1 hostB[any] hostA[any] any out ipsec esp/transport//require spid=21 seq=0 pid=1037 refcnt=1 hostB# ping6 hostA PING6(56=40+8+8 bytes) hostB --> hostA 16 bytes from hostA, icmp_seq=0 hlim=64 time=12.401 ms ^C --- hostA ping6 statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 12.401/12.401/12.401/0.000 ms hostB# setkey -DP hostA[any] hostB[any] any in ipsec esp/transport//require spid=22 seq=0 pid=1040 refcnt=1 So the outbound policy is gone! ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.3 fxp0 MBUF and PAE
On Wed, Mar 12, 2008 at 04:53:18PM -0300, Daniel Dias Gon?alves wrote: > Hi, > > When using the interface fxp0 with PAE enable in kernel, occurs the > following error: > > fxp0: can't map mbuf (error 12) > ... > > it repeats, repeats and lost communication. > error 12 means ENOMEM. bus_dmamap_load_mbuf_sg(9) failed due to insuffcient resources. I guess there is no way to overcome this situation in driver. The only remaining way I can think of would be reclaiming of transmitted frames but how well it works would depends on circumstances. Personally I don't see a reason to print these ENOMEM errors for production box without late limiting. > Information: > 6.3-RELEASE > > [EMAIL PROTECTED]:4:0: class=0x02 card=0x00708086 chip=0x12298086 > rev=0x10 > hdr=0x00 >vendor = 'Intel Corporation' >device = '82550/1/7/8/9 EtherExpress PRO/100(B) Ethernet Adapter' >class = network >subclass = ethernet > > I wait reply. > > Thanks. > > Daniel -- Regards, Pyun YongHyeon ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [Wireless] Can't connect to wlan
On Wed, 2008-03-12 at 08:06 +1030, Benjamin Close wrote: > Alphons "Fonz" van Werven wrote: > > Mel wrote: > > > >>> Do the recent patches by Andrew make a difference? > >>> > >>> http://people.freebsd.org/~thompsa/wpi_head.diff > >>> http://people.freebsd.org/~thompsa/wpi_releng7.diff > > (ccing freebsd-net) Ben, I had a go with this patch today on top of 7.0-RELEASE. The good: - Switching off the radio and back on finally works - nice work. - Scanning seems faster (but see caveat below) - Association is MUCH faster (mind you, I don't use an encrypted AP). - The "failed to align memory" stuff when the driver loads up - fixed. - The fact that it reloaded in the kernel even if I manually kldunloaded if_wpi.ko - fixed The slightly wonky: - As reported by someone else: wpi0: timeout resetting Tx ring 1 wpi0: timeout resetting Tx ring 3 wpi0: timeout resetting Tx ring 4 appear on startup and occasionally on kldload - however they don't appear to adversely affect too much The ugly: - I can only do an ifconfig wpi0 scan every OTHER time - in between successful attempts, I get wpi0: fatal firmware error wpi0: timeout resetting Tx ring (or: timeout resetting Tx ring 0) wpi0: link state changed to DOWN This wouldn't be so bad since it works every other time, but the problem is that every time I do a scan, it sets the link state down, causing the connection to drop - doesn't seem normal. Of course then it comes right back up but the network interruption is not so great. Hmm - what else? The whole thing seems - livelier. I need to run some throughput benchmarks but traffic to/from the card on my local network seems faster and more responsive. Hopefully this isn't the placebo effect. ;) Great work to you & rest of team on this patch... it's more than usable at this point! --Yousif ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VLAN trunking and fragmentation
On Thu, Mar 13, 2008 at 11:13:14AM +1300, Andrew Thompson wrote: > On Wed, Mar 12, 2008 at 12:38:06PM -0700, Sean Chittenden wrote: > >> interface ethernet 1/g1 > >> switchport mode trunk > >> switchport trunk allowed vlan add 10 > >> exit > > > > I think this is an issue with default VLAN membership. I have this config > > running on *hundreds* of servers without issue. Since Dell should be a > > cisco rip-off, on your switchport config, throw in (haven't tested this, on > > dell's CLI): > > > > switchport trunk encapsulation dot1q > > > > then change your ifconfig foo to: > > > > cloned_interfaces="vlan10 vlan11" > > ifconfig_re0="media 100baseTX mediaopt full-duplex" > > ifconfig_vlan10="vlan 10 vlandev re0" > > ifconfig_vlan10_alias0="inet 192.168.60.1 netmask 255.255.255.0" > > ifconfig_vlan11="vlan 11 valndev re0" > > ifconfig_vlan11_alias0="inet 192.168.100.1 netmask 255.255.255.0" > > > > FWIW, I think you'll find fewer gray hairs if you stick to the convention > > of using a vlan device that has the same VLAN tag. You may be able to have > > a default VLAN, but I consider it poor practice to rely on default VLAN > > membership. > > Even nicer is using . autoconfig, the following is > equivalent to above: > > cloned_interfaces="re0.10 re0.11" > ifconfig_re0="media 100baseTX mediaopt full-duplex" > ifconfig_re0.10="inet 192.168.60.1 netmask 255.255.255.0" > ifconfig_re0.11="inet 192.168.100.1 netmask 255.255.255.0" One small nit. The '.' isn't valid in variable names so the ifconfig_re0.xx lines need to turn into ifconfig_re0_xx (we compress ./-+ to _). -- Brooks pgpNHC7VvZrW6.pgp Description: PGP signature
Re: TCP options order changed in FreeBSD 7, incompatible with some routers
d.s. al coda wrote: Hi, We recently upgraded one of our webservers to FreeBSD 7, and we started receiving complaints from some users not able to connect to that server anymore. On top of that, users were saying that the problem only occurred on Windows (at least, the ones who had more than on OS to try it out). After managing to get a user who had the problem running windump, running tcpdump on the new server, and comparing that to the windump & tcpdump output for a "control" user (me) that could connect, we managed to figure out the following: - For the user with this problem, ping works fine, but all TCP connections to the server fail. - The user, trying to connect, sends out a SYN packet, receives no response, and retries a few times until timing out. - The server sees a bunch of SYN packets and responds with SYN-ACK each time. - The issue only seems to arise if the sender has RFC1323 disabled. So, the SYN-ACK is getting lost somewhere. - For the control user (who can connect via TCP just fine), we set the TCP window size and RFC1323 options the same as the user with the problem. - The control user sees the SYN-ACK packet. - We send a connection attempt to one of our other servers, running FreeBSD 5.5, and one to the server running FreeBSD 7. - There is only one notable difference between the responses: the order of the options. - FreeBSD 5.5 has - FreeBSD 7 has (there is of course an aligning nop after the eol, which tcpdump skips) - These options don't appear in this exact configuration when using RFC1323 options. I get a hunch that the users with the problem have a router that erroneously thinks that these options are invalid, or thinks that the some part of byte sequence (e.g. 0204 05b4 0101 0402) is an attack. Just to try it out, I patched tcp_output.c so that the SACK permitted option was aligned on a 4-byte boundary, preventing the "sackOK, eol" pattern from ever occuring. Looking through previous versions, I found where the tcp option code had changed, and there used to be a comment about putting SACK permitted last, but I can't tell if it's relevant. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_output.c.diff?r1=1.125;r2=1.126 The one-line patch to tcp_output.c is attached. Sure enough, it fixed the problem. Afterwards, we collected some information about the routers the users who had the problem were using, and while they didn't all have the same manufacturer, several mentioned that their router had a built-in firewall, which, when they disabled it, allowed them to access the server. I'd be very interesting to know the exactly models and their firmware version of the affected routers. If available locally I'd like to obtain a similar model myself for future regression tests. Does all of this sound reasonable? And if so, would it be worth submitting this patch? I don't know if this particular change in options order was intentional, or just a side-effect of the new code, but it certainly works around an extremely hard-to-diagnose problem. We've already fixed two issues. The first changes the order of the TCP options and is in this change: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_var.h.diff?r1=1.160;r2=1.161 It is to solve a problem observed by ISC that sounds very much like what you describe. This fixed the issue in this case. The second changes the alignment padding from NOP to 0x00. Whether this was a contributing factor to the reported problem is not clear. There hasn't (yet) been any specific test case for it. It was fixed because the RFC specifies 0x00 to be used for padding and nothing else. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_output.c.diff?r1=1.145;r2=1.146 It would be very helpful if you could apply these two patches after each other to your 7.0 test server and find out together with the affected user(s) which of these fixes the issue. If you can please try to test each one with and w/o the routers firewall enabled. It is interesting to know whether the NAT or firewalling part of the router chokes on it. Your help is very appreciated and I try to document all strange TCP occurrences so we can incorporate them into a regression test suite later on. The more information we have the better it'll become. -- Andre ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VLAN trunking and fragmentation
interface ethernet 1/g1 switchport mode trunk switchport trunk allowed vlan add 10 exit I think this is an issue with default VLAN membership. I don't think it's where the problem lies, otherwise even a simple ping wouldn't work. The problem here explicitly arises when packets are fragmented... fragmentation? I think, you use ethernet links, all have 1500byte max packet size, you have 1500byte packet size also comfigured at the vlan interface, so.. why do you think anything should start fragmenting? (and tagged vlan frames are bigger than 1500byte at the "raw" ethernet link). check for maximum mtu that can travel over the link. (ping -s 1472 for 1500byte packet) It's the MTU size, not the fragmentation or VLAN membership. The use of a default VLAN can cause problems potentially because the size of each frame can vary and, IMHO, is the cause of the problem. By default VLAN membership, I don't mean to suggest you've got your port tagged in the wrong VLAN. Switch all traffic to 802.1q tagged and you should see everything work. Use of VLANs reduces the MTU size automatically, but cycling between the two? Likely a no-go and the source of your problems. Even nicer is using . autoconfig, the following is equivalent to above: cloned_interfaces="re0.10 re0.11" ifconfig_re0="media 100baseTX mediaopt full-duplex" ifconfig_re0.10="inet 192.168.60.1 netmask 255.255.255.0" ifconfig_re0.11="inet 192.168.100.1 netmask 255.255.255.0" *boggles* That's hawt! 'ya learn something new every day, thanks! :~] -sc -- Sean Chittenden [EMAIL PROTECTED] http://sean.chittenden.org/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VLAN trunking and fragmentation
On Wed, Mar 12, 2008 at 12:38:06PM -0700, Sean Chittenden wrote: >> interface ethernet 1/g1 >> switchport mode trunk >> switchport trunk allowed vlan add 10 >> exit > > I think this is an issue with default VLAN membership. I have this config > running on *hundreds* of servers without issue. Since Dell should be a > cisco rip-off, on your switchport config, throw in (haven't tested this, on > dell's CLI): > > switchport trunk encapsulation dot1q > > then change your ifconfig foo to: > > cloned_interfaces="vlan10 vlan11" > ifconfig_re0="media 100baseTX mediaopt full-duplex" > ifconfig_vlan10="vlan 10 vlandev re0" > ifconfig_vlan10_alias0="inet 192.168.60.1 netmask 255.255.255.0" > ifconfig_vlan11="vlan 11 valndev re0" > ifconfig_vlan11_alias0="inet 192.168.100.1 netmask 255.255.255.0" > > FWIW, I think you'll find fewer gray hairs if you stick to the convention > of using a vlan device that has the same VLAN tag. You may be able to have > a default VLAN, but I consider it poor practice to rely on default VLAN > membership. Even nicer is using . autoconfig, the following is equivalent to above: cloned_interfaces="re0.10 re0.11" ifconfig_re0="media 100baseTX mediaopt full-duplex" ifconfig_re0.10="inet 192.168.60.1 netmask 255.255.255.0" ifconfig_re0.11="inet 192.168.100.1 netmask 255.255.255.0" Andrew ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VLAN trunking and fragmentation
Dear Giuilio, Sean Chittenden wrote: interface ethernet 1/g1 switchport mode trunk switchport trunk allowed vlan add 10 exit I think this is an issue with default VLAN membership. I don't think it's where the problem lies, otherwise even a simple ping wouldn't work. The problem here explicitly arises when packets are fragmented... fragmentation? I think, you use ethernet links, all have 1500byte max packet size, you have 1500byte packet size also comfigured at the vlan interface, so.. why do you think anything should start fragmenting? (and tagged vlan frames are bigger than 1500byte at the "raw" ethernet link). check for maximum mtu that can travel over the link. (ping -s 1472 for 1500byte packet) switchport trunk encapsulation dot1q There's no such option, I believe it's implicit in the trunk mode... and put the server back to back and remove the switch, just to be shure the switch is not the problem. Kind regards, Ingo Flaschberger ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VLAN trunking and fragmentation
Sean Chittenden wrote: interface ethernet 1/g1 switchport mode trunk switchport trunk allowed vlan add 10 exit I think this is an issue with default VLAN membership. I don't think it's where the problem lies, otherwise even a simple ping wouldn't work. The problem here explicitly arises when packets are fragmented... switchport trunk encapsulation dot1q There's no such option, I believe it's implicit in the trunk mode... then change your ifconfig foo to: cloned_interfaces="vlan10 vlan11" ifconfig_re0="media 100baseTX mediaopt full-duplex" ifconfig_vlan10="vlan 10 vlandev re0" ifconfig_vlan10_alias0="inet 192.168.60.1 netmask 255.255.255.0" ifconfig_vlan11="vlan 11 valndev re0" ifconfig_vlan11_alias0="inet 192.168.100.1 netmask 255.255.255.0" Apart from vlan names, this configuration is equivalent to mine... There are good reasons to have a default VLAN configured, but this doesn't sound like one of those cases. I have no default vlan. Thanks for your answer. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VLAN trunking and fragmentation
Sam Leffler wrote: You failed to provide the output of ifconfig on your running system. Be sure any checksum offload is disabled (should be by the bridge). Sam My bad. I switched off checksum offload in /etc/rc.conf like this: ifconfig_re0="inet 192.168.60.1 netmask 255.255.255.0 -rxcsum -txcsum" (same thing on the other machine) Now my ifconfig on PC #1 is : - # ifconfig re0 re0: flags=8843 metric 0 mtu 1500 options=98 ether 00:14:c1:40:c2:e8 inet 192.168.60.1 netmask 0xff00 broadcast 192.168.60.255 media: Ethernet autoselect (1000baseTX ) status: active # ifconfig vlan0 vlan0: flags=8843 metric 0 mtu 1500 ether 00:14:c1:40:c2:e8 inet 192.168.100.1 netmask 0xff00 broadcast 192.168.100.255 media: Ethernet autoselect (1000baseTX ) status: active vlan: 10 parent interface: re0 - on PC #2 : - # ifconfig re0 re0: flags=8843 metric 0 mtu 1500 options=98 ether 00:15:8a:00:48:80 inet 192.168.60.2 netmask 0xff00 broadcast 192.168.60.255 media: Ethernet autoselect (1000baseTX ) status: active # ifconfig vlan0 vlan0: flags=8843 metric 0 mtu 1500 ether 00:15:8a:00:48:80 inet 192.168.100.2 netmask 0xff00 broadcast 192.168.100.255 media: Ethernet autoselect (1000baseTX ) status: active vlan: 10 parent interface: re0 - Any packet greater than 1472 which gets fragmented doesn't pass through: command : ping -c 1 -s 1473 192.168.100.2 on the sending machine: - # tcpdump -i re0 -n -vvv not tcp and not stp 23:11:07.649600 IP (tos 0x0, ttl 64, id 399, offset 0, flags [+], proto ICMP (1), length 1500) 192.168.100.1 > 192.168.100.2: ICMP echo request, id 19972, seq 0, length 1480 23:11:07.649605 IP (tos 0x0, ttl 64, id 399, offset 1480, flags [none], proto ICMP (1), length 21) 192.168.100.1 > 192.168.100.2: icmp - Whereas on the receiving machine I don't get any packet. Thanks for your answer. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VLAN trunking and fragmentation
On Wed, March 12, 2008 8:38 pm, Sean Chittenden wrote: >> interface ethernet 1/g1 >> switchport mode trunk >> switchport trunk allowed vlan add 10 >> exit > > I think this is an issue with default VLAN membership. I have this > config running on *hundreds* of servers without issue. Since Dell > should be a cisco rip-off, on your switchport config, throw in > (haven't tested this, on dell's CLI): > > switchport trunk encapsulation dot1q > > then change your ifconfig foo to: > > cloned_interfaces="vlan10 vlan11" > ifconfig_re0="media 100baseTX mediaopt full-duplex" > ifconfig_vlan10="vlan 10 vlandev re0" > ifconfig_vlan10_alias0="inet 192.168.60.1 netmask 255.255.255.0" > ifconfig_vlan11="vlan 11 valndev re0" > ifconfig_vlan11_alias0="inet 192.168.100.1 netmask 255.255.255.0" > > FWIW, I think you'll find fewer gray hairs if you stick to the > convention of using a vlan device that has the same VLAN tag. You may > be able to have a default VLAN, but I consider it poor practice to > rely on default VLAN membership. > > There are good reasons to have a default VLAN configured, but this > doesn't sound like one of those cases. > > Stick with explicit VLAN tagging on your servers and you can't go wrong. > > -sc > > -- > Sean Chittenden > [EMAIL PROTECTED] > http://sean.chittenden.org/ > For what it's worth: I am using the above setup a lot and that works fine for me! -- /"\ Best regards, | [EMAIL PROTECTED] \ / Remko Lodder | [EMAIL PROTECTED] Xhttp://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD 6.3 fxp0 MBUF and PAE
Hi, When using the interface fxp0 with PAE enable in kernel, occurs the following error: fxp0: can't map mbuf (error 12) ... it repeats, repeats and lost communication. Information: 6.3-RELEASE [EMAIL PROTECTED]:4:0: class=0x02 card=0x00708086 chip=0x12298086 rev=0x10 hdr=0x00 vendor = 'Intel Corporation' device = '82550/1/7/8/9 EtherExpress PRO/100(B) Ethernet Adapter' class = network subclass = ethernet I wait reply. Thanks. Daniel ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VLAN trunking and fragmentation
interface ethernet 1/g1 switchport mode trunk switchport trunk allowed vlan add 10 exit I think this is an issue with default VLAN membership. I have this config running on *hundreds* of servers without issue. Since Dell should be a cisco rip-off, on your switchport config, throw in (haven't tested this, on dell's CLI): switchport trunk encapsulation dot1q then change your ifconfig foo to: cloned_interfaces="vlan10 vlan11" ifconfig_re0="media 100baseTX mediaopt full-duplex" ifconfig_vlan10="vlan 10 vlandev re0" ifconfig_vlan10_alias0="inet 192.168.60.1 netmask 255.255.255.0" ifconfig_vlan11="vlan 11 valndev re0" ifconfig_vlan11_alias0="inet 192.168.100.1 netmask 255.255.255.0" FWIW, I think you'll find fewer gray hairs if you stick to the convention of using a vlan device that has the same VLAN tag. You may be able to have a default VLAN, but I consider it poor practice to rely on default VLAN membership. There are good reasons to have a default VLAN configured, but this doesn't sound like one of those cases. Stick with explicit VLAN tagging on your servers and you can't go wrong. -sc -- Sean Chittenden [EMAIL PROTECTED] http://sean.chittenden.org/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: TCP options order changed in FreeBSD 7, incompatible with some routers
On Wed, Mar 12, 2008 at 1:48 AM, Andre Oppermann <[EMAIL PROTECTED]> wrote: > Kip Macy wrote: > > Are you running 7.0-RELEASE? What I believe was this issue was a > > showstopper for it, so I'm surprised to hear of it now. > > No, this is a different issue and not really the fault of TCP but > of certain cable modem vendors with broken code in their devices. > FreeBSD is fully compliant to the spec. Sibly committed a workaround > for this issue to -current and I expect the MFC to RELENG_7 and > RELENG_7_0 soon. We know your opinion Andre. Most people don't care whose fault it is, they just want it to work. I didn't realized that Silby's change hadn't made it in to the release. -Kip > > -- > Andre > > > > > -Kip > > > > On Tue, Mar 11, 2008 at 5:56 PM, d.s. al coda <[EMAIL PROTECTED]> wrote: > >> Hi, > >> We recently upgraded one of our webservers to FreeBSD 7, and we started > >> receiving complaints from some users not able to connect to that server > >> anymore. On top of that, users were saying that the problem only > occurred on > >> Windows (at least, the ones who had more than on OS to try it out). > >> > >> After managing to get a user who had the problem running windump, running > >> tcpdump on the new server, and comparing that to the windump & tcpdump > >> output for a "control" user (me) that could connect, we managed to figure > >> out the following: > >> - For the user with this problem, ping works fine, but all TCP > connections > >> to the server fail. > >> - The user, trying to connect, sends out a SYN packet, receives no > response, > >> and retries a few times until timing out. > >> - The server sees a bunch of SYN packets and responds with SYN-ACK each > >> time. > >> - The issue only seems to arise if the sender has RFC1323 disabled. > >> > >> So, the SYN-ACK is getting lost somewhere. > >> > >> - For the control user (who can connect via TCP just fine), we set the > TCP > >> window size and RFC1323 options the same as the user with the problem. > >> - The control user sees the SYN-ACK packet. > >> - We send a connection attempt to one of our other servers, running > FreeBSD > >> 5.5, and one to the server running FreeBSD 7. > >> - There is only one notable difference between the responses: the order > of > >> the options. > >> - FreeBSD 5.5 has > >> - FreeBSD 7 has (there is of course an aligning > nop > >> after the eol, which tcpdump skips) > >> - These options don't appear in this exact configuration when using > RFC1323 > >> options. > >> > >> I get a hunch that the users with the problem have a router that > erroneously > >> thinks that these options are invalid, or thinks that the some part of > byte > >> sequence (e.g. 0204 05b4 0101 0402) is an attack. > >> > >> Just to try it out, I patched tcp_output.c so that the SACK permitted > option > >> was aligned on a 4-byte boundary, preventing the "sackOK, eol" pattern > from > >> ever occuring. Looking through previous versions, I found where the tcp > >> option code had changed, and there used to be a comment about putting > SACK > >> permitted last, but I can't tell if it's relevant. > >> > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_output.c.diff?r1=1.125;r2=1.126 > >> > >> The one-line patch to tcp_output.c is attached. > >> > >> Sure enough, it fixed the problem. Afterwards, we collected some > information > >> about the routers the users who had the problem were using, and while > they > >> didn't all have the same manufacturer, several mentioned that their > router > >> had a built-in firewall, which, when they disabled it, allowed them to > >> access the server. > >> > >> Does all of this sound reasonable? And if so, would it be worth > submitting > >> this patch? I don't know if this particular change in options order was > >> intentional, or just a side-effect of the new code, but it certainly > works > >> around an extremely hard-to-diagnose problem. > >> > >> -coda > >> > >> ___ > >> freebsd-net@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-net > >> To unsubscribe, send any mail to "[EMAIL PROTECTED]" > >> > > ___ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > > > > > > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: TCP options order changed in FreeBSD 7, incompatible with some routers
On Tue, Mar 11, 2008 at 5:56 PM, d.s. al coda <[EMAIL PROTECTED]> wrote: > Hi, > We recently upgraded one of our webservers to FreeBSD 7, and we started > receiving complaints from some users not able to connect to that server > anymore. On top of that, users were saying that the problem only occurred on > Windows (at least, the ones who had more than on OS to try it out). ... Me too: I saw this exact problem with RELENG_7 a month or so ago, and worked around it by disabling SACK. Matt ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FYI: inpcb/pcbinfo mutex -> rwlock at some point in the mid-distant future
FYI: Kris Kennaway and I have been working on diagnosing and addressing network stack contention and scheduling issues for high performance DNS serving with nsd and bind9. One of the changes in the pipeline is converting from using a mutex to protect the pcbinfo and inpcb data structures to an rwlock, so that UDP, which doesn't require exclusion for either of those structures in a number of key cases, doesn't have to experience as high contention. TCP would continue to use them only exclusively [for now]. This is a heads up that this change will likely end up in HEAD in the next month or two, but we're still working through some issues. This may well be something that can be MFC'd as rwlocks are intentionally fairly layout compatible with mutexes, and these locks and the data structures they protect are not considered "public" structures from the perspective of most kernel modules (although there are potentially issues with firewalls that reach "up" the stack to look at th connection table). One of those issues is that we need to demonstrate to ourselves that exclusive access contention is managed as well with rwlocks as with sleep mutexes, as these locks would continue to be fairly highly contended in TCP. The other issue is that rwlocks don't support full priority propagation for reader access, although Jeff Roberson has recently improved fairness to writers with many readers. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: TCP options order changed in FreeBSD 7, incompatible with some routers
On Tue, 11 Mar 2008, d.s. al coda wrote: - FreeBSD 7 has (there is of course an aligning nop after the eol, which tcpdump skips) Which is a bug (the nop after the EOL) that I recently fixed in HEAD. I am still curious to know if it's only ordering or the invalid padding or both that keeps clients from connecting. The problem is getting hands on such a problematic "client". I still cannot see why someone would drop because of option ordering but I could see why someone would drop because of the wrong padding which is violating the TCP RFC. Of course other exmaples seem to have shown that it was option ordering that made peers freak out and drop the packet. - These options don't appear in this exact configuration when using RFC1323 options. I get a hunch that the users with the problem have a router that erroneously thinks that these options are invalid, or thinks that the some part of byte sequence (e.g. 0204 05b4 0101 0402) is an attack. Just to try it out, I patched tcp_output.c so that the SACK permitted option was aligned on a 4-byte boundary, preventing the "sackOK, eol" pattern from ever occuring. Looking through previous versions, I found where the tcp option code had changed, and there used to be a comment about putting SACK permitted last, but I can't tell if it's relevant. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_output.c.diff?r1=1.125;r2=1.126 The one-line patch to tcp_output.c is attached. Sure enough, it fixed the problem. Afterwards, we collected some information That of course seems to have dropped the need for padding after a possible EOL (if there is no EOL anymore) hiding the second problem. I wonder if you would have the resources to try this patch (on an unpatched kernel) http://docs.freebsd.org/cgi/mid.cgi?200803091326.m29DQoCI095152 and find out if one of the formerly not working users can connect again. As said before this might not be the case and it might be option alignment/ordering but that would rule out the padding problem for us. /bz -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: TCP options order changed in FreeBSD 7, incompatible with some routers
On Tue, 11 Mar 2008, d.s. al coda wrote: Hi, We recently upgraded one of our webservers to FreeBSD 7, and we started receiving complaints from some users not able to connect to that server anymore. On top of that, users were saying that the problem only occurred on Windows (at least, the ones who had more than on OS to try it out). This sounds like the issue Jake Rizzo has been describing. The tcp_var.h change I put in a few days ago only seems to help when timestamps are enabled. I'll try to sit down and read through this e-mail tonight. -Mike ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
VLAN trunking and fragmentation
I need to configure ports to work with multiple vlan on my redundant freebsd router/firewall. In order to setup my test environment I have 2 freebsd boxes 7.0 STABLE amd64 both with gigabit realtek (re0). According to what the man says, these cards should support vlan in hardware. These PCs are connected to a dell 48 port managed layer-3 switch on port 1 and 2. On the dell CLI I configure the vlans: --- enable configure vlan database vlan 10 exit interface vlan 10 name testvlan exit interface ethernet 1/g1 switchport mode trunk switchport trunk allowed vlan add 10 exit interface ethernet 1/g2 switchport mode trunk switchport trunk allowed vlan add 10 exit --- On both PC I have configured a vlan interface like this: from /etc/rc.conf --- ifconfig_re0="inet 192.168.60.1 netmask 255.255.255.0" cloned_interfaces="vlan0" ifconfig_vlan0="inet 192.168.100.1 netmask 255.255.255.0 vlan 10 vlandev re0" --- same on the other PC, but with physical address = 192.168.60.2 and virtual address 192.168.100.2 When I now try to ping from one machine to the other there is no problem: --- # ping -c 1 192.168.100.2 PING 192.168.100.2 (192.168.100.2): 56 data bytes 64 bytes from 192.168.100.2: icmp_seq=0 ttl=64 time=0.108 ms --- 192.168.100.2 ping statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.108/0.108/0.108/0.000 ms --- The problems start when I send a packet which is bigger than 1472 bytes: --- ping -c 1 -s 1473 192.168.100.2 --- The packet is fragmented as it should, but there seems to be some problem with the checksum computation. --- # on PC 192.168.100.1 tcpdump -i re0 -n -vvv not stp 13:33:37.789615 IP (tos 0x0, ttl 64, id 809, offset 0, flags [+], proto ICMP (1), length 1500, bad cksum 0 (->8a4)!) 192.168.100.1 > 192.168.100.2: ICMP echo request, id 31748, seq 0, length 1480 13:33:37.789622 IP (tos 0x0, ttl 64, id 809, offset 1480, flags [none], proto ICMP (1), length 21, bad cksum 0 (->2db2)!) 192.168.100.1 > 192.168.100.2: icmp #on PC 192.168.100.2 tcpdump -i re0 -n -vvv not stp 13:32:49.038581 IP (tos 0x0, ttl 64, id 809, offset 1480, flags [none], proto ICMP (1), length 21) 192.168.100.1 > 192.168.100.2: icmp --- I'm told that this same configuration works under linux. It seems to me this could be a bug of the vlan stack under freebsd... Thanks in advance for any workaround / quick patch to solve this issue. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: TCP options order changed in FreeBSD 7, incompatible with some routers
On Wed, 12 Mar 2008, Andre Oppermann wrote: Kip Macy wrote: Are you running 7.0-RELEASE? What I believe was this issue was a showstopper for it, so I'm surprised to hear of it now. No, this is a different issue and not really the fault of TCP but of certain cable modem vendors with broken code in their devices. FreeBSD is fully compliant to the spec. Sibly committed a workaround for this issue to -current and I expect the MFC to RELENG_7 and RELENG_7_0 soon. Sounds like a potential errata patch candidate. re@ added to the CC line. We should probably wait a couple of weeks to let it settle out, as well as see what other surprises with TCP are in store for us that we might want to fix in the same patch. Robert N M Watson Computer Laboratory University of Cambridge -- Andre -Kip On Tue, Mar 11, 2008 at 5:56 PM, d.s. al coda <[EMAIL PROTECTED]> wrote: Hi, We recently upgraded one of our webservers to FreeBSD 7, and we started receiving complaints from some users not able to connect to that server anymore. On top of that, users were saying that the problem only occurred on Windows (at least, the ones who had more than on OS to try it out). After managing to get a user who had the problem running windump, running tcpdump on the new server, and comparing that to the windump & tcpdump output for a "control" user (me) that could connect, we managed to figure out the following: - For the user with this problem, ping works fine, but all TCP connections to the server fail. - The user, trying to connect, sends out a SYN packet, receives no response, and retries a few times until timing out. - The server sees a bunch of SYN packets and responds with SYN-ACK each time. - The issue only seems to arise if the sender has RFC1323 disabled. So, the SYN-ACK is getting lost somewhere. - For the control user (who can connect via TCP just fine), we set the TCP window size and RFC1323 options the same as the user with the problem. - The control user sees the SYN-ACK packet. - We send a connection attempt to one of our other servers, running FreeBSD 5.5, and one to the server running FreeBSD 7. - There is only one notable difference between the responses: the order of the options. - FreeBSD 5.5 has - FreeBSD 7 has (there is of course an aligning nop after the eol, which tcpdump skips) - These options don't appear in this exact configuration when using RFC1323 options. I get a hunch that the users with the problem have a router that erroneously thinks that these options are invalid, or thinks that the some part of byte sequence (e.g. 0204 05b4 0101 0402) is an attack. Just to try it out, I patched tcp_output.c so that the SACK permitted option was aligned on a 4-byte boundary, preventing the "sackOK, eol" pattern from ever occuring. Looking through previous versions, I found where the tcp option code had changed, and there used to be a comment about putting SACK permitted last, but I can't tell if it's relevant. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_output.c.diff?r1=1.125;r2=1.126 The one-line patch to tcp_output.c is attached. Sure enough, it fixed the problem. Afterwards, we collected some information about the routers the users who had the problem were using, and while they didn't all have the same manufacturer, several mentioned that their router had a built-in firewall, which, when they disabled it, allowed them to access the server. Does all of this sound reasonable? And if so, would it be worth submitting this patch? I don't know if this particular change in options order was intentional, or just a side-effect of the new code, but it certainly works around an extremely hard-to-diagnose problem. -coda ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: TCP options order changed in FreeBSD 7, incompatible with some routers
Exact same problem that i'm having. I confirmed it exists in 7.0 only since downgrading one of our servers back to 6.3 stable allowed the same clients to connect again. This seems to work for us as a workaround: sysctl net.inet.tcp.sack.enable=0 On 3/12/08, d.s. al coda <[EMAIL PROTECTED]> wrote: > > On 3/11/08, Kip Macy <[EMAIL PROTECTED]> wrote: > > > Are you running 7.0-RELEASE? What I believe was this issue was a > > showstopper for it, so I'm surprised to hear of it now. > > > > -Kip > > > > > Yes, we are running 7.0-RELEASE. > > -coda > > > On Tue, Mar 11, 2008 at 5:56 PM, d.s. al coda <[EMAIL PROTECTED]> > > wrote: > > > Hi, > > > We recently upgraded one of our webservers to FreeBSD 7, and we > started > > > receiving complaints from some users not able to connect to that > server > > > anymore. On top of that, users were saying that the problem only > > occurred on > > > Windows (at least, the ones who had more than on OS to try it out). > > > > > > After managing to get a user who had the problem running windump, > > running > > > tcpdump on the new server, and comparing that to the windump & > tcpdump > > > output for a "control" user (me) that could connect, we managed to > > figure > > > out the following: > > > - For the user with this problem, ping works fine, but all TCP > > connections > > > to the server fail. > > > - The user, trying to connect, sends out a SYN packet, receives no > > response, > > > and retries a few times until timing out. > > > - The server sees a bunch of SYN packets and responds with SYN-ACK > each > > > time. > > > - The issue only seems to arise if the sender has RFC1323 disabled. > > > > > > So, the SYN-ACK is getting lost somewhere. > > > > > > - For the control user (who can connect via TCP just fine), we set > the > > TCP > > > window size and RFC1323 options the same as the user with the > problem. > > > - The control user sees the SYN-ACK packet. > > > - We send a connection attempt to one of our other servers, running > > FreeBSD > > > 5.5, and one to the server running FreeBSD 7. > > > - There is only one notable difference between the responses: the > order > > of > > > the options. > > > - FreeBSD 5.5 has > > > - FreeBSD 7 has (there is of course an > aligning > > nop > > > after the eol, which tcpdump skips) > > > - These options don't appear in this exact configuration when using > > RFC1323 > > > options. > > > > > > I get a hunch that the users with the problem have a router that > > erroneously > > > thinks that these options are invalid, or thinks that the some part > of > > byte > > > sequence (e.g. 0204 05b4 0101 0402) is an attack. > > > > > > Just to try it out, I patched tcp_output.c so that the SACK permitted > > option > > > was aligned on a 4-byte boundary, preventing the "sackOK, eol" > pattern > > from > > > ever occuring. Looking through previous versions, I found where the > > tcp > > > option code had changed, and there used to be a comment about putting > > SACK > > > permitted last, but I can't tell if it's relevant. > > > > > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_output.c.diff?r1=1.125;r2=1.126 > > > > > > The one-line patch to tcp_output.c is attached. > > > > > > Sure enough, it fixed the problem. Afterwards, we collected some > > information > > > about the routers the users who had the problem were using, and while > > they > > > didn't all have the same manufacturer, several mentioned that their > > router > > > had a built-in firewall, which, when they disabled it, allowed them > to > > > access the server. > > > > > > Does all of this sound reasonable? And if so, would it be worth > > submitting > > > this patch? I don't know if this particular change in options order > was > > > intentional, or just a side-effect of the new code, but it certainly > > works > > > around an extremely hard-to-diagnose problem. > > > > > > -coda > > > > > > ___ > > > freebsd-net@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > > To unsubscribe, send any mail to "[EMAIL PROTECTED] > " > > > > > > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: TCP options order changed in FreeBSD 7, incompatible with some routers
Kip Macy wrote: Are you running 7.0-RELEASE? What I believe was this issue was a showstopper for it, so I'm surprised to hear of it now. No, this is a different issue and not really the fault of TCP but of certain cable modem vendors with broken code in their devices. FreeBSD is fully compliant to the spec. Sibly committed a workaround for this issue to -current and I expect the MFC to RELENG_7 and RELENG_7_0 soon. -- Andre -Kip On Tue, Mar 11, 2008 at 5:56 PM, d.s. al coda <[EMAIL PROTECTED]> wrote: Hi, We recently upgraded one of our webservers to FreeBSD 7, and we started receiving complaints from some users not able to connect to that server anymore. On top of that, users were saying that the problem only occurred on Windows (at least, the ones who had more than on OS to try it out). After managing to get a user who had the problem running windump, running tcpdump on the new server, and comparing that to the windump & tcpdump output for a "control" user (me) that could connect, we managed to figure out the following: - For the user with this problem, ping works fine, but all TCP connections to the server fail. - The user, trying to connect, sends out a SYN packet, receives no response, and retries a few times until timing out. - The server sees a bunch of SYN packets and responds with SYN-ACK each time. - The issue only seems to arise if the sender has RFC1323 disabled. So, the SYN-ACK is getting lost somewhere. - For the control user (who can connect via TCP just fine), we set the TCP window size and RFC1323 options the same as the user with the problem. - The control user sees the SYN-ACK packet. - We send a connection attempt to one of our other servers, running FreeBSD 5.5, and one to the server running FreeBSD 7. - There is only one notable difference between the responses: the order of the options. - FreeBSD 5.5 has - FreeBSD 7 has (there is of course an aligning nop after the eol, which tcpdump skips) - These options don't appear in this exact configuration when using RFC1323 options. I get a hunch that the users with the problem have a router that erroneously thinks that these options are invalid, or thinks that the some part of byte sequence (e.g. 0204 05b4 0101 0402) is an attack. Just to try it out, I patched tcp_output.c so that the SACK permitted option was aligned on a 4-byte boundary, preventing the "sackOK, eol" pattern from ever occuring. Looking through previous versions, I found where the tcp option code had changed, and there used to be a comment about putting SACK permitted last, but I can't tell if it's relevant. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_output.c.diff?r1=1.125;r2=1.126 The one-line patch to tcp_output.c is attached. Sure enough, it fixed the problem. Afterwards, we collected some information about the routers the users who had the problem were using, and while they didn't all have the same manufacturer, several mentioned that their router had a built-in firewall, which, when they disabled it, allowed them to access the server. Does all of this sound reasonable? And if so, would it be worth submitting this patch? I don't know if this particular change in options order was intentional, or just a side-effect of the new code, but it certainly works around an extremely hard-to-diagnose problem. -coda ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
