Passing Interface Name to Event Script

[Rick Solotke]

Hi Simon,

Thanks for your response.

Let me preface this by saying that I have decided that in my specific
case, it makes more sense to hard code different address ranges (still
in the same subnet) for dhcpd to assign to each interface, rather than
continuing to struggle with making this fully automatic.

>Rick Solotke wrote:

>>I have dhcpd running on a router with several network interfaces, 
>>all of which belong to the same subnet.  Because all interfaces 
>>belong to the same subnet, the Linux routing table is ambiguous (an 
>>address on the subnet is reachable via more than one interface).

>Hmm, interesting concept. You do realise that this fundamentally 
>violates the most basic rules of IP addressing don't you ? I'm 
>curious as to the reasons for needing this.

I'm trying to emulate something similar to a standard consumer home
router, where end devices are plugged into each of the router's
interfaces, and all addresses are on the same subnet.  I realize that
internally the "router" is most likely a 2-port (WAN and LAN) router
with the LAN side going to an embedded switch, but it seems like I
should be able to accomplish the same behavior with a Linux box.

>>  Consequently, once a DHCP transaction completes, the router and the 
>>new client are unable to communicate until a static route is added 
>>to the router's routing table.

>Correct.

>>This route specifies the specific IP address of the client and the 
>>interface on which that address is accessible (e.g. route add 
>>192.168.1.10 dev eth0).  If I manually enter the route at the 
>>command line, the router and client are then able to communicate 
>>happily.
>>
>>I'd like to automate this process, so that as soon as the DHCP 
>>transaction occurs, the static route is automatically added.  The 
>>dhcpd COMMIT event seems to be the right place to do this, and I am 
>>able to make the IP address available to the script.  However, I see 
>>no way to make the interface name available to the script.  Without 
>>the interface name, the script is unable to add the static route.
>>
>>Any suggestions?

>Parse the logs ?

I had of course considered parsing the system log, because dhcpd does
print all the required information there, but that seems a bit too hacky
and destined for failure if/when the format of dhcpd's log messages
changes.

>>dhcpd obviously knows which interface the DHCP transaction occurred on

>Don't rely on that !

I have decided not to rely on this (see above), but to satisfy my
curiosity, what reasons did you have in mind as to why I should not rely
on dhcpd knowing on which interface a DHCP transaction occurs?

>Yes, when responding via broadcast, the server should respond using 
>the same physical interface that the request came in by, but when 
>responding by unicast I believe it simply sends a packet via the 
>kernel. In real terms this isn't a problem - if the host route is 
>lost, then the client presumably loses connectivity and being unable 
>to renew the DHCP lease until it's nearly run out and the client 
>reverts to broadcasts is likely to be the lease of your worries.


Thank you for your time an input.

Thanks,
Rick


-----Original Message-----
From: dhcp-users-bounces at lists.isc.org
[mailto:dhcp-users-bounces at lists.isc.org] On Behalf Of Simon Hobson
Sent: Saturday, November 14, 2009 8:53 AM
To: Users of ISC DHCP
Subject: Re: Passing Interface Name to Event Script

Rick Solotke wrote:

>I have dhcpd running on a router with several network interfaces, 
>all of which belong to the same subnet.  Because all interfaces 
>belong to the same subnet, the Linux routing table is ambiguous (an 
>address on the subnet is reachable via more than one interface).

Hmm, interesting concept. You do realise that this fundamentally 
violates the most basic rules of IP addressing don't you ? I'm 
curious as to the reasons for needing this.

>  Consequently, once a DHCP transaction completes, the router and the 
>new client are unable to communicate until a static route is added 
>to the router's routing table.

Correct.

>This route specifies the specific IP address of the client and the 
>interface on which that address is accessible (e.g. route add 
>192.168.1.10 dev eth0).  If I manually enter the route at the 
>command line, the router and client are then able to communicate 
>happily.
>
>I'd like to automate this process, so that as soon as the DHCP 
>transaction occurs, the static route is automatically added.  The 
>dhcpd COMMIT event seems to be the right place to do this, and I am 
>able to make the IP address available to the script.  However, I see 
>no way to make the interface name available to the script.  Without 
>the interface name, the script is unable to add the static route.
>
>Any suggestions?

Parse the logs ?

>dhcpd obviously knows which interface the DHCP transaction occurred on

Don't rely on that !

Yes, when responding via broadcast, the server should respond using 
the same physical interface that the request came in by, but when 
responding by unicast I believe it simply sends a packet via the 
kernel. In real terms this isn't a problem - if the host route is 
lost, then the client presumably loses connectivity and being unable 
to renew the DHCP lease until it's nearly run out and the client 
reverts to broadcasts is likely to be the lease of your worries.

-- 
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.
_______________________________________________
dhcp-users mailing list
dhcp-users at lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users