Ipv6 - problem with multicast addresses
Brecht Vermeulen
brecht.vermeulen at rug.ac.be
Wed Feb 27 02:24:37 EST 2002
Hi all again,
sorry for replying to my own mail, but I've found the solution, so maybe
anyone is interested :-).
This was a tough one :-).
The key is lying in the use of multicast MAC addresses on the ethernet
layer. For IPv6 neighbour discovery, hosts send multicasts on ipv6 layer
which are mapped onto multicast L2 addresses (starting with 33:33:...).
Now, if you load the ipv6 module, then auto-magically the ethernet card
listens to some multicast ethernet addresses, which can be found in
/proc/net/dev_mcast.
2 eth0 1 0 3333ffca2b8e
2 eth0 1 0 333300000001
2 eth0 1 0 01005e000001
3 eth1 1 0 3333ff07acd4
3 eth1 1 0 333300000001
3 eth1 1 0 01005e000001
4 eth2 1 0 3333ffc81c97
4 eth2 1 0 333300000001
4 eth2 1 0 01005e000001
the 3333 addresses are added by ipv6. So, this means that the card
receives also these ethernet packets.
So in the setup:
host 1 (eth1) ------- (eth1) host 2
if you run click on host 2 without ipv6 with a configuration:
echo "FromDevice(eth1,1)->Print(yes)->Discard;"> /proc/click/config
then it doesn't receive the neighbour sollicitation messages from host 1
(ipv6 loaded) which are destined for 33:33...
However if you load ipv6 on host 2, then the packets are received
because the loading of ipv6 adds the needed multicast groups to the NIC.
(well, ipv6 uses link local addresses which are based on the MAC
address, so if you ping6 -I eth1 to the virtual ipv6 link local address
of host 2, if you ping6 to another address than host 2 isn't listening
to the right multicast address).
So, I missly assumed that promiscuous mode would capture all packets.
The ethernet multicast packets aren't captured. However, with ifconfig
you can put the interface in 'allmulti' mode :
[-]allmulti
Enable or disable all-multicast mode. If selected,
all multicast packets on the network will be
received by the interface.
so, a ifconfig eth1 allmulti
does the job on host2. (maybe with putting the interface down and up,
but this wasn't needed for me)
So, now it is possible without loading ipv6 on host 2 and with the click
config as above to capture all packets from host 1.
I don't know if this is true for all interface cards (ours are DLINK
DFE530TX, via-rhine driver, which are cheap ones) or if promiscuous mode
is more promiscous on other cards (will test this tomorrow).
This parameter makes it also possible to simply run tcpdump on a host
which isn't ipv6 enabled while capturing *all* packets.
regards,
Brecht
Brecht Vermeulen wrote:
>
> 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
More information about the click
mailing list