* netfilter6: ICMPv6 type 143 doesn't match
@ 2004-12-25 17:47 Peter Bieringer
2004-12-27 4:17 ` Yasuyuki Kozakai
0 siblings, 1 reply; 18+ messages in thread
From: Peter Bieringer @ 2004-12-25 17:47 UTC (permalink / raw)
To: Maillist netdev, Maillist USAGI-users; +Cc: Harald Welte, Patrick McHardy
Hi,
playing around with DHCPv6 (running on a very secured box with also
outgoing netfilter ruleset) I found that something's going wrong with the
ICMPv6 matcher:
LOG rule reports:
Dec 25 18:31:01 gatepbg kernel: OUTPUT-FW6/cleanup:IN= OUT=eth0
SRC=0000:0000:0000:0000:0000:0000:0000:0000
DST=ff02:0000:0000:0000:0000:0000:0000:0016 LEN=96 TC=0 HOPLIMIT=1
FLOWLBL=0 OPT ( ) PROTO=ICMPv6 TYPE=143 CODE=0
I tried several rules (don't wonder about the wrong order, it was a try and
error -I insert, uppest rule was inserted last):
# ip6tables -vn -L OUTPUT
Chain OUTPUT (policy DROP 4 packets, 4872 bytes)
pkts bytes target prot opt in out source
destination
2 192 ACCEPT all * eth0 ::/0 ::/0
0 0 ACCEPT icmpv6 * * ::/0 ::/0
0 0 ACCEPT icmpv6 * * ::/0 ::/0
ipv6-icmp type 143
0 0 ACCEPT icmpv6 * * ::/0
ff02::/16 ipv6-icmp type 143
0 0 ACCEPT icmpv6 * * ::/0
ff02::/16 ipv6-icmp type 143
0 0 ACCEPT icmpv6 * * ::/0
ff02::16/128 ipv6-icmp type 143
Packet dump:
18:46:07.984044 :: > ff02::16: HBH (rtalert: 0x0000) (padn)[icmp6 sum ok]
icmp6: type-#143 [hlim 1] (len 56)
0x0000: 6000 0000 0038 0001 0000 0000 0000 0000 `....8..........
0x0010: 0000 0000 0000 0000 ff02 0000 0000 0000 ................
0x0020: 0000 0000 0000 0016 3a00 0502 0000 0100 ........:.......
0x0030: 8f00 6b6a 0000 0002 0400 0000 ff05 0000 ..kj............
0x0040: 0000 0000 0000 0000 0001 0003 0400 0000 ................
0x0050: ff02 0000 0000 0000 0000 0000 0001 0002 ................
I wonder that only the proto "all" rule matches such packet.
BTW: makes it sense that ip6tables remember, whether I had used "-p all" on
insert or not?
# ip6tables -I OUTPUT -p all -o eth0 -j ACCEPT
# ip6tables -D OUTPUT -o eth0 -j ACCEPT
ip6tables: Bad rule (does a matching rule exist in that chain?)
# ip6tables -D OUTPUT -p all -o eth0 -j ACCEPT
(ok)
Same the other way:
# ip6tables -I OUTPUT -o eth0 -j ACCEPT
# ip6tables -D OUTPUT -p all -o eth0 -j ACCEPT
ip6tables: Bad rule (does a matching rule exist in that chain?)
Strange...I didn't really expect such behaviour as "newbie" ;-)
Peter
--
Dr. Peter Bieringer http://www.bieringer.de/pb/
GPG/PGP Key 0x958F422D mailto: pb at bieringer dot de
Deep Space 6 Co-Founder and Core Member http://www.deepspace6.net/
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: netfilter6: ICMPv6 type 143 doesn't match 2004-12-25 17:47 netfilter6: ICMPv6 type 143 doesn't match Peter Bieringer @ 2004-12-27 4:17 ` Yasuyuki Kozakai 2004-12-27 9:02 ` YOSHIFUJI Hideaki / 吉藤英明 2005-05-05 19:53 ` Patrick McHardy 0 siblings, 2 replies; 18+ messages in thread From: Yasuyuki Kozakai @ 2004-12-27 4:17 UTC (permalink / raw) To: pb; +Cc: usagi-users, netdev, netfilter-devel, kaber, laforge From: Peter Bieringer <pb@bieringer.de> Date: Sat, 25 Dec 2004 18:47:52 +0100 > I tried several rules (don't wonder about the wrong order, it was a try and > error -I insert, uppest rule was inserted last): > > # ip6tables -vn -L OUTPUT > Chain OUTPUT (policy DROP 4 packets, 4872 bytes) > pkts bytes target prot opt in out source > destination > 2 192 ACCEPT all * eth0 ::/0 ::/0 > 0 0 ACCEPT icmpv6 * * ::/0 ::/0 > 0 0 ACCEPT icmpv6 * * ::/0 ::/0 > ipv6-icmp type 143 > 0 0 ACCEPT icmpv6 * * ::/0 > ff02::/16 ipv6-icmp type 143 > 0 0 ACCEPT icmpv6 * * ::/0 > ff02::/16 ipv6-icmp type 143 > 0 0 ACCEPT icmpv6 * * ::/0 > ff02::16/128 ipv6-icmp type 143 > > Packet dump: > > 18:46:07.984044 :: > ff02::16: HBH (rtalert: 0x0000) (padn)[icmp6 sum ok] > icmp6: type-#143 [hlim 1] (len 56) > 0x0000: 6000 0000 0038 0001 0000 0000 0000 0000 `....8.......... > 0x0010: 0000 0000 0000 0000 ff02 0000 0000 0000 ................ > 0x0020: 0000 0000 0000 0016 3a00 0502 0000 0100 ........:....... > 0x0030: 8f00 6b6a 0000 0002 0400 0000 ff05 0000 ..kj............ > 0x0040: 0000 0000 0000 0000 0001 0003 0400 0000 ................ > 0x0050: ff02 0000 0000 0000 0000 0000 0001 0002 ................ > > I wonder that only the proto "all" rule matches such packet. Well, the Multicast Listener Report seems that skb->data != skb->nh.ipv6h when interface is up. But IPv6 netfilter modules assumes that skb->data == skb->nh.ipv6h like IPv4 netfilter modules. folks, is this wrong or bad asumption ? If so, I'll fix this problem in many modules as follows. --- linux-2.6.10/net/ipv6/netfilter/ip6_tables.c 2004-12-27 11:26:57.000000000 +0900 +++ linux-2.6.10-fixed/net/ipv6/netfilter/ip6_tables.c 2004-12-27 11:28:23.000000000 +0900 @@ -222,7 +222,7 @@ u_int16_t hdrlen; /* Header */ u_int16_t _fragoff = 0, *fp = NULL; - ptr = IPV6_HDR_LEN; + ptr = ((u8*)skb->nh.ipv6h - skb->data) + IPV6_HDR_LEN; while (ip6t_ext_hdr(currenthdr)) { /* Is there enough space for the next ext header? */ Regards, ----------------------------------------------------------------- Yasuyuki KOZAKAI @ USAGI Project <yasuyuki.kozakai@toshiba.co.jp> ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: netfilter6: ICMPv6 type 143 doesn't match 2004-12-27 4:17 ` Yasuyuki Kozakai @ 2004-12-27 9:02 ` YOSHIFUJI Hideaki / 吉藤英明 2005-01-02 9:12 ` netfilter6: ICMPv6 type 143 doesn't match (130 also not) Peter Bieringer 2005-01-08 11:45 ` (usagi-users 03180) Re: netfilter6: ICMPv6 type 143 doesn't match Peter Bieringer 2005-05-05 19:53 ` Patrick McHardy 1 sibling, 2 replies; 18+ messages in thread From: YOSHIFUJI Hideaki / 吉藤英明 @ 2004-12-27 9:02 UTC (permalink / raw) To: yasuyuki.kozakai Cc: usagi-users, netdev, yoshfuji, netfilter-devel, laforge, pb, kaber In article <200412270417.iBR4HZRG021429@toshiba.co.jp> (at Mon, 27 Dec 2004 13:17:34 +0900 (JST)), Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp> says: > > - ptr = IPV6_HDR_LEN; > + ptr = ((u8*)skb->nh.ipv6h - skb->data) + IPV6_HDR_LEN; > IMHO, skb->nh.ipv6h does not points ipv6 header anymore; it should be skb->nh.raw in this case. --yoshfuji ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: netfilter6: ICMPv6 type 143 doesn't match (130 also not) 2004-12-27 9:02 ` YOSHIFUJI Hideaki / 吉藤英明 @ 2005-01-02 9:12 ` Peter Bieringer 2005-01-08 11:45 ` (usagi-users 03180) Re: netfilter6: ICMPv6 type 143 doesn't match Peter Bieringer 1 sibling, 0 replies; 18+ messages in thread From: Peter Bieringer @ 2005-01-02 9:12 UTC (permalink / raw) To: YOSHIFUJI Hideaki / 吉藤英明, yasuyuki.kozakai Cc: netdev, usagi-users, laforge, kaber, netfilter-devel Hi, --On Monday, December 27, 2004 10:02:05 AM +0100 "YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=" <yoshfuji@linux-ipv6.org> wrote: > In article <200412270417.iBR4HZRG021429@toshiba.co.jp> (at Mon, 27 Dec > 2004 13:17:34 +0900 (JST)), Yasuyuki Kozakai > <yasuyuki.kozakai@toshiba.co.jp> says: > >> >> - ptr = IPV6_HDR_LEN; >> + ptr = ((u8*)skb->nh.ipv6h - skb->data) + IPV6_HDR_LEN; >> > > IMHO, skb->nh.ipv6h does not points ipv6 header anymore; > it should be skb->nh.raw in this case. > > --yoshfuji Can someone pls. provide me a patch for kernel version 2.6.9? If so, I would run tests. BTW: at the moment, I have an additional packet where no ICMPv6 rule matches: Jan 2 10:04:15 gate kernel: default-drop-extIN:IN=sit1 OUT= MAC=53:2e:55:**:**:**->00:00:65:**:**:** TUNNEL=212.224. 0.188->217.228.***.*** SRC=fe80:0000:0000:0000:0000:0000:d4e0:00bc DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=76 TC=0 HOPLIMIT=1 FLOWLBL=0 OPT ( ) PROTO=ICMPv6 TYPE=130 CODE=0 10:08:25.540037 fe80::d4e0:bc > ff02::1: HBH icmp6: multicast listener query max resp delay: 2000 addr: :: [hlim 1] 0x0000: 6000 0000 0024 0001 fe80 0000 0000 0000 `....$.......... 0x0010: 0000 0000 d4e0 00bc ff02 0000 0000 0000 ................ 0x0020: 0000 0000 0000 0001 3a00 0502 0000 0100 ........:....... 0x0030: 8200 a03a 07d0 0000 0000 0000 0000 0000 ...:............ 0x0040: 0000 0000 0000 0000 027d 0000 .........}.. # ip6tables -vnL INPUT --line-num Chain INPUT (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 0 0 ACCEPT icmpv6 * * ::/0 fe80::/10 ipv6-icmp type 136 HL match HL == 255 2 0 0 ACCEPT icmpv6 * * ::/0 ff02::1:ff00:1/128 ipv6-icmp type 135 HL match HL == 255 3 0 0 ACCEPT icmpv6 * * ::/128 fe80::/10 ipv6-icmp type 135 HL match HL == 255 4 0 0 ACCEPT icmpv6 * * fe80::/10 ::/0 ipv6-icmp type 135 HL match HL == 255 5 4 384 ACCEPT icmpv6 * * fe80::/10 ff02::1/128 ipv6-icmp type 134 HL match HL == 255 6 0 0 ACCEPT icmpv6 * * fe80::/10 fe80::/10 ipv6-icmp type 133 HL match HL == 255 7 0 0 ACCEPT icmpv6 * * fe80::/10 ff02::1/128 ipv6-icmp type 130 HL match HL == 1 8 0 0 ACCEPT icmpv6 * * ::/0 ::/0 ipv6-icmp type 4 9 0 0 ACCEPT icmpv6 * * ::/0 ::/0 ipv6-icmp type 3 10 0 0 ACCEPT icmpv6 * * ::/0 ::/0 ipv6-icmp type 2 11 0 0 ACCEPT icmpv6 * * ::/0 ::/0 ipv6-icmp type 1 Expected: match of rule 7 Peter -- Dr. Peter Bieringer http://www.bieringer.de/pb/ GPG/PGP Key 0x958F422D mailto: pb at bieringer dot de Deep Space 6 Co-Founder and Core Member http://www.deepspace6.net/ ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: (usagi-users 03180) Re: netfilter6: ICMPv6 type 143 doesn't match 2004-12-27 9:02 ` YOSHIFUJI Hideaki / 吉藤英明 2005-01-02 9:12 ` netfilter6: ICMPv6 type 143 doesn't match (130 also not) Peter Bieringer @ 2005-01-08 11:45 ` Peter Bieringer 2005-01-09 17:41 ` (usagi-users 03187) " Peter Bieringer 2005-01-10 13:17 ` (usagi-users 03180) " Olaf Kirch 1 sibling, 2 replies; 18+ messages in thread From: Peter Bieringer @ 2005-01-08 11:45 UTC (permalink / raw) To: usagi-users; +Cc: yasuyuki.kozakai, netdev, laforge, kaber, netfilter-devel --On Monday, December 27, 2004 10:02:05 AM +0100 "YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=" <yoshfuji@linux-ipv6.org> wrote: > In article <200412270417.iBR4HZRG021429@toshiba.co.jp> (at Mon, 27 Dec > 2004 13:17:34 +0900 (JST)), Yasuyuki Kozakai > <yasuyuki.kozakai@toshiba.co.jp> says: > >> >> - ptr = IPV6_HDR_LEN; >> + ptr = ((u8*)skb->nh.ipv6h - skb->data) + IPV6_HDR_LEN; >> > > IMHO, skb->nh.ipv6h does not points ipv6 header anymore; > it should be skb->nh.raw in this case. > > --yoshfuji I use following patch now: --- net/ipv6/netfilter/ip6_tables.c.orig 2005-01-07 10:14:08.928948139 +0100 +++ net/ipv6/netfilter/ip6_tables.c 2005-01-07 10:14:54.373283422 +0100 @@ -220,7 +220,7 @@ u_int16_t ptr; /* Header offset in skb */ u_int16_t hdrlen; /* Header */ - ptr = IPV6_HDR_LEN; + ptr = ((u8*)skb->nh.raw - skb->data) + IPV6_HDR_LEN; while (ip6t_ext_hdr(currenthdr)) { /* Is there enough space for the next ext header? */ But it won't help :-(( Current results: ======================= OK/Packet matches rule: 1410 147K ACCEPT icmpv6 * * ::/0 ::/0 ipv6-icmp type 128 12:17:47.666912 2001:6f8:800:1003::2 > 2001:6f8:900:*::*: icmp6: echo request seq 31744 0x0000: 6000 0000 0040 3a40 2001 06f8 0800 1003 `....@:@........ 0x0010: 0000 0000 0000 0002 2001 06f8 0900 **** ................ 0x0020: **** **** **** **** 8000 5c69 2c49 7c00 ..........\i,I|. 0x0030: 0400 0000 5bc1 df41 cc41 0000 0000 0000 ....[..A.A...... 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0060: 0000 0000 0000 0000 ........ ======================= Problem/Packet does not match rule: 0 0 ACCEPT icmpv6 * * fe80::/10 ff02::1/128 ipv6-icmp type 130 HL match HL == 1 12:40:48.484375 fe80::****:**** > ff02::1: HBH (rtalert: 0x0000) (padn)[icmp6 sum ok] icmp6: multicast listener query max resp delay: 2000 addr: :: [hlim 1] (len 36) 0x0000: 6000 0000 0024 0001 fe80 0000 0000 0000 `....$.......... 0x0010: 0000 0000 **** **** ff02 0000 0000 0000 ................ 0x0020: 0000 0000 0000 0001 3a00 0502 0000 0100 ........:....... 0x0030: 8200 a03a 07d0 0000 0000 0000 0000 0000 ...:............ 0x0040: 0000 0000 0000 0000 027d 0000 .........}.. Jan 8 12:19:58 *** kernel: default-drop-extIN:IN=sit1 OUT= MAC=**:**:**:**:**:**->**:**:**:**:**:** TUNNEL=212.224. 0.188->217. 80.***.*** SRC=fe80:0000:0000:0000:0000:0000:****:**** DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=76 TC=0 HOPLIMIT=1 FLOWLBL=0 OPT ( ) PROTO=ICMPv6 TYPE=130 CODE=0 ======================= Problem/Packet does not match rule: 0 0 ACCEPT icmpv6 * * fe80::/10 ff02::16/128 ipv6-icmp type 143 HL match HL == 1 12:42:42.046741 fe80::200:**ff:fe**:**** > ff02::16: HBH (rtalert: 0x0000) (padn)[icmp6 sum ok] icmp6: type-#143 [hlim 1] (len 56) 0x0000: 6000 0000 0038 0001 fe80 0000 0000 0000 `....8.......... 0x0010: 0200 **ff fe** **** ff02 0000 0000 0000 .....*.......... 0x0020: 0000 0000 0000 0016 3a00 0502 0000 0100 ........:....... 0x0030: 8f00 a1d9 0000 0002 0300 0000 ff02 0000 ................ 0x0040: 0000 0000 0000 0000 0001 0002 0300 0000 ................ 0x0050: ff05 0000 0000 0000 0000 0000 0001 0003 ................ Jan 8 12:24:37 gate kernel: default-drop-intOUT:IN= OUT=eth0 SRC=fe80:0000:0000:0000:0200:**ff:fe**:**** DST=ff02:0000:0000:0000:0000:0000:0000:0016 LEN=96 TC=0 HOPLIMIT=1 FLOWLBL=0 OPT ( ) PROTO=ICMPv6 TYPE=143 CODE=0 It looks like that all packets with a Hop-By-Hop Option header causes problems at the moment. I would be glad, if someone can more dig into and provide me patches for kernel and probably also for tcpdump. Note also that kernel doesn't log the options, is this a bug or a missing feature? Thank you very much, Peter -- Dr. Peter Bieringer http://www.bieringer.de/pb/ GPG/PGP Key 0x958F422D mailto: pb at bieringer dot de Deep Space 6 Co-Founder and Core Member http://www.deepspace6.net/ ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: (usagi-users 03187) Re: netfilter6: ICMPv6 type 143 doesn't match 2005-01-08 11:45 ` (usagi-users 03180) Re: netfilter6: ICMPv6 type 143 doesn't match Peter Bieringer @ 2005-01-09 17:41 ` Peter Bieringer 2005-01-10 13:17 ` (usagi-users 03180) " Olaf Kirch 1 sibling, 0 replies; 18+ messages in thread From: Peter Bieringer @ 2005-01-09 17:41 UTC (permalink / raw) To: usagi-users; +Cc: yasuyuki.kozakai, netdev, laforge, kaber, netfilter-devel --On Saturday, January 08, 2005 12:45:14 PM +0100 Peter Bieringer <pb@bieringer.de> wrote: > 12:40:48.484375 fe80::****:**** > ff02::1: HBH (rtalert: 0x0000) > (padn)[icmp6 sum ok] icmp6: multicast listener query max resp delay: 2000 > addr: :: [hlim 1] (len 36) > 0x0000: 6000 0000 0024 0001 fe80 0000 0000 0000 `....$.......... > 0x0010: 0000 0000 **** **** ff02 0000 0000 0000 ................ > 0x0020: 0000 0000 0000 0001 3a00 0502 0000 0100 ........:....... > 0x0030: 8200 a03a 07d0 0000 0000 0000 0000 0000 ...:............ > 0x0040: 0000 0000 0000 0000 027d 0000 .........}.. > 12:42:42.046741 fe80::200:**ff:fe**:**** > ff02::16: HBH (rtalert: 0x0000) > (padn)[icmp6 sum ok] icmp6: type-#143 [hlim 1] (len 56) > 0x0000: 6000 0000 0038 0001 fe80 0000 0000 0000 `....8.......... > 0x0010: 0200 **ff fe** **** ff02 0000 0000 0000 .....*.......... > 0x0020: 0000 0000 0000 0016 3a00 0502 0000 0100 ........:....... > 0x0030: 8f00 a1d9 0000 0002 0300 0000 ff02 0000 ................ > 0x0040: 0000 0000 0000 0000 0001 0002 0300 0000 ................ > 0x0050: ff05 0000 0000 0000 0000 0000 0001 0003 ................ > I would be glad, if someone can more dig into and provide me patches for > kernel and probably also for tcpdump. I mentioned "tcpdump" here also because I played with tcpdump filters around and found that while tcpdump displays "icmp6" packet, the filter "icmp6" won't work at all, only the "ip6" filter matches. Understandable, because the next protocol is "00" (hop-by-hop), but I don't know whether this is well enough. My opinion is that tcpdump should be improved to be more smarter (if possible). Peter -- Dr. Peter Bieringer http://www.bieringer.de/pb/ GPG/PGP Key 0x958F422D mailto: pb at bieringer dot de Deep Space 6 Co-Founder and Core Member http://www.deepspace6.net/ ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: (usagi-users 03180) Re: netfilter6: ICMPv6 type 143 doesn't match 2005-01-08 11:45 ` (usagi-users 03180) Re: netfilter6: ICMPv6 type 143 doesn't match Peter Bieringer 2005-01-09 17:41 ` (usagi-users 03187) " Peter Bieringer @ 2005-01-10 13:17 ` Olaf Kirch 2005-01-11 19:56 ` (usagi-users 03190) " Peter Bieringer 1 sibling, 1 reply; 18+ messages in thread From: Olaf Kirch @ 2005-01-10 13:17 UTC (permalink / raw) To: Peter Bieringer Cc: usagi-users, netdev, yasuyuki.kozakai, netfilter-devel, laforge, kaber On Sat, Jan 08, 2005 at 12:45:14PM +0100, Peter Bieringer wrote: > - ptr = IPV6_HDR_LEN; > + ptr = ((u8*)skb->nh.raw - skb->data) + IPV6_HDR_LEN; [...] > But it won't help :-(( The following works for me on 2.6.8: ptr = ((char *) ipv6 - (char *) skb->data) + IPV6_HDR_LEN; Older 2.6 kernels also do not call ipv6_skip_exthdr() in icmp6_match(); more recent kernels fix this. Olaf -- Olaf Kirch | Things that make Monday morning interesting, #2: okir@suse.de | "We have 8,000 NFS mount points, why do we keep ---------------+ running out of privileged ports?" ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: (usagi-users 03190) Re: netfilter6: ICMPv6 type 143 doesn't match 2005-01-10 13:17 ` (usagi-users 03180) " Olaf Kirch @ 2005-01-11 19:56 ` Peter Bieringer 0 siblings, 0 replies; 18+ messages in thread From: Peter Bieringer @ 2005-01-11 19:56 UTC (permalink / raw) To: usagi-users; +Cc: yasuyuki.kozakai, netdev, laforge, kaber, netfilter-devel --On Monday, January 10, 2005 02:17:09 PM +0100 Olaf Kirch <okir@suse.de> wrote: > On Sat, Jan 08, 2005 at 12:45:14PM +0100, Peter Bieringer wrote: >> - ptr = IPV6_HDR_LEN; >> + ptr = ((u8*)skb->nh.raw - skb->data) + IPV6_HDR_LEN; > [...] >> But it won't help :-(( > > The following works for me on 2.6.8: > > ptr = ((char *) ipv6 - (char *) skb->data) + IPV6_HDR_LEN; > > Older 2.6 kernels also do not call ipv6_skip_exthdr() in icmp6_match(); > more recent kernels fix this. > > Olaf I'll be very happy now that I can report that on a recompiled 2.6.10 (latest Fedora Core 3 update), this patch works for me. I will file a RH bugzilla entry for that and the esp match problem. Thank you all very much for helping! Peter -- Dr. Peter Bieringer http://www.bieringer.de/pb/ GPG/PGP Key 0x958F422D mailto: pb at bieringer dot de Deep Space 6 Co-Founder and Core Member http://www.deepspace6.net/ ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: netfilter6: ICMPv6 type 143 doesn't match 2004-12-27 4:17 ` Yasuyuki Kozakai 2004-12-27 9:02 ` YOSHIFUJI Hideaki / 吉藤英明 @ 2005-05-05 19:53 ` Patrick McHardy 2005-05-05 20:20 ` Patrick McHardy 2005-05-05 22:26 ` David Stevens 1 sibling, 2 replies; 18+ messages in thread From: Patrick McHardy @ 2005-05-05 19:53 UTC (permalink / raw) To: Yasuyuki Kozakai; +Cc: usagi-users, netdev, netfilter-devel, laforge, pb [-- Attachment #1: Type: text/plain, Size: 615 bytes --] Yasuyuki Kozakai wrote: > Well, the Multicast Listener Report seems that skb->data != skb->nh.ipv6h > when interface is up. But IPv6 netfilter modules assumes that > skb->data == skb->nh.ipv6h like IPv4 netfilter modules. > > folks, is this wrong or bad asumption ? If so, I'll fix this problem in > many modules as follows. Sorry for getting back to this so late, I must have missed it at the time. Anyway, I think it would be safer to restore netfilters assumption by doing something like this patch. If everyone is fine with it I'm going to add it to my pending netfilter patches for 2.6.13. Regards Patrick [-- Attachment #2: x --] [-- Type: text/plain, Size: 2294 bytes --] Index: net/ipv6/mcast.c =================================================================== --- 2cfdb1827d9c176f4df42619c693e7b990a61963/net/ipv6/mcast.c (mode:100644 sha1:393b6e6f50a9626e2894c9a5abd8dafd903e5eba) +++ uncommitted/net/ipv6/mcast.c (mode:100644) @@ -1280,15 +1280,6 @@ return NULL; skb_reserve(skb, LL_RESERVED_SPACE(dev)); - if (dev->hard_header) { - unsigned char ha[MAX_ADDR_LEN]; - - ndisc_mc_map(&mld2_all_mcr, ha, dev, 1); - if (dev->hard_header(skb, dev, ETH_P_IPV6,ha,NULL,size) < 0) { - kfree_skb(skb); - return NULL; - } - } if (ipv6_get_lladdr(dev, &addr_buf)) { /* <draft-ietf-magma-mld-source-05.txt>: @@ -1312,6 +1303,24 @@ return skb; } +static inline int igmp6_dev_queue_xmit(struct sk_buff *skb) +{ + struct net_device *dev = skb->dev; + + if (dev->hard_header) { + unsigned char ha[MAX_ADDR_LEN]; + int err; + + ndisc_mc_map(&skb->nh.ipv6h->daddr, ha, dev, 1); + err = dev->hard_header(skb, dev, ETH_P_IPV6, ha, NULL, skb->len); + if (err < 0) { + kfree_skb(skb); + return err; + } + } + return dev_queue_xmit(skb); +} + static void mld_sendpack(struct sk_buff *skb) { struct ipv6hdr *pip6 = skb->nh.ipv6h; @@ -1329,7 +1338,7 @@ pmr->csum = csum_ipv6_magic(&pip6->saddr, &pip6->daddr, mldlen, IPPROTO_ICMPV6, csum_partial(skb->h.raw, mldlen, 0)); err = NF_HOOK(PF_INET6, NF_IP6_LOCAL_OUT, skb, NULL, skb->dev, - dev_queue_xmit); + igmp6_dev_queue_xmit); if (!err) { ICMP6_INC_STATS(idev,ICMP6_MIB_OUTMSGS); IP6_INC_STATS(IPSTATS_MIB_OUTMCASTPKTS); @@ -1635,12 +1644,6 @@ } skb_reserve(skb, LL_RESERVED_SPACE(dev)); - if (dev->hard_header) { - unsigned char ha[MAX_ADDR_LEN]; - ndisc_mc_map(snd_addr, ha, dev, 1); - if (dev->hard_header(skb, dev, ETH_P_IPV6, ha, NULL, full_len) < 0) - goto out; - } if (ipv6_get_lladdr(dev, &addr_buf)) { /* <draft-ietf-magma-mld-source-05.txt>: @@ -1668,7 +1671,7 @@ idev = in6_dev_get(skb->dev); err = NF_HOOK(PF_INET6, NF_IP6_LOCAL_OUT, skb, NULL, skb->dev, - dev_queue_xmit); + igmp6_dev_queue_xmit); if (!err) { if (type == ICMPV6_MGM_REDUCTION) ICMP6_INC_STATS(idev, ICMP6_MIB_OUTGROUPMEMBREDUCTIONS); @@ -1683,7 +1686,6 @@ in6_dev_put(idev); return; -out: IP6_INC_STATS(IPSTATS_MIB_OUTDISCARDS); kfree_skb(skb); } ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: netfilter6: ICMPv6 type 143 doesn't match 2005-05-05 19:53 ` Patrick McHardy @ 2005-05-05 20:20 ` Patrick McHardy 2005-05-05 21:34 ` David S. Miller 2005-05-05 22:26 ` David Stevens 1 sibling, 1 reply; 18+ messages in thread From: Patrick McHardy @ 2005-05-05 20:20 UTC (permalink / raw) To: Yasuyuki Kozakai; +Cc: usagi-users, netdev, netfilter-devel, laforge, pb [-- Attachment #1: Type: text/plain, Size: 683 bytes --] Patrick McHardy wrote: > Yasuyuki Kozakai wrote: > >>Well, the Multicast Listener Report seems that skb->data != skb->nh.ipv6h >>when interface is up. But IPv6 netfilter modules assumes that >>skb->data == skb->nh.ipv6h like IPv4 netfilter modules. >> >>folks, is this wrong or bad asumption ? If so, I'll fix this problem in >>many modules as follows. > > > Sorry for getting back to this so late, I must have missed it at the > time. Anyway, I think it would be safer to restore netfilters assumption > by doing something like this patch. If everyone is fine with it I'm > going to add it to my pending netfilter patches for 2.6.13. The last patch left some unreachable code. [-- Attachment #2: x --] [-- Type: text/plain, Size: 2432 bytes --] Index: net/ipv6/mcast.c =================================================================== --- 2cfdb1827d9c176f4df42619c693e7b990a61963/net/ipv6/mcast.c (mode:100644 sha1:393b6e6f50a9626e2894c9a5abd8dafd903e5eba) +++ uncommitted/net/ipv6/mcast.c (mode:100644) @@ -1280,15 +1280,6 @@ return NULL; skb_reserve(skb, LL_RESERVED_SPACE(dev)); - if (dev->hard_header) { - unsigned char ha[MAX_ADDR_LEN]; - - ndisc_mc_map(&mld2_all_mcr, ha, dev, 1); - if (dev->hard_header(skb, dev, ETH_P_IPV6,ha,NULL,size) < 0) { - kfree_skb(skb); - return NULL; - } - } if (ipv6_get_lladdr(dev, &addr_buf)) { /* <draft-ietf-magma-mld-source-05.txt>: @@ -1312,6 +1303,25 @@ return skb; } +static inline int igmp6_dev_queue_xmit(struct sk_buff *skb) +{ + struct net_device *dev = skb->dev; + + if (dev->hard_header) { + unsigned char ha[MAX_ADDR_LEN]; + int err; + + ndisc_mc_map(&skb->nh.ipv6h->daddr, ha, dev, 1); + err = dev->hard_header(skb, dev, ETH_P_IPV6, ha, NULL, skb->len); + if (err < 0) { + IP6_INC_STATS(IPSTATS_MIB_OUTDISCARDS); + kfree_skb(skb); + return err; + } + } + return dev_queue_xmit(skb); +} + static void mld_sendpack(struct sk_buff *skb) { struct ipv6hdr *pip6 = skb->nh.ipv6h; @@ -1329,7 +1339,7 @@ pmr->csum = csum_ipv6_magic(&pip6->saddr, &pip6->daddr, mldlen, IPPROTO_ICMPV6, csum_partial(skb->h.raw, mldlen, 0)); err = NF_HOOK(PF_INET6, NF_IP6_LOCAL_OUT, skb, NULL, skb->dev, - dev_queue_xmit); + igmp6_dev_queue_xmit); if (!err) { ICMP6_INC_STATS(idev,ICMP6_MIB_OUTMSGS); IP6_INC_STATS(IPSTATS_MIB_OUTMCASTPKTS); @@ -1635,12 +1645,6 @@ } skb_reserve(skb, LL_RESERVED_SPACE(dev)); - if (dev->hard_header) { - unsigned char ha[MAX_ADDR_LEN]; - ndisc_mc_map(snd_addr, ha, dev, 1); - if (dev->hard_header(skb, dev, ETH_P_IPV6, ha, NULL, full_len) < 0) - goto out; - } if (ipv6_get_lladdr(dev, &addr_buf)) { /* <draft-ietf-magma-mld-source-05.txt>: @@ -1668,7 +1672,7 @@ idev = in6_dev_get(skb->dev); err = NF_HOOK(PF_INET6, NF_IP6_LOCAL_OUT, skb, NULL, skb->dev, - dev_queue_xmit); + igmp6_dev_queue_xmit); if (!err) { if (type == ICMPV6_MGM_REDUCTION) ICMP6_INC_STATS(idev, ICMP6_MIB_OUTGROUPMEMBREDUCTIONS); @@ -1682,10 +1686,6 @@ if (likely(idev != NULL)) in6_dev_put(idev); return; - -out: - IP6_INC_STATS(IPSTATS_MIB_OUTDISCARDS); - kfree_skb(skb); } static int ip6_mc_del1_src(struct ifmcaddr6 *pmc, int sfmode, ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: netfilter6: ICMPv6 type 143 doesn't match 2005-05-05 20:20 ` Patrick McHardy @ 2005-05-05 21:34 ` David S. Miller 0 siblings, 0 replies; 18+ messages in thread From: David S. Miller @ 2005-05-05 21:34 UTC (permalink / raw) To: Patrick McHardy Cc: yasuyuki.kozakai, usagi-users, netdev, netfilter-devel, laforge, pb On Thu, 05 May 2005 22:20:05 +0200 Patrick McHardy <kaber@trash.net> wrote: > Patrick McHardy wrote: > > Yasuyuki Kozakai wrote: > > > >>Well, the Multicast Listener Report seems that skb->data != skb->nh.ipv6h > >>when interface is up. But IPv6 netfilter modules assumes that > >>skb->data == skb->nh.ipv6h like IPv4 netfilter modules. > >> > >>folks, is this wrong or bad asumption ? If so, I'll fix this problem in > >>many modules as follows. > > > > > > Sorry for getting back to this so late, I must have missed it at the > > time. Anyway, I think it would be safer to restore netfilters assumption > > by doing something like this patch. If everyone is fine with it I'm > > going to add it to my pending netfilter patches for 2.6.13. > > The last patch left some unreachable code. This looks OK with me, I hope it doesn't inadvertantly break anything. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: netfilter6: ICMPv6 type 143 doesn't match 2005-05-05 19:53 ` Patrick McHardy 2005-05-05 20:20 ` Patrick McHardy @ 2005-05-05 22:26 ` David Stevens 2005-05-05 22:32 ` Patrick McHardy 1 sibling, 1 reply; 18+ messages in thread From: David Stevens @ 2005-05-05 22:26 UTC (permalink / raw) To: Patrick McHardy Cc: usagi-users, netdev, Yasuyuki Kozakai, netfilter-devel, laforge, pb, netdev-bounce I'll look at it in more detail and let you know if I see any problems, but I wouldn't call it "igmpv6", which doesn't exist. "MLD" is the equivalent in IPv6. There certainly are existing references to "igmp6" in the Linux code-- that just isn't the name of the protocol. :-) suggest: change to mld_dev_queue_xmit(). +-DLS ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: netfilter6: ICMPv6 type 143 doesn't match 2005-05-05 22:26 ` David Stevens @ 2005-05-05 22:32 ` Patrick McHardy 2005-05-05 22:31 ` David S. Miller 0 siblings, 1 reply; 18+ messages in thread From: Patrick McHardy @ 2005-05-05 22:32 UTC (permalink / raw) To: David Stevens Cc: usagi-users, netdev, Yasuyuki Kozakai, netfilter-devel, laforge, pb David Stevens wrote: > I'll look at it in more detail and let you know if I see any problems, Thanks. Is there a reason why these packets never hit the POST_ROUTING hook? > but I wouldn't call it "igmpv6", which doesn't exist. "MLD" is the > equivalent in IPv6. There certainly are existing references to > "igmp6" in the Linux code-- that just isn't the name of the protocol. :-) > > suggest: change to mld_dev_queue_xmit(). Done. Regards Patrick ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: netfilter6: ICMPv6 type 143 doesn't match 2005-05-05 22:32 ` Patrick McHardy @ 2005-05-05 22:31 ` David S. Miller 2005-05-05 22:50 ` Patrick McHardy 0 siblings, 1 reply; 18+ messages in thread From: David S. Miller @ 2005-05-05 22:31 UTC (permalink / raw) To: Patrick McHardy Cc: usagi-users, netdev, yasuyuki.kozakai, netfilter-devel, dlstevens, laforge, pb On Fri, 06 May 2005 00:32:31 +0200 Patrick McHardy <kaber@trash.net> wrote: > David Stevens wrote: > > I'll look at it in more detail and let you know if I see any problems, > > Thanks. Is there a reason why these packets never hit the POST_ROUTING > hook? I think it is an oversight rather than intentional. The NDISC lookup stuff wrt. routing went back and forth implementation wise. We used to use a seperate routing table for NDISC entries, but that caused all kinds of problems wrt. IPSEC (which the seperate routing table was ironically meant to fix) so that got undone and now NDISC routes and normal routes exist in one table. So I think this oversight is just fallout from all of those changes. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: netfilter6: ICMPv6 type 143 doesn't match 2005-05-05 22:31 ` David S. Miller @ 2005-05-05 22:50 ` Patrick McHardy 2005-05-06 13:22 ` Herbert Xu 0 siblings, 1 reply; 18+ messages in thread From: Patrick McHardy @ 2005-05-05 22:50 UTC (permalink / raw) To: David S. Miller Cc: usagi-users, netdev, yasuyuki.kozakai, netfilter-devel, dlstevens, laforge, pb [-- Attachment #1: Type: text/plain, Size: 726 bytes --] David S. Miller wrote: > On Fri, 06 May 2005 00:32:31 +0200 > Patrick McHardy <kaber@trash.net> wrote: > >>Is there a reason why these packets never hit the POST_ROUTING hook? > > I think it is an oversight rather than intentional. > > The NDISC lookup stuff wrt. routing went back and forth > implementation wise. We used to use a seperate routing > table for NDISC entries, but that caused all kinds of > problems wrt. IPSEC (which the seperate routing table > was ironically meant to fix) so that got undone and now > NDISC routes and normal routes exist in one table. > > So I think this oversight is just fallout from all of > those changes. Thanks, I've added a call to NF_HOOK(NF_IP6_POST_ROUTING) to the patch. [-- Attachment #2: x --] [-- Type: text/plain, Size: 2602 bytes --] Index: net/ipv6/mcast.c =================================================================== --- 2cfdb1827d9c176f4df42619c693e7b990a61963/net/ipv6/mcast.c (mode:100644 sha1:393b6e6f50a9626e2894c9a5abd8dafd903e5eba) +++ uncommitted/net/ipv6/mcast.c (mode:100644) @@ -1280,15 +1280,6 @@ return NULL; skb_reserve(skb, LL_RESERVED_SPACE(dev)); - if (dev->hard_header) { - unsigned char ha[MAX_ADDR_LEN]; - - ndisc_mc_map(&mld2_all_mcr, ha, dev, 1); - if (dev->hard_header(skb, dev, ETH_P_IPV6,ha,NULL,size) < 0) { - kfree_skb(skb); - return NULL; - } - } if (ipv6_get_lladdr(dev, &addr_buf)) { /* <draft-ietf-magma-mld-source-05.txt>: @@ -1312,6 +1303,31 @@ return skb; } +static inline int mld_dev_queue_xmit2(struct sk_buff *skb) +{ + struct net_device *dev = skb->dev; + + if (dev->hard_header) { + unsigned char ha[MAX_ADDR_LEN]; + int err; + + ndisc_mc_map(&skb->nh.ipv6h->daddr, ha, dev, 1); + err = dev->hard_header(skb, dev, ETH_P_IPV6, ha, NULL, skb->len); + if (err < 0) { + IP6_INC_STATS(IPSTATS_MIB_OUTDISCARDS); + kfree_skb(skb); + return err; + } + } + return dev_queue_xmit(skb); +} + +static inline int mld_dev_queue_xmit(struct sk_buff *skb) +{ + return NF_HOOK(PF_INET6, NF_IP6_POST_ROUTING, skb, NULL, skb->dev, + mld_dev_queue_xmit2); +} + static void mld_sendpack(struct sk_buff *skb) { struct ipv6hdr *pip6 = skb->nh.ipv6h; @@ -1329,7 +1345,7 @@ pmr->csum = csum_ipv6_magic(&pip6->saddr, &pip6->daddr, mldlen, IPPROTO_ICMPV6, csum_partial(skb->h.raw, mldlen, 0)); err = NF_HOOK(PF_INET6, NF_IP6_LOCAL_OUT, skb, NULL, skb->dev, - dev_queue_xmit); + mld_dev_queue_xmit); if (!err) { ICMP6_INC_STATS(idev,ICMP6_MIB_OUTMSGS); IP6_INC_STATS(IPSTATS_MIB_OUTMCASTPKTS); @@ -1635,12 +1651,6 @@ } skb_reserve(skb, LL_RESERVED_SPACE(dev)); - if (dev->hard_header) { - unsigned char ha[MAX_ADDR_LEN]; - ndisc_mc_map(snd_addr, ha, dev, 1); - if (dev->hard_header(skb, dev, ETH_P_IPV6, ha, NULL, full_len) < 0) - goto out; - } if (ipv6_get_lladdr(dev, &addr_buf)) { /* <draft-ietf-magma-mld-source-05.txt>: @@ -1668,7 +1678,7 @@ idev = in6_dev_get(skb->dev); err = NF_HOOK(PF_INET6, NF_IP6_LOCAL_OUT, skb, NULL, skb->dev, - dev_queue_xmit); + mld_dev_queue_xmit); if (!err) { if (type == ICMPV6_MGM_REDUCTION) ICMP6_INC_STATS(idev, ICMP6_MIB_OUTGROUPMEMBREDUCTIONS); @@ -1682,10 +1692,6 @@ if (likely(idev != NULL)) in6_dev_put(idev); return; - -out: - IP6_INC_STATS(IPSTATS_MIB_OUTDISCARDS); - kfree_skb(skb); } static int ip6_mc_del1_src(struct ifmcaddr6 *pmc, int sfmode, ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: netfilter6: ICMPv6 type 143 doesn't match 2005-05-05 22:50 ` Patrick McHardy @ 2005-05-06 13:22 ` Herbert Xu 2005-05-06 14:39 ` Patrick McHardy 0 siblings, 1 reply; 18+ messages in thread From: Herbert Xu @ 2005-05-06 13:22 UTC (permalink / raw) To: Patrick McHardy Cc: davem, dlstevens, laforge, netdev, netfilter-devel, pb, usagi-users, yasuyuki.kozakai, yoshfuji Patrick McHardy <kaber@trash.net> wrote: > > +static inline int mld_dev_queue_xmit2(struct sk_buff *skb) > +{ > + struct net_device *dev = skb->dev; > + > + if (dev->hard_header) { > + unsigned char ha[MAX_ADDR_LEN]; > + int err; > + > + ndisc_mc_map(&skb->nh.ipv6h->daddr, ha, dev, 1); > + err = dev->hard_header(skb, dev, ETH_P_IPV6, ha, NULL, skb->len); > + if (err < 0) { > + IP6_INC_STATS(IPSTATS_MIB_OUTDISCARDS); You're now incrementing this twice since the callers will also increment this. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: netfilter6: ICMPv6 type 143 doesn't match 2005-05-06 13:22 ` Herbert Xu @ 2005-05-06 14:39 ` Patrick McHardy 0 siblings, 0 replies; 18+ messages in thread From: Patrick McHardy @ 2005-05-06 14:39 UTC (permalink / raw) To: Herbert Xu Cc: davem, dlstevens, laforge, netdev, netfilter-devel, pb, usagi-users, yasuyuki.kozakai, yoshfuji Herbert Xu wrote: > Patrick McHardy <kaber@trash.net> wrote: >>+ err = dev->hard_header(skb, dev, ETH_P_IPV6, ha, NULL, skb->len); >>+ if (err < 0) { >>+ IP6_INC_STATS(IPSTATS_MIB_OUTDISCARDS); > > You're now incrementing this twice since the callers will also > increment this. Thanks, I've removed the line again. Regards Patrick ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: netfilter6: ICMPv6 type 143 doesn't match
@ 2005-04-25 18:09 Jonathan Wood
0 siblings, 0 replies; 18+ messages in thread
From: Jonathan Wood @ 2005-04-25 18:09 UTC (permalink / raw)
To: netfilter-devel
Has there been any progress on this issue? I am seeing it in 2.6.11.7,
and making the change suggested below fixes it for me.
Thanks
> On Sat, Jan 08, 2005 at 12:45:14PM +0100, Peter Bieringer wrote:
> > - ptr = IPV6_HDR_LEN;
> > + ptr = ((u8*)skb->nh.raw - skb->data) + IPV6_HDR_LEN;
> [...]
> > But it won't help :-((
>
> The following works for me on 2.6.8:
>
> ptr = ((char *) ipv6 - (char *) skb->data) +
> IPV6_HDR_LEN;
>
> Older 2.6 kernels also do not call ipv6_skip_exthdr() in icmp6_match();
> more recent kernels fix this.
>
> Olaf
^ permalink raw reply [flat|nested] 18+ messages in threadend of thread, other threads:[~2005-05-06 14:39 UTC | newest] Thread overview: 18+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2004-12-25 17:47 netfilter6: ICMPv6 type 143 doesn't match Peter Bieringer 2004-12-27 4:17 ` Yasuyuki Kozakai 2004-12-27 9:02 ` YOSHIFUJI Hideaki / 吉藤英明 2005-01-02 9:12 ` netfilter6: ICMPv6 type 143 doesn't match (130 also not) Peter Bieringer 2005-01-08 11:45 ` (usagi-users 03180) Re: netfilter6: ICMPv6 type 143 doesn't match Peter Bieringer 2005-01-09 17:41 ` (usagi-users 03187) " Peter Bieringer 2005-01-10 13:17 ` (usagi-users 03180) " Olaf Kirch 2005-01-11 19:56 ` (usagi-users 03190) " Peter Bieringer 2005-05-05 19:53 ` Patrick McHardy 2005-05-05 20:20 ` Patrick McHardy 2005-05-05 21:34 ` David S. Miller 2005-05-05 22:26 ` David Stevens 2005-05-05 22:32 ` Patrick McHardy 2005-05-05 22:31 ` David S. Miller 2005-05-05 22:50 ` Patrick McHardy 2005-05-06 13:22 ` Herbert Xu 2005-05-06 14:39 ` Patrick McHardy -- strict thread matches above, loose matches on Subject: below -- 2005-04-25 18:09 Jonathan Wood
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.