Using hostapd behind the AP (on the wired side)

[Bryan Kadzban]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20050927/57ac3426/attachment.pgp