PXEBOOT confsued by dhcrelay -- two gids ?

[Robinson Tiemuqinke]

David,

 Thanks a lot.. You are one of the greatest geniuses
I've ever met.

 my dhcrelay has only one NIC and I don't want to mess
around with mangle iptables.

 So my workaround is pretty stupid but works: I just
fire up the dhcpd service on orignal dhc relay server
with exactly the same dhcpd.conf configuration file
copied from orignal central server, Because the router
blocks dhcpd traffic, I don't need to concern that the
clients will receive reply from wrong server.

And if we change the network topology or enable dhc
traffic on routers in the future, I can just shut down
the dhcpd service on orignal dhc relay server one
minute before that.

It is quite stupid but as you said, I have no way -- I
got hundreds of these crappy pxeboot clients and I
don't like the idea to burn NIC firmware with floppies
after powering off machines one by one(Does Linux
supports firmware-burning on-line?? ). Nevetheless,
after three years these machines will be phased out
and probably are sent to somewhere I have never heard
before.

Thanks again for figuring out my problem so precisely
and quickly.



--- "David W. Hankins" <David_Hankins at isc.org> wrote:

> Ah, I understand the problem now.
> 
> The relay is leaving giaddr set to itself (what the
> server set it to),
> and pxeboot is ignoring the routers option in favor
> of the giaddr.
> 
> 
> In RFC1542, section 3.4, we find this text:
> 
>       DISCUSSION:
> 
>          The semantics of the 'giaddr' field were
> poorly defined.
>          Section 7.5 of [1] states:
> 
>            "If 'giaddr' (gateway address) is
> nonzero, then the packets
>            should be forwarded there first, in order
> to get to the
>            server."
> 
>    In that sentence, "get to" refers to
> communication from the client to
>    the server subsequent to the BOOTP exchange, such
> as a TFTP session.
>    Unfortunately, the 'giaddr' field may contain the
> address of a BOOTP
>    relay agent that is not itself an IP router
> (according to [1],
>    Section 8, fifth paragraph), in which case, it
> will be useless as a
>    first-hop for TFTP packets sent to the server
> (since, by definition,
>    non-routers don't forward datagrams at the IP
> layer).
> ...
>    To reach a non-local server, clients can obtain a
> first-hop router
>    address from the "Gateway" subfield of the
> "Vendor Information
>    Extensions" [2] (if present), or via the ICMP
> router discovery
>    protocol [5] or other similar mechanism.
> 
> 
> Have you already taken this up with the pxeboot
> people?
> 
> Looking again at RFC1542 section 4.1.2:
> 
>          All BOOTP fields MUST be preserved intact. 
> The relay agent
>          MUST NOT modify any BOOTP field of the
> BOOTREPLY message when
>          relaying it to the client.
> 
> What you want I guess is a way to set giaddr on
> BOOTREPLY for these
> older clients...precisely what that says you can't.
> 
> But in practice that shouldn't be dangerous, so I
> don't know why it
> says that except no one probably thought of it at
> the time.
> 
> But there's no way to do it right now...no option
> you can set to get
> this behaviour that I'm aware of.
> 
> 
> The only real workaround I can see from my end of
> the problem is to
> setup your relay box to ip forward.
> 
> But the pxeboot people might have better news.
> 
> -- 
> David W. Hankins		"If you don't do it right the
> first time,
> Software Engineer			you'll just have to do it
> again."
> Internet Systems Consortium, Inc.		-- Jack T.
> Hankins
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com