On Thu, 2020-05-28 at 00:37 -0700, Samuel Sieb wrote:
On 5/27/20 3:46 PM, Robert G (Doc) Savage via users wrote:
> Here's what "journalctl -b" tells me:
>
> May 27 16:48:50
tiger.protogeek.org rfkill[14554]: unblock set for
> all
> May 27 16:48:50
tiger.protogeek.org audit[1]: SERVICE_START pid=1
> uid=0
> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
> msg='unit=systemd-rfkill comm="systemd"
> exe="/usr/lib/systemd/systemd"
> hostname=? addr=? terminal=? res=success'
> May 27 16:48:56
tiger.protogeek.org systemd[1]: systemd-
> rfkill.service:
> Succeeded.
> May 27 16:48:56
tiger.protogeek.org audit[1]: SERVICE_STOP pid=1
> uid=0
> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
> msg='unit=systemd-rfkill comm="systemd"
> exe="/usr/lib/systemd/systemd"
> hostname=? addr=? terminal=? res=success'
Is that the only references to rfkill? Did the log start at boot up?
Try searching also for "KILL", it's likely in the wifi device
initialization.
No. It was the final instance of four lines that repeat every time I
disconnect my copper Ethernet cable and the system tries to light up
the WiFi connection. In my next reply I'll send the entire output
following a restart.
What is the "lspci" line for your wifi device?
# lspci
...
00:14.3 Network controller: Intel Corporation Wireless-AC 9560
[Jefferson Peak] (rev 10)
...
> It looks like every time the service tries to start wifi with
> rfkill,
> SOMETHING is turning it around and stopping it. As the rfkill list
> command shows, this denial will apparently be done on all wifi
> connections that are stored in /etc/sysconfig/network-scripts:
systemd-rfkill is a static service, it runs when called and then
stops.
> # rfkill list
> 2: phy0: Wireless LAN
> Soft blocked: no
> Hard blocked: yes
>
> Since there is no hardware switch to enable/disable WiFi on the
> ThinkPad P72, there must be some configuration command I can give
> that
> turns "Hard blocked: yes" to "Hard blocked: no".
No, that's the difference between a "hard" block and a "soft"
block.
You need to find out why rfkill thinks the hardware is blocked.
Because of a recent event where the opposite situation occurred -- wifi
but no copper connectivity -- I decided to perform this 3-step
experiment:
1. State immediately following a restart with copper Ethernet
connected:
$ rfkill list
0: tpacpi_bluetooth_sw: Bluetooth
Soft blocked: no
Hard blocked: no
1: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
2: phy0: Wireless LAN
Soft blocked: no
Hard blocked: yes
2. Disconnect copper Ethernet and allow NetworkManager to try setting
up wifi:
$ rfkill list
0: tpacpi_bluetooth_sw: Bluetooth
Soft blocked: no
Hard blocked: no
1: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
2: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
3. Reconnect copper Ethernet and allow NetworkManager to finish:
$ rfkill list
0: tpacpi_bluetooth_sw: Bluetooth
Soft blocked: no
Hard blocked: no
1: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
2: phy0: Wireless LAN
Soft blocked: no
Hard blocked: yes
This test appears to show that NetworkManager is actually controlling
the Wireless LAN hard blocking.
My working theory is to the problem is in NetworkManager.
--Doc Savage
Fairview Heights, IL