From owner-freebsd-arm@FreeBSD.ORG Thu Jan 31 15:17:32 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AC155C4F for ; Thu, 31 Jan 2013 15:17:32 +0000 (UTC) (envelope-from mats@exmandato.se) Received: from ext.mellstrand.net (ext.mellstrand.net [IPv6:2001:2040:4:2::51]) by mx1.freebsd.org (Postfix) with ESMTP id 01CE2D80 for ; Thu, 31 Jan 2013 15:17:31 +0000 (UTC) Received: by ext.mellstrand.net Thu, 31 Jan 2013 15:17:22 GMT Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 From: Mats Mellstrand X-Priority: 3 In-Reply-To: <9E78813F3BF946A4A2FCEA2C363A847E@ad.peach.ne.jp> Date: Thu, 31 Jan 2013 16:17:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2659960079254C38ACD2F1DCBB7A1A19@ad.peach.ne.jp> <722ED669-A682-4F25-A65B-1E2FF8CFAA4D@exmandato.se> <20130131001553.GC67562@cicely7.cicely.de> <9E78813F3BF946A4A2FCEA2C363A847E@ad.peach.ne.jp> To: Daisuke Aoyama Cc: freebsd-arm@freebsd.org, ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list 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 15:17:32 -0000 Hi Thanks!=20 Your patch works fine! /mm On 31 jan 2013, at 16:07, Daisuke Aoyama wrote: > Hi, >=20 > I found a solution. When disabling hardware check sum offload, it = works. > (# ifconfig ue0 -rxcsum) >=20 > Please check new kernel or apply the patch attached this mail. > http://www.peach.ne.jp/archives/rpi/kernel/kernel-20130131.gz >=20 > Thanks, > --=20 > Daisuke Aoyama >=20 > -------------------------------------------------- > From: "Bernd Walter" > Sent: Thursday, January 31, 2013 9:15 AM > To: "Mats Mellstrand" > Cc: "Daisuke Aoyama" ; > Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + = ubldr) >=20 >> On Wed, Jan 30, 2013 at 06:28:12PM +0100, Mats Mellstrand wrote: >>> Hi >>>=20 >>>=20 >>> On 30 jan 2013, at 17:28, Daisuke Aoyama wrote: >>>=20 >>> >> 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=3D8843 metric = 0 mtu 1500 >>> >> options=3D80008 >>> >> 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=3D21 >>> >> media: Ethernet autoselect (100baseTX ) >>> >> status: active >>> > >>> > If possible, please try other ether device (include wireless LAN). >>>=20 >>>=20 >>> Thanks! The interface run0/wlan0 works fine with IPv6 >>=20 >> 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. >>=20 >> 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... >>=20 >> 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. >>=20 >>=20 >> --=20 >> B.Walter http://www.bwct.de >> Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. >