Hi,
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?
Thomas
PS: The ZIP file contains a license file that seems to imply that ALL contents are copyright QTI and subject to a proprietary license. I'm rather sure Linus and a few other people would disagree with that. Someone might want to fix that.
Le 13 juil. 2015 12:44 PM, Thomas B. Rücker thomas@ruecker.fi a écrit :
Hi,
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
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...
Thomas
PS: The ZIP file contains a license file that seems to imply that ALL contents are copyright QTI and subject to a proprietary license. I'm rather sure Linus and a few other people would disagree with that. Someone might want to fix that.
Will check this one too
Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev
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.
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.
Thomas
PS: I'm also available for chat on #96boards on freenode IRC, but it's a rather dead channel it seems.
"Thomas B. Rücker" wrote (ao):
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.
FWIW, there is a post on the forum regarding this issue:
https://www.96boards.org/forums/topic/410c-linux-and-incoming-tcpip-connecti...
Patryk writes: "Today we noticed that in when the 410C is configured in hotspot mode using hostapd (so that you can directly connect to it without going through a Wifi network), this problem does not occur."
Sander
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.
On 07/13/2015 02:02 PM, Nicolas Dechesne wrote:
Le 13 juil. 2015 3:44 PM, Thomas B. Rücker thomas@ruecker.fi a écrit :
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.
I just dug out an old 'ADMtek ADM8511 "Pegasus II" USB Ethernet' device. Looks like the necessary "pegasus" driver wasn't compiled. Please consider this a high priority wishlist item for when you are back in the office: Enable all possible usb-ethernet drivers to be available as modules.
That way it will be easily possible for people to get around the WiFi experience.
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:
I wonder though why nobody noticed that it is that broken so far? Or could it be a configuration or a WiFi firmware issue? I'll try to dig into the driver. I suspect it's filtering multicast traffic or such and the Wiki page mentions multicast filtering explicitly.
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.
Enjoy your time off then and let's get things tackled next week.
Thomas
hi Thomas,
On Mon, Jul 13, 2015 at 4:16 PM, "Thomas B. Rücker" thomas@ruecker.fi wrote:
I just dug out an old 'ADMtek ADM8511 "Pegasus II" USB Ethernet' device. Looks like the necessary "pegasus" driver wasn't compiled. Please consider this a high priority wishlist item for when you are back in the office: Enable all possible usb-ethernet drivers to be available as modules.
That way it will be easily possible for people to get around the WiFi experience.
I am planning to add the following to our config:
+# USB Eth +CONFIG_USB_CATC=m +CONFIG_USB_KAWETH=m +CONFIG_USB_PEGASUS=m +CONFIG_USB_RTL8150=m +CONFIG_USB_RTL8152=m +CONFIG_USB_NET_SR9700=m +CONFIG_USB_NET_SR9800=m +CONFIG_USB_NET_SMSC75XX=m +CONFIG_USB_NET_SMSC95XX=m +CONFIG_USB_NET_MCS7830=m
Does that cover your needs?
cheers nico
On 07/22/2015 10:34 AM, Nicolas Dechesne wrote:
hi Thomas,
On Mon, Jul 13, 2015 at 4:16 PM, "Thomas B. Rücker" thomas@ruecker.fi wrote:
I just dug out an old 'ADMtek ADM8511 "Pegasus II" USB Ethernet' device. Looks like the necessary "pegasus" driver wasn't compiled. Please consider this a high priority wishlist item for when you are back in the office: Enable all possible usb-ethernet drivers to be available as modules.
That way it will be easily possible for people to get around the WiFi experience.
I am planning to add the following to our config:
+# USB Eth +CONFIG_USB_CATC=m +CONFIG_USB_KAWETH=m +CONFIG_USB_PEGASUS=m +CONFIG_USB_RTL8150=m +CONFIG_USB_RTL8152=m +CONFIG_USB_NET_SR9700=m +CONFIG_USB_NET_SR9800=m +CONFIG_USB_NET_SMSC75XX=m +CONFIG_USB_NET_SMSC95XX=m +CONFIG_USB_NET_MCS7830=m
Does that cover your needs?
That covers mine yes. There are a few other drivers a few lines down in the config. Not sure how common they are. I have a GBit USB3 adapter on order and will check its chipset once it arrives. Worst case we just add more entries later. :-)
Thanks!
Thomas