NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: wpa_supplicant and dhcp

On Jan 24, 2010, at 4:50 AM, Sad Clouds wrote:

> On Saturday 23 January 2010 18:46:59 Steven Bellovin wrote:
>> First -- look at /etc/rc.d/wpa_supplicant.  Does yours have the same lines
>> as mine?  (I do see what appears to be a bug: wpa_supplicant says it has
>> to occurs before dhclient; I think it should also say that it has to occur
>> before dhcpcd.  If you're using dhcpcd as your dhcp client, that might be
>> the problem.)
>> Second: to see what order things are run in at boot time, try the
>> following:
>>      cd /etc/rc.d
>>      rcorder -s start *
>> probably redirected to a file or piped to 'more' or some such.
>> Third: if you do use dhclient, do you have any interface {...} clauses in a
>> dhclient.conf file?  In at least some cases, the presence of such clauses
>> seems to cause dhclient (via its shell script) to issue ifconfigs and
>> hence ioctls that reset the device.  If it's not locking in well to the RF
>> signal -- and I've had a *lot* of trouble with that -- the reset is
>> deadly, because it makes the scan start over.  (I have a wpi0 interface;
>> it usually works at home, but rarely works well elsewhere.)
>>              --Steve Bellovin,
> In my /etc/rc.d/wpa_supplicant I have the following:
> # PROVIDE: wpa_supplicant
> # REQUIRE: network mountcritlocal
> # BEFORE:  NETWORKING dhclient
> And I don't have any /etc/dhclient.conf files.
> But I think I know what the problem might be. I changed the following lines 
> in 
> /etc/rc.d/dhlient:
> ...
> load_rc_config $name
> sleep 10
> run_rc_command "$1"
> So when rc scrips leeps for 10 seconds before starting dhclient, everything 
> works as it should.
> I start wpa_supplicant from rc.conf with the following:
> wpa_supplicant=yes
> wpa_supplicant_flags="-B -i iwn0 -c /etc/wpa_supplicant.conf"
> I think what happens, wpa_supplicant starts in the background as a daemon and 
> tries to initialise network interface and almost immediately dhclient starts 
> on the same interface. This causes problems.

It shouldn't cause problems, but I have no trouble believing that it does.

> Once solution could be to sleep for a few seconds at the end of 
> wpa_supplicant 
> script to let things "settle" a bit.

So here's a clean way to do that.  I have the following in 
/etc/rc.conf.d/ntpdate on my system, to let named initialize before ntpdate 
tries to resolve things:


        echo ntpdate pausing...
        for i in 0 1 2 3 4 5 6 7 8 9
                sleep 1
                echo -n .

You should use start_postcmd and of course change ntpdate to wpa_supplicant.  
This way, you haven't changed a file that a new version may wish to update.

That said, I don't think this is the whole story.  Lots of people, including 
me, have no trouble without such a delay.  Manually starting wpa_supplicant and 
waiting until it has associated with an access point before starting dhclient 
doesn't always work, either.  There's just something fundamentally wrong in the 
depths of the driver and/or the 802.11 support, possibly exacerbated by how 
dhclient interacts.  
> PS.
> I think in my first attempts I tried dhcpd instead of dhclient. I think I 
> noticed dhcpd was starting in the wrong order, i.e. it was started before 
> wpa_supplicant. So this should be taken care of too.

                --Steve Bellovin,

Home | Main Index | Thread Index | Old Index