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
_______________________________________________
users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[email protected]
