[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: know any neat tricks for 2 * dhclient?
- To: misc_(_at_)_openbsd_(_dot_)_org
- Subject: Re: know any neat tricks for 2 * dhclient?
- From: Graham Toal <gtoal_(_at_)_gtoal_(_dot_)_com>
- Date: Wed, 26 Oct 2005 15:05:49 -0500
- Cc: gtoal_(_at_)_pizzabox_(_dot_)_gtoal_(_dot_)_com
> It *ought* to be possible to configure both hostname.xl0 and hostname.fxp1
> as dhcp, and whichever one comes up first, will then bridge through the
> DHCP server for the other. Unfortunately it just happens by luck of
> alphabetical order, that the one which comes up first is *not* looking
> at a DHCP server. So after a relatively short period of retries it
> goes to sleep. Then the other interface asks for its dhcp address and
> gets it quickly. What I expected was that the first would sleep for a
> short time then ask again, and get it OK. I haven't seen that happen -
> about 30 minutes later and the interface still has no IP.
I was thinking when I posted this that the problem was that the
interfaces picked up IP addresses in the wrong order. That would
be true if we were routing from one to the other, but in fact I've
just realised that the real problem is that the interfaces are brought
up *before the bridging is turned on*. So naturally only one
of them will be facing a DHCP server. The other one should only get
its IP address *after* the bridging is enabled. It never does.
I think the problem may be a misunderstanding of dhclient. Why is it not
retrying? The man page doesn't give any clues. It *is* still running, as
can be seen from ps. I'm not accidentally blocking it with pf as my
pf.conf allows everything from anywhere to anywhere! Do I have to do
something special to make dhclient wake up? (Yes, I know I can manually
kill it and re-issue the command, and I can even automate it by writing
a script to grep ifconfig -A, find the interface that has no IP, look
for the dhclient for that interface, kill it and restart it - but as I
said I'm looking for a guru-level elegant solution, not a crude hack...)
Or might this be one of these bridging problems where the packets
are going out on the wrong interface...? (thinking aloud as I type here...)
OK, I'll go do some tcpdumping.
Assuming that the problem turns out to be that the dhcp request for
fxp1 is always routed out of fxp1 (makes sense, right?) what can I do
to have it routed out the other interface via bridging? (Remembering
that the solution has to work symmetrically, if in some other deployment
it is the other of the two interfaces which can't see the DHCP server...)