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

Pedro Ramalhais ramalhais at serrado.net
Thu Jan 12 14:04:22 EST 2006

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.
Pedro Ramalhais <ramalhais at serrado.net>

More information about the HostAP mailing list