More on IPv6/IPv4 translator...

[Brecht Vermeulen]

Hi Juan,

> First I ping6 ::172.25.0.3 from 3ffe:1ce1:2:0:200::2. Like before, the packet gets translated but the translator responds to 172.25.0.3 with a destination unreachable message and the echo reply never comes back to ipv6 host. But in the capture now there's a new and extrange packet sent by the translator, with Protocol type SLL (info says "Sent by us" (who???)) and source address the MAC address of one of the two interfaces of the translator, but  with no destination.

Huh ? Don't know this :-).

> That was the first strange thing, now the second. I then started tcpdump in the ipv6 host to see if it was receiving the neighboor adverticement messages from the translator, and bang!!! the echo reply packets started appearing in the ipv6 host!!! but the capture in ethereal in the translator remained the same (no echo reply coming out from the translator to the ipv6 host).

tcpdump puts the interface in promiscuous mode. You can do this manually
with ifconfig eth1 promisc  (on Linux), so maybe there is a problem with
the MAC addresses of the packets which can only be received when the
interface is in promiscuous mode ? (problem with the multicast ethernet
address of the sollicitation messages ? as in one of my previous mails
?) Are you able to put another sniff box in between the translator and
IPv6 host ?

This was what I meant by 3 different OSs. The IPv6 is a BSD machine, so
I don't know if the ethernet multicast things can also be found in
/proc/net/dev_mcast...


> 
> If it is of relevance, I'm using two Realtek 8029 cards (NE2000 compatible) on the translator, and an integrated SiS in th e ipv6 host. The win98 is a laptop with a pcmcia card.
> 
> Here I send my new config file and the new capture in the translator

I've had no time to get a look at it.

I would advise to also test it with click at kernel level if you can.

regards,
Brecht