View Full Version : DHCP server (DHCP auto-auth) limitation
I see there is a limitation imposed on the DHCP auto-auth server, it refuses to let me run it on an interface that is bridged.
Is this a limitation we can remove?
I have setups like for example:
wpci1 is a WAN IP from a /29, the backhaul from my backbone
wpci2 is an AP with a /27
ether1 is the person/business hosting the system
wpci2 and ether1 are bridged together so they can use IPs from the same /27
lonnie
04-18-2006, 06:00 PM
If you are using the v2 system you can use the ISC DHCP server. The no bridge limitation will be removed in an upcoming V3 release. v2 as you know is stuck.
Er yeah, sorry I meant to mention this was a v3 system. I was in a hurry to get out the door when I wrote the post.
I use the ISC DHCP server very happily under v2. The reason I asked today was because I swapped out our first v2/WRAP for a v3/WAR and that's the type of configuration it had so it had to be changed :)
I had to tell the guy on ether1 to renumber to his own /29, he got over it.
Most excellent to hear that limitation is planned to be removed in v3.
How far is a full DHCP server on the priority list ? We have a couple of nodes to launch and just noticed I cant add static DHCP on the WARs
beta-17 now allows auto-auth to operate on bridged interfaces.
At this time, there are no immediate plans to introduce the ISC DHCP server to the WAR platform simply due to it's size.
There are several open source embeded dhcp servers that I was able to google up. Stupid suggestion, but what did cisco use on the wrt54g. I really can't see how you are seriously not planning to put some sort of dhcp server into the v3 platform thats a pretty basic function.
lonnie
05-02-2006, 04:59 PM
I do not understand your question. DHCP AutoAuth is a DHCP Server and has been there for quite some time, so we are seriously not doing what you asked about. Do you have a WAR board or are you speculating and asking questions?
There are several open source embeded dhcp servers that I was able to google up. Stupid suggestion, but what did cisco use on the wrt54g. I really can't see how you are seriously not planning to put some sort of dhcp server into the v3 platform thats a pretty basic function.
My mistake. Requiring a radius server for anything more than assigning from a range and even then unless I have missed something there is no way to assign more than one address to the same mac address is obviously a fully functional dhcp server. Something as simple as having my own laptop roam accross our network requires me to put a range on every interface I might connect to. I hate to be snippy, but I am guessing that I am not the only one here who doesn't consider autoAuth a legit replacement for a fully functional dhcp server.
The last time I looked at autoAuth flexibility was seriously lacking. If you have modified it so that it passes an attribute for the interface the request is coming from so that the radius server can use that information as well as the mac address that would mitigate one complaint. I don't remember seeing dhcp requests and errors logged by autoAuth. If my memory is correct that is another big hole. I 'm sure other things will occur to me, but these are at least the high points.
And yes I started deploying war boards last September. I have been with them through many iterations and I am finally looking forward to taking them mainstream. I just don't look forward to changing our address procedures because a war can't even do something that a wrt54g can do. ( i.e. statically assign from a local configuration).
I do not understand your question. DHCP AutoAuth is a DHCP Server and has been there for quite some time, so we are seriously not doing what you asked about. Do you have a WAR board or are you speculating and asking questions?
auto-auth does not require a radius server or hotspot, and as such, can operate as a simple stand-alone dhcp server to hand out dynamic leases.
The beta-18 release, that is currently in testing has isc-dhcp server support. We have decided to include it after all, due to it's flexibility, and ability to assign static leases.
That is great to hear. AutoAuth simply did not work for us because of its limitations so while you are right it is a "DHCP server" it is not what most people mean when using that phrase. If you added some of the functions that I mentioned it could be made usable in a larger number of environments, but in the end there would still be someone who would need something it didn't do.
If you are really that tight on memory it doesn't seem like the features I mentioned woud be that hard to add. Actually the request that someone else made for appending a realm to the radius request could fix my biggest complaint. If I could specify a string that was appended to the request people who don't need it could just specify "strip realm" and everything would countinue to work. Those of us who need to allow devices to roam our network would be able to do so.
The only other thing that I saw as a major limitation is not having local logging of dhcp errors. My above suggestion might even fix that since at least you would know which interface bad requests were coming in on and could track the problem down.
I hate to hijack the thread, but could it be time to address the issue that the gateworks boards as shipped simply don't have enough memory on them for the long run. You spec'd those boards based on using a small kernel since that is no longer the case how about a survey to see who would be willing to pay extra for boards if it meant greater functionality. Or maybe take the path that the wrap has taken where there are different models with different memory levels.
lonnie
05-03-2006, 11:47 AM
No surveys are required on whether we add memory or not. It is not an issue I need any advice on. Thanks for the advice though.
Realms are not requried for roaming, just for customization of the login. AutoAuth does report to the kernel message log.
udhcpd (AKA dhcp auto-auth) has near-useless logging. It doesn't even mention the MAC address that was talking to it much less any details of the DHCP conversation.
I'm very happy to have isc dhcpd back
lonnie
05-03-2006, 12:35 PM
I guess I do things differently. If they get an IP I am happy. I spend very little time looking at MAC addresses and the units who have failed. My association display has names for all identified users and as long as they have an IP I have no other information requirements. The goal is to get them to the Internet and all they need for that is an IP and a reliable connection.
I think the ISC DHCP is superior but we rarely use it except at my central site. All remotes use AutoAuth.
Unless I missed something the way you have it set up I will get the same ip address no matter where I am. When I tried using autoAuth there was no way to allow the same mac address to pull a different ip address depending on what interface it connected to. The suggestion for appending a realm would address that because the radius server could respond differently depending on where on our network I was. I am not saying this is the only way, just pointing out that what the other guy asked for might actually have a use after all.
Glad to hear that it does log. It has been quite a while since I tried to make autoAuth work for us and I didn't remember seeing any failed requests logged. My Bad.
If you don't want any feedback on features that your customers would like to see in your hardware, thats fine. I would like to go on record for being willing to pay more for a platform that is a superset of v2 not one that requires us to give up features we are currently using. If that means more memory and higher expense so be it. For ap use it is a small price to pay. If you want to cost reduce the daylights out of a single port single radio cpe I fully endorse that as well. I'm not saying you guys made a mistake, I was just pointing out that the parameters of the problem changed midway through the project.
[QUOTE=
Realms are not requried for roaming, just for customization of the login. AutoAuth does report to the kernel message log.[/QUOTE]
Unfortunately for us we do centralized logging and shaping of traffic. Therefore I need to know who is on what address and if they aren't getting the address they should I don't like to spend a lot of time trying to figure out why. I have one central device that I can log into and see pretty much everything that is happening on my network. Logging into each ap and looking at the association list would be a step back. This is one of the many reasons I keep harping on true SNMP support. I can pull info from v2 using scripts, but I haven't even bothered with v3 yet since it is in such a rapid state of change. Pulling from a custom mib would be a lot easier.
I guess I do things differently. If they get an IP I am happy. I spend very little time looking at MAC addresses and the units who have failed. My association display has names for all identified users and as long as they have an IP I have no other information requirements. The goal is to get them to the Internet and all they need for that is an IP and a reliable connection.
It's when they don't get an IP that I need to see what's going on :)
Additionally, for tracking purposes, it's nice to go back in my logs and be able to see what MAC address was attached to what IP address. Since the DHCP leases aren't kept across reboots, clients change IPs sometimes. If someone sends me an abuse report from an incident 3 days ago I need to be able to see who was on that IP.
Nice detailed logging is important to me, udhcpd doesn't log anything useful. "I gave out this IP" is about all it says.
lonnie
05-03-2006, 02:27 PM
AutoAuth is attached to the device it listens on. That means you have to enable and configure on every device, at which time it gives out the proper IP, mask, and gateway for the device the request was heard on.
Now, if you are using Radius with AutoAuth, yes it will only give out a single IP, etc.
Unless I missed something the way you have it set up I will get the same ip address no matter where I am. When I tried using autoAuth there was no way to allow the same mac address to pull a different ip address depending on what interface it connected to. The suggestion for appending a realm would address that because the radius server could respond differently depending on where on our network I was. I am not saying this is the only way, just pointing out that what the other guy asked for might actually have a use after all.
Glad to hear that it does log. It has been quite a while since I tried to make autoAuth work for us and I didn't remember seeing any failed requests logged. My Bad.
If you don't want any feedback on features that your customers would like to see in your hardware, thats fine. I would like to go on record for being willing to pay more for a platform that is a superset of v2 not one that requires us to give up features we are currently using. If that means more memory and higher expense so be it. For ap use it is a small price to pay. If you want to cost reduce the daylights out of a single port single radio cpe I fully endorse that as well. I'm not saying you guys made a mistake, I was just pointing out that the parameters of the problem changed midway through the project.