View Full Version : OLSR dhcpd caveat
FYI, you cannot run ISC dhcpd and olsrd on the same network interface, at least not on br0. I haven't tested on ethernet and atheros interfaces nor have I tested udhcpd (DHCP auto-auth) but I don't know why udhcpd or ethernet/atheros interfaces would act any different.
For security and usability purposes (like being able to run dhcpd on one of the interfaces) be selective in your OLSR config about which interfaces it binds to. Remove any unused interfaces or client-facing interfaces, only bind it to interfaces it makes sense to be talking OLSR on.
I just happened to have a mix of clients and backhauls on a 5GHz AP that's in a bridge and found out dhcpd stopped working when I turned on olsrd on br0.
Oh well, only a couple clients were using dhcp and I'm on the phone helping the last one put in a static IP.
Thank you Tog for the useful information. There should be no problems using DHCP server with a OLSR-enabled interface. We will look into this.
lonnie
06-06-2006, 07:15 PM
Actually I would say that you should not run OLSR on a bridged interface, nor would I run DHCP. The job of a bridge is to pass traffic from one interface to the other. It is rarely a destination and really should not modify any packets or take any action based on what it hears.
Whenever people try and misuse a bridge they find out all kinds of wonderful things. I wouldn't call the results a bug as much as a situation that was never intended to happen.
There is a useful situation however, such as two or more AP cards being bridged, routed to the ethernet. Situations such as can be common, and worth the investigation.
Sure, it is a destination, it has an IP address assigned and everything. If you stick two interfaces in a bridge and start assigning IPs to any of those bridge member interfaces in the GUI it smartly puts them on br0 rather than the individual interfaces that are members of the bridge. dhcpd runs on br0, you run olsrd on br0 if you want, etc.
It's a nice setup, and I think it's the way it should work. OpenBSD's if_bridge (now also available in FreeBSD) works the same way, you run dhcpd or whatever on bridge0 rather than any individual interface that's assigned to the bridge if you want things to work.
I sould also mention that you cannot run OLSR on additional aliased IP addresses which show up as "interfacename:0" and "interfacename:1" in Linux. olsrd does not understand "wpci0:0" or whatever as an interface name. and will not start up if you try. Make sure the IP address you're talking to your other OLSR-enabled routers from is the first listed in the GUI so it becomes the "main" IP address. You can view system information to confirm that the main entry for "br0" or "wpci0" or whatever your interface is the IP address you need and your additional IPs are the ones assigned to br0:0 and br0:1, etc.
My particular situation today is exactly as tony described, I have two atheros interfaces in AP mode bridged together so they can share address space. I branched off a second AP at some point and moved existing clients over to it so the bridged setup makes perfect sense.
Thank you for the update.
You are correct in that OLSR is designed to only work with the first IP from any bound interface.
To further my OLSR+dhcpd commentary:
If you run a dhcp server (either type, ISC or udhcpd) on the same router that you're running OLSR on, please be very careful to watch the logs after enabling OLSR and make sure your DHCP server is still working, or at least just confirm olsr and dhcpd aren't bound to the same interface, then restart the DHCP service for good measure after you are done restarting OLSR.
I started olsrd up last night on a WAR router and this morning found that dhcpd was still running but not receiving anything. Restarting dhcpd fixed it. olsrd might have been bound to dhcpd's interface briefly last night, which rendered it deaf until dhcpd was restarted.
Just to confirm, I rebooted one of the WARs running OLSR. olsrd is bound only to wpci0 (its incoming backhaul) and ISC dhcpd does work fine after the reboot, everything is behaving as expected so there's nothing to worry about on an ongoing basis after the OLSR configuration is established.
That is very good information, and should help those using DHCP and OLSR on the same system (which is a common case).
lonnie
06-06-2006, 11:50 PM
I do disagree that is useful. In fact it is to be avoided since it gives you a single broadcast segment, so instead of delivering 10 mbps bandwidth to two connections you end up with 10 mbps shared between two segments. Customers can snoop the entire segment and a rogue DHCP can take down BOTH segments instead of simply the AP it is connected to.
There are lots of simplistic ways to try and justify using a bridge with two or more AP units, but when you look at the downsides I say it just is not worth it.
I do recommend a bridge when you wish to actually join two locations and make them appear as one, but if you are not trying to join them you really should use a routed and separate design. The bridge design will be forever giving little issues and mostly you will not even be aware of the cause.
Our whole system is separately routed segments and we simply do not have the troubles and little issues that i seem to be discussing with people on the phone, all day and every day. After 7 years of helping with issues I do know for certain that bridged non-designs have all sorts of little issues and routed is superior. Our system is proof of that. When we have a runaway customer we can narrow it down to a particular radio in no time at all. If we were bridged we would narrow it down to a particular group of radios.
There is a useful situation however, such as two or more AP cards being bridged, routed to the ethernet. Situations such as can be common, and worth the investigation.
Getting a little bit off topic... The problem described in this thread happens on non-bridged interfaces as well. It's a general problem with binding olsrd and dhcpd to the same interface.
lonnie
06-07-2006, 09:12 AM
That is fine and we'll check into that, as Tony said. I now will correct any bridging related misconceptions whenever they occur. People really must learn to route. The time I waste each day with bridging problems is simply stupid and a waste of my time, as well as the customer's time. If they routed they would be having a solid system and I would have more time.
So, you see, I have to correct these times. It is in my best interest to get people to learn something other than bridging.
We use OLSR with the DHCP AutoAuth and it seems to have no issues, so it is not simply DHCP, it must be the ISC DHCP server.
Getting a little bit off topic... The problem described in this thread happens on non-bridged interfaces as well. It's a general problem with binding olsrd and dhcpd to the same interface.
You've specifically enabled udhcpd on the same interface that you have bound olsrd to? If so, great. A workaround.
I do think there is a situation or two that we did have to use DHCP with OLSR on the same interface, which did seem to work as expected. This was before we had ISC DHCP however. I will be doing some testing to see why ISC fails.
Thanks!
lonnie
06-07-2006, 01:25 PM
Yes, all of our client units were running OLSR and it announced their Ethernet which had DHCP AutoAuth on it.
You've specifically enabled udhcpd on the same interface that you have bound olsrd to? If so, great. A workaround.
David L. Vrablic
07-28-2006, 11:09 AM
Yes, all of our client units were running OLSR and it announced their Ethernet which had DHCP AutoAuth on it.
Lonnie, Tog Anybody!
Any of you folks that are running OSLR mesh.
Has anyone tried using the plug ins and graphing the system connections.?
The only plugin I'm using is the http interface, sorry.