No Offer Sent by DHCP Relay

[Josh]

Simon Hobson wrote:
> Josh wrote:
>   
>> I am having a problem getting dhcrelay to broadcast a DHCP offer from an
>> upstream DHCP server to clients.  I am running DHCP 3.0.3.
>>
>> My network setup is as follows (for a picture representation, see
>> http://pekster.myftp.org/josh/dhcp_relay.png )
>>
>> Clients that should pick up a 192.168.101.x address send a DHCP Discover
>> broadcast which is picked up by a DHCP relay agent on 192.168.101.1 (as
>> eth0.)  This device has another interface (called tun_fv) with IP
>> 192.168.105.5.  The DHCP relay agent relays this to 192.168.10.9 through
>> the tun_fv interface
>>     
>
>   
>> Any help would be appreciated.  On a final note, when I start dhcrelay,
>> I get this message in the system logging facility: "dhcrelay: tun_fv:
>> unknown hardware address type 65534".
>>     
>
>
> This came up a little while ago, except I think in that case it was a 
> PPP interface. In it's current design, the relay agent does not work 
> with interfaces that don't support a broadcast mode. Ethernet is 
> fine, ppp (and I assume tun) interfaces aren't.
>
> Do you have any other machine on the client network you could run the 
> relay agent on ? It can be on any machine, not just a router.
>   
At this point we have only the router (also the VPN machine) and clients
on the remote subnet.  We could deploy a separate workstation to act as
the DHCP relay, but would really rather not do that if there is any
other option.

If possible, can I get clarification on what problem the point-to-point
tun adapter poses?  From what I see, the tun adapter is both passing the
DHCP discover to the real DHCP server and receiving it back.  Here's
what I see with tcpdump from the remote gateway machine (eth0 is the
physical LAN link and tun_fv is the remote point-to-point IP link):

tcpdump -n -i eth0 udp port 67 or 68
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 68 bytes
11:02:53.479707 IP 192.168.101.52.68 > 192.168.101.1.67: BOOTP/DHCP,
Request [|bootp]
11:02:57.877462 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request
[|bootp]
11:03:00.871784 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request
[|bootp]
11:03:09.869481 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request
[|bootp]
11:03:25.867297 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request
[|bootp]

tcpdump -n -i tun_fv udp port 67 or 68
tcpdump: WARNING: arptype 65534 not supported by libpcap - falling back
to cooked socket
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun_fv, link-type LINUX_SLL (Linux cooked), capture size 68
bytes
11:02:53.480041 IP 192.168.105.5.67 > 192.168.10.9.67: BOOTP/DHCP,
Request [|bootp]
11:02:57.877642 IP 192.168.105.5.67 > 192.168.10.9.67: BOOTP/DHCP,
Request [|bootp]
11:03:00.580188 IP 192.168.10.9.67 > 192.168.101.1.67: BOOTP/DHCP,
Reply, length: 302
11:03:00.871820 IP 192.168.105.5.67 > 192.168.10.9.67: BOOTP/DHCP,
Request [|bootp]
11:03:00.917756 IP 192.168.10.9.67 > 192.168.101.1.67: BOOTP/DHCP,
Reply, length: 302
11:03:09.869544 IP 192.168.105.5.67 > 192.168.10.9.67: BOOTP/DHCP,
Request [|bootp]
11:03:09.907240 IP 192.168.10.9.67 > 192.168.101.1.67: BOOTP/DHCP,
Reply, length: 302
11:03:25.867344 IP 192.168.105.5.67 > 192.168.10.9.67: BOOTP/DHCP,
Request [|bootp]
11:03:25.905149 IP 192.168.10.9.67 > 192.168.101.1.67: BOOTP/DHCP,
Reply, length: 302

As I'm reading that, the tun interface is passing the DHCP request to
the DHCP server and receiving a response as expected.  I'm just confused
as to how the p-t-p link is the cause of this problem.  Since the return
DHCP offer comes to the 192.168.101.1 address, what's preventing
dhcrelay from sending it on back to the client from that same address?

If there is no good way around this issue, are there any other DHCP
relay options available for Linux that allow relaying over
point-to-point IP-level links?  Something along the lines of the Cisco
"ip-helper" option is exactly what we're looking for.

Thanks.

-- 
Josh