linux ipv6 questions. bugs?
i'm using test12 with ipv6 enabled. i'm seeing something strange, but i can't tell if it's a linux or openbsd bug.
i have two boxes, one's running 2.4.0-test12 and the other's running openbsd 2.8 (the same problem was seen with this machine using 2.7 too). they are on a little ipv6 network, with a 125 bit prefix length.
i have two question, one short, one longer. i'll start with the short one:
0. whenever i ping6 the loopback interface (::1/128), all echo requests seem to be dropped and i get no echo replies. is this correct? on the openbsd box, i can ping6 ::1 just fine.
1. i can only ping6 the ipv6 address of the openbsd machine once i put the openbsd box's ethernet interface into promisc mode (with tcpdump). after that (and even once the openbsd box's eth is back in non-promisc mode), i can ping6 the openbsd box fine. looking at a packet capture, i see the neighbor solicitation packets from the linux box, but i noticed something strange; in the ethernet header of the n.s. packets, the destination mac address is set to the linux box's mac address and the source mac address is set to 0:0:0:0:0:0. shouldn't this be the other way around? this would explain why the openbsd box doesn't respond to the linux box's n.s. until it starts looking at all the packets in promisc mode, right?
thanks,
pete
Signature · 2 lines
Pete Toscano p:[email protected] w:[email protected] GPG fingerprint: D8F5 A087 9A4C 56BB 8F78 B29C 1FF0 1BA7 9008 2736
Hello!
Quoted 2 lines
0. whenever i ping6 the loopback interface (::1/128), all echo requests seem to be dropped and i get no echo replies. is this correct?
Your guess? 8) Of course, it is incorrect. I even have no idea how it is possible to put system into such sad state. Though... probably, you forgot to up loopback.
Quoted 2 lines
the destination mac address is set to the linux box's mac address and the source mac address is set to 0:0:0:0:0:0.
I think it is consequence of above. When loopback interface is missing, networking does not work.
Quoted 3 lines
other way around? this would explain why the openbsd box doesn't respond to the linux box's n.s. until it starts looking at all the packets in promisc mode, right?
Rather it means that openbsd is buggy, its stack accepts packets not destined to it. It cannot react to those strange packets, which you have just described.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 3 lines · [email protected] writes:
Your guess? 8) Of course, it is incorrect. I even have no idea how it is possible to put system into such sad state. Though... probably, you forgot to up loopback.
I've seen exactly the same thing here. I have ipv6 in -test11 built as a module, and after the machine has booted, I can ping the ipv4 loopback address (using normal ping).
When I insert the ipv6 module, I can still ping the ipv4 loopback address fine, but trying to ping6 the ipv6 loopback address results in the packets getting lost.
According to the ipv6 SNMP file, the icmp ping echos and ping responses are sent and received, but ping6 never sees them (strace reveals that the recvmsg function never returns any data):
sendto(3, "\200\0\0\0l\32\0\0\7\2678:YH\16\0\10\t\n\v\f\r\16\17\20"..., 64, 0, {sin_family=AF_INET6, sin6_port=htons(58), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=htonl(0)}}, 24) = 64 setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={1, 0}}, NULL) = 0
time(NULL) = 976795399recvmsg(3, 0xbffff9e4, 0) = ? ERESTARTSYS (To be restarted)--- SIGALRM (Alarm clock) ---
- /proc/net/snmp6 (zero entries removed) -
Ip6InReceives 6 Ip6OutRequests 6 Icmp6InMsgs 6 Icmp6InEchos 3 Icmp6InEchoReplies 3 Icmp6OutMsgs 15 Icmp6OutEchoReplies 3 Icmp6OutRouterSolicits 8 Icmp6OutNeighborSolicits 4
So, the ipv6 pings are being sent, they are also being received, but are not being passed back to ping6.
I'm not well up on ipv6, and crawling the web for information reveals very little about this, but should I be able to ping6 these link addresses?
eth0 Link encap:Ethernet HWaddr 08:00:2B:95:1D:7B
inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::800:2b95:1d7b/10 Scope:Link
inet6 addr: fe80::a00:2bff:fe95:1d7b/10 Scope:LinkIf yes, I don't seem to be able to:
bash-2.04# ping6 fe80::a00:2bff:fe95:1d7b
connect: Invalid argument
bash-2.04# ping6 fe80::800:2b95:1d7b
connect: Invalid argument
And yes, eth0 is up and running (its a ipv4 root-NFS box so if it wasn't, I wouldn't be able to run any of these commands). ;)
Quoted 1 line
From my (probably wrong) understanding, it looks like the Linux ipv6 stack
is really sick in 2.4.0-test11 and probably needs a visit to the local surgery for a health check.
_____
|_____| ------------------------------------------------- ---+---+- | | Russell King [email protected] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ ------------------------------------------------- /\\\ |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Hello!
Quoted 6 lines
sendto(3, "\200\0\0\0l\32\0\0\7\2678:YH\16\0\10\t\n\v\f\r\16\17\20"..., 64, 0, {sin_family=AF_INET6, sin6_port=htons(58),
inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=htonl(0)}}, 24) = 64setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={1, 0}}, NULL)= 0
time(NULL) = 976795399recvmsg(3, 0xbffff9e4, 0)= ? ERESTARTSYS (To be restarted)--- SIGALRM (Alarm clock) ----
/proc/net/snmp6(zero entries removed) -
Quoted 9 lines
Ip6InReceives 6 Ip6OutRequests 6 Icmp6InMsgs 6 Icmp6InEchos 3 Icmp6InEchoReplies 3 Icmp6OutMsgs 15 Icmp6OutEchoReplies 3 Icmp6OutRouterSolicits 8 Icmp6OutNeighborSolicits 4
It is very interesting, indeed. I was going to suspect DNS, now it is clear that the problem is not here.
I still have no guesses, what happened with you.
Quoted 1 line
little about this, but should I be able to ping6 these link addresses?
Yes, of course.
Quoted 2 lines
bash-2.04# ping6 fe80::a00:2bff:fe95:1d7b
connect: Invalid argument
Yes, of course. Link local address without interface is invalid.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 4 lines · [email protected] writes:
Quoted 2 lines
bash-2.04# ping6 fe80::a00:2bff:fe95:1d7b
connect: Invalid argumentYes, of course. Link local address without interface is invalid.
Ok...
bash-2.04# strace ping6 -I fe80::800:2b95:1d7b fe80::800:2b95:1d7b
...
socket(PF_INET6, SOCK_RAW, 58) = 3 getuid() = 0 setuid(0) = 0
bind(3, {sin_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6, "fe80::800:2b95:1d7b", &sin6_addr), sin6_flowinfo=htonl(0)}}, 24) = -1 EINVAL (Invalid argument) write(2, "ping: bind icmp socket: Invalid "..., 41ping: bind icmp socket: Invalid argument) = 41_exit(1) = ?
bash-2.04#
still no go.
_____
|_____| ------------------------------------------------- ---+---+- | | Russell King [email protected] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ ------------------------------------------------- /\\\ |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Hello!
Quoted 1 line
bash-2.04# strace ping6 -I fe80::800:2b95:1d7b fe80::800:2b95:1d7b
ping6 -I eth0 fe80::800:2b95:1d7b
String "fe80::800:2b95:1d7b" does not allow to guess interface. In fact, it can be address on your other link or even address of your neighbour on some link.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 7 lines · On Wed, 13 Dec 2000, [email protected] wrote:
Hello!
Quoted 2 lines
0. whenever i ping6 the loopback interface (::1/128), all echo requests seem to be dropped and i get no echo replies. is this correct?
Your guess? 8) Of course, it is incorrect. I even have no idea how it is possible to put system into such sad state.
well, just power it on, it seems. but then again, this is just a guess. =;]
Quoted 1 line
Though... probably, you forgot to up loopback.
doesn't look it:
[root@nsv6 /root]# ifconfig lo
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:7952 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0
[root@nsv6 /root]# ping6 ::1
PING ::1(::1) from ::1 : 56 data bytes
--- ::1 ping statistics ---
156 packets transmitted, 0 packets received, 100% packet loss
...and this is right after boot.
Quoted 7 lines
Quoted 2 lines
the destination mac address is set to the linux box's mac address and the source mac address is set to 0:0:0:0:0:0.
I think it is consequence of above. When loopback interface is missing, networking does not work.
Quoted 7 lines
Quoted 3 lines
other way around? this would explain why the openbsd box doesn't respond to the linux box's n.s. until it starts looking at all the packets in promisc mode, right?
Rather it means that openbsd is buggy, its stack accepts packets not destined to it. It cannot react to those strange packets, which you have just described.
that may very well be, but shouldn't the neighbor solisitation packets from the linux box have the source mac address set to its mac address and the destination mac address set to 0:0:0:0:0:0 and not the other way around?
thanks,
pete
Signature · 2 lines
Pete Toscano p:[email protected] w:[email protected] GPG fingerprint: D8F5 A087 9A4C 56BB 8F78 B29C 1FF0 1BA7 9008 2736
Hello!
Quoted 3 lines
Quoted 1 line
Though... probably, you forgot to up loopback.
doesn't look it:
Funny, indeed.
I have no idea what does happen. I cannot reproduce this. Please, describe your setup in more details.
Quoted 4 lines
that may very well be, but shouldn't the neighbor solisitation packets from the linux box have the source mac address set to its mac address and the destination mac address set to 0:0:0:0:0:0 and not the other way around?
What NS do you talk about, if you even cannot ping even loopback? 8)8)8)
In such state you cannot expect of your system nothing but generating some crap. BTW these funny mac addresses are exaclty those one, which would be used on loopback, if it required ns. 8)
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 1 line · On Thu, 14 Dec 2000 [email protected] wrote:
Hello!
[snip]
Quoted 2 lines
I have no idea what does happen. I cannot reproduce this. Please, describe your setup in more details.
Hi Alexey!
I have several different boxen (test11, test12) that do something very similar. They cannot ping6 the link-local addresses at all. As in:
[root@paksecuredX tech]# ping6 ::1
PING ::1(::1) from ::1 : 56 data bytes
64 bytes from ::1: icmp_seq=0 hops=64 time=351 usec 64 bytes from ::1: icmp_seq=1 hops=64 time=200 usec
--- ::1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/mdev = 0.200/0.275/0.351/0.077 ms
[root@paksecuredX tech]# ip -6 ad
1: lo: <LOOPBACK,UP> mtu 3840 qdisc noqueue
inet6 ::1/128 scope host
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
inet6 fe80::210:5aff:fe05:e828/10 scope link[root@paksecuredX tech]# ip -6 ro
fe80::/10 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 ff00::/8 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 default dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 unreachable default dev lo metric -1 error -101
[root@paksecuredX tech]# ping6 fe80::210:5aff:fe05:e828
connect: Invalid argument
Now if I try and setup an address such as the following it works but still will not ping6 the link-local. IE:
[root@paksecuredX tech]# ip -6 ad ad dead:2::1/64 dev eth0
[root@paksecuredX tech]# ip -6 ad
1: lo: <LOOPBACK,UP> mtu 3840 qdisc noqueue
inet6 ::1/128 scope host
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
inet6 dead:2::1/64 scope global tentative
inet6 fe80::210:5aff:fe05:e828/10 scope link
[root@paksecuredX tech]# ping6 dead:2::1
PING dead:2::1(dead:2::1) from ::1 : 56 data bytes 64 bytes from dead:2::1: icmp_seq=0 hops=64 time=377 usec 64 bytes from dead:2::1: icmp_seq=1 hops=64 time=196 usec
--- dead:2::1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/mdev = 0.196/0.286/0.377/0.092 ms
[root@paksecuredX tech]# ping6 fe80::210:5aff:fe05:e828
connect: Invalid argument
Now from my local box which is running 2.2.12 I can ping the link-local of those boxes. IE:
[root@netmonster Kernel]# ping6 fe80::210:5aff:fe05:e828
PING fe80::210:5aff:fe05:e828(fe80::210:5aff:fe05:e828) from fe80::2a0:ccff:fe21:eed3 : 56 data bytes
64 bytes from fe80::210:5aff:fe05:e828: icmp_seq=0 hops=64 time=1.291 msec 64 bytes from fe80::210:5aff:fe05:e828: icmp_seq=1 hops=64 time=520 usec 64 bytes from fe80::210:5aff:fe05:e828: icmp_seq=2 hops=64 time=500 usec
--- fe80::210:5aff:fe05:e828 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/mdev = 0.500/0.770/1.291/0.368 ms
So it looks like there is something going on with just the Link-Local addresses. I have not yet started to regress the kernels to see where this started. Hope it helps!
Note - this is using iputils 001110 and also 001011
[snip]
Quoted 1 line
Alexey
--------------------------------------------------
Matthew G. Marsh, President
Paktronix Systems LLC
1506 North 59th Street
Omaha NE 68104
Phone: (402) 932-7250
Email: [email protected]
WWW: http://www.paktronix.com
--------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Hello!
Quoted 7 lines
I have several different boxen (test11, test12) that do something very similar. They cannot ping6 the link-local addresses at all. As in:
[root@paksecuredX tech]# ping6 ::1
PING ::1(::1) from ::1 : 56 data bytes
64 bytes from ::1: icmp_seq=0 hops=64 time=351 usec 64 bytes from ::1: icmp_seq=1 hops=64 time=200 usec
This does not look similar. I daresay it rather looks working well. 8)8)
Quoted 2 lines
[root@paksecuredX tech]# ping6 fe80::210:5aff:fe05:e828
connect: Invalid argument
Right, you forgot to tell what interface you expect. Address is link local yet, it is invalid without interface.
ping6 -I eth0 fe80::210:5aff:fe05:e828
Quoted 2 lines
Now from my local box which is running 2.2.12 I can ping the link-local of those boxes. IE:
It was bug, it is fixed.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
ugh, bad form, i know, but i forgot this little dollop of information:
it looks like the incorrectly mac addressed n.s. packets are being fed right back into the linux box's ip stack (as it sees an ethernet packet with the destination set to its own mac address):
[root@nsv6 /root]# ping6 X:Y::1
PING X:Y::1(X:Y::1) from X:Y::4 : 56 data bytes From ::1: Destination unreachable: Address unreachable From ::1: Destination unreachable: Address unreachable
.
.
.From ::1: Destination unreachable: Address unreachable 64 bytes from X:Y::1: icmp_seq=16 hops=64 time=433 usec 64 bytes from X:Y::1: icmp_seq=15 hops=64 time=1.000 sec
the pings start working when i put the X:Y::1 box's ethernet card into promsc mode and it sees an ipv6 packet destined for one of its multicast addresses. (i guess promsc mode tells the eth to just ignore all link-level addressing info.)
pete
Quoted 56 lines · Pete Toscano
Quoted 7 lines · On Wed, 13 Dec 2000, [email protected] wrote:
Hello!
Quoted 2 lines
0. whenever i ping6 the loopback interface (::1/128), all echo requests seem to be dropped and i get no echo replies. is this correct?
Your guess? 8) Of course, it is incorrect. I even have no idea how it is possible to put system into such sad state.
well, just power it on, it seems. but then again, this is just a guess. =;]
Quoted 1 line
Though... probably, you forgot to up loopback.
doesn't look it:
[root@nsv6 /root]# ifconfig lo
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:7952 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0
[root@nsv6 /root]# ping6 ::1
PING ::1(::1) from ::1 : 56 data bytes--- ::1 ping statistics ---
156 packets transmitted, 0 packets received, 100% packet loss...and this is right after boot.
Quoted 7 lines
Quoted 2 lines
the destination mac address is set to the linux box's mac address and the source mac address is set to 0:0:0:0:0:0.
I think it is consequence of above. When loopback interface is missing, networking does not work.
Quoted 7 lines
Quoted 3 lines
other way around? this would explain why the openbsd box doesn't respond to the linux box's n.s. until it starts looking at all the packets in promisc mode, right?
Rather it means that openbsd is buggy, its stack accepts packets not destined to it. It cannot react to those strange packets, which you have just described.
that may very well be, but shouldn't the neighbor solisitation packets from the linux box have the source mac address set to its mac address and the destination mac address set to 0:0:0:0:0:0 and not the other way around?
thanks,
pete
Signature · 2 lines
Pete Toscano p:[email protected] w:[email protected] GPG fingerprint: D8F5 A087 9A4C 56BB 8F78 B29C 1FF0 1BA7 9008 2736