Re: wpa_supplicant and dhcp

[Steven Bellovin <smb%cs.columbia.edu@localhost>]

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, http://www.cs.columbia.edu/~smb
>> 
> 
> 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:

start_precmd="ntpdate_precmd"

ntpdate_precmd()
{
        echo ntpdate pausing...
        for i in 0 1 2 3 4 5 6 7 8 9
        do
                sleep 1
                echo -n .
        done
        echo
}

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, http://www.cs.columbia.edu/~smb