Re: RADIUS for MAC authentication in WLAN, how doing it?
From: Igor Sobrado (sobrado_at_string1.ciencias.uniovi.es)
Date: 01/07/04
- Next message: Skylar Thompson: "Re: Tagged queueing"
- Previous message: Domènec: "Installing NetBSD on a SparcStation 10, what should I read?"
- In reply to: jpd: "Re: RADIUS for MAC authentication in WLAN, how doing it?"
- Next in thread: jpd: "Re: RADIUS for MAC authentication in WLAN, how doing it?"
- Reply: jpd: "Re: RADIUS for MAC authentication in WLAN, how doing it?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 7 Jan 2004 20:36:36 +0100
jpd <read_the_sig@do.not.spam.it> wrote:
>
> Provided they want to have you, but that would be a cool place to work,
> true. If you're serious about getting there, you might not want to dig
> too deep into the local administration mess, though. Having a working
> wireless setup is not as important as finishing your dissertation. :-)
Don't worry about that. I will finish my doctoral dissertation soon.
I have some papers published (one of those papers was translated to
Italian at the University of Bologna, two unrelated works were useful
to start some projects at the United States and Germany, and a research
about mobile agents was useful for a research at a NATO contractor).
This contractor is interested in getting a patent on one of the algorithms
developed two years ago. I believe that I will get a Ph.D. without
problems.
You are absolutely right about spending my time on administration
issues. I am not a system manager now and I do not want to work as
a system manager in the future. But the idea was good (with some
high-quality access points building that network was not difficult)
and it will be useful for me (running a RADIUS server will help me
a lot, I prefer authenticating users on a NetBSD machine instead
of updating an access list on my AP-1000).
> *snort* Tell that to the people that wrote the software. Especially
> if they come from a different networking system or are right out of
> college.
Indeed, but the concepts of TCP/IP internetworking are easy to
understand and implement. They should fix those issues if it is
possible.
> Long, long ago the IP world thought in classes. Even as recently as
> mid last year someone in cubfm had to show off his knowledge of IP
> addressing -- but was completely oblivious to the fact that we've been
> classless for, whatsit, 10 or so years?
Certainly, CIDR is a good deployment. It allows addresses to be
assigned on a more efficient way, but even CIDR uses prefixes
from 13 to 27 bits. Again, netmask as some sense here.
> So, whether we like it or not, best to skip over all the .0 and .255
> addresses. And for big enough blocks, the loss is no real issue.
Discarding those addresses is a problem. I supposed that it was the
problem when I got an error message about the addresses assigned to
the DHCP server for the LAN side of the APs. But other people will
not understand this problem. The worst problem is that some corporations
can need a large address space (something like 10.0.0.0/8 or 172.16.0.0/16)
and they will find a lot of "invalid addresses" (e.g., 10.x.y.0, 10.x.y.255,
172.16.x.0, or 172.16.x.255) that will divide their space in 256 or 65536
address spaces. Perhaps they need only one address space.
IMHO, it is a real issue for big blocks that are divided in smaller
address spaces by those unauthorized addresses.
> Ugh. Reason enough to pull a serial cable, I'd say. :-) Then again,
> I'm spoiled by having a 48-port serial console solution in the rack.
> If you have patch panels throughout the building you can route
> serial lines through those, too.
The serial cable only allows us to go into a small configuration
menu where it is possible choosing the IP addres of the AP-1000 (I
prefer allocating those addresses from a DHCP server running on NetBSD),
and choosing the channel used by each wireless interface (up to two)
supported by the access point.
It would be nice for Lucent releasing the cliproxy source code in
the same way they did in the past with a lot of software packages
that are available from their machines (operating systems like
EclipseBSD and Plan9, tools for integrating CORBA with other
environments, improvements for LDAP servers...).
> You're thinking of scaling up, no? Besides, lots of management software
> and graphing tools can easily use SNMP, so for that it's really useful.
> Generally less so for human interaction, though. I'd still want a CLI
> for that. Speaking of which, a tool like scli can be fairly useful, too.
Indeed! I was thinking on my personal access point (a Lucent Technologies
AP-1000). Either web or telnet management is not an option for our
campus-wide network.
> I'm very sorry I haven't had time to dig into it yet, I'll see if I can
> do so within a week and get back to you about it.
Don't worry about that. I have a lot of information and I guess what
is happening with our access points. If I am able to fix those issues
(I am not spending more than two or three hours/week on this project)
I will post a full description of how deploying 802.1x. Not a NetBSD
issue, but perhaps useful for NetBSD users.
> Well, you didn't have convincing documentation ready to pull them over
> right away --something which you might not want to have done anyway,
> mind you, for political reasons--, and since we're talking almost-
> government here, don't expect the money to be spent efficiently at all.
> The paper-pushers in your way might make more --and at least cost the
> university more-- every day, than the APs cost, and you can't do
> anything about that, either.
>
> Your vice-president may well have done you a big favour already. Since
> you're so completely out of the standard operations loop you can
> actually get things done, but don't push it too hard as it is a touchy
> subject for some. You might end up having to hand a working setup over
> to the regular operations people, and after that it even might just stop
> working after a while. Just hope you're gone by then.
>
> I know this isn't what you were hoping for but as of yet you seem to have
> support from the science faculty in spite of the people that should have
> done it in the first place. This may very well be why the computer science
> department is not supporting you. Build your network gradually and enjoy
> while you can. As for the money, well, burning a lot of money, and your
> sanity as well, on an inter-department feud is no good to anyone, is it?
You are right about this issue. My current department is not working on
this project because they do not want. We offered them the possibility
of working on this project about a year ago, they were glad about
participating in the deployment of this network, but they have changed
the way they want to work. They got some Cisco APs freely provided by
one of our phone companies as sponsors. They payed about 3000 EUR to
two students on the first course for installing those APs and they
asked the Faculty of Sciences about paying the installation of those
APs. Of course, those APs are not covering the Faculty of Sciences
building. A very bad movement, but at least the Physics Department
was glad about paying the installation of those APs. They allocated all
the frequencies available making my AP-1000 practically unavailable
for some weeks and they threaten me to move the AP-1000 out of this
building. Of course, I didn't. I got the support of the presidents
of the Maths and Geological Sciences departments, and my AP is running
again.
On the other hand, my current department wanted to manage all the APs,
choosing what users will have access to the wireless network (with my
proposal each department/faculty will be able to authorize its own
users on all the campus) and, worst of all, they want to run all the
wireless infrastructure on a Windows 3000 Advanced Server machine.
Now, they are NOT authorized to run that wireless network, their
APs are on, but blocked in the campus routers.
As my proposal is a collaboration between all the Departments and
Faculties in our campus (except my current department) all is working
just fine. We have all the permissions to run this network, and we
are glad about the possibility of running the network on this way:
each department will have a manager and, once authorized, a user
will have access to all the APs in the campus.
I believe that a framework like this one, should be an open project
for all research groups interested in its deployment and use. It is
a good infrastructure for research and education. And an important
service for our campus.
> Use ipsec, lay tunnels like with PPPoE and use some VPN tricks, etc.
> There are a number of solutions possible. :-)
Indeed! I will look for some alternatives if I am unable to get
802.1x running.
>> my University has money to pay other students (even more than
>> 1000 EUR/month for managing systems... and they are unable to set up
>> something more complex that a Windows XP workstation sometimes!).
>
> Been there, seen that, got the tee shirt. You're on the wrong spot
> and don't fit in the administrative structure to actually get money.
Agreed. But I do not trust on the right spot.
> Time to get your papers and go somewhere where you are appreciated.
> No sense in trying to pound some sense into them. Unless you're stubborn
> enough and like that sort of battle. Don't make their loss your loss.
That is a fine advice. I will follow this advice.
> There's more nice places. If you want to live in spain again, see if
> you can get enough reputation to get your government to sponsor you
> and maybe a few others in a spanish research institute. But those
> are all long-term dreams.
I want to work on a good research lab or University. MIT, UCLA, UCB,
Stanford... are good places. But it will be really difficult get a
position in, we say, MIT. On the other hand, my english skills are
not too high. They will need a lot of patience with me.
> I'm not sure if you should do that, especially if you're not supplying
> the network cards also. Better stick to standards even if they're slower.
> That way you can easily replace access points with a different brand
> should USR cease to exist or just cease to produce 802.11g+ APs.
> On top of that, 802.11g+ uses a disproportional amount of bandwidth in
> the free band that isn't big to begin with. You'll run out of free
> channels real fast, which means that you can't get your entire building
> covered well enough for full bandwidth. The higher the datarate the
> higher the spectrum consumption but also the shorter the usable range.
>
> Besides, if you have a few public 100Mbit lines (perhaps with 802.1x?)
> near the access point, you use those if you need to transfer a lot of
> data, otherwise you can use the wireless. Even 1mbit is plenty for
> reading email.
Indeed, I will stick to standards. A good point about US Robotics
APs is that those devices will support (at least theoretically,
they should support telnet and they DON'T) both 802.11b and 802.11g
clients simultaneously. I will not run 256-bit WEP keys, for example.
And I do not want MSCHAPv2 as authentication method (even if it is
supported by xsupplicant now).
I agree about using our 100 Mbit ethernet. Hopefully, most people
understand that the wireless network we are building is not a
replacement for our current networking infrastructure, but an
alternative network for people with special requeriments.
> I don't know what that is, hardware wise. If you run, say, your 15 APs
> on 11mbit max (which is theoretical), you get a theoretical max of 165
> mbit. More likely your peak max will be at about 100 mbit which a decent
> if not overly recent peecee can handle with two quality 100mbit NICs.
> Four ports, FastEtherChannel bonded in pairs if you want to be sure.
> GigE NICs are also nice but not necessairy.
Indeed, but we are able to run all our APs at 100 Mbit, we have 2 Gb/sec
fibre channels between floors in our building, and higher speeds between
buildings and campuses (some campuses are more than 30 Km. away).
There are noise issues that seriously limit the speed on some buildings
(that are running at 10 Mbps yet) but those problems will be fixed soon.
> Using the things in bridge mode should help there. You would want to
> use a vlan to keep the bridged traffic separate from the regular traffic.
A very good advice. A good workaround if we are not able to get 802.1x
running on those devices.
> You can contribute code, and it is up to the NetBSD people to decide
> if yours is good enough. Making sure it is up to your standards at least
> should help though. :-)
Thanks! ;-)
I will consider writting code for the NetBSD project again.
> Reason enough to ditch them, or at the very least get USR to fix that.
> Hanging admin interfaces are completely unacceptable for production use.
I hope that those problems will be fixed in the next months. They
should add the missing telnet server, and improve the devices
reliability. If not, I hope that we will be able to return those
devices to USR.
Thanks a lot for all those useful advices.
Igor.
-- Igor Sobrado, UK34436 - sobrado@acm.org
- Next message: Skylar Thompson: "Re: Tagged queueing"
- Previous message: Domènec: "Installing NetBSD on a SparcStation 10, what should I read?"
- In reply to: jpd: "Re: RADIUS for MAC authentication in WLAN, how doing it?"
- Next in thread: jpd: "Re: RADIUS for MAC authentication in WLAN, how doing it?"
- Reply: jpd: "Re: RADIUS for MAC authentication in WLAN, how doing it?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|