wired authentication (kernel module)
Tue Sep 21 23:47:08 PDT 2004
> > Ok - here is the directory. Makefile is very easy at the moment. My
> > make book will come in a couple of days. There is also a little test
> > programm. The patch for hostap i will send in next mail.
> Should the code be renamed to something else, e.g., pae? If I understood
> correctly, it implements one part of IEEE 802.1X, namely the port access
> Any plans on making Linux 2.6.x version of this? Linux 2.4.x is getting
> somewhat old for new development..
> Kernel Makefile should be used instead of own Makefile when building
> kernel modules (make -C (linux dir) SUBDIRS=.... modules).
I will try it on linux 2.6 and include it into kernel makefile.
> Is the new netdevice really needed? Is that just for the ioctl handler?
> New ioctls are not exactly in favor of Linux networking maintainers, so
> something else (e.g., netlink) could be better option to make this more
> I don't know whether I would like to see something like wlan0ap being
> added for wired network (todo.lst). Filtering should work fine with one
> interface and EAPOL packets could be allowed through always. They are
> not supposed to be bridged or consumed by anything else than the
> Authenticator code.
Well, I have no experience with netlink sockets. There is nearly no
dokumentation for netlink communication. Netlink sounds great for
kernel userspace communication but at the moment its impossible for me
to implement without dokumentation. The netdivice is only needed for
the ioctl (I thought would need it for some packet interaction). Im
searching for another device type (eg. misc).
> Can more than one Ethernet device be used at the same time? In most
> cases, wired IEEE 802.1X is used in switch setups with large number of
> ports (Ethernet interfaces in this case)..
Yes. Half of it is implemented quite now :). I plan to add vlan
support to seperate ports: A switch with vlan support can tag each
physical port with a vlan id and the filter only accepts it if the id
matches. But there are more basic things to do at the moment.
> Multicast should not be accepted in input direction from unauthorized
> stations unless ethertype == EAPOL.
More information about the Hostap