Re: TCP options order changed in FreeBSD 7, incompatible with some routers
On Wed, 12 Mar 2008, Mike Silbersack wrote: 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 1460,sackOK,eol,eol> 7.0: IP A > B : S 3304309835:3304309835(0) ack 710421411 win 65535 1380,sackOK,eol,nop> That makes the problem quite a bit more clear. Anyone working on this issue should apply this patch ASAP. While this makes it more clear I'd rather see things in hex after the first EOL but either way is fine, just to see it. Ideally tcpdump would also complain if any padding after EOL is not 0x00. I wonder if wireshark does? -- 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 Wed, 12 Mar 2008, Mike Silbersack wrote: 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'll do that the next hours. 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]" -- 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: VLAN trunking and fragmentation
Pyun YongHyeon wrote: 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 The latter is if_rlreg.h, I guess... Anyway they don't compile: cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /usr/src/sys/dev/random/yarrow.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /usr/src/sys/dev/re/if_re.c /usr/src/sys/dev/re/if_re.c: In function 're_allocmem': /usr/src/sys/dev/re/if_re.c:997: error: 'struct rl_list_data' has no member named 'rl_rx_desc_cnt' /usr/src/sys/dev/re/if_re.c:998: error: 'struct rl_list_data' has no member named 'rl_tx_desc_cnt' /usr/src/sys/dev/re/if_re.c:1017: error: 'RL_NTXSEGS' undeclared (first use in this function) /usr/src/sys/dev/re/if_re.c:1017: error: (Each undeclared identifier is reported only once /usr/src/sys/dev/re/if_re.c:1017: error: for each function it appears in.) /usr/src/sys/dev/re/if_re.c:1018: error: 'struct rl_list_data' has no member named 'rl_tx_mtag' /usr/src/sys/dev/re/if_re.c:1030: error: 'struct rl_list_data' has no member named 'rl_rx_mtag' /usr/src/sys/dev/re/if_re.c:1073: error: 'struct rl_list_data' has no member named 'rl_tx_desc_cnt' /usr/src/sys/dev/re/if_re.c:1074: error: 'struct rl_list_data' has no member named 'rl_tx_mtag' /usr/src/sys/dev/re/if_re.c:1075: error: 'struct rl_list_data' has no member named 'rl_tx_desc' /usr/src/sys/dev/re/if_re.c:1119: error: 'struct rl_list_data' has no member named 'rl_rx_mtag' /usr/src/sys/dev/re/if_re.c:1120: error: 'struct rl_list_data' has no member named 'rl_rx_sparemap' /usr/src/sys/dev/re/if_re.c:1125: error: 'struct rl_list_data' has no member named 'rl_rx_desc_cnt' /usr/src/sys/dev/re/if_re.c:1126: error: 'struct rl_list_data' has no member named 'rl_rx_mtag' /usr/src/sys/dev/re/if_re.c:1127: error: 'struct rl_list_data' has no member named 'rl_rx_desc' /usr/src/sys/dev/re/if_re.c: In function 're_attach': /usr/src/sys/dev/re/if_re.c:1200: error: 'RL_CFG2_MSI' undeclared (first use in this function) /usr/src/sys/dev/re/if_re.c:1266: error: 'struct rl_list_data' has no member named 'rl_tx_desc_cnt' /usr/src/sys/dev/re/if_re.c:1266: error: 'RL_8169_TX_DESC_CNT' undeclared (first use in this function) /usr/src/sys/dev/re/if_re.c:1267: error: 'struct rl_list_data' has no member named 'rl_rx_desc_cnt' /usr/src/sys/dev/re/if_re.c:1267: error: 'RL_8169_RX_DESC_CNT' undeclared (first use in this function) /usr/src/sys/dev/re/if_re.c:1272: error: 'struct rl_list_data' has no member named 'rl_tx_desc_cnt' /usr/src/sys/dev/re/if_re.c:1272: error: 'RL_8139_TX_DESC_CNT' undeclared (first use in this function) /usr/src/sys/dev/re/if_re.c:1273: error: 'struct rl_list_data' has no member named 'rl_rx_desc_cnt' /usr/src/sys/dev/re/if_re.c:1273: error: 'RL_8139_RX_DESC_CNT' undeclared (first use in this function) /usr/src/sys/dev/re/if_re.c: In function 're_detach': /usr/src/sys/dev/re/if_re.c:1517: error: 'struct rl_list_data' has no member named 'rl_tx_mtag' /usr/src/sys/dev/re/if_re.c:1518: error: 'struct rl_list_data' has no member named 'rl_tx_desc_cnt' /usr/src/sys/dev/re/if_re.c:1519: error: 'struct rl_list_data' has no member named 'rl_tx_mtag' /usr/src/sys/dev/re/if_re.c:1520: error: 'struct rl_list_data' has no member named 'rl_tx_desc' /usr/src/sys/dev/re/if_re.c:1521: error: 'struct rl_list_data' has no member named 'rl_tx_mtag' /usr/src/sys/dev/re/if_re.c:1523: error: 'struct rl_list_data' has no member named 'rl_rx_mtag' /usr/src/sys/dev/re/if_re.c:1524: error: 'struct rl_list_data' has no member named 'rl_rx_desc_cnt' /usr/src/sys/dev/re/if_re.c:1525: error: 'struct rl_list_data' has no member named 'rl_rx_mtag' /usr/src/sys/dev/re/if_re.c:1526: error: 'struct rl_list_data' has no member named 'rl_rx_desc' /usr/src/sys/dev/re/if_r
Re: VLAN trunking and fragmentation
Giulio, good day. Thu, Mar 13, 2008 at 02:43:57PM +0100, Giulio Ferro wrote: > Pyun YongHyeon wrote: >> 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 >> >> > The latter is if_rlreg.h, I guess... > > Anyway they don't compile: If you're running 7.x, you probably want to get the files from http://people.freebsd.org/~yongari/re/7.0R/ For 6.3 use http://people.freebsd.org/~yongari/re/6.3R/ I am running the 7.x flavour and it compiled without problems around two weeks ago. And it is working far more better then the original driver. You seem to use the version for the -CURRENT. -- Eygene ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
IPFW, DIVERT, and if_bridge
Hello, I posted a similar message to Questions but received no answer so I'm reposting a paraphrase here to see if anyone knows. I built FreeBSD 7.0 with options DIVERT and if_bridge to see if I could make snort_inline work with the bridging firewall I'm building. I found that the divert would not direct packets to snort_inline which sounded a little like the experiences people had when they tried to do this with the pre-6.x bridge. Is it still not possible to use divert with if_bridge? Here is what I'm seeing in ipfw. 65000 48 7382 count ip from any to any 65001 0 0 divert 8300 ip from any to any 65010 48 7382 allow ip from any to any Thank you, Chris Pratt ___ 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: 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 1460,sackOK,eol,eol> 7.0: IP A > B : S 3304309835:3304309835(0) ack 710421411 win 65535 1380,sackOK,eol,nop> That makes the problem quite a bit more clear. Anyone working on this issue should apply this patch ASAP. what do you think of this version? http://sources.zabbadoz.net/freebsd/patchset/20080313-01-tcpdump-print-tcp-option-padding.diff It should give you output like this: -- 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: IPFW, DIVERT, and if_bridge
On Thu, 2008-03-13 at 07:16 -0700, Chris wrote: > Hello, > > I posted a similar message to Questions but received no > answer so I'm reposting a paraphrase here to see if anyone > knows. > > I built FreeBSD 7.0 with options DIVERT and if_bridge to > see if I could make snort_inline work with the bridging > firewall I'm building. I found that the divert would not > direct packets to snort_inline which sounded a little like > the experiences people had when they tried to do this > with the pre-6.x bridge. > > Is it still not possible to use divert with if_bridge? Here > is what I'm seeing in ipfw. > > 65000 48 7382 count ip from any to any > 65001 0 0 divert 8300 ip from any to any > 65010 48 7382 allow ip from any to any Yes, it is possible to use divert with if_bridge and ipfw. It sounds like you have not enabled packet filtering on the bridge. I use the following: # /etc/sysctl.conf net.link.ether.ipfw=1 net.link.bridge.ipfw=0 net.link.bridge.pfil_bridge=0 net.link.bridge.pfil_member=1 # ipfw.conf 1 divert 8000 ip from any to any out via bridge0 > > Thank you, > Chris Pratt > > ___ > 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: VLAN trunking and fragmentation
Eygene Ryabinkin wrote: Giulio, good day. Thu, Mar 13, 2008 at 02:43:57PM +0100, Giulio Ferro wrote: Pyun YongHyeon wrote: 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 The latter is if_rlreg.h, I guess... Anyway they don't compile: If you're running 7.x, you probably want to get the files from http://people.freebsd.org/~yongari/re/7.0R/ Yes, these are the files I'm now using... # md5 if_re.c MD5 (if_re.c) = bab9ab56e24b5090b9cac6f697736602 # md5 if_rlreg.h MD5 (if_rlreg.h) = aa08e0f34bf394f7e43d180f0ffdd855 # uname -a FreeBSD x.x.x 7.0-STABLE FreeBSD 7.0-STABLE #0: Mon Mar 10 13:28:18 CET 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FIREWALL amd64 And this is how it aborts: cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /usr/src/sys/dev/re/if_re.c /usr/src/sys/dev/re/if_re.c: In function 're_allocmem': /usr/src/sys/dev/re/if_re.c:999: error: 'struct rl_list_data' has no member named 'rl_rx_desc_cnt' /usr/src/sys/dev/re/if_re.c:1000: error: 'struct rl_list_data' has no member named 'rl_tx_desc_cnt' /usr/src/sys/dev/re/if_re.c:1019: error: 'RL_NTXSEGS' undeclared (first use in this function) /usr/src/sys/dev/re/if_re.c:1019: error: (Each undeclared identifier is reported only once /usr/src/sys/dev/re/if_re.c:1019: error: for each function it appears in.) /usr/src/sys/dev/re/if_re.c:1020: error: 'struct rl_list_data' has no member named 'rl_tx_mtag' /usr/src/sys/dev/re/if_re.c:1032: error: 'struct rl_list_data' has no member named 'rl_rx_mtag' /usr/src/sys/dev/re/if_re.c:1075: error: 'struct rl_list_data' has no member named 'rl_tx_desc_cnt' /usr/src/sys/dev/re/if_re.c:1076: error: 'struct rl_list_data' has no member named 'rl_tx_mtag' /usr/src/sys/dev/re/if_re.c:1077: error: 'struct rl_list_data' has no member named 'rl_tx_desc' /usr/src/sys/dev/re/if_re.c:1121: error: 'struct rl_list_data' has no member named 'rl_rx_mtag' /usr/src/sys/dev/re/if_re.c:1122: error: 'struct rl_list_data' has no member named 'rl_rx_sparemap' /usr/src/sys/dev/re/if_re.c:1127: error: 'struct rl_list_data' has no member named 'rl_rx_desc_cnt' /usr/src/sys/dev/re/if_re.c:1128: error: 'struct rl_list_data' has no member named 'rl_rx_mtag' /usr/src/sys/dev/re/if_re.c:1129: error: 'struct rl_list_data' has no member named 'rl_rx_desc' /usr/src/sys/dev/re/if_re.c: In function 're_attach': /usr/src/sys/dev/re/if_re.c:1260: error: 'struct rl_list_data' has no member named 'rl_tx_desc_cnt' /usr/src/sys/dev/re/if_re.c:1260: error: 'RL_8169_TX_DESC_CNT' undeclared (first use in this function) /usr/src/sys/dev/re/if_re.c:1261: error: 'struct rl_list_data' has no member named 'rl_rx_desc_cnt' /usr/src/sys/dev/re/if_re.c:1261: error: 'RL_8169_RX_DESC_CNT' undeclared (first use in this function) /usr/src/sys/dev/re/if_re.c:1266: error: 'struct rl_list_data' has no member named 'rl_tx_desc_cnt' /usr/src/sys/dev/re/if_re.c:1266: error: 'RL_8139_TX_DESC_CNT' undeclared (first use in this function) /usr/src/sys/dev/re/if_re.c:1267: error: 'struct rl_list_data' has no member named 'rl_rx_desc_cnt' /usr/src/sys/dev/re/if_re.c:1267: error: 'RL_8139_RX_DESC_CNT' undeclared (first use in this function) /usr/src/sys/dev/re/if_re.c: In function 're_detach': /usr/src/sys/dev/re/if_re.c:1503: error: 'struct rl_list_data' has no member named 'rl_tx_mtag' /usr/src/sys/dev/re/if_re.c:1504: error: 'struct rl_list_data' has no member named 'rl_tx_desc_cnt' /usr/src/sys/dev/re/if_re.c:1505: error: 'struct rl_list_data' has no member named 'rl_tx_mtag' /usr/src/sys/dev/re/if_re.c:1506: error: 'struct rl_list_data' has no member named 'rl_tx_desc' /usr/src/sys/dev/re/if_re.c:1507: error: 'struct rl_list_data' has no member named 'rl_tx_mtag' /usr/src/sys/dev/re/if_re.c:1509: error: 'struct rl_list_data' has no member named 'rl_rx_mtag' /usr/src/sys/dev/re/if_re.c:1510: error: 'struct rl_list_data' has no member named 'rl_rx_desc_cnt' /usr/src/sys/dev/re/if_re.c:1511: error: 'struct rl_list_data' has no member named 'rl_rx_mtag' /usr/src/sys/dev/re/if_re.c:1512: error: 'struct rl_list_data' has no member named 'rl_rx_desc' /usr/src/sys/dev/re/if_re.c:1513: error: 'struct rl_list_data' has no member named 'rl_rx_sparemap' /usr/src/sys/dev/re/if_re.c:1514: error: 'struct rl_list_data' has no mem
Re: IPFW, DIVERT, and if_bridge
On Mar 13, 2008, at 8:34 AM, Ronald Roskens wrote: On Thu, 2008-03-13 at 07:16 -0700, Chris wrote: Hello, I posted a similar message to Questions but received no answer so I'm reposting a paraphrase here to see if anyone knows. I built FreeBSD 7.0 with options DIVERT and if_bridge to see if I could make snort_inline work with the bridging firewall I'm building. I found that the divert would not direct packets to snort_inline which sounded a little like the experiences people had when they tried to do this with the pre-6.x bridge. Is it still not possible to use divert with if_bridge? Here is what I'm seeing in ipfw. 65000 48 7382 count ip from any to any 65001 0 0 divert 8300 ip from any to any 65010 48 7382 allow ip from any to any Yes, it is possible to use divert with if_bridge and ipfw. It sounds like you have not enabled packet filtering on the bridge. I use the following: # /etc/sysctl.conf net.link.ether.ipfw=1 net.link.bridge.ipfw=0 net.link.bridge.pfil_bridge=0 net.link.bridge.pfil_member=1 # ipfw.conf 1 divert 8000 ip from any to any out via bridge0 Thanks very much. I had commented out two of these. The reason was that I was unable to differentiate between the local interface and the bridge (this is from memory). The reason isn't relevant anymore so I've set them correctly. The divert appears to work fine now as shown. 65000 5 288 count ip from any to any 65001 5 288 divert 8300 ip from any to any 65010 0 0 allow ip from any to any Thank you very much. Thank you, Chris Pratt ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net- [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: [Wireless] Can't connect to wlan
Sam Leffler wrote: 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 :) It's certainly on my todo list! Cheers, Benjamin ___ 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 02:43:57PM +0100, Giulio Ferro wrote: > Pyun YongHyeon wrote: > >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 ^^ Should be read if_rlreg.h > > > > > The latter is if_rlreg.h, I guess... Oops, yes. > > Anyway they don't compile: > Maybe you don't copy if_rlreg.h to /usr/src/sys/pci directory? The above files have latest fixes I'd like to commit and it should build without problems on CURRENT/RELENG_7/7.0-RELEASE. -- 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: kern/120958: no response to ICMP traffic on interface configured with a link-local address
The following reply was made to PR kern/120958; it has been noted by GNATS.
From: James Snow <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc:
Subject: Re: kern/120958: no response to ICMP traffic on interface configured
with a link-local address
Date: Thu, 13 Mar 2008 20:23:55 -0400
--IS0zKkzwUGydFO0o
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Attached is a patch that reworks the problematic if statement in
sys/netinet/ip_icmp.c and adds two new macros to sys/netinet/in.h.
This fixes the problem, and eliminates a duplicate check for loopback
addresses. (Although it introduces some redundant ntohl() calls.)
-Snow
--IS0zKkzwUGydFO0o
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="link-local-icmp.patch"
diff -ru /usr/src/sys/netinet/in.h /usr/src.new/sys/netinet/in.h
--- /usr/src/sys/netinet/in.h 2007-06-12 16:24:53.0 +
+++ /usr/src.new/sys/netinet/in.h 2008-03-13 10:44:29.0 +
@@ -379,6 +379,8 @@
#define IN_BADCLASS(i) (((u_int32_t)(i) & 0xf000) ==
0xf000)
#define IN_LINKLOCAL(i) (((u_int32_t)(i) & 0x) ==
0xa9fe)
+#define IN_LOOPBACK(i)(((u_int32_t)(i) & 0xff00) ==
0x7f00)
+#define IN_ZERONET(i) (((u_int32_t)(i) & 0xff00) == 0)
#define IN_PRIVATE(i) u_int32_t)(i) & 0xff00) == 0x0a00)
|| \
(((u_int32_t)(i) & 0xfff0) == 0xac10) || \
diff -ru /usr/src/sys/netinet/ip_icmp.c /usr/src.new/sys/netinet/ip_icmp.c
--- /usr/src/sys/netinet/ip_icmp.c 2007-10-07 20:44:23.0 +
+++ /usr/src.new/sys/netinet/ip_icmp.c 2008-03-13 11:03:44.0 +
@@ -622,13 +622,14 @@
struct mbuf *opts = 0;
int optlen = (ip->ip_hl << 2) - sizeof(struct ip);
- if (!in_canforward(ip->ip_src) &&
- ((ntohl(ip->ip_src.s_addr) & IN_CLASSA_NET) !=
- (IN_LOOPBACKNET << IN_CLASSA_NSHIFT))) {
+ if (IN_MULTICAST(ntohl(ip->ip_src.s_addr)) ||
+ IN_EXPERIMENTAL(ntohl(ip->ip_src.s_addr)) ||
+ IN_ZERONET(ntohl(ip->ip_src.s_addr)) ) {
m_freem(m); /* Bad return address */
icmpstat.icps_badaddr++;
goto done; /* Ip_output() will check for broadcast */
}
+
t = ip->ip_dst;
ip->ip_dst = ip->ip_src;
--IS0zKkzwUGydFO0o--
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[PATCH] kern/120958: no response to ICMP traffic on interface configured with a link-local address
On Fri, Feb 22, 2008 at 10:04:12PM +, Bruce M. Simpson wrote:
> I looked at this very briefly.
>
> It's gnarly because in_canforward() is a candidate for inlining and is a
> predicate which is being overloaded with different meanings by
> ip_forward()/ip_input() and icmp_reflect().
>
> So whilst the fix is most likely a 3 liner, it risks making the code
> look crap. We genuinely don't want to forward 169.254.0.0/16 traffic,
> however we genuinely need to reply to ICMP which originates from these
> ranges.
Attached is a patch that fixes the failure to respond to ICMP for
link-local addresses. I reworked the opening if statement in
icmp_reflect() to make it a touch more readable, and eliminated the call
to in_canforward() since its logic doesn't work in this context.
Also, I took a cue from the IN_LINKLOCAL() macro and added two new
macros to sys/netinet/in.h to perform checks for the loopback network
and the "zero" network. IN_LOOPBACK() and IN_ZERONET(), respectively.
IN_ZERONET seems like a lousy name, but the only alternative I could
find in RFC3330 was "'this' net," and IN_THISNET wasn't an improvement.
-Snow
diff -ru /usr/src/sys/netinet/in.h /usr/src.new/sys/netinet/in.h
--- /usr/src/sys/netinet/in.h 2007-06-12 16:24:53.0 +
+++ /usr/src.new/sys/netinet/in.h 2008-03-13 10:44:29.0 +
@@ -379,6 +379,8 @@
#define IN_BADCLASS(i) (((u_int32_t)(i) & 0xf000) == 0xf000)
#define IN_LINKLOCAL(i) (((u_int32_t)(i) & 0x) == 0xa9fe)
+#define IN_LOOPBACK(i) (((u_int32_t)(i) & 0xff00) == 0x7f00)
+#define IN_ZERONET(i) (((u_int32_t)(i) & 0xff00) == 0)
#define IN_PRIVATE(i) u_int32_t)(i) & 0xff00) == 0x0a00) || \
(((u_int32_t)(i) & 0xfff0) == 0xac10) || \
diff -ru /usr/src/sys/netinet/ip_icmp.c /usr/src.new/sys/netinet/ip_icmp.c
--- /usr/src/sys/netinet/ip_icmp.c 2007-10-07 20:44:23.0 +
+++ /usr/src.new/sys/netinet/ip_icmp.c 2008-03-13 11:03:44.0 +
@@ -622,13 +622,14 @@
struct mbuf *opts = 0;
int optlen = (ip->ip_hl << 2) - sizeof(struct ip);
- if (!in_canforward(ip->ip_src) &&
- ((ntohl(ip->ip_src.s_addr) & IN_CLASSA_NET) !=
- (IN_LOOPBACKNET << IN_CLASSA_NSHIFT))) {
+ if (IN_MULTICAST(ntohl(ip->ip_src.s_addr)) ||
+ IN_EXPERIMENTAL(ntohl(ip->ip_src.s_addr)) ||
+ IN_ZERONET(ntohl(ip->ip_src.s_addr)) ) {
m_freem(m); /* Bad return address */
icmpstat.icps_badaddr++;
goto done; /* Ip_output() will check for broadcast */
}
+
t = ip->ip_dst;
ip->ip_dst = ip->ip_src;
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] kern/120958: no response to ICMP traffic on interface configured with a link-local address
On Thu, Mar 13, 2008 at 08:40:07PM -0400, James Snow wrote:
>
> Also, I took a cue from the IN_LINKLOCAL() macro and added two new
> macros to sys/netinet/in.h to perform checks for the loopback network
> and the "zero" network. IN_LOOPBACK() and IN_ZERONET(), respectively.
Woops. I suppose the macros are more useful when they're actually
called.
Attached is a revised patch that performs the check for loopback
addresses less than twice but more than never.
-Snow
diff -ru src/sys/netinet/in.h src.new/sys/netinet/in.h
--- src/sys/netinet/in.h 2007-06-12 16:24:53.0 +
+++ src.new/sys/netinet/in.h 2008-03-13 10:44:29.0 +
@@ -379,6 +379,8 @@
#define IN_BADCLASS(i) (((u_int32_t)(i) & 0xf000) == 0xf000)
#define IN_LINKLOCAL(i) (((u_int32_t)(i) & 0x) == 0xa9fe)
+#define IN_LOOPBACK(i) (((u_int32_t)(i) & 0xff00) == 0x7f00)
+#define IN_ZERONET(i) (((u_int32_t)(i) & 0xff00) == 0)
#define IN_PRIVATE(i) u_int32_t)(i) & 0xff00) == 0x0a00) || \
(((u_int32_t)(i) & 0xfff0) == 0xac10) || \
diff -ru src/sys/netinet/ip_icmp.c src.new/sys/netinet/ip_icmp.c
--- src/sys/netinet/ip_icmp.c 2007-10-07 20:44:23.0 +
+++ src.new/sys/netinet/ip_icmp.c 2008-03-14 00:47:44.0 +
@@ -622,13 +622,15 @@
struct mbuf *opts = 0;
int optlen = (ip->ip_hl << 2) - sizeof(struct ip);
- if (!in_canforward(ip->ip_src) &&
- ((ntohl(ip->ip_src.s_addr) & IN_CLASSA_NET) !=
- (IN_LOOPBACKNET << IN_CLASSA_NSHIFT))) {
+ if (IN_MULTICAST(ntohl(ip->ip_src.s_addr)) ||
+ IN_EXPERIMENTAL(ntohl(ip->ip_src.s_addr)) ||
+ IN_LOOPBACK(ntohl(ip->ip_src.s_addr)) ||
+ IN_ZERONET(ntohl(ip->ip_src.s_addr)) ) {
m_freem(m); /* Bad return address */
icmpstat.icps_badaddr++;
goto done; /* Ip_output() will check for broadcast */
}
+
t = ip->ip_dst;
ip->ip_dst = ip->ip_src;
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ndis0 no link on 6.3-RELEASE
Hello everyone. First off, sorry for the double post, but I'm not 100% certain at where this post belongs. I've found via Google many problems with ndis0 and failure to find a link in 6.3-RELEASE, without resolution. So here's my setup. I'm using a Broadcom 4318 chipset, with drivers created from ndisgen. If you need more specific information on the drivers, I'll be more than happy to provide information, however I believe it to be irrelevant at this moment, as I have used more than one driver version, with the same results. In 6.3-RC1 and below (tested in 6.2-RELEASE, and all -STABLE releases in between), my ndis0 adapter works as exptected, using WPA and DHCP. I can't pinpoint exaclty what changed (I've check in /usr/src/UPDATING, as it seemed to be most relevant), with no avail to finding anything regarding either wpa or dhclient. Since an upgrade to 6.3-RELEASE (both, via csup and a fresh install off of cd), I generate my ndis module, create an /etc/wpa_supplicant.conf, leaving /etc/dhclient as default, and am prompted with: ndis0: no link.. giving up Upon 'kldunload bcmwl5.ko; kldload bcmwl5.ko', my ndis0 card looses all WPA capabilities. What seems to me to be the interesting part is this: If I 'csup' to 6.3-RELEASE from -RC1, and build a kernel, the problem does not occur -- as long as I do not 'buildworld'. However, once I 'buildworld; installworld', I am faced with the same problems as if I had installed 6.3-RELEASE from cd. I would really like to figure out what is causing this (both for myself, and the other affected ndis0 victims), but I'm not sure where to look -- dhclient, wpa_supplicant or ndis itself. Any other information I could provide, please let me know. Thanks. -- Glen Barber (570)328-0318 http://www.dev-urandom.com/ ___ 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 Thu, 13 Mar 2008, Bjoern A. Zeeb wrote: It should give you output like this: 19549200,sackOK,eol,0x01[bad padding]> I like the [bad padding]. But I think the "good" case should look like it did before, per POLA. -Mike ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
