Re: no IPv4 address for 3g modem on 6.11.5
JED
Thu May 24 13:05:50 2018
I figured out wpa_supplicant by listing the processes. I used the
dhcpcd.conf to turn off the wpa_supplicant invocation. That worked and
that got me a bit more but since dhcpcd was waiting for carrier even
after I had a connection I was stuck and quit using it all together.
On 5/24/2018 6:05 AM, Serge Schneider wrote:
On Thu, May 24, 2018 at 10:50 AM, Roy Marples <roy@xxxxxxxxxxxx
<mailto:roy@xxxxxxxxxxxx>> wrote:
On 24/05/2018 10:37, Serge Schneider wrote:
Yes , we have the hook enabled. Is that not the recommended way
to start wpa_supplicant when using dhcpcd?
It's just not the default way.
dhcpcd should NOT make the assumption that just because the
interface is wireless AND wpa_supplicant exists AND
wpa_supplicant.conf is configured that IT is responsible for
starting and stopping it.
A good recent example is the recent introduction of IWD which
competes with wpa_supplicant. If both are installed and configured,
we don't want dhcpcd starting wpa_supplicant when it knows nothing
about IWD - the user needs to make the conscious choice here.
IIRC, the original reason for adding this patch was that some
wifi devices don't match "if_getssid(ifp) != -1", so "
*ifp->name == 'w'" was added as a quick workaround.
If the operation of getting the SSID returns -1 that means that
there was an error. Even if not associated and not instructed to
associate, the call will succeed. Every wireless card must support
getting and setting SSID as a minium and only wireless cards do this.
Thus it follows that any fix should be at the kernel level and not
in dhcpcd. Unless of course it's a dhcpcd bug, but I don't recall
any reported issues here in years.
On BSD at least, most wireless devices don't start with the letter w
and on Linux you can rename them anyway.
Thanks, Roy. That all makes sense. And yes it's a driver floating around
on github that has never been upstreamed, possibly due to issues like this.
Roy
Archive administrator: postmaster@marples.name