bearer
Posts: 1
Joined: Thu Jun 13, 2019 9:05 pm

Multiple DHCP leases on wlan0

Thu Jun 13, 2019 9:38 pm

Trying to add an alias wlan0:0 with its own hostname and a IP address allocated by DHCP.

I've tried adding

Code: Select all

interface wlan0:0
hostname_short mqtt
clientid mqtt
to /etc/dhcpcd.conf

and

Code: Select all

iface wlan0:0 inet dhcp
  hostname mqtt
to /etc/network/interfaces.d/wlan00 (with and without the last hostname line). But dhcpc doesn't seem to send the clientid, only the hostname. I.e. my udhcpd server shows an updated lease, with the same MAC, same clientid but new hostname after wlan0:0 is up

I've also tried the macvlan method described online. But this results in the router seeing the DHCP request with the virtual MAC address and offering a lease that the pi never receives. (Confirmed with tcpdump, and ifconfig shows PROMISC is set):

Code: Select all

iface vir1 inet dhcp
    hostname vir1-hostname
    pre-up ip link set dev wlan0 promisc on && ip link add link wlan0 address 02:cd:ab:00:10:01 vir1 type macvlan
    post-down ip link delete vir1

Code: Select all

[email protected]:~ $ sudo ifup vir1
Internet Systems Consortium DHCP Client 4.3.5
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/vir1/02:cd:ab:00:10:01
Sending on   LPF/vir1/02:cd:ab:00:10:01
Sending on   Socket/fallback
DHCPDISCOVER on vir1 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on vir1 to 255.255.255.255 port 67 interval 19
DHCPDISCOVER on vir1 to 255.255.255.255 port 67 interval 19
DHCPDISCOVER on vir1 to 255.255.255.255 port 67 interval 9
DHCPDISCOVER on vir1 to 255.255.255.255 port 67 interval 7
No DHCPOFFERS received.
No working leases in persistent database - sleeping.
tcpdump from pi

Code: Select all

[email protected]:~ $ sudo tcpdump -i wlan0:0 -n port 67 and port 68
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0:0, link-type EN10MB (Ethernet), capture size 262144 bytes
22:25:21.037356 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 02:cd:ab:00:10:01, length 300
22:25:21.516977 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 02:cd:ab:00:10:01, length 329
22:25:25.992244 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 02:cd:ab:00:10:01, length 329
22:25:27.898558 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 02:cd:ab:00:10:01, length 300
22:25:33.792148 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 02:cd:ab:00:10:01, length 329
22:25:46.061500 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 02:cd:ab:00:10:01, length 300
22:25:49.532570 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 02:cd:ab:00:10:01, length 329
22:26:05.664541 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 02:cd:ab:00:10:01, length 300
22:26:14.483227 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 02:cd:ab:00:10:01, length 300
22:26:22.186928 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 02:cd:ab:00:10:01, length 329
^C
10 packets captured
10 packets received by filter
0 packets dropped by kernel
tcpdump from router

Code: Select all

[email protected]:~# tcpdump -i eth0.2 -n port 67 and port 68
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0.2, link-type EN10MB (Ethernet), capture size 262144 bytes
21:25:21.088651 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 02:cd:ab:00:10:01, length 300
21:25:24.102452 IP 10.10.0.1.67 > 10.10.0.211.68: BOOTP/DHCP, Reply, length 300
21:26:05.676492 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 02:cd:ab:00:10:01, length 300
21:26:08.692812 IP 10.10.0.1.67 > 10.10.0.211.68: BOOTP/DHCP, Reply, length 300
21:26:14.494457 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 02:cd:ab:00:10:01, length 300
21:26:14.501126 IP 10.10.0.1.67 > 10.10.0.211.68: BOOTP/DHCP, Reply, length 300
21:26:22.197721 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 02:cd:ab:00:10:01, length 329
21:26:22.210059 IP 10.10.0.1.67 > 10.10.0.211.68: BOOTP/DHCP, Reply, length 300
^C
8 packets captured
9 packets received by filter
0 packets dropped by kernel
I installed udhcpc on the pi and ran sudo udhcpc -i wlan0:0 -x hostname:mqtt and besides the udhcpc script messing up the ip configuration for wlan0 the router did receive the requst with identical MAC address, new hostname and successfully issued a new lease in adittion to the old. After some quick changes to /etc/udhcpc/default.script and its route handling)

While the workaround kinda works, it would be preferable to use standard software and config files rather than relying on udhcpc and custom scripts.

Any suggestions as to why the former methods have failed?

epoch1970
Posts: 2806
Joined: Thu May 05, 2016 9:33 am
Location: Paris, France

Re: Multiple DHCP leases on wlan0

Fri Jun 14, 2019 9:01 am

The main problem comes from the fact you're using a wifi interface. Adding a MAC via a macvlan bridge is not going to work, because either the wifi hardware or the wifi protocol will not support that.
What you'd normally do is create a virtual STA interface, eg wlan1, and connect it to the wifi network. The wifi hardware in Pi does not support virtual STA interfaces AFAIK, so that's that.

If you want the feel of a virtual interface over wlan0, you can use an ipvlan device, mode "l2 bridge". It has the same MAC as the underlying interface, as the name implies. It could work with DHCP assuming you manage to send a different ID and your server is ok with that. Such an interface is unable to authenticate itself on wifi, you can't use it to control the "real" wifi interface via, e.g. iw, so it is, by and large, powerless and useless.

Next, an alias like eth0:0 represents actually an IP alias, aka a secondary IP address, not a virtual interface. It is an ifupdown concept made to fit the design of the interfaces file, that is why it looks like an interface. In modern times, you'd simply use "ip address add ... dev eth0" as many times as you'd want, giving you multiples addresses. An IP alias has nothing to do with the MAC address of the original interface, so DHCP is not going to work over it unless you tweak both client and server.

With DHCP clients, YMMV. I've seen ifup do strange things when calling the DHCP client, so I'd steer clear of the interfaces file and try various DHCP clients directly from the command-line until a working formula is found.
Dhcpcd, the standard DHCP client in Raspbian is not the worst client you can find, for sure. It has support for custom scripting like ifupdown has had, it handles netlink events from the kernel so it is dynamic. You can run an instance from the command-line, I suggest you try it.
If dhcpcd works for you, I would next suggest ditching the interfaces file unless you have very good reasons not to. ifupdown was doing ok with sysVinit/init.d but it does not mix well with systemd and dynamic interface management. Ifupdown has no future, use it only if you know why.
"S'il n'y a pas de solution, c'est qu'il n'y a pas de problème." Les Shadoks, J. Rouxel

Return to “Networking and servers”