PATCH: wired eapol receive/send
gbur at informatik.uni-rostock.de
Thu Sep 2 02:55:05 EDT 2004
> > First patch to bring wired authentication with hostapd alive. This
> > patch enables hostapd to send and recieve eapol frames via ethernet.
> > Furthermore sta detection is implemented via dhcp for station which
> > didn't send eapol-start (like winxp supplicant).
> Thanks! I haven't yet merged this in, but couple of quick
> comments/questions first..
> Is there any particular reason for parsing DHCP packets? One option
> would be to open packet socket on the same interface with Linux Socket
> filter to capture the packets and then take the layer 2 address from
> them. Then again, this may not end up being much simpler. Eventually, I
> would assume this could be replaced with something like iptables
> firewall queueing packets from unknown MAC addresses for user space
> processing and all devices would be noticed whenever they send the first
> packet, no matter whether it is DHCP or something else, i.e., static IP
> and non-IPv4 hosts would also be processed.
Sounds good. I will check it. But iptables has no real api. In
documentation iptables_restore is recommended as api. I've written a
function that starts iptables_restore, puts the iptables rules to its
stdin and parses stdout to check if it was successfull. I'm realy
unhappy about this. But at the moment i see no other way.
I would like to use iptables for port authorization. Adding some rules
for authorized stations that patckets from this station where acceptet.
But iptables is layer 3 in ISO/OSI. Only ip address is known. Ok you
can match to incomming mac address. But there is no way to controll
packets sent to the station without knowlege of the ip address of this
Another way is that only one station can connect to a port (device).
Together with vlan-devices and a vlan enabled switch it would be a
Is accounting using iptables ok? I will not count all packets in user
space (to slow) and i will not hack into device drivers.
> > In ieee802_11.c auth_get_sta() is implemented. I think this function
> > should move to hostapd.c . There are no 802.11 thinks in this function.
> > At the moment i declared this function to extern.
> I would agree on moving the function, although I would probably move it
> to sta_info.c, not hostapd.c. In addition, the function should be
> renamed to something like ap_sta_add().
Should i do it or you?
More information about the HostAP