* 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; 17+ 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] 17+ 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; 17+ 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] 17+ 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; 17+ 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] 17+ 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; 17+ 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] 17+ 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; 17+ 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] 17+ 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; 17+ 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] 17+ 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; 17+ 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] 17+ 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; 17+ 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] 17+ 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; 17+ 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] 17+ 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; 17+ 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] 17+ 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; 17+ 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] 17+ 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; 17+ 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] 17+ 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; 17+ 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] 17+ 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; 17+ 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] 17+ 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; 17+ 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] 17+ 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; 17+ 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] 17+ 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; 17+ 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] 17+ messages in thread
end of thread, other threads:[~2005-05-06 14:39 UTC | newest]
Thread overview: 17+ 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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).