Ipv6 - problem with multicast addresses

Tue Feb 26 10:58:14 EST 2002

Hi,

> If the ipv6 module is loaded, ping6'ing ::172.25.0.3 and using a sniffer, I can see that the translator responds >to the ipv6 machine with an destination unreachable message, but click translates the packet and send it to >172.25.0.3. This machine replies to the packet but again the translator responds to it with an destination >unreachable message, and the packet never goes back to the ipv6 machine. 

mmm, and what are the 'destination unreachable messages' which are sent
?
with our configuration the first host just doesn't receive anything and
says destination unreachable, but it doesn't get such messages. Do you
have a tcpdump trace of all these ?

> If I leave off the ipv6 module, the behavior is similar, but the first destination unreachable message > > desappears (the one from the translator to the ipv6 machine), in any case the translator works! :-P .

and the packet just goes through the translator ?

> 
> Oh, and I'm not using the kernel module, but the user level tool and I'm having similar problems, so the problem I think is not related to the kernel.
> 

mmm, if you use the userlevel tool, it gets its packets via FromDevice
based on libpcap (the same library as used by tcpdump), so this seems
logical if there is a problem with the kernel-libpcap which blocks all
packets, click userlevel will not get any also. However with the click
kernel module, I believed that the whole network stack was taken over by
click.

Not 100% sure about this though...

regards,
Brecht

> bye
> 
> Juan Luis
> 
> -----Original Message-----
> From: Brecht Vermeulen <brecht.vermeulen at rug.ac.be>
> Date: Tue, 26 Feb 2002 05:19:59 +0100
> To: click at amsterdam.lcs.mit.edu, frederik.scholaert at rug.ac.be
> Subject: Re: Ipv6 - problem with multicast addresses
> 
> >
> > Hi all,
> >
> > I did some further testing on the problem with IPv6 and multicast
> > addresses for sollicitation messages (see mail of Frederik Scholaert).
> >
> > So the problem is further compressed to:
> >
> > host 1 (eth1)  ----    host 2 (eth 2)
> >
> > I have 3 scenarios (with a fresh reboot of both machines in between)
> >
> > 1) if we load on both hosts the ipv6 module, then it is possible to ping
> > from host 1 to the link scope address of host 2. (everything is
> > auto-magically configured, we do not nothing)
> > ping6 fe80::250:baff:feca:2cae -I eth1
> >
> > on host 1, we see
> > tcpdump: listening on eth1
> > 04:42:52.504557 :: > ff02::1:ff07:acd4: icmp6: neighbor sol: who has
> > fe80::250:baff:fe07:acd4
> > 04:42:56.504584 fe80::250:baff:fe07:acd4 > ip6-allrouters: icmp6: router
> > solicitation
> > 04:43:00.504555 fe80::250:baff:fe07:acd4 > ip6-allrouters: icmp6: router
> > solicitation
> > 04:43:01.045766 fe80::250:baff:fe07:acd4 > ff02::1:ffca:2cae: icmp6:
> > neighbor sol: who has fe80::250:baff:feca:2cae
> > 04:43:01.045896 fe80::250:baff:feca:2cae > fe80::250:baff:fe07:acd4:
> > icmp6: neighbor adv: tgt is fe80::250:baff:feca:2cae
> > 04:43:01.045934 fe80::250:baff:fe07:acd4 > fe80::250:baff:feca:2cae:
> > icmp6: echo request
> > 04:43:01.046038 fe80::250:baff:feca:2cae > fe80::250:baff:fe07:acd4:
> > icmp6: echo reply
> > 04:43:02.044621 fe80::250:baff:fe07:acd4 > fe80::250:baff:feca:2cae:
> > icmp6: echo request
> > 04:43:02.044727 fe80::250:baff:feca:2cae > fe80::250:baff:fe07:acd4:
> > icmp6: echo reply
> > 04:43:03.044605 fe80::250:baff:fe07:acd4 > fe80::250:baff:feca:2cae:
> > icmp6: echo request
> >
> > So, this works.
> >
> > 2) on host 1, we load the ipv6 module, on host 2 we load click with the
> > following config:
> > echo "FromDevice(eth1,1)->Print(yes)->Discard;"> /proc/click/config
> >
> > and we do the same ping from host 1 to host 2 : nothing is printed by
> > click (a tcpdump on host 1 shows
> > tcpdump: listening on eth1
> > 04:51:06.010989 fe80::250:baff:fe07:acd4 > ff02::1:ffca:2cae: icmp6:
> > neighbor sol: who has fe80::250:baff:feca:2cae
> > 04:51:07.004349 fe80::250:baff:fe07:acd4 > ff02::1:ffca:2cae: icmp6:
> > neighbor sol: who has fe80::250:baff:feca:2cae
> > 04:51:08.004341 fe80::250:baff:fe07:acd4 > ff02::1:ffca:2cae: icmp6:
> > neighbor sol: who has fe80::250:baff:feca:2cae
> >
> > If we then however load ipv6 on host2, then the packets are printed in
> > the syslog (without stopping click).
> > We use the kernel level click module of Jan. 11th, 2002 with linux
> > 2.2.19. The ethernet cards are DLINK DFE 530TX with via-rhine
> > (non-polling) driver. I haven't tried with other cards yet.
> >
> > 3) if we start on host 2 a tcpdump, load the ipv6 modules on both hosts
> > and do the ping from host1 to host2, then it is the same as in scenario
> > 2, no packets at host2, but tcpdump on host 1 sees the packets. If we
> > stop tcpdump on host 2 and start tcpdump again, then we see the packets.
> > (tried with libpcap 0.4a6/tcpdump 3.7.1 and libpcap 0.6.2/tcpdump 3.6.2,
> > hope these are the correct version numbers).
> >
> >
> >
> > If we look at the ethernet headers, we see
> > tcpdump: listening on eth1
> > 04:51:20.932240 0:50:ba:7:ac:d4 33:33:ff:ca:2c:ae 86dd 86:
> > fe80::250:baff:fe07:acd4 > ff02::1:ffca:2cae: icmp6: neighbor sol: who
> > has fe80::250:baff:feca:2cae
> >
> > so, the destination MAC address is 33:33:... which is an ethernet
> > multicast.
> >
> > So, scenario 2 seems very strange to me as I thought that click just
> > took over the networking from Linux, but how comes then that it doesn't
> > see any packet and that the loading of the ipv6 module makes that this
> > works.
> > Or could there be something broken with the multicast ethernet addresses
> > and the card (although click is in promiscuous mode) ?
> >
> > Our system is debian 2.2 (potato), kernel 2.2.19 with Click patch. (for
> > all scenarios, Click is however not loaded in the 1st and 3rd scenario).
> >
> > anyone any good idea (next possibilities I see is testing with other
> > cards, 2.4.x kernels) ?
> >
> > regards,
> > Brecht
> >
> >
> >
> >
> >
> >
> >
> >
> > Hi,
> >
> > I'm experimenting with IPv6 in click. It works pretty well except for
> > the
> > fact that i'm not able to receive all-nodes or all-router multicast
> > addresses in my click config.
> >
> > My configuration is like this:
> >
> > |HOST|-ETH1-fec0:0:0:1::65/64---ETH1-|CLICK
> > ROUTER|-ETH2---fec0:0:0:2::66/64-ETH1-|HOST|
> >                           [fec0:0:0:1::64/64]  [fec0:0:0:2::64/64]
> >
> >
> > The IPv6-addresses fec0:0:0:1::64 and fec0:0:0:2::64 are not really
> > assigned because IPv6 is not loaded on the click router.
> >
> > When for instance the IPv6 Click config is loaded and i load IPv6 on the
> > left host, the all-routers sollicitation packets don't seem to arrive at
> > the click router. Or, when i do a ping fec0:0:0:2::66 on the left host,
> > i
> > see 'fec0:0:0:1::65 > ff02::1:ff00:64: icmp6: neighbor sol: who has
> > fec0:0:0:1::64' -packets (leaving?) on eth1 of the left host, but they
> > also do not seem to arrive at the click router. (I have a Print-element
> > there after a FromDevice(eth1,1)-element and see nothing).
> >
> > But when i first load the IPv6-module on the click-router and actually
> > assign the fec0:0:0:1::64 and fec0:0:0:2::64 addresses, and then
> > afterwards load click, i can ping through the click router.
> >
> > I don't think it should have to be this way. Shouldn't i be able to run
> > a
> > IPv6 click config completely indepedent of IPv6 in the Linux kernel?
> >
> > I use a click-version from january (from cvs), and kernel 2.2.19.
> >
> > Can somebody help me on this matter?
> >
> > regards,
> > Frederik
> >
> >
> 
> --
> 
> Get your free email from www.linuxmail.org
> 
> Powered by Outblaze