dhcp-relay over tun interface - solution?
Shane Kerr
shane at isc.org
Mon Jan 13 15:04:07 UTC 2014
Stefan,
On Fri, 3 Jan 2014 13:14:12 +0100
Stefan Bauer <stefan.bauer at cubewerk.de> wrote:
> -----Ursprüngliche Nachricht-----
> Von: Shane Kerr <shane at isc.org>
> > Hm... it looks like the --enable-use-sockets option is currently
> > broken. :(
> >
> > The attached patch should fix the build, but it is not a proper
> > solution.
>
> Hi Shane,
>
> thank you for your time. I can now build with your patch but trying
> to use it results in:
>
> root at srv1:~# ./dhcrelay -d -i tun0 10.8.0.5
> Internet Systems Consortium DHCP Relay Agent 4.2.5-P1
> Copyright 2004-2013 Internet Systems Consortium.
> All rights reserved.
> For info, please visit https://www.isc.org/software/dhcp/
> Unsupported device type 65534 for "tun0"
>
> exiting.
> root at srv1:~#
>
Hm...
This error message comes from common/lpf.c:
sa = &tmp.ifr_hwaddr;
switch (sa->sa_family) {
.
.
.
default:
log_fatal("Unsupported device type %ld for \"%s\"",
(long int)sa->sa_family, name);
}
The 65534 value looks to be this:
#define ARPHRD_NONE 0xFFFE /* zero header length */
This value (sa_family) comes from an ioctl(..., SIOCGIFHWADDR, ...)
call.
Looking at the kernel source:
http://lxr.free-electrons.com/source/drivers/net/tun.c
We see:
case SIOCGIFHWADDR:
/* Get hw address */
memcpy(ifr.ifr_hwaddr.sa_data, tun->dev->dev_addr, ETH_ALEN);
ifr.ifr_hwaddr.sa_family = tun->dev->type;
if (copy_to_user(argp, &ifr, ifreq_len))
ret = -EFAULT;
break;
The logic appears to basically have been the same since the 2.6.32
kernel at least.
So... what does this mean? It looks like the tunnel is not providing a
hardware address. Can you please confirm this by trying one of these:
$ ip addr show dev tun0
$ /sbin/ifconfig tun0
If they are missing a hardware address then that is indeed the problem,
and frankly I'm not sure how to work around it. Otherwise, we can
probably come up with something. :)
Cheers,
--
Shane
More information about the dhcp-hackers
mailing list