NetBSD Problem Report #33823

From www@NetBSD.org  Sun Jun 25 20:48:35 2006
Return-Path: <www@NetBSD.org>
Received: by narn.NetBSD.org (Postfix, from userid 31301)
	id 8F98863B848; Sun, 25 Jun 2006 20:48:35 +0000 (UTC)
Message-Id: <20060625204835.8F98863B848@narn.NetBSD.org>
Date: Sun, 25 Jun 2006 20:48:35 +0000 (UTC)
From: nbgnats@anastigmatix.net
Reply-To: nbgnats@anastigmatix.net
To: gnats-bugs@NetBSD.org
Subject: wpa_supplicant -w broken
X-Send-Pr-Version: www-1.0

>Number:         33823
>Category:       bin
>Synopsis:       wpa_supplicant -w broken
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Jun 25 20:50:00 +0000 2006
>Last-Modified:  Mon Jan 25 10:30:00 +0000 2016
>Originator:     Chapman Flack
>Release:        3.99.21
>Organization:
>Environment:
>Description:
The -w option to wpa_supplicant directs it to lie in wait until the named
interface is attached.

On NetBSD it exits with "Failed to initialize driver interface".
If -d is added, the additional output includes "wpa_driver_bsd_init:
interface ath0 does not exist" and "Failed to add interface ath0."

In other words, it is not even trying to do -w right.

The problem is in src/usr.sbin/wpa/wpa_supplicant/driver_netbsd.c
which contains this comment:

/*
 * NB: We require the interface name be mappable to an index.
 *     This implies we do not support having wpa_supplicant
 *     wait for an interface to appear. This seems ok; that
 *     doesn't belong here; it's really the job of devd.
 *     XXXSCW: devd is FreeBSD-specific.
 */
>How-To-Repeat:
Use wpa_supplicant -w for an interface that is not yet attached.
Or read the code.
>Fix:
This is at the very least an embarrassing doc bug. Of the at least
two people who knew that driver_netbsd.c was going to break
wpa_supplicant -- the one who wrote that not implementing the
documented behavior "seems ok", and the one who noticed that
the suggested alternative was a FreeBSDism -- nobody bothered to say
so in the manual. In fact, the one sentence in the man page that
comes closest to saying so has been /commented out/!

But how hard would it be to implement the documented behavior?
Save the iface name in the wpa_driver_bsd_data struct and mark
the rest uninitialized, with a real_init() callback for first
use? If the cost of checking for first-call in every method would
be a concern, why not populate the struct at first with init-checking
methods, and have real_init() replace them?

I don't know the intricacies of the ieee80211 code to know how hard
that would be, but bin/31513 and bin/32537 are probably consequences
of the same issue: they deal with breakage when an already initialized
interface goes away.

Fundamentally, it looks as if the author of wpa_supplicant intended
a drv structure to be something that can be initialized and afterward
represent either an interface that is present and active or one that
isn't. We've plugged in a bsd driver implementation that doesn't follow
that design, and the reported bugs are the consequences of that,
either when a device isn't present at init time, or when it goes away
later. If our drv implementation had a not-here state, it should just
revert to that state on device disappearance; wpa_supplicant itself
seems designed for that possibility.

>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/33823: wpa_supplicant -w broken
Date: Sun, 25 Jun 2006 23:11:56 +0200

 On Sun, Jun 25, 2006 at 08:50:00PM +0000, nbgnats@anastigmatix.net wrote:
 > documented behavior "seems ok", and the one who noticed that
 > the suggested alternative was a FreeBSDism

 Not commenting on the other issues brought up here - the FreeBSD workaround
 works pretty easily with NetBSD too, just s/devd/ifwatchd/.

 Martin

From: Chapman Flack <chap@anastigmatix.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/33823: wpa_supplicant -w broken
Date: Sun, 25 Jun 2006 18:29:02 -0400

 Martin Husemann wrote:
 >  Not commenting on the other issues brought up here - the FreeBSD workaround
 >  works pretty easily with NetBSD too, just s/devd/ifwatchd/.

 It should be remembered though that the possibility of running one
 supplicant process to manage more than one interface is also part of
 wpa_supplicant's documented design. So is the possibility of having
 wpa_cli or wpa_gui persistently connected to the daemon to query status,
 list available interfaces and scan results, and tell it what to do. That
 starts to get messy once you get into killing and restarting supplicants
 from some other daemon's event scripts.

 -Chap

From: Roy Marples <roy@marples.name>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/33823
Date: Wed, 27 May 2009 07:50:28 +0100

 I've create 5 patches to address this problem and sent them upstream.
 Here's the first patch email:
 http://lists.shmoo.com/pipermail/hostap/2009-May/019815.html
 The other 4 follow that one.

 Then you can do this

 wpa_supplicant -c /etc/wpa_supplicant.conf -m "*"

 And wpa_supplicant will attempt to start wireless via driver_bsd on each
 interface.

 We could then supply a default /etc/wpa_supplicant.conf and modify
 defaults/rc.conf accordingly so that the only user configuration is
 setting wpa_supplicant=YES in rc.conf to connect to unsecured APs by
 default.

 When/if they are merged upstream I'll probably merge a wpa_supplicant
 snapshot into -current to address this.

 Thanks

 Roy

From: Roy Marples <roy@marples.name>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/33823
Date: Mon, 25 Jan 2016 10:25:21 +0000

 So, we are now almost 7 years later!
 My how time flys.

 Since then, upstream rejected the initial patches.
 However, I have been pushing all NetBSD patches upstream, so far they
 are being accepted. Our man page now reflects reality with the installed
 program.

 I have a new patch (singular now) which adds similar functionality which
 I will again try to push upstream once the others are accepted.
 The patch can be found here:
 http://www.netbsd.org/~roy/wpa_supplicant-match-iface.patch

 Invoke it like so

 wpa_supplicant -B -M -c/etc/wpa_supplicant.conf

 You can match on a specific name like so

 wpa_supplicant -B -M -c/etc/wpa_supplicant.conf -i"iwn*"

 AND even give it a driver

 wpa_supplicant -B -M -c/etc/wpa_supplicant.conf -i"bge*" -Dwired

 OR do both

 wpa_supplicant -B -M -c/etc/wpa_supplicant.conf -i"bge*" -Dwired \
 	-M -c/etc/wpa_supplicant.conf -i"iwn*"

 Roy

Home	PR Database Search