Passing Interface Name to Event Script

Rick Solotke RSolotke at
Mon Nov 16 21:51:15 UTC 2009

Simon and Jeff,

Thanks to both of you for the bridging suggestion.  I have used the
Linux Ethernet bridge in the past, but hadn't even considered it in this
situation.  The end devices connected to the router in this setup are
custom devices that appear to be sensitive to receiving unexpected
traffic.  I believe that with bridging, there will be circumstances when
packets will be forwarded out every bridge interface (prior to the
bridge learning which port to use for a given address).  However, this
still seems worth investigating, as it may simplify the setup.

Thanks again for the help.


-----Original Message-----
From: dhcp-users-bounces at
[mailto:dhcp-users-bounces at] On Behalf Of Simon Hobson
Sent: Monday, November 16, 2009 12:40 PM
To: Users of ISC DHCP
Subject: RE: Passing Interface Name to Event Script

Rick Solotke wrote:

>  >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.

I had a suspicion it might be something like that - and multiple 
interfaces like you are playing with won't work - not without a LOT 
of work to handle all the broadcast stuff that clients need in order 
for the network to run. Fortunately, the Linux networking guys have 
already done that for you in the bridging module (as Jeff has pointed 

Just install the bridge-utils package - this gives you the brctl 
command. Then you can do :

brctl addbr br0
ip link set eth0 up
brctl addif br0 eth0
ip link set eth1 up
brctl addif br0 eth1
ip link set eth2 up
brctl addif br0 eth2

then 'ifconfig' your IP configuration onto br0. Of course, you can 
normally do this in the distribution network scripts, eg in Debian 
you would declare br0 as your interface in /etc/network/interfaces, 
and add :

pre-up brctl addbr br0
pre-up ip link set eth0 up
pre-up brctl addif br0 eth0
pre-up ip link set eth1 up
pre-up brctl addif br0 eth1
pre-up ip link set eth2 up
pre-up brctl addif br0 eth2

to it's config section - then as the system boots, it will 
automatically create the bridge, attach some interfaces to it, and 
bring up an IP interface on the bridge. It works "quite nicely" and 
avoids all the problems you'd found (and not found yet !).

PS - the bridging defaults to 15s STP learning time on bridge ports, 
you may want to tune that as it means no traffic through each port 
for 15s after it's been brought up (or a cable plugged in).

PPS - that's (mostly) done from memory, so you may want to look for a 
howto appropriate for your distribution and cross check.

>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
>on dhcpd knowing on which interface a DHCP transaction occurs?

In the case of unicast packets, I was under the impression that dhcpd 
simply passed a packet to the Linux kernel and let it handle the 
routing. Clients normally use unicast for mid-lease renewals - though 
in that case, they should still have a host route that would get the 
packet back to them.
Simon Hobson

Visit 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

More information about the dhcp-users mailing list