[PATCH] wpa_supplicant: Work around odd driver-reported ssid lengths

Dan Williams dcbw at redhat.com
Thu Jan 12 14:29:13 EST 2006


On Thu, 2006-01-12 at 19:04 +0000, Pedro Ramalhais wrote:
> On Thu, 2006-01-12 at 13:47 -0500, Dan Williams wrote:
> > On Thu, 2006-01-12 at 18:54 +0100, Henrik Brix Andersen wrote:
> > > On Thu, Jan 12, 2006 at 11:30:37AM -0500, Dan Williams wrote:
> > > > At least the atmel and airo drivers do odd, technically incorrect,
> > > > things in their SIOCGIWESSID:
> > > 
> > > As you've pointed out yourself, the drivers do "technically incorrect
> > > things" whereas wpa_supplicant does the right thing.
> > > 
> > > Please fix the offending drivers instead of breaking wpa_supplicant.
> > 
> > Right, so I've got a patch (attached) that does this that I'll be
> > submitting to netdev at vger.  But two questions:
> > 
> > 1) What if upstream rejects the patch?  The patch may break existing
> > user-space tools.  Turns out that airo, atmel, prism54, ray_cs, and
> > wavelan_cs all have this problem.  If upstream rejects, what will
> > wpa_supplicant do?  Continue to fail with these drivers?
> > 
> > 2) If the patch is accepted, will it be noted somewhere that
> > wpa_supplicant is unreliable with the previously stated cards and
> > kernels older than (and including) 2.6.15?
> > 
> > "fix the offending drivers instead of breaking wpa_supplicant" is an
> > entirely inconsistent line, since there are already quite a few
> > compromises in wpa_supplicant.  For example, working with non-WEXT
> > drivers.  I'm just trying to encourage keeping an open mind when it
> > comes to workarounds here, since kernel drivers, wpa_supplicant, and
> > wireless in general are not perfect but must still work with each other
> > as well as possible.
> > 
> > Dan
> 
> Try to see how wireless tools handles it. If it works OK with your
> patch, i guess it will be accepted.

Wireless tools appears to zero out the structure it uses for WEXT
ioctl() calls and then simply print the returned data.  It does,
however, use us a buffer of IW_MAX_ESSID_SIZE + 1, so it appears to be
OK.  It's not extremely clear that there aren't corner cases that would
catch wireless-tools though.

In any case, I think the patch is likely to get accepted.

Dan





More information about the HostAP mailing list