FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr)

[Bernd Walter]

On Wed, Jan 30, 2013 at 06:28:12PM +0100, Mats Mellstrand wrote:
> Hi
> 
> 
> On 30 jan 2013, at 17:28, Daisuke Aoyama <aoyama at peach.ne.jp> wrote:
> 
> >> The image works, but I can't get IPv6 to work as expected.
> >> I can ping6 to and from my Raspberry but trying to ssh in to RPIs IPv6 address just hangs.
> >> The same happens when I try to ssh out from RPI to a IPv6 address.
> >> IPv4 works.
> > 
> > Sorry, I didn't check with ue0.
> > It seems if_smsc is buggy.
> > I'm using axe for testing. It works IPv6.
> > 
> >> pi at raspberry-pi:~ % w
> >> 4:19PM  up  2:50, 3 users, load averages: 0.00, 0.00, 0.00
> >> USER       TTY      FROM                      LOGIN@  IDLE WHAT
> >> root       u0       -                         4:11PM     - -csh (csh)
> >> pi         pts/0    172.18.0.20               4:12PM     - _su (csh)
> >> pi         pts/1    2001:3e0:6cf:18:20c:29ff  4:19PM     - w
> >> pi at raspberry-pi:~ % ifconfig ue1
> >> ue1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> >>       options=80008<VLAN_MTU,LINKSTATE>
> >>       ether 10:6f:3f:66:75:1d
> >>       inet6 fe80::126f:3fff:fe66:751d%ue1 prefixlen 64 scopeid 0x3
> >>       inet 172.18.0.99 netmask 0xffff0000 broadcast 172.18.255.255
> >>       inet6 2001:3e0:6cf:18:126f:3fff:fe66:751d prefixlen 64
> >>       nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
> >>       media: Ethernet autoselect (100baseTX <full-duplex>)
> >>       status: active
> > 
> > If possible, please try other ether device (include wireless LAN).
> 
> 
> Thanks! The interface run0/wlan0  works fine with IPv6

If IPv4 works, then usually multicast hash support is broken in driver.
It is hard to debug if you are unaware of the undelying protocol details.
Assuming machine B is the one with the brokmen driver.
You can't ping6 from A to B until B sends anything to A.
This way A learns MAC address from B without needing the neighbor
discovery packet (ARP replacement, although ND6 has other purpose as well),
which is send via multicast, to be received by machine B.
Putting an interface into promiscuous helps as workaround, because then
the interface won't filter anything and all multicast frames are received
as well, unless promiscuous support is broken too.
If ping6 works both sides than ssh should do as well, but only if you
try before the nd6 entries expire.
A simple ping6 test might look as if it works if you started ping6 from
B to A before trying from A to B, so A already has nd6 entry for B.
You can lookup nd6 table by issuing ndp -an command.

Some low level details.
A system has an IPv6 adress configured on it's interface.
It also joins a multicast group for that IP address.
There is a formular to calculate the multicast address from the unicast(*)
address.
(*) when I write unicast I also mean link local and anycast as well.
You can lookup all IP addresses including multicast by netstat -ia.
A system, which wants to send an IPv6 packet to an IPv6 address at the
same LAN needs the MAC address of the machine, which has the IPv6 address
configured.
Unless it has the address in his neighbor address cache already it
sends an inquiry (Neighbor Discovery ND) to the multicast address - with
IPv4 it was send via broadcast.
It knows the multicast address by using the same formular from the
targeting unicast address as the host owning that address.
This way the inquiry packet won't disturb every host allowing larger LANs.
Some IPv6 unicast addresses share the same multicast, so there are some
collisions, but less than with broadcast.
Multicast however also needs to be transfered using target MAC addresses.
There is a formular which translates an IPv6 multicast address to an
ethernet MAC address, giving more address collisions.
Network interfaces can't filter countless individual MAC addresses, so
there is a filter layer as well, usually containg 64 bits, with each
bit allowing a given set of multicast MAC addresses.
The formular from MAC address to filter bit is hardware dependend,
although most use the plain old NE2000 formular, there are exeptions
with other formular and chips using more bits allowing finer filters.
This point is often done wrong in drivers - some forgot to take care
about multicast bits completely, some use the standard NE2000 filter
with hardware using something different, etc...

PS:
In the end there are many collisions, only to be avoided by using
multicast aware switches in large LANs and a few multicast addresses.
Therefor also wise to avoid some unicast addresses as they collide
with anyhost or other popular multicast addresses.


-- 
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.