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 -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/users@xxxxxxxxxxxxxxxxxxxxxxx
