Recently when I checked the system journals, I found a lot of spams generated by my WIFI connection like these

Short DHCP Lease Time

The first one is weird. How is DHCP lease time only 120 seconds?! This way, the DHCP client will try to renew the lease about every minute. Every time the DHCP client tries to renew the lease, it will increase my laptop power consumption and spam useless messages into the system journal, making it harder to find potentially important journal logs, increase disk usage/load and further reduce the laptop battery life. The default DHCP lease time for dhclient is 2 hours, other common values are 6 hours, 24 hours, 1 week, etc. Anyway, much longer than 120 seconds. I guess the CityU IT staff uses a very short lease time to free disconnected IP addresses as soon as possible, since there are so may devices trying to connect and the IP address pool is limited.

I tried to request for a longer DHCP lease time by explicitly setting it in dhclient configuration file.

1
2

$ cat /etc/dhclient.conf
send dhcp-lease-time 7200;

This doesn’t change anything. Then I decided to override this setting, since I am sitting in the lab using my laptop basically like a desktop all day.

1
2

$ cat /etc/dhclient.conf
supersede dhcp-lease-time 7200;

This kind of works, until the first day of the new semester. Every now and then, I lost internet connection and have to reconnect the WIFI. I thought there are so many devices trying to connect to WIFI, the DHCP server can no longer reserve the IP address for me if I only renew it every two hours. So I reverted the changes to dhclient configuration. But when I checked the system journal, I found that the IP address assigned to my laptop were the same before and after the configuration change.

1

$ journalctl -b -2 | grep dhcp4 | grep address

So the DHCP server did not assign the IP address to another client. I don’t know what happened. My wild guess is that it is using DHCP lease renewal as some kind of heartbeat detection, if you don’t respond (try to renew the lease) it will drop your connection when the traffic is crowded. I don’t have a good solution to this since this is a server side decision, I either accept or refuse to use the WIFI.

Proactive Key Caching

The second one is also weird. A quick search shows that PMKSA-CACHE enables fast switch between access points. But why NetworkManager rescans about every 30 seconds and generates so many useless journal logs? The fast switch is useful for mobile phones, since you can walk pass a few access points while video chatting with your friends. It’s hard to imagine anyone would move quickly with his/her laptop while working with the internet.

I think the easy solution is to disable PMKSA-CACHE. But NetworkManager actually always enables proactive key caching for WPA Enterprise connections. So I have to patch the source code to disable it. That’s too much work to do. I will just leave it as default (for now).

Update (2019-09-04)

I have found a workaround to disable the enforced proactive key caching function, by using a specific BSSID for your WIFI connection.

We can list all the BSSIDs around us for the WIFI SSID (for my case CityU WLAN (WPA)) by using

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

$ nmcli -f SSID,BSSID,SIGNAL,ACTIVE,FREQ dev wifi list --rescan yes | grep "CityU WLAN (WPA)"
CityU WLAN (WPA)    xx:xx:xx:xx:xx:40  100     no      2412 MHz
CityU WLAN (WPA)    xx:xx:xx:xx:xx:00  94      no      2437 MHz
CityU WLAN (WPA)    xx:xx:xx:xx:xx:10  75      yes     5785 MHz
CityU WLAN (WPA)    xx:xx:xx:xx:xx:A0  70      no      2412 MHz
CityU WLAN (WPA)    xx:xx:xx:xx:xx:40  64      no      2437 MHz
CityU WLAN (WPA)    xx:xx:xx:xx:xx:A0  57      no      2462 MHz
CityU WLAN (WPA)    xx:xx:xx:xx:xx:A0  55      no      2412 MHz
CityU WLAN (WPA)    xx:xx:xx:xx:xx:E1  54      no      2412 MHz
CityU WLAN (WPA)    xx:xx:xx:xx:xx:F1  49      no      5240 MHz

Choose a BSSID (the MAC address of the access point) that is good for you (strong signal strength, 2.4G or 5G).

Then specify the BSSID for your WIFI profile (if you use NetworkManager and nm-applet).

The downside of this workaround is that your WIFI will NOT connect to any other access points for the same SSID. So if you moved your laptop to a new place (thus a different access point), remember to specify a new BSSID or just remove the specified BSSID.

Update (2019-09-16)

The excessive log messages from NetworkManager DHCP component and wpa_supplicant are really annoying. The system journal is filled with useless messages and the real important log messages are discarded, since I set the 50M journal file size limit.

To suppress NetworkManager DHCP log messages lower than warning level, we can set

1

$ sudo nmcli general logging level WARN domain DHCP

To make this consistent after boot, we can add a configuration file for NetworkManager by using

1

$ echo -e '[logging]\nlevel=WARN\ndomains=DHCP' | sudo tee /etc/NetworkManager/conf.d/dhcp-logging.conf

To suppress wpa_supplicant log messages lower than warning level we can override the systemd service unit with

1

$ echo -e '[Service]\nLogLevelMax=4' | sudo SYSTEMD_EDITOR=tee systemctl edit wpa_supplicant.service

Finally I get a more meaningful system journal (filled with errors 😂).

References