Using hostapd behind the AP (on the wired side)

[Bryan J. Smith]

Okay, thanx.  I guess it's time for me to just play with the
darn thing for now, and follow-up with first-hand questions.
Thanx again for your patience.

--- Bryan Kadzban <bryan at kadzban.is-a-geek.net> wrote:

> Bryan J. Smith wrote:
> > Understand that.  Let me restate/refocus my question, my
> primary 
> > interest is actually in authenticating a node, not
> encryption.  For 
> > encryption, I'll rely on the capabilities of the AP.
> 
> Ah, OK.  That does help, I think.
> 
> > Correct.  This would be something that is _forced_ --
> i.e.,
> > explicitly configured -- on the client, not
> auto-negotiated.  Which
> > brings me really to what I'm looking for ...
> > 
> > Is it even possible?
> 
> I'm not sure.  It'd depend on the specific supplicant
> software in use; I
> believe wpa_supplicant, for instance, checks for a WPA/RSN
> IE in the
> association info passed by the NDIS driver (and the
> association info
> that's available from the wireless extensions on Linux),
> and does ...
> something, if it's not found.  (I think it just doesn't
> associate with
> that BSSID, but I'm not sure.)
> 
> > I just didn't want to get too deep into using hostapd if
> it wasn't
> > possible for an STA to reach a node on the wired portion
> of a
> > bridging AP at all.
> 
> It should be able to pass traffic to the wired (since
> that's the whole
> *job* of an AP ;-) ), I'm just not sure whether you can
> force EAP to
> happen with all supplicants.
> 
> >> (You might also have to modify the association response,
> I'm not
> >> sure on that.)
> > 
> > That's fine.  We have our own peer-to-peer replication,
> because we
> > work on mesh (i.e., the backend might not be, and
> typically isn't,
> > available for authenticating anyway).  So adding
> additional chat is
> > not an issue.
> 
> Well, the association response frame is part of the 802.11
> standard,
> just like the probe response -- it's not really anything
> that you can
> add, it's already happened by the time the STA would start
> talking to
> your device.
> 
> The probe response is what tells the STA that it needs to
> have a
> supplicant do EAP (it also tells the STA what encryption
> types and
> speeds are supported, etc., etc.), and if you can't modify
> the contents
> of this frame in the APs you plan on using, then some
> supplicants may
> not try EAP, even if they were configured to do it.  The
> association
> response frame may also have these pieces of information in
> it, I'm not
> sure.  If it does, then you'd have to modify it too.
> 
> > Can you force a client to sent it regardless, if the
> client is so 
> > explicitly configured?
> 
> That's going to depend on the supplicant software, and
> whether it
> "filters" BSSIDs based on the probe-response /
> association-response
> frame, compared to its configuration.  If the supplicant in
> use does do
> this filtering, then I don't think it'll work.
> 
> > Especially for proprietary APs for more standalone mesh
> situations. 
> > Something where the AP might already be RADIUS enabled
> and have it's
> > own chat with the clients.
> 
> If that's happening, then yes, what you want is pretty easy
> -- if the AP
> already does 802.1x (with any of WEP, WPA, or RSN), then
> the clients
> will try to RADIUS-authenticate one way or the other.  All
> you need in
> that case is (probably) some RADIUS server.
> 
> But if the AP doesn't do 802.1x because it's too old (or
> proprietary)
> for that, then it'll depend on the supplicant software that
> the client
> is using, as above.
> > _______________________________________________
> HostAP mailing list
> HostAP at shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap
> 


-- 
Bryan J. Smith                | Sent from Yahoo Mail
mailto:b.j.smith at ieee.org     |  (please excuse any
http://thebs413.blogspot.com/ |   missing headers)