View Full Version : OLSR dhcpd caveat [Off-topic]
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.
bradg
06-06-2006, 02:18 PM
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.
Good grief! How many more times does the ability to bind services to specific interfaces need to crop up before it's finally addressed? It appears that it may have bitten you in the rear end once again with OLSR.
Guys - regardless of this issue, lack of service binding control is a fundamental design flaw, and needs some attention. Tossing out workaround after workaround after workaround only complicates and contorts the customer's network design - yet more "features" to break, and possibly more vendor lock-in (something I absolutely despise, BTW).
Sooner or later, the workarounds will need workarounds. They aren't workarounds, call it what they are - band-aids for missing features.
The selective service availability/binding is in the top five "best practice" items in good network design and administration. You need to get over your hang-up about support issues and use that effort and energy to educate users, and work out a graceful configuration recovery mechanism for people who do screw up their networks.
Like it or not, by not addressing this (amongst others) issue you are penalizing and seriously alienating existing and potential intelligent users of your products.
Brad
OLSR has a nice configuration file, you can tell it which specific interfaces to bind to there. I was merely providing a recommendation to all the other StarOS users who want to start using OLSR.
ISC dhcpd I don't really care too much because it intelligently decides not to bind to interfaces that it doesn't have subnet declarations for.
You just can't bind both OLSR and ISC dhcpd to the same interface and still have dhcpd work and I thought it would be good to have that information available for others.
bradg
06-06-2006, 04:18 PM
OLSR has a nice configuration file, you can tell it which specific interfaces to bind to there. I was merely providing a recommendation to all the other StarOS users who want to start using OLSR.
Which is the proper thing to do, and useful information for everyone. Thanks.
ISC dhcpd I don't really care too much because it intelligently decides not to bind to interfaces that it doesn't have subnet declarations for.
However, DHCP relay does not "intelligently bind" to interfaces, it's an all-or-nothing affair - making relaying impossible on the same box you may use for backhaul other relayed requests on. I'm not sure about you, but I have no burning desire to run a DHCP server on every AP, and manage each configuration file separately. Centralized management and configuration is the only way to go there.
Unfortunately, the same all-or-nothing service binding approach goes for DNS, SSH, admin ports, pretty much everything else running on the router.
You just can't bind both OLSR and ISC dhcpd to the same interface and still have dhcpd work and I thought it would be good to have that information available for others.
Still, this is good information, and I'm sure others will appreciate it. It just doesn't address the core issue at hand as far as I'm concerned - controlling the binding. It makes the entire product less flexible, can cost you more in terms of hardware and maintainance per site, "workarounds" make the network more complex and easier to break than necessary, and is generally a PITA.
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.
Bradg,
star-v3 does not include support for DHCP Relay, and going on about it's miss-features is not relevant to this thread.
If a service is able to bind to a specific interface(s), we will provide the option to do so if we find the feature is warranted.
I can tell you are trying to keep civil, and appreciate this. Please try not let this escalate in a negative fashion, or I may be forced to start pruning, which is not something I look forward too.
http://forums.star-os.com/showthread.php?t=5221
Thanks.
UPDATE:
Thread as been restarted in a sticky due to it's useful information. Please try and keep it on-topic.