I don't know if it's too soon to plan a release date for 1.1.1, as 1.1.0 has some annoying known problems: - an error on x86_64 machines when reading dictionnaries. - compilation fails on FreeBSD because of rlm_otp. - rlm_eap_peap and rlm_eap_ttls have libtool problems on Debian. The following list is surely very incomplete, but I tried to put together the things we could do before the next release. - pull eap fixes from CVS head to address Debian's issues. I found many changes not in branch 1.1 but I've no idea whether they are safe or not: - moved TLS code from rlm_eap_tls to libeap. - removed record_* functions from global visibility. - remove the EAP submodule locking. - change autoconf tests for OpenSSL. - put the eap sessions into a tree, so that looking them up is very fast, and no longer O(n) in the number of sessions. - if the callback fails, do eap_fail() to get an EAP-Failure message and return reject. - use new hex2bin function to be more forgiving for NT-Passwords - make "use_tunneled_reply" work properly for PEAP - fix bug #314 about rlm_otp: the module could have more tests in configure.in so it is silently disabled instead of giving compilation errors. - net-snmp patches. (and move #includes from radius_snmp.h to smux.h) - maybe undelete the database schema for MSSQL server? We could put the file under src/modules/rlm_sql/drivers/rlm_sql_unixodbc for example. - maybe back-port the changes in the makefiles in CVS head? It would fix some warnings and make the autoconf/libtool upgrade easier in the future. -- Nicolas Baradakis
Nicolas Baradakis <nbk@sitadelle.com> wrote:
I don't know if it's too soon to plan a release date for 1.1.1, as 1.1.0 has some annoying known problems:
We can put out 1.1.1 as soon as we have fixes for 1.1.0.
- an error on x86_64 machines when reading dictionnaries. - compilation fails on FreeBSD because of rlm_otp. - rlm_eap_peap and rlm_eap_ttls have libtool problems on Debian.
Those 3 alone should result in a 1.1.0.
- pull eap fixes from CVS head to address Debian's issues. I found many changes not in branch 1.1 but I've no idea whether they are safe or not: - moved TLS code from rlm_eap_tls to libeap.
Yes.
- removed record_* functions from global visibility.
Not necessary.
- remove the EAP submodule locking.
Sure, but not necessary.
- change autoconf tests for OpenSSL. - put the eap sessions into a tree, so that looking them up is very fast, and no longer O(n) in the number of sessions.
Not really necessary, but sure. There should only be 10's of ongoing EAP sessions at a time, so it's not critical.
- if the callback fails, do eap_fail() to get an EAP-Failure message and return reject. - use new hex2bin function to be more forgiving for NT-Passwords - make "use_tunneled_reply" work properly for PEAP
Yes.
- fix bug #314 about rlm_otp: the module could have more tests in configure.in so it is silently disabled instead of giving compilation errors.
Yes.
- net-snmp patches. (and move #includes from radius_snmp.h to smux.h)
Yes.
- maybe undelete the database schema for MSSQL server? We could put the file under src/modules/rlm_sql/drivers/rlm_sql_unixodbc for example.
Put the schemas under /doc, or create a /doc/examples and put them there.
- maybe back-port the changes in the makefiles in CVS head? It would fix some warnings and make the autoconf/libtool upgrade easier in the future.
Sure. Alan DeKok.
On Mon, Jan 30, 2006 at 12:00:25PM -0500, Alan DeKok wrote:
Nicolas Baradakis <nbk@sitadelle.com> wrote:
I don't know if it's too soon to plan a release date for 1.1.1, as 1.1.0 has some annoying known problems:
We can put out 1.1.1 as soon as we have fixes for 1.1.0.
- an error on x86_64 machines when reading dictionnaries. - compilation fails on FreeBSD because of rlm_otp. - rlm_eap_peap and rlm_eap_ttls have libtool problems on Debian.
Those 3 alone should result in a 1.1.0.
If we get 2 quickly and the third isn't already visible, I'd vote vote for a quick 1.1.1 release. Especially the AMD64 problem, since the other two are module-related rather than core-releated.
- pull eap fixes from CVS head to address Debian's issues. I found many changes not in branch 1.1 but I've no idea whether they are safe or not: - moved TLS code from rlm_eap_tls to libeap.
Yes.
And a reminder, that alone won't fix the Debian concern. Someone has to port libeap to gnuTLS... I think I once volunteered myself for that, so I should get cracking on it. Then once the libeap-centralised-SSL changes get into the 1.1 branch, I'll be ready. ^_^
- maybe undelete the database schema for MSSQL server? We could put the file under src/modules/rlm_sql/drivers/rlm_sql_unixodbc for example.
Put the schemas under /doc, or create a /doc/examples and put them there.
For reference, the Debian build already hunts down the schemas and puts them in /usr/share/doc/freeradius/examples, as well as the various scripts and the rlm_perl example script. -- ----------------------------------------------------------- Paul "TBBle" Hampson, Bsc, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@Pobox.Com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ -----------------------------------------------------------
Paul TBBle Hampson wrote:
On Mon, Jan 30, 2006 at 12:00:25PM -0500, Alan DeKok wrote:
Nicolas Baradakis <nbk@sitadelle.com> wrote:
- pull eap fixes from CVS head to address Debian's issues. I found many changes not in branch 1.1 but I've no idea whether they are safe or not: - moved TLS code from rlm_eap_tls to libeap.
Yes.
And a reminder, that alone won't fix the Debian concern.
Since you mentioned it, I tried today to build the CVS head without OpenSSL headers, and some files in libeap have failed to compile. I'll have to look into this before we can back-port the rlm_eap changes.
Someone has to port libeap to gnuTLS... I think I once volunteered myself for that, so I should get cracking on it. Then once the libeap-centralised-SSL changes get into the 1.1 branch, I'll be ready. ^_^
That's great, go for it! -- Nicolas Baradakis
Alan DeKok wrote:
Nicolas Baradakis <nbk@sitadelle.com> wrote:
- pull eap fixes from CVS head to address Debian's issues. I found many changes not in branch 1.1 but I've no idea whether they are safe or not: - moved TLS code from rlm_eap_tls to libeap.
Yes.
- removed record_* functions from global visibility.
Not necessary.
- remove the EAP submodule locking.
Sure, but not necessary.
- change autoconf tests for OpenSSL. - put the eap sessions into a tree, so that looking them up is very fast, and no longer O(n) in the number of sessions.
Not really necessary, but sure. There should only be 10's of ongoing EAP sessions at a time, so it's not critical.
- if the callback fails, do eap_fail() to get an EAP-Failure message and return reject. - use new hex2bin function to be more forgiving for NT-Passwords - make "use_tunneled_reply" work properly for PEAP
Yes.
Ok, I made a sweep on all files under src/modules/rlm_eap and pulled the changes into branch 1.1. I can now build all the problematic modules rlm_eap_{peap,tls,ttls} on my Debian box, and the server successfully link them at startup. (this had never worked before with 1.1.0 on Debian) It'd be great if someone else could also run a few tests on the new code in CVS, just to be sure that nothing is broken. -- Nicolas Baradakis
Nicolas Baradakis <nbk@sitadelle.com> wrote:
Ok, I made a sweep on all files under src/modules/rlm_eap and pulled the changes into branch 1.1. I can now build all the problematic modules rlm_eap_{peap,tls,ttls} on my Debian box, and the server successfully link them at startup. (this had never worked before with 1.1.0 on Debian)
Sounds good. I'll take a look. Alan DeKok.
The following list is surely very incomplete, but I tried to put together the things we could do before the next release.
- pull eap fixes from CVS head to address Debian's issues.
Done. As Paul noted, the build produces a non-redistributable binary package, but it's a lot better than not working at all :)
- fix bug #314 about rlm_otp.
Franck fixed it.
- net-snmp patches. (and move #includes from radius_snmp.h to smux.h)
Done.
- maybe undelete the database schema for MSSQL server?
All the backend schemas are now under doc/examples.
- maybe back-port the changes in the makefiles in CVS head? It would fix some warnings and make the autoconf/libtool upgrade easier in the future.
I'll work on it when I have time, but if version 1.1.1 is released without these changes, it isn't a problem. The up-to-date changelog is: http://www.freeradius.org/cgi-bin/cvsweb.cgi/radiusd/doc/ChangeLog?rev=1.57.... Last things to do: - change 1.1.0 -> 1.1.1 everywhere. - fix permissions for a few files. -- Nicolas Baradakis
Nicolas Baradakis <nbk@sitadelle.com> wrote:
- pull eap fixes from CVS head to address Debian's issues.
Done.
As Paul noted, the build produces a non-redistributable binary package, but it's a lot better than not working at all :)
I have no objection to updating the license to allow linking against OpenSSL. Also, the GPL *does* allow this, if OpenSSL is already installed on your system. As proof, it's possible to distribut Solaris binaries of GPL'd packages, even though Solaris libc isn't GPL'd.
- change 1.1.0 -> 1.1.1 everywhere.
I'll take a stab at that.
- fix permissions for a few files.
I'll poke Chris again. Alan DeKok.
Alan DeKok wrote:
Nicolas Baradakis <nbk@sitadelle.com> wrote:
As Paul noted, the build produces a non-redistributable binary package, but it's a lot better than not working at all :)
I have no objection to updating the license to allow linking against OpenSSL.
Also, the GPL *does* allow this, if OpenSSL is already installed on your system. As proof, it's possible to distribut Solaris binaries of GPL'd packages, even though Solaris libc isn't GPL'd.
Perhaps it's not a problem with the GPL, but with OpenSSL license itself. In such case it'd be no use to update the FreeRADIUS license. (unless we change it completely) Honestly I don't know why Debian doesn't distribute packages linked against OpenSSL. I'll have to look in the Debian policy manual to find out the reasons. I also have concerns about a license modification. If we stick to a plain GPL license we are in a very common situation, and it is clear when a company asks how it could contribute, and when a licence violation occurs. (we also can ask the FSF for assistance as we are GPL) If we create a "FreeRADIUS license", it'll make things more confusing. In short, I prefer a lot a debian patch for gnuTLS than a license modification. As gnuTLS has an OpenSSL compatibility layer, perhaps it's not hard to do. -- Nicolas Baradakis
Nicolas Baradakis <nbk@sitadelle.com> wrote:
Perhaps it's not a problem with the GPL, but with OpenSSL license itself. In such case it'd be no use to update the FreeRADIUS license. (unless we change it completely)
I think it's that the OpenSSL advertising clauses are annoying. I dunno...
I also have concerns about a license modification. If we stick to a plain GPL license we are in a very common situation, and it is clear when a company asks how it could contribute, and when a licence violation occurs. (we also can ask the FSF for assistance as we are GPL)
Uh, no. The FSF supports people who've assigned copyright to the FSF. They're not as enthusiastic about supporting other people.
In short, I prefer a lot a debian patch for gnuTLS than a license modification. As gnuTLS has an OpenSSL compatibility layer, perhaps it's not hard to do.
Sure. I have no objection to that. Alan DeKok.
On Fri, Feb 10, 2006 at 11:21:05AM +0100, Nicolas Baradakis wrote:
In short, I prefer a lot a debian patch for gnuTLS than a license modification. As gnuTLS has an OpenSSL compatibility layer, perhaps it's not hard to do.
The last time I looked at this compatibility layer, I did not find suitable functionality for implementing EAP methods due to the requirement of doing I/O with own routines (instead of using TCP sockets). If someone is planning on converting FreeRADIUS to use GnuTLS, it might be worthwhile to take a look at the TLS wrapper I designed for wpa_supplicant (EAP peer) and hostapd (EAP server). It includes implementation for both OpenSSL and GnuTLS, i.e., there is a build time option to select which one to use and core code does not need any changes regardless of which TLS library is used. I would assume that similar design would work fine with FreeRADIUS, too, or at least tls_gnutls.c wrapper implementation can provide some examples on how EAP-TLS/PEAP/TTLS can be implemented with GnuTLS. -- Jouni Malinen PGP id EFC895FA
Jouni Malinen <jkmaline@cc.hut.fi> wrote:
The last time I looked at this compatibility layer, I did not find suitable functionality for implementing EAP methods due to the requirement of doing I/O with own routines (instead of using TCP sockets).
Yuck.
If someone is planning on converting FreeRADIUS to use GnuTLS, it might be worthwhile to take a look at the TLS wrapper I designed for wpa_supplicant (EAP peer) and hostapd (EAP server). It includes implementation for both OpenSSL and GnuTLS, i.e., there is a build time option to select which one to use and core code does not need any changes regardless of which TLS library is used. I would assume that similar design would work fine with FreeRADIUS, too, or at least tls_gnutls.c wrapper implementation can provide some examples on how EAP-TLS/PEAP/TTLS can be implemented with GnuTLS.
Yeah. I've taken a look at eapol_test. It's *exactly* what we need to do automated regression tests for FreeRADIUS. It's also neat, clear, and well designed. Do you think it would be a good idea to develop a client & server EAP library? I know FreeRADIUS has bits & pieces that have been severely hacked over time. FreeRADIUS also needs an EAP client program that does more than radeapclient, and eapol_test doesn't send RADIUS attributes. I had patches sitting somewhere for eapol_test that would link to the FreeRADIUS libs & load the dictionaries. Would you be interested in those patches? Alan DeKok.
On Sun, Feb 12, 2006 at 12:45:48AM -0500, Alan DeKok wrote:
Do you think it would be a good idea to develop a client & server EAP library? I know FreeRADIUS has bits & pieces that have been severely hacked over time.
Making number of modules in hostapd/wpa_supplicant more isolated from eachother so that they could be used more easily for other purposes is certainly an area that I'm interested in and EAP client and server sides are good candidates for that. In other words, yes, that sounds like a good idea to me. Based on a quick look, the current EAP server implementation in hostapd is quite self contained. It does require the TLS/crypto wrapper API hostapd/wpa_supplicant are using, so that would need to linked in (maybe as another library). Other than that, EAP code is just using couple of generic helper functions (debug printing, etc.) that should not take too much work to resolve nicely. There is one exception to this in EAP-SIM/AKA access to external gateways for HLR/AuC access that is sending and receiving messages and as such, is currently tied into an event loop implementation. That would need to changed to use some kind of abstraction to work with other programs. The interface from EAP module to "lower layer" is designed based on RFC 4137 and it seems to fit in relatively easily with a RADIUS authentication server even though some of the terminology may be somewhat more familiar from IEEE 802.1X. I have done some experiments with EAP implementation in FreeRADIUS, but it has been too long from this that I would actually remember any details, so I would probably need to take a closer look to understand how that code interacts with rest of the implementation and how close that would be to the design used in hostapd.
FreeRADIUS also needs an EAP client program that does more than radeapclient, and eapol_test doesn't send RADIUS attributes.
What do you mean with not sending RADIUS attributes? eapol_test links in RADIUS authentication client implementation from hostapd (i.e., from a NAS). It includes the basic attributes needed for 802.11 networks and 802.1X/EAP. However, the attributes are hardcoded in the implementation, so that is certainly a limitation for some uses (though, so far, I have never needed more flexibility in projects I've been working with).
I had patches sitting somewhere for eapol_test that would link to the FreeRADIUS libs & load the dictionaries. Would you be interested in those patches?
If you have them easily available and against a relatively recent version of eapol_test, it would be interesting to see them. They could also be of interest for hostapd in the sense of allowing 802.1X authenticator and RADIUS client to do something more flexible as far as RADIUS attributes are concerned. -- Jouni Malinen PGP id EFC895FA
On Thu, Feb 09, 2006 at 01:14:16PM -0500, Alan DeKok wrote:
Nicolas Baradakis <nbk@sitadelle.com> wrote:
- pull eap fixes from CVS head to address Debian's issues.
Done.
As Paul noted, the build produces a non-redistributable binary package, but it's a lot better than not working at all :)
I have no objection to updating the license to allow linking against OpenSSL.
Also, the GPL *does* allow this, if OpenSSL is already installed on your system. As proof, it's possible to distribut Solaris binaries of GPL'd packages, even though Solaris libc isn't GPL'd.
That's slightly different. The GPL's exception is for things that are normally part of the OS (ie libc) unless the GPL'd thing is also part of the OS. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. In Debian, OpenSSL would normally accompany FreeRADIUS if FreeRADIUS depended on OpenSSL, thanks to apt-get. The idea of the clause as I understand it is to allow you to run GPL programs on non-GPL OSs without giving you open slather to write GPLd code that depends on non-GPLd libraries more than absolutelly neccessary. ie. It's no problem to use Solaris' libssl (if I remember correctly that comes with the OS from Sun) but OpenSSL isn't. I'm sure there's an FAQ around somewhere that explains it better... Anyway, the short summary is you can't upload to Debian anything that has both GPL'd code and links to OpenSSL. -- ----------------------------------------------------------- Paul "TBBle" Hampson, Bsc, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@Pobox.Com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ -----------------------------------------------------------
Paul TBBle Hampson <Paul.Hampson@Pobox.com> wrote:
That's slightly different. The GPL's exception is for things that are normally part of the OS (ie libc) unless the GPL'd thing is also part of the OS.
i.e. Since RedHat ships with OpenSSL, linking FreeRADIUS to OpenSSL is fine.
Anyway, the short summary is you can't upload to Debian anything that has both GPL'd code and links to OpenSSL.
Debian has always had a slightly odd interpretation of the GPL. As you said:
In Debian, OpenSSL would normally accompany FreeRADIUS if FreeRADIUS depended on OpenSSL, thanks to apt-get.
Which would appear to allow uploads linking things. But maybe that's why I don't participate in Debian. Alan DeKok.
On Mon, Feb 13, 2006 at 01:34:43PM -0500, Alan DeKok wrote:
Paul TBBle Hampson <Paul.Hampson@Pobox.com> wrote:
That's slightly different. The GPL's exception is for things that are normally part of the OS (ie libc) unless the GPL'd thing is also part of the OS.
i.e. Since RedHat ships with OpenSSL, linking FreeRADIUS to OpenSSL is fine.
Since Red Hat ships with OpenSSL, linking FreeRADIUS to OpenSSL and shipping it *outside of Red Hat* is fine. By the most conservative interpretation of the GPL, shipping it *in* Red Hat would not be.
Anyway, the short summary is you can't upload to Debian anything that has both GPL'd code and links to OpenSSL.
Debian has always had a slightly odd interpretation of the GPL.
Without case law to settle the license's ambiguities, or a legal budget for when a copyright holder decides they have a different interpretation of the license than we do, Debian is always going to err on the side of caution. FWIW, the GPLv3 draft includes language that appears aimed both at resolving the license incompatibility with advertising clauses, and resolving the OS exception ambiguity in favor of people who want to bundle GPL works with propietary (or at least, incompatibly-licensed) OSes. As a proponent of free operating systems I don't really think the latter is a good idea, but there it is. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
Nicolas Baradakis <nbk@sitadelle.com> wrote:
I don't know if it's too soon to plan a release date for 1.1.1, as 1.1.0 has some annoying known problems:
Are there any objections to releasing 1.1.1? There's another patch I'm committing today, but that should be it, I think. Alan DeKok.
Nicolas Baradakis <nbk@sitadelle.com> wrote:
No objection. I think all of the problems in the release 1.1.1 TODO have been solved.
Ok. I've added a bunch more trivial fixes, and have one question. doc/Makefile was updated to install the docs under share/doc/freeradius/ rather than shared/doc/freeradius-$(VERSION). Why? Everything else under share/doc is version dependent. Alan DeKok.
Alan DeKok wrote:
Ok. I've added a bunch more trivial fixes, and have one question. doc/Makefile was updated to install the docs under share/doc/freeradius/ rather than shared/doc/freeradius-$(VERSION). Why? Everything else under share/doc is version dependent.
Since a "make install" put the libraries and the executables in version-independent directories, I was thinking it'd be more consistent to have the docs under share/doc/freeradius. It doesn't make a lot of sense to overwrite /usr/sbin/radiusd during install but keep old documentation in shared/doc/freeradius-old-version. However it's only my personal opinion, therefore I'd change it immediately if needed. I apologize because I didn't ask the list before changing doc/Makefile. I also note on a Debian system the documentation is to be found in the directory /usr/share/doc/${package} and not /usr/share/doc/${package}-${version} but of course we have no obligation to do that in FreeRADIUS. -- Nicolas Baradakis
Nicolas Baradakis <nbk@sitadelle.com> wrote:
Since a "make install" put the libraries and the executables in version-independent directories, I was thinking it'd be more consistent to have the docs under share/doc/freeradius. It doesn't make a lot of sense to overwrite /usr/sbin/radiusd during install but keep old documentation in shared/doc/freeradius-old-version.
Sure, I have no strong opinions. I was just curious. I'm trying to re-build branch_1_1, and now I can't get EAP to build. The CVS head builds, but branch_1_1 keeps giving me "libeap/libeap.la is not a convenience library". Ideas? Alan DeKok.
"Alan DeKok" <aland@ox.org> wrote:
I'm trying to re-build branch_1_1, and now I can't get EAP to build. The CVS head builds, but branch_1_1 keeps giving me "libeap/libeap.la is not a convenience library".
And, it tries to build rlm_eap.so before libeap, so it complains about libeap not existing. Alan DeKok.
Are there any objections to releasing 1.1.1? There's another patch I'm committing today, but that should be it, I think.
How about adding bug #335? It's trivial, speeds up normal packet handling and makes "hints" usage *consistent* for every packet received. Greetings, Stefan Winter -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473
Stefan Winter <stefan.winter@restena.lu> wrote:
How about adding bug #335? It's trivial, speeds up normal packet handling and makes "hints" usage *consistent* for every packet received.
Speeds up packet handling? If it doesn't change existing behavior, I'm OK with adding it in. Alan DeKok.
Hi,
How about adding bug #335? It's trivial, speeds up normal packet handling and makes "hints" usage *consistent* for every packet received.
Speeds up packet handling?
If it doesn't change existing behavior, I'm OK with adding it in.
existing behaviour is unchanged. The speed-up is very marginal, but: as of yet, for every packet this if () condition is evaluated, and and in the vast majority of cases (whenever User-Name is present) it evals to true. After taking these lines out, the if eval is saved (kinda being true always). Overall, you save one boolean evaluation per packet. Greetings, Stefan Winter -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473
After taking these lines out, the if eval is saved (kinda being true false
Too early in the morning. -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473
On Monday 06 March 2006 20:46, Alan DeKok wrote:
Nicolas Baradakis <nbk@sitadelle.com> wrote:
I don't know if it's too soon to plan a release date for 1.1.1, as 1.1.0 has some annoying known problems:
Are there any objections to releasing 1.1.1? There's another patch I'm committing today, but that should be it, I think.
rlm_perl fix for bug 348 ? should i commit it in branch_1_1 ? This patch works for me. Tested on Gentoo with perl 5.8.8 and libperl 5.8.8 Any body else can confirm ? -- Best Regards, Boian Jordanov SNE Orbitel - Next Generation Telecom tel. +359 2 4004 723 tel. +359 2 4004 002
participants (8)
-
Alan DeKok -
Anton Gorlov -
Boian Jordanov -
Jouni Malinen -
Nicolas Baradakis -
Paul TBBle Hampson -
Stefan Winter -
Steve Langasek