rsta2
DHCP starting before WLAN is connected
The DHCP process starts before the WLAN interface has connected. This means the DHCP request is lost and there's an increasing timeout between reach retry.
From lib/net/dhcpclient.cpp: const unsigned CDHCPClient::s_TimeoutHZ[MAX_TRIES] = {4HZ, 8HZ, 16HZ, 32HZ};
Log of this occurring:
00:00:00.40 logger: Circle 49 started on Raspberry Pi Zero 2 W 512MB
00:00:00.40 logger: Revision code is 902120, compiler has been GCC 13.2.1
00:00:02.59 kernel: EMMC init complete
00:00:02.59 kernel: Filesystem SD: mounted
00:00:02.72 wlan: ether4330: chip 43430 rev 1 type 1
00:00:03.17 wlan: ether4330: firmware ready
00:00:03.17 wlan: ether4330: addr D8:3A:DD:6D:03:F4
00:00:03.20 kernel: WLAN init complete
00:00:03.20 kernel: Net init complete
00:00:03.20 kernel: WPA Supplicant init complete
00:00:03.20 kernel: WPA waiting for connection
00:00:03.34 wpa: Setting country code to 'NZ'
00:00:06.74 wpa: Trying to associate with 8a:2a:a8:51:2e:4c (SSID='PRIVATE' freq=2412 MHz)
00:00:07.34 dhcp: No response from server. Retrying.
00:00:07.37 wpa: Associated with 8a:2a:a8:51:2e:4c
00:00:08.21 wpa: WPA: Key negotiation completed with 8a:2a:a8:51:2e:4c [PTK=CCMP GTK=CCMP]
00:00:08.21 wpa: CTRL-EVENT-CONNECTED - Connection to 8a:2a:a8:51:2e:4c completed (auth) [id=0 id_str=]
00:00:08.29 kernel: WPA connected
00:00:15.34 dhcp: No response from server. Retrying.
00:00:15.38 dhcp: IP address is 192.168.1.26
In my case this is adding about 7 seconds to the connect time.
A work around is to suspend new tasks after the WPA supplicant has been initilized. e.g.
if (!m_EMMC.Initialize()) {
klog(LogError, "EMMC init failed");
return false;
} else
klog(LogNotice, "EMMC init complete");
if (f_mount (&m_FileSystem, DRIVE, 1) != FR_OK) {
klog(LogError, "Cannot mount drive: %s", DRIVE);
return false;
} else
klog(LogNotice, "Filesystem %s mounted", DRIVE);
if (!m_WLAN.Initialize()) {
klog(LogError, "WLAN init failed");
return false;
} else
klog(LogNotice, "WLAN init complete");
if (!m_Net.Initialize(false)) {
klog(LogError, "Net init failed");
return false;
} else
klog(LogNotice, "Net init complete");
if (!m_WPASupplicant.Initialize()) {
klog(LogError, "WPA Supplicant init failed");
return false;
} else
klog(LogNotice, "WPA Supplicant init complete");
// prevent the dhcp process from running
m_Scheduler.SuspendNewTasks();
klog(LogNotice, "WPA waiting for connection");
while(!m_WPASupplicant.IsConnected()) {
m_Scheduler.MsSleep(100);
}
klog(LogNotice, "WPA connected");
// allow the dhcp process to run
m_Scheduler.ResumeNewTasks();
The result is:
00:00:00.40 logger: Circle 49 started on Raspberry Pi Zero 2 W 512MB
00:00:00.40 logger: Revision code is 902120, compiler has been GCC 13.2.1
00:00:02.59 kernel: EMMC init complete
00:00:02.59 kernel: Filesystem SD: mounted
00:00:02.72 wlan: ether4330: chip 43430 rev 1 type 1
00:00:03.17 wlan: ether4330: firmware ready
00:00:03.17 wlan: ether4330: addr D8:3A:DD:6D:03:F4
00:00:03.20 kernel: WLAN init complete
00:00:03.20 kernel: Net init complete
00:00:03.20 kernel: WPA Supplicant init complete
00:00:03.20 kernel: WPA waiting for connection
00:00:03.34 wpa: Setting country code to 'NZ'
00:00:06.74 wpa: Trying to associate with 8a:2a:a8:51:2e:4c (SSID='PRIVATE' freq=2412 MHz)
00:00:07.34 wpa: Associated with 8a:2a:a8:51:2e:4c
00:00:08.19 wpa: WPA: Key negotiation completed with 8a:2a:a8:51:2e:4c [PTK=CCMP GTK=CCMP]
00:00:08.19 wpa: CTRL-EVENT-CONNECTED - Connection to 8a:2a:a8:51:2e:4c completed (auth) [id=0 id_str=]
00:00:08.27 kernel: WPA connected
00:00:08.30 dhcp: IP address is 192.168.1.26
Yes, this is a known problem. I have to see, if I can implement some signaling from WPA Supplicant to the network subsystem, to start the DHCP process, when the WPA(2) link comes up. I saved myself the trouble when the WLAN thing was implemented.
Thanks for the quick reply.
There isn't any hurry for this, the work-around does the trick nicely. I mainly thought it useful to document the work-around in case others discover the same issue.
The issue should be fixed on the develop branch. This required a modification on the addon/wlan/hostap submodule too.