Hi,

dhcrelay segfaults on first incoming packet if the client-facing
interface has a label on its IP address

Steps to reproduce:

Have Debian box with two interfaces, two networks 192.168.0.0/24 and
10.0.0.0/24.

ip link set dev eth0 up
ip link set dev eth1 up
ip addr add dev eth0 192.168.0.254/24 brd +
ip addr add dev eth1 10.0.0.1/24 brd + label eth1:foo
ip addr
50: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether 00:25:b3:01:c6:d0 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.254/24 brd 192.168.0.255 scope global
51: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether 00:25:b3:01:c6:d0 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.1/24 brd 10.0.0.255 scope global eth1:foo
dhcrelay -d -i eth0 -i eth1 192.168.0.1
(it is not necessary to have a DHCP server on 192.168.0.1)
have a client connected to 10.0.0.1 send a DHCP request

dhcrelay segfaults in dhcrelay.c line 660

backtrace:
$ gdb /usr/sbin/dhcrelay core
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/sbin/dhcrelay...Reading symbols from /usr/lib/debug/usr/sbin/dhcrelay...done.
(no debugging symbols found)...done.

warning: Can't read pathname for load map: Input/output error.
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libnss_files.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libnss_files.so.2
Core was generated by `dhcrelay -d -i eth0 -i eth1 192.168.0.1'.
Program terminated with signal 11, Segmentation fault.
#0  0x0804c5f8 in do_relay4 (ip=0x80aa560, packet=0xbfe2d768, length=300,
    from_port=17408, from=..., hfrom=0xbfe2e77e) at dhcrelay.c:660
660     dhcrelay.c: No such file or directory.
        in dhcrelay.c
(gdb) bt
#0  0x0804c5f8 in do_relay4 (ip=0x80aa560, packet=0xbfe2d768, length=300,
    from_port=17408, from=..., hfrom=0xbfe2e77e) at dhcrelay.c:660
#1  0x08053923 in got_one (h=0x80aa560) at discover.c:1393
#2  0x0807dd22 in omapi_one_dispatch (wo=0x0, t=0x0) at dispatch.c:520
#3  0x08055718 in dispatch () at dispatch.c:92
#4  0x0804ad56 in main (argc=7, argv=0xbfe2ecb4) at dhcrelay.c:549
(gdb)

   654          /* If giaddr is not already set, Set it so the server can
   655             figure out what net it's from and so that we can later
   656             forward the response to the correct net.    If it's already
   657             set, the response will be sent directly to the relay agent
   658             that set giaddr, so we won't see it. */
   659          if (!packet->giaddr.s_addr)
   660                  packet->giaddr = ip->addresses[0];
   661          if (packet->hops < max_hop_count)
   662                  packet->hops = packet->hops + 1;
   663          else
   664                  return;

Greetings
Marc

This bugs makes it impossible to set a dhcp relay on a vlan interface.

tags 617258 + moreinfo
thanks

Could you provide some instructions on how to reproduce with 4.2.4?

I wasn't able to reproduce it using a VLAN interface of eth1.1

tags 617258 + unreproducible
thanks

Thanks for the detailed reproduction instructions.

I've been unable to reproduce this with 4.2.4. Can you?

Hi Andrew,

sorry for taking so long to reply.

The bug has changed. dhcrelay does not crash any more, but it does
also not work.

root@testkiste:/home/mh# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
    link/ether 52:54:00:24:af:60 brd ff:ff:ff:ff:ff:ff
root@testkiste:/home/mh# ip link set dev eth0 up
root@testkiste:/home/mh# ip addr add dev eth0 192.168.18.23/24 brd + label eth0:foo
root@testkiste:/home/mh# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:54:00:24:af:60 brd ff:ff:ff:ff:ff:ff
    inet 192.168.18.23/24 brd 192.168.18.255 scope global eth0:foo
    inet6 fe80::5054:ff:fe24:af60/64 scope link
       valid_lft forever preferred_lft forever
root@testkiste:/home/mh# dhcrelay -d -i eth0 -i eth0 192.168.18.100             Internet Systems Consortium DHCP Relay Agent 4.2.2
Copyright 2004-2011 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/eth0/52:54:00:24:af:60
Sending on   LPF/eth0/52:54:00:24:af:60
Listening on LPF/eth0/52:54:00:24:af:60
Sending on   LPF/eth0/52:54:00:24:af:60
Sending on   Socket/fallback
Discarding packet received on eth0 interface that has no IPv4 address assigned.
Discarding packet received on eth0 interface that has no IPv4 address assigned.

It is perfectly OK to have the only IP address on an Interface
labeled. dhcrelay does seem to explicitly check for that and to bail
if no unlabeled IP address is found. I think that behavior is wrong,
dhcrelay should just use a labeled IP address as if it were unlabeled.

The eth0:foo interface is working perfectly fine IP-wise; I actually
sshed in to the VM through that interface to be able to cut&paste the
typescript to this mail.

Please note that this is eth0:foo, not eth0.foo. The period notation
is not a label, it is an alias. I think _this_ works, the misbehavior
happens when a label (colon notation) is used.

Greetings
Marc

hi,

this is also an issue when using carp¹ to implement vrrp-like failover.

virtual interface(s) managed by the carp userspace daemon are named
$raw_device:carp by default (and by convention), using these interfaces to
relay dhcp requests with isc-dhcp-relay does not work:

root@router1:/home/thoralf# ip add show if172.2001
54: if172.2001@if172: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether a0:36:9f:1c:51:d3 brd ff:ff:ff:ff:ff:ff
    inet 172.20.1.1/24 brd 172.20.1.255 scope global if172.2001:carp
    inet6 fe80::a236:9fff:fe1c:51d3/64 scope link
       valid_lft forever preferred_lft forever
root@router1:/home/thoralf# ip add show if172.2011
58: if172.2011@if172: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether a0:36:9f:1c:51:d3 brd ff:ff:ff:ff:ff:ff
    inet 172.20.11.1/24 brd 172.20.11.255 scope global if172.2011:carp
    inet6 fe80::a236:9fff:fe1c:51d3/64 scope link
       valid_lft forever preferred_lft forever
root@router1:/home/thoralf# dhcrelay -4 -d -i if172.2011 -i if172.2001 172.20.1.30
Internet Systems Consortium DHCP Relay Agent 4.2.4
Copyright 2004-2012 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/if172.2001/a0:36:9f:1c:51:d3
Sending on   LPF/if172.2001/a0:36:9f:1c:51:d3
Listening on LPF/if172.2011/a0:36:9f:1c:51:d3
Sending on   LPF/if172.2011/a0:36:9f:1c:51:d3
Sending on   Socket/fallback
Discarding packet received on if172.2011 interface that has no IPv4 address assigned.
Discarding packet received on if172.2011 interface that has no IPv4 address assigned.
Discarding packet received on if172.2011 interface that has no IPv4 address assigned.
^C
root@router1:/home/thoralf

… as Marc already pointed out, dhcrelay does not crash anymore, but it is not
usable either. it works, however, if the interfaces are renamed:

root@router1:/home/thoralf# ip link set dev if172.2001 down && ip link set if172.2001 name if172_2001 && ip link set dev if172_2001 up && ip add show if172_2001
54: if172_2001@if172: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether a0:36:9f:1c:51:d3 brd ff:ff:ff:ff:ff:ff
    inet 172.20.1.1/24 brd 172.20.1.255 scope global if172_2001
    inet6 fe80::a236:9fff:fe1c:51d3/64 scope link tentative
       valid_lft forever preferred_lft forever
root@router1:/home/thoralf# ip link set dev if172.2011 down && ip link set if172.2011 name if172_2011 && ip link set dev if172_2011 up && ip add show if172_2011
58: if172_2011@if172: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether a0:36:9f:1c:51:d3 brd ff:ff:ff:ff:ff:ff
    inet 172.20.11.1/24 brd 172.20.11.255 scope global if172_2011
    inet6 fe80::a236:9fff:fe1c:51d3/64 scope link tentative
       valid_lft forever preferred_lft forever
root@router1:/home/thoralf# dhcrelay -4 -d -i if172_2011 -i if172_2001 172.20.1.30
Internet Systems Consortium DHCP Relay Agent 4.2.4
Copyright 2004-2012 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/if172_2001/a0:36:9f:1c:51:d3
Sending on   LPF/if172_2001/a0:36:9f:1c:51:d3
Listening on LPF/if172_2011/a0:36:9f:1c:51:d3
Sending on   LPF/if172_2011/a0:36:9f:1c:51:d3
Sending on   Socket/fallback
Forwarded BOOTREQUEST for 00:1e:37:cb:a6:6a to 172.20.1.30
Forwarded BOOTREPLY for 00:1e:37:cb:a6:6a to 172.20.11.10
^C
root@router1:/home/thoralf

… everything fine and dandy, vlan interfaces are not an issue.
anyway, changing the interface names on our production servers is next to
impossible - a lot of scripts depend on the :carp suffix to figure out what
should happen with certain interfaces in case a router goes down or comes up.
and i'm not sure if carp would work anymore if the suffix is omitted.

to make things worse, i was not able to get dhcp-helper to work with vlan
interfaces, either.

with kind regards,
thoralf.

Dear submitter,

as the package isc-dhcp has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/1143544

The version of this package that was in Debian prior to this removal
can still be found using https://snapshot.debian.org/.

Please note that the changes have been done on the master archive and
will not propagate to any mirrors until the next dinstall run at the
earliest.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Thorsten Alteholz (the ftpmaster behind the curtain)