Debian Jessie release and rfkill soft block Bluetooth/WiFi on boot

[erich...@gmail.com]

I have recently acquired a Beagleboard Black for a project and am having some problems with WiFi rfkill soft blocking.

Following the the recommendations on the getting started page, I updated the system to the latest Jessie release, Debian 8.2 2015-11-12. I also followed the recommendation to update to the latest kernel: 4.1.13-ti-r36 as of this writing.

I next attached a WiFi adaptor: Realtek Semiconductor RTL8188CUS 802.11n, and followed the recommendation to edit the /etc/network/interfaces file to uncomment the WLAN example and set the SSID and passphrase (using the output of wpa_passphrase).

I saw that rfkill has the interface soft blocked; manually unblocking the interface, I can connect to my WiFi network, however, this does not survive a reboot, even though the systemd-rfkill service is running, which should preserve rfkill state across reboots. Further checking the service, I discovered that by default the rfkill service saves the state, but does not restore unless a kernel parameter, system.restore_state is set, which I have done in the uEnv.txt file via:

cmdline=coherent_pool=1M quiet cape_universal=enable systemd.restore_state=1

Despite this, the WiFi is still blocked upon boot. Any ideas for what configuration changes are needed to get WiFi enabled (hopefully without a kludge tower of scripts, this ought to be a single parameter change somewhere)?

[fishe...@gmail.com]

Found a solution.... remove connmand and install network-manager. network-manager seemed to "just work" (once you remove the wifi config lines from /etc/network/interfaces). This guide pointed me in the right direction: http://madscientistlabs.blogspot.com/2015/01/wifi-on-beaglebone-black-with-systemd.html

[fishe...@gmail.com]

I hate to make an unhelpful "me too" post, but... me too. Same adapter.

I did notice that in the boot logs from journalctl, everything seems like it's working fine up until connmand starts. I'm not too familiar with connmanctl or how connmand works, so I'm kind of bumbling around with that at the moment.

On Monday, December 14, 2015 at 8:06:17 PM UTC-5, erich...@gmail.com wrote:

[Robert Nelson]

On Sun, Dec 20, 2015 at 1:55 AM, <fishe...@gmail.com> wrote:
> Found a solution.... remove connmand and install network-manager.
> network-manager seemed to "just work" (once you remove the wifi config lines
> from /etc/network/interfaces). This guide pointed me in the right direction:
> http://madscientistlabs.blogspot.com/2015/01/wifi-on-beaglebone-black-with-systemd.html

So the only reason we use connman on jessie with the beaglebone black..

If you define, "eth0" in /etc/network/interfaces but don't actually
plug in the ethernet jack, it takes up to 2 minutes before
ifup/friends gives up and then allows the boot to move on.

So connman is in control..

With the lxqt/gui, we have "CMST" installed to give you easy control
of connman..

So for the future, with "stretch" systemd has a networkd.service,
which i think will allow us to drop the conman workaround..

http://www.freedesktop.org/software/systemd/man/systemd-networkd.service.html

Regards,

--
Robert Nelson
https://rcn-ee.com/

[Enoch]

Hi Robert,

Like other USB WiFi users before me I have had the chipset (RT5370 in my
case) soft blocked after each boot. The problem, IMHO, rests with
/lib/systemd/systemd-rfkill and not with rfkill itself.

The /lib/systemd/system/systemd-rfkill@.service unit is expected to
restore the blocking state of all devices after boot to what they were
on shutdown. This is a perfect policy only that it has some bug...

The network-manager package nmtui utility is a too convenient solution
to those encountering trouble or otherwise this systemd bug would have
been long gone.

Can you provide a pointer to systemd-rfkill source code of the latest
image?

Thanks, Enoch.

----------------------------------------------------------------------


Robert Nelson <robert...@gmail.com>
writes:

[Robert Nelson]

On Tue, Dec 22, 2015 at 6:56 PM, Enoch <ix...@hotmail.com> wrote:
> Hi Robert,
>
> Like other USB WiFi users before me I have had the chipset (RT5370 in my
> case) soft blocked after each boot. The problem, IMHO, rests with
> /lib/systemd/systemd-rfkill and not with rfkill itself.
>
> The /lib/systemd/system/systemd-rfkill@.service unit is expected to
> restore the blocking state of all devices after boot to what they were
> on shutdown. This is a perfect policy only that it has some bug...
>
> The network-manager package nmtui utility is a too convenient solution
> to those encountering trouble or otherwise this systemd bug would have
> been long gone.
>
> Can you provide a pointer to systemd-rfkill source code of the latest
> image?

So in wheezy, we have systemd v215

https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/log/?h=jessie

For us, i've add one patch:

https://github.com/rcn-ee/repos/blob/master/debian-8-systemd/suite/jessie/debian/patches/0001-systemd-backport-70-power-switch.rules.patch

Upstream repo is here:

https://github.com/systemd/systemd

Maybe?

https://github.com/systemd/systemd/pull/1438

i need to push out 215-17+deb8u3 + our patch first, then i'll queue
1438 up for a test bulid..

[Robert Nelson]

On Tue, Dec 22, 2015 at 7:32 PM, Robert Nelson <robert...@gmail.com> wrote:
> On Tue, Dec 22, 2015 at 6:56 PM, Enoch <ix...@hotmail.com> wrote:
>> Hi Robert,
>>
>> Like other USB WiFi users before me I have had the chipset (RT5370 in my
>> case) soft blocked after each boot. The problem, IMHO, rests with
>> /lib/systemd/systemd-rfkill and not with rfkill itself.
>>
>> The /lib/systemd/system/systemd-rfkill@.service unit is expected to
>> restore the blocking state of all devices after boot to what they were
>> on shutdown. This is a perfect policy only that it has some bug...
>>
>> The network-manager package nmtui utility is a too convenient solution
>> to those encountering trouble or otherwise this systemd bug would have
>> been long gone.
>>
>> Can you provide a pointer to systemd-rfkill source code of the latest
>> image?
>
> So in wheezy, we have systemd v215

"jessie"

[Enoch]

Robert Nelson <robert...@gmail.com>
writes:

The Season's Greetings!

(1) I'm pleased to advise that your recent systemd update solved the problem
with systemd-rfkill. No longer it comes up soft blocked.

(2) I need a DTB with ttyS4 enabled so I have to use dtb-rebuilder. My
first attempt bricked the system though I made sure (at least
I believe so) to have matching sources... will try again.

Regards, Enoch.

[Enoch]

Answering my own question for the occasional Googler:

RN is using a non standard DTC. Run the script 'dtb-rebuilder/dtc-overlay.sh' to
create. Could have helped if the README had mentioned that :-)

Regards, Enoch.





>
> Regards, Enoch.