[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5117B73C.10600@linux-ipv6.org>
Date: Mon, 11 Feb 2013 00:05:32 +0900
From: YOSHIFUJI Hideaki <yoshfuji@...ux-ipv6.org>
To: stephan.gatzka@...il.com
CC: netdev@...r.kernel.org, linux1394-devel@...ts.sourceforge.net,
davem@...emloft.net, stefanr@...6.in-berlin.de,
YOSHIFUJI Hideaki <yoshfuji@...ux-ipv6.org>
Subject: Re: [net-next (TAKE 2) 0/4] IPv6 over Firewire
Hi,
Stephan Gatzka wrote:
>
>> I have tested against MacOS X 10.5.8.
>>
>> ARP and ping works but unfortunately NDP does not seem to work.
>>
>> If I assign static NDP entry on Linux, ping6 ff02::1%fw0 from MacOS
>> works well.icmp
>>
>> I checked tcpdump on both side, and I guess this is because MacOS is
>> broken; - tcpdump on Linux side complains that ICMP checksum is
>> incorrect. - tcpdump on MacOS side says that length of Link-layer
>> address option is 2 (16) instead of 3 (24).
>
> Than I would assume that there is a bug in your new implementation.
> RFC3146 section 8 states that the link layer option is of length 3. In
> addition, my proof of concept implementation also worked with MacOS X
> and I double checked the ndisc packets directly on the firewire line
> using a firewire sniffing device (firespy).
Can I have you code?
I meant, on MacOS X, it reports its originating lladdr option of 16bytes.
Then Linux side receives lladdr option of 24bytes, in ICMPv6 with incorrect
checksum. I guess that lladdr option is 16byte long at bpf layer,
and then, it is mangled in the driver, but ICMPv6 checksum was not modified.
In reverse, on Linux side, it sends lladdr option of 24 bytes long
with correct checksum, but it is ignored by MacOS.
--yoshfuji
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists