Need help with off-standard 802.1x authentication on Linux
fracting at gmail.com
Mon Sep 26 16:08:44 EDT 2011
Thanks for the quick reply, and sorry for my delay :<
I've forwarded this post to several mailing list which focusing on
off-standard 802.1x protocal such as Ruijie and H3C iNode, but few
response until now. I'll answer your question as I can, but I don't
know very much about 802.1x, hopes I won't make too much mistakes.
On Mon, Sep 19, 2011 at 12:17 AM, Jouni Malinen <j at w1.fi> wrote:
> It depends.. In general, I like to promote use of standard-based
> solutions and protocols that have open standard. That said, if there are
> are authentication mechanisms that are in common use, it sounds
> reasonable to consider adding support for them.
Appreciate for your support!
> I agree that it would be desirable for Linux distributions to work
> out-of-box on networks that are widely deployed.
Yep, I'm so glad that you agree with it ;-)
> Sending a feature request to this mailing list and reporting which
> protocols are being used is a good start.
Ok, I'll post some feature request to http://w1.fi/bugz/ and update
this mail with the bug url.
> I've never even heard of many of the examples you mentioned.
Yes, most of them are only using in Colleges in China. What's worse,
those company usually don't care Linux users.
> Unfortunately, there is still quite a bit
> of language barrier that can explain that and while some of the
> automated translation services are making it easier to get the needed
> information, it can still slow down efforts getting these implemented.
> It can certainly if people familiar with the custom authentication
> mechanisms (or at least familiar with the language used in their
> specification and/or implementations) can participate in the effort.
That is why I forward our conversation to other 802.1x lists. However,
most of pre-developer who ever worked on off-standard 802.1x open
source client have leave school for some years, they have no testing
environment any more.
I'm interesting in getting involve, please feel free to let me know
what can I help. At this time I can test with both Ruijie network
environment and H3C network environment. Also I can capture
authentication packages with wireshark.
> As far as legal issues are concerned, there can be potential problems in
> using proprietary solutions. It is difficult to give generic comments on
> this as this will mostly need to be handled on case by case basis.
> Ideally there would be a publicly available description of the used
> protocol, but if not, 3rd party reverse engineered implementations could
> be considered as documentation.
IIRC there is no publicly available documentation from those client
company. However, there is some notes from open source developers.
Since those notes are in Chinese, I wonder if they will helps more
then source code.
Here is an example: http://apt-blog.net/tag/8021x
Do you think it is necessary to translate them to English?
> I'm not completely sure what you ask here. In general, it will be
> difficult to work on custom protocols without having access to a test
> setup that can be used to verify protocol and implementation behavior,
> so many cases can be too time consuming to justify the effort.
For example, the latest version of H3C INode (V3.6-E6203) has never
been implemented by it's open source alternatives. However I agree
that so many cases can be too time consuming to justify the effort,
maybe it is not the right time to consider supporting H3C INode
>> H3C INode
>> Official Website(Chinese) :
>> Third party open source implement: git://github.com/liuqun/njit8021xclient
> This looks like some kind of design based in wired IEEE 802.1X
> authentication and the 802.1X part itself could even be standard
> compliant (didn't really review it in detail). There is some kind of
> custom EAP method (EAP type 20 which is unassigned). There seem to be
> even university-based differences in how exactly those messages are
> processed based on the comments. In addition, EAP notification may be
> used in some custom way.
> The client seems to include support for EAP-MD5, so that may be used, too.
Yes, a user from njit8021xclient mailing list reported that he has
successfully pass the authentication using wpa_supplicant, however,
he'll be auto disconnect by server after a while. Below is his
> I don't really like the concept of picking an unassigned EAP type and
> using it for some custom purpose taken into account that this can easily
> conflict with other uses should the specific EAP type actually get
> assigned in the future. Anyway, it sounds possible to add support for
> this in wpa_supplicant.
Sounds great if it is supported by wpa_supplicant ;-)
> Would you happen to know how widely this is deployed? The comments in
> njit8021xclient seemed to point to at least some university use.
I can confirm that H3C INode and Ruijie Network are very widely
deployed, fortunately I can access to both environment ( as I
mentioned above ) . For other clients, maybe the sub-forum of
a good place to see how widely it used:
There is also a summary here http://wiki.ubuntu.org.cn/802.1X
> I would
> assume this is a wired network using something from H3C (Huawei-3Com?).
Yes, it is.
> Any idea whether the technology is still being developed and supported
> (as part of HP now?)?
I think the technology is still being supported, but I'm not sure. In
fact H3C release a Linux INode last year, but even their own Linux
Client does not support their latest V3.6-E6203 ... No updates from
H3C since last year.
> Do you know whether there is any documentation of the custom EAP method
> or changes to EAP? H3C seemed to have some related documentation in
> English available at
Do you think this one is useful?
H3C Client V2.40-0143 encryption
It is wrote by a pre-developer of njit8021xclient, unfortunately it is
in Chinese... Hopes I can help.
>> Official Website: http://www.ruijienetworks.com/
>> Third party open source implement: http://code.google.com/p/mentohust/
> This seemed to include some functionality that would be outside the
> scope of wpa_supplicant. I'm not completely sure what exactly is in
> scope, but there were some references on 8021x.exe (but that was not
> really used for more than extracting something from the binary) and the
> group MAC address for Ruijie (01:d0:f8:00:00:03) was used similarly to
> the IEEE 802.1X EAPOL group address, so there is some connection, but it
> would take more time to figure out what exactly is being done here.
Does some packages captured by wireshark helps?
>> Official Website: http://www.doctorcom.com/en/index.php
>> Third party open source implement: http://sourceforge.net/projects/drcom-client/
> This seems to be out of scope for wpa_supplicant functionality, so it
> looks like the project could be integrated on its own to network
> management functionality in a distro.
Got it, thanks!
Thank you Jouni!
> Jouni Malinen PGP id EFC895FA
> HostAP mailing list
> HostAP at lists.shmoo.com
Sent from Ubuntu
More information about the HostAP