Re: Beaglebone software issues [was: Using beaglebones as boards for the ietf "homenet" and "babel" working groups]

[Jason Kridner]

This gmail client bites and doesn't allow for inline replies. You don't have to subscribe to post. This is now cross-posted...

On Wed, Jul 27, 2016 at 10:49 AM Juliusz Chroboczek <j...@pps.univ-paris-diderot.fr> wrote:

Hi Jason, and thanks for your kind reply.

> The larger and more official for .org boards is "beagleboard",
> http://BeagleBoard.org/discuss or beagl...@googlegroups.com.

I've tried to subscribe, but it asks me for a Google account.

(Snipped bunch of helpful info, will look into it.)

>> The critical bit is to remove connman, which broke the WiFi on a network
>> with a DHCPv6 server

> Grrr connman. It drives us nuts all the time.

Why not simply use the static /etc/network/interfaces config, perhaps with
a script to edit it automatically?  Right now, your system has three
different methods for configuring interfaces (/etc/network, connman, and
the hotspot thingie), which is a lot of conceptual load for somebody new
to Linux.

>> There is a race condition between booting and loading the Bluetooth
>> firmware.  Reloading the firmware manually works around the issue.

> This has been haunting us for a while.

Okay, that's good to know, I'll keep hacking at it.

>> There appears to be a race condition that prevents udhcpd from running on
>> some occasions.  Rebooting works around the issue.

> I added a recent hack to lower the lease time dramatically to
> work-around the issue.

I don't think it's the same issue.  In my case, there's no udhcpd process,
while systemd wrongly thinks that it's running.  I blame systemd, but
then, I always do ;-)

I'd be interested to hear what is the issue you're having, as I might be
able to help (I've implemented DHCPv4 before).

Thanks again,

-- Juliusz

[evilwulfie]

Try pop3 on thunderbird with gmail works perfect.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CA%2BT6QPmjpn23v4yztShetZ%3DnKv_W4X9gW-2wFRVqWWRm3WiH%3DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Juliusz Chroboczek]

>>> There is a race condition between booting and loading the Bluetooth
>>> firmware. Reloading the firmware manually works around the issue.

>> This has been haunting us for a while.

Okay, I found it. You just need to add

Type=forking

to the [Service] section of /lib/systemd/system/bb-wl18xx-bluetooth.service .

What's going on is that the script is starting the hciconfig daemon.
However, systemd knows better than you, so it kills the daemon as soon as
your script exits.

With "Type=forking", you politely ask systemd to stop being a dick.

-- Juliusz

[Juliusz Chroboczek]

After some reading of the kernel sources (always a pleasure), I've found
how to enable 2x2 MIMO on the BBGW. I'm getting 77Mbit/s downstream (TCP
iperf), which is pretty cool, but only 22Mbit/s upstream.

In order to enable 2x2 MIMO on the board, you need to add a file
/etc/modprobe.d/wl18xx.conf containing the following line:

options wl18xx ht_mode=default

This might actually be an upstream bug -- the default ht_mode should
probably be "default" (duh), and the documentation for the "n_antennas_2"
module parameter is incorrect (it is documented as defaulting to 1, but
actually defaults to 2).

I'll let you know if something breaks.

-- Juliusz

[William Hermans]

With "Type=forking", you politely ask systemd to stop being a dick.

-- Juliusz

heh !

[Dave Taht]

On Wed, Jul 27, 2016 at 6:25 PM, Juliusz Chroboczek
<j...@pps.univ-paris-diderot.fr> wrote:
> After some reading of the kernel sources (always a pleasure), I've found
> how to enable 2x2 MIMO on the BBGW. I'm getting 77Mbit/s downstream (TCP
> iperf), which is pretty cool, but only 22Mbit/s upstream.

Is this AP/sta or adhoc mode?

It may be you are running low on memory bandwidth or cpu. I'd done a
test over usbnet to the board and got about the same result.

Does the wifi use the softmac layer? The changes toke made there on
ath9k (see https://blog.tohojo.dk/2016/06/fixing-the-wifi-performance-anomaly-on-ath9k.html
) resulted in quite a nice gain in performance.

Also the supplied antennas are not the best, you can get better
antennas pretty cheaply via amazon.

> In order to enable 2x2 MIMO on the board, you need to add a file
> /etc/modprobe.d/wl18xx.conf containing the following line:
>
> options wl18xx ht_mode=default
>
> This might actually be an upstream bug -- the default ht_mode should
> probably be "default" (duh), and the documentation for the "n_antennas_2"
> module parameter is incorrect (it is documented as defaulting to 1, but
> actually defaults to 2).
>
> I'll let you know if something breaks.

Next time I boot mine I will add in all the changes you've figured out
out! Thanks!
> -- Juliusz



--
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

[Juliusz Chroboczek]

>> After some reading of the kernel sources (always a pleasure), I've found
>> how to enable 2x2 MIMO on the BBGW. I'm getting 77Mbit/s downstream (TCP
>> iperf), which is pretty cool, but only 22Mbit/s upstream.

> Is this AP/sta or adhoc mode?

Client mode to a WNDR 3700 situated in the next room. I didn't run any
more extensive tests, I was only trying to ensure that MIMO was
functional. (If you asked me, I'd guess that the AP is doing aggregation
and the STA isn't, but since you aren't asking, I'm not going to guess.)

> It may be you are running low on memory bandwidth or cpu.

Perhaps.

> I'd done a test over usbnet to the board and got about the same result.

For me, usbnet goes the other way around (upstream traffic has higher
throughput than downstream). It would probably take a USB protocol
analyser to understand why.

> Does the wifi use the softmac layer?

It looks to me like a completely separate module implemented in its own
microcontroller (I think it's connected through SDIO, plus a UART, plus
a GPIO, plus an interrupt line). Jason, do you know where I can find the
programming manual?

-- Juliusz

[Jason Kridner]

Brilliant!

https://github.com/rcn-ee/repos/pull/17

 

-- Juliusz

[Jason Kridner]

On Jul 29, 2016, at 5:12 PM, Juliusz Chroboczek <j...@pps.univ-paris-diderot.fr> wrote:

>> https://github.com/rcn-ee/repos/pull/17
>
> Thanks for the speedy commit.
>
> Have you considered my suggestion to enable MIMO in the Wifi by default?

I haven't noticed that suggestion yet. Do you say how to do so?

> Since the BBGW has two antenna connectors, it might make sense, although
> it might cause problems for people who decide not to connect any
> antennas -- I'm not sure how well the chip handles having just one antenna
> in MIMO mode (detecting misconfiguration is doable, just not usually
> implemented except on Atheros chips).
>
> On a related note -- I've evaluated the BBGW carefully, and while I like
> the hardware very much, it's unsuitable for my purposes since it's unable
> to do ad-hoc (I need a chip able to do ad-hoc and AP at the same time).
> Do you know if there are any plans to implement ad-hoc on the wl18xx?

I'm looking at talking to a third party for some firmware updates. I will inquire if this can be done.

>
> Finally, does anyone know how to test whether a USB port has enough power
> for the Beaglebone? I'm hooking mine off a port I don't have reliable
> information on, I'm wondering how to load it so I can know for sure.

By the spec, it likely does not. In practice, you are likely fine. I think the WL1835MOD can pull 800mA during quick calibration cycles.

>
> Thanks,
>
> -- Juliusz

[Jason Kridner]

On Wed, Jul 27, 2016 at 10:49 AM Juliusz Chroboczek <j...@pps.univ-paris-diderot.fr> wrote:

Hi Jason, and thanks for your kind reply.

> The larger and more official for .org boards is "beagleboard",
> http://BeagleBoard.org/discuss or beagl...@googlegroups.com.

I've tried to subscribe, but it asks me for a Google account.

(Snipped bunch of helpful info, will look into it.)

>> The critical bit is to remove connman, which broke the WiFi on a network
>> with a DHCPv6 server

> Grrr connman. It drives us nuts all the time.

Why not simply use the static /etc/network/interfaces config, perhaps with
a script to edit it automatically?  Right now, your system has three
different methods for configuring interfaces (/etc/network, connman, and
the hotspot thingie), which is a lot of conceptual load for somebody new
to Linux.

I think Robert would have to reply, but I'm guessing that connman provides a GUI and lots of seemingly useful defaults while remaining relatively small.

Can /etc/network handle it all?  How do you enable a GUI or even CUI to edit it?

 

>> There is a race condition between booting and loading the Bluetooth
>> firmware.  Reloading the firmware manually works around the issue.

> This has been haunting us for a while.

Okay, that's good to know, I'll keep hacking at it.

Thanks for solving that issue for us!!!

 

>> There appears to be a race condition that prevents udhcpd from running on
>> some occasions.  Rebooting works around the issue.

> I added a recent hack to lower the lease time dramatically to
> work-around the issue.

I don't think it's the same issue.  In my case, there's no udhcpd process,
while systemd wrongly thinks that it's running.  I blame systemd, but
then, I always do ;-)

I'd be interested to hear what is the issue you're having, as I might be
able to help (I've implemented DHCPv4 before).

I haven't really narrowed it down, but I think on unclean shutdowns, and perhaps other conditions as well, the leases file doesn't get deleted and UDHCPD thinks all (the only) lease is already checked out. It could also have to do with the virtual MAC address changing at times. Anyway, reducing the lease time is appearing to make the situation livable, but it isn't a fix to the issue.

I think our lives could be a lot easier if we could figure out how to configure dnsmasq for all of our DNS/DHCP needs (and keep connman out of the way).

For newbs, wifi network config via a GUI is a big deal, but we are typically headless.

 

Thanks again,

-- Juliusz

[Juliusz Chroboczek]

n <87oa5jp2...@pps.univ-paris-diderot.fr>
<CA+T6QPmjpn23v4yztShetZn...@mail.gmail.com>
<87lh0noz...@pps.univ-paris-diderot.fr>
<CA+T6QPkxuAWycFHMq7A-PUHb...@mail.gmail.com>
<87y44k5e...@pps.univ-paris-diderot.fr>
n <210A8A84-01E5-4934...@gmail.com>
User-Agent: Wanderlust/2.15.9

>> Have you considered my suggestion to enable MIMO in the Wifi by default?

> I haven't noticed that suggestion yet. Do you say how to do so?

From my mail dated 27 July 2016, sent to both lists:

After some reading of the kernel sources (always a pleasure), I've found
how to enable 2x2 MIMO on the BBGW. I'm getting 77Mbit/s downstream (TCP
iperf), which is pretty cool, but only 22Mbit/s upstream.

In order to enable 2x2 MIMO on the board, you need to add a file
/etc/modprobe.d/wl18xx.conf containing the following line:

options wl18xx ht_mode=default

This might actually be an upstream bug -- the default ht_mode should
probably be "default" (duh), and the documentation for the "n_antennas_2"
module parameter is incorrect (it is documented as defaulting to 1, but
actually defaults to 2).

-- Juliusz

[Juliusz Chroboczek]

> I think Robert would have to reply, but I'm guessing that connman provides a
> GUI and lots of seemingly useful defaults while remaining relatively small.

Yes. See the note at the bottom.

> Can /etc/network handle it all? How do you enable a GUI or even CUI to edit
> it?

It cannot and you don't. See the note at the bottom.

> I haven't really narrowed it down, but I think on unclean shutdowns, and
> perhaps other conditions as well, the leases file doesn't get deleted and
> UDHCPD thinks all (the only) lease is already checked out.

Right now my board is broken, so I cannot do more debugging -- as soon as
I do a wifi scan, it Oopses. I've reflashed it over USB, no help, so
I guess either my uBoot is corrupted, or something is wrong with my power
supply. I'll keep hacking (next step is to reflash from SD, advice
appreciated), but I'm soon running out of time.

But what I was seeing with udhcpcd is a different issue -- udhcpd does
a DHCPOFFER (the first "discovery" stage of lease acquisition), then gets
killed by SIGTERM. I'll go off a limb and blame systemd again, but
I really don't know.

> I think our lives could be a lot easier if we could figure out how to
> configure dnsmasq for all of our DNS/DHCP needs (and keep connman out of the
> way).

Definitely. Dnsmasq is a rock solid piece of software.

> For newbs, wifi network config via a GUI is a big deal,

I most respectfully disagree.

Newbies need clear instructions that work. Newbies are fine with editing
a cryptical file, as long as the result works reliably. What is not
user-friendly, on the other hand, is having a system that fails for
mysterious reasons -- newbies cannot troubleshoot it, so they try the same
operations again and again and tear their hair out.

Jason, I've got 20 years experience working with first year students.
They're 18, they're uneducated, and not all of them are CS students --
I work with biologists, psychology students, even linguistic students. And
the conclusion is always the same, clear and working instructions are
fine, no matter how cryptic, things that don't work reliably are
frustrating.

If I were you, I'd do something much simpler. Less ambitious, but rock
solid. I can outline it if you think it can be useful.

> but we are typically headless.

Which only adds insult to injury.

-- Juliusz

[Juliusz Chroboczek]

> https://github.com/rcn-ee/repos/pull/17

Thanks for the speedy commit.

Have you considered my suggestion to enable MIMO in the Wifi by default?

Since the BBGW has two antenna connectors, it might make sense, although
it might cause problems for people who decide not to connect any
antennas -- I'm not sure how well the chip handles having just one antenna
in MIMO mode (detecting misconfiguration is doable, just not usually
implemented except on Atheros chips).

On a related note -- I've evaluated the BBGW carefully, and while I like
the hardware very much, it's unsuitable for my purposes since it's unable
to do ad-hoc (I need a chip able to do ad-hoc and AP at the same time).
Do you know if there are any plans to implement ad-hoc on the wl18xx?

Finally, does anyone know how to test whether a USB port has enough power
for the Beaglebone? I'm hooking mine off a port I don't have reliable
information on, I'm wondering how to load it so I can know for sure.

Thanks,

-- Juliusz

[drhun...@gmail.com]

Hi Juliusz,

As far as the wl1835 driver is concerned it has MIMO enabled.

It is defined in the file /lib/firmware/ti-connectivity/wl18xx-conf.bin in the entry wl18xx.phy.number_of_assembled_ant2_4 = 0x02. 

You can inspect the contents of this file with

#wlconf -i /lib/firmware/ti-connectivity/wl18xx-conf.bin -g | grep phy

There is no ad-hoc mode driver for WL18xx. There is an 802.11s mesh driver using open80211s. However, this is only available in TI's driver at the moment in latest release R8.7 (http://software-dl.ti.com/ecs/WiLink8/latest/index_FDS.html). It is relatively trivial exercise to build this driver.

Iain

[drhun...@gmail.com]

I missed your USB question.

If you don't have enough power from USB for the Wi-Fi calibration you will get a driver timeout just after initialisation.

I use a 2.1A powered Hub for my BBGW having seen failures on other "supplies".

Iain

[Juliusz Chroboczek]

> As far as the wl1835 driver is concerned it has MIMO enabled.
> It is defined in the file /lib/firmware/ti-connectivity/wl18xx-conf.bin in the
> entry wl18xx.phy.number_of_assembled_ant2_4 = 0x02.

Right. It looks like I was confused, then. I'll do some more testing.

Thanks for your help,

-- Juliusz

[Juliusz Chroboczek]

> As far as the wl1835 driver is concerned it has MIMO enabled.

After some further checking, I don't think it does.

$ wlconf -i /lib/firmware/ti-connectivity/wl18xx-conf.bin -g | grep ht.mode
wl18xx.ht.mode = 0x01

From wl18xx/conf.h:

enum wl18xx_ht_mode {
/* Default - use MIMO, fallback to SISO20 */
HT_MODE_DEFAULT = 0,

/* Wide - use SISO40 */
HT_MODE_WIDE = 1,

/* Use SISO20 */
HT_MODE_SISO20 = 2,
};

This can be worked around with the ht_mode module parameter, as
I previously reported.

-- Juliusz