From owner-freebsd-arm@FreeBSD.ORG Thu Jan 31 00:42:14 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9726E7F7 for ; Thu, 31 Jan 2013 00:42:14 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 40F36F86 for ; Thu, 31 Jan 2013 00:42:13 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id r0V0FuQ7095264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 31 Jan 2013 01:15:57 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id r0V0FsE7011600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jan 2013 01:15:54 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id r0V0Fs9f068031; Thu, 31 Jan 2013 01:15:54 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id r0V0FrBZ068030; Thu, 31 Jan 2013 01:15:53 +0100 (CET) (envelope-from ticso) Date: Thu, 31 Jan 2013 01:15:53 +0100 From: Bernd Walter To: Mats Mellstrand Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) Message-ID: <20130131001553.GC67562@cicely7.cicely.de> References: <2659960079254C38ACD2F1DCBB7A1A19@ad.peach.ne.jp> <722ED669-A682-4F25-A65B-1E2FF8CFAA4D@exmandato.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 00:42:14 -0000 On Wed, Jan 30, 2013 at 06:28:12PM +0100, Mats Mellstrand wrote: > Hi > > > On 30 jan 2013, at 17:28, Daisuke Aoyama 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@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@raspberry-pi:~ % ifconfig ue1 > >> ue1: flags=8843 metric 0 mtu 1500 > >> options=80008 > >> 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 > >> media: Ethernet autoselect (100baseTX ) > >> 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 http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.