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
--
Pete Toscano p:[email protected] w:[email protected]
GPG fingerprint: D8F5 A087 9A4C 56BB 8F78 B29C 1FF0 1BA7 9008 2736
Hello!
> 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.
> 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.
> 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
On Wed, 13 Dec 2000, [email protected] wrote:
> Hello!
>
> > 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.
=;]
> 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.
> > 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.
>
>
> > 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
--
Pete Toscano p:[email protected] w:[email protected]
GPG fingerprint: D8F5 A087 9A4C 56BB 8F78 B29C 1FF0 1BA7 9008 2736
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
On Wed, 13 Dec 2000, Pete Toscano wrote:
>
> On Wed, 13 Dec 2000, [email protected] wrote:
>
> > Hello!
> >
> > > 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.
> =;]
>
> > 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.
>
> > > 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.
> >
> >
> > > 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
--
Pete Toscano p:[email protected] w:[email protected]
GPG fingerprint: D8F5 A087 9A4C 56BB 8F78 B29C 1FF0 1BA7 9008 2736
[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) = 976795399
recvmsg(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:Link
If 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). ;)
>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 |+| /|\
/ | | | --- |
+-+-+ ------------------------------------------------- /\\\ |
Hello!
> > 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.
> 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
On Thu, 14 Dec 2000 [email protected] wrote:
> Hello!
[snip]
> 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]
> 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
--------------------------------------------------
Hello!
> 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)
> [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
> 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
Hello!
> 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) = 976795399
> recvmsg(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
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.
> little about this, but should I be able to ping6 these link addresses?
Yes, of course.
> bash-2.04# ping6 fe80::a00:2bff:fe95:1d7b
> connect: Invalid argument
Yes, of course. Link local address without interface is invalid.
Alexey
[email protected] writes:
> > bash-2.04# ping6 fe80::a00:2bff:fe95:1d7b
> > connect: Invalid argument
>
> Yes, 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 |+| /|\
/ | | | --- |
+-+-+ ------------------------------------------------- /\\\ |
Hello!
> 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