Le 13 juil. 2015 3:44 PM, Thomas B. Rücker thomas@ruecker.fi a écrit :
Hi,
On 07/13/2015 11:41 AM, Nicolas Dechesne wrote:
Le 13 juil. 2015 12:44 PM, Thomas B. Rücker thomas@ruecker.fi a écrit
:
After some unrelated delay, I have started using my Dragonboard. I downloaded a Linaro customized Ubuntu image: dragonboard410c_sdcard_install_ubuntu-40-47.zip from:
http://builds.96boards.org/releases/dragonboard410c/linaro/ubuntu/latest/
I was very surprised to find out that the IP network stack is broken on this image (cf. RFC 6540). The Kernel has been built with IPv6
disabled.
This means I can't reach a substantial part of my test network and my production systems.
Who at LINARO do I need to poke to get this fixed?
To me ... or to bugs.96boards.org
Ah, good. :-)
This is something that will be fixed in July release, and already fixed
in
our daily builds, can you inspect our current kernel config [1] and let
us
know if that fixes your issues.
[1]
http://builds.96boards.org/snapshots/dragonboard410c/linaro/ubuntu/latest/ke...
Skimmed the config, looked OK. Found the images in the same directory flashed them.
Thanks!
Good news: Yes the kernel knows about IPv6. The interfaces come up with link local addresses from within fe80::/64.
Bad news: Something horribly breaks the network behaviour of this board. It does NOT acquire a routed IPv6 prefix through stateless auto configuration. It doesn't even see the route advertisements (checked by installing 'radvd' and running 'radvdump'). Other devices on the network use those without issue. The IPv6 link local address is NOT reachable over ICMPv6. It becomes reachable by _one_ node at a time by pinging that node _from_ the device. Actually the same behaviour can be observed for legacy IPv4 too. You can't ping the device until the Dragonboard has pinged that particular machine and its address first.
I'm not going to bother explaining how broken such network behaviour is, it's rather obvious. Time to get a USB ethernet adaptor from my drawer.
Is there anything I can do to the wifi driver to fix this? Like disabling all optimizations and power saving? I highly suspect this is one of those optimized until useless for anything than an Android phone in its basic use case drivers.
The wlan driver we use is wcn36xx from mainline, it's a reverse eng driver, not a qcom driver, and not used in any android product:
https://wireless.wiki.kernel.org/en/users/drivers/wcn36xx
While the driver is still WIP , at least we can engage with upstream and hope to fix issues.. I am not working this week.. But will get back on that next week.
Thomas
PS: I'm also available for chat on #96boards on freenode IRC, but it's a rather dead channel it seems.