Need Two IPs (using wlan0 interface) but do not have any control over static allocations

Question

Brief:

In a previous question I asked whether multiple IPs can be assigned via DHCP and reserved by a single Raspberry Pi. The accepted answer demonstrates how to achieve this by setting up virtual network interfaces linked to eth0 and assigning a unique MAC address to the interface.

When I attempt the same steps using wlan0 instead of eth0 I get IPs allocated on the 192.254.x.x subnet, which suggests there is an issue reaching the DHCP server.

Is there a reason this process would work for eth0 but not wlan0?

Details:

I start by loading the latest Raspbian image onto my Raspberry Pi (Buster 2021-01-11).

I create a file /etc/network/interfaces.d/eth0 and write the following:

auto eth0
iface eth0 inet manual
  up ip link add link eth0 name eth0.01 address 02:00:00:00:00:01 type macvlan
  up ip link add link eth0 name eth0.02 address 02:00:00:00:00:02 type macvlan

I create a file /etc/network/interfaces.d/wlan0 and write the following:

auto wlan0
iface wlan0 inet manual
  up ip link add link wlan0 name wlan0.01 address 02:00:00:00:00:A1 type macvlan
  up ip link add link wlan0 name wlan0.02 address 02:00:00:00:00:A2 type macvlan

These settings are applied with the command:

sudo systemctl restart networking

Let's WiFi tether to an Android cell phone. Hopefully this is an easily repeatable setup; it implements a DHCP server at 192.168.43.1/24 using netd to handle the tethering using dnsmasq. To try to keep things comparable between the eth0 and wlan0 interface I use a DLink WiFi extender to wirelessly tether to the Android's WiFi Hotspot and forward a WiFi signal to the Raspberry Pi's wlan0 and an ethernet cable to connect to the Raspberry Pi's eth0 interfaces.

I use the following command to see what my IP addresses are for each interface:

ifconfig

Here is a summary of the lines of code that are of interest:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.43.233  netmask 255.255.255.0  broadcast 192.168.43.255
eth0.01: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.43.41  netmask 255.255.255.0  broadcast 192.168.43.255
eth0.02: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.43.54  netmask 255.255.255.0  broadcast 192.168.43.255
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.43.76  netmask 255.255.255.0  broadcast 192.168.43.255
wlan0.01: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 169.254.36.195  netmask 255.255.0.0  broadcast 169.254.255.255
wlan0.02: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 169.254.75.246  netmask 255.255.0.0  broadcast 169.254.255.255

It is clear that the wlan0.01 and wlan0.02 interfaces are not communicating with the DHCP server (as seen by the IPs starting with 169.254), whereas the eth0.01 and eth0.02 interfaces are.

Can I reserve two IPs via the wlan0 interface?

it's odd, you said in a comment on my other answer that you Just tested and it also works for wlan0 - I tried and I got the same issue as you describe here - DHCP not working on the extra wlan interfaces - I would highly recommend for anything but the standard "mom and pop" or "kids toy" setup that you switch to using systemd-networkd - far greater control for such exotic requirements - I'm in the process of doing just that for nice simple vlan and wireguard setup — Jaromanda X, Feb 07 '21 at 06:16
these commands ip link add link eth0 name eth0.01 address 02:00:00:00:00:01 type macvlan etc could be used in a systemd service that you configure - thereby removing the need to touch /etc/network at all - something I realised after posting that answer :p — Jaromanda X, Feb 07 '21 at 06:20
When I saw IPs being allocated on 169.154.x.x I didn't know at the time that would be inaccessible to the network. In this sense, it also works means the method assigns a unique IP to the network interface. Unfortunately it doesn't provide one that is ping-able from outside the Raspberry Pi. I hope this clarifies. I am going to read up on systemd-networkd as you suggest. — Insert name here, Feb 07 '21 at 06:25
it's worth noting that when you use the method you accepted for wlan0, the interface does get a valid ipv6 address - so there's probably something you can do in dhcpcd.conf — Jaromanda X, Feb 07 '21 at 06:38
The valid IPv6 thing sounds hopeful (possibly). However, I wouldn't know what things to look into or which questions to ask. — Insert name here, Feb 07 '21 at 07:14
I gave systemd-networkd a go. Works for eth0, but not wlan0. I suspect the core issue is something that happens inside the brcmfmac driver, as opposed to the Debian networking side of things. This is pure conjecture; there are a large number of different parts of the system where the wlan packet might be dropped and I don't have the expertise to track down exactly where this occurs. — Insert name here, Feb 07 '21 at 12:08
I've read your answer, and now I understand why my answer for a similar question, but one where the IP addresses are static actually works for wlan, since you don't need a "fake" MAC for that — Jaromanda X, Feb 07 '21 at 12:45
I have tried to achieve the same thing using scapy (Python library) from a Windows PC (i.e. Raspberry Pi completely out of the equation). DHCP REQUEST messages with 'fake' MAC addresses are ignored when sent via WiFi. It makes sense from a security perspective why wlan0 and eth0 would be treated differently. — Insert name here, Feb 07 '21 at 22:24
There's a limit to how man macvlan you can add to ethernet interface too, obviously the limit on wlan is 1 and ethernet is generally something more than 1 — Jaromanda X, Feb 07 '21 at 22:34

score 1 · Answer 1 · answered Feb 07 '21 at 11:58

Starting with the question:

Is there a reason this process would work for eth0 but not wlan0?

There is a difference in how the eth0 interface treats packets compared to wlan0. A comment on a blog post poses a plausible explanation:

I read somewhere that wireless doesn't work because frames coming in are then found to have a 'wrong' mac address. The frames contain a mac address of the physical device but appear to have come in through the macvlan's mac address. This is seen as suspicious and the frame gets dropped.

I tried to solve the problem systemd-networkd style networking. However, much of my experience was the same as what you can see in the original question where /etc/network/interface.d/ is used. That is, macvlan interfaces worked with eth0 without too much difficulty, but macvlan interfaces do not play well with wlan0.

To answer the underlying problem:

Can I reserve two IPs via the wlan0 interface?

The short answer is:

Yes

However, the solution I found is not great. I couldn't add any more than a single virtual interface. It appears to be sensitive to the name given to the virtual interface. It appears to be sensitive to the MAC address given to the interface. It has even been observed to drop out. I would not recommend as a permanent solution.

Assuming you already have set up your WiFi, copy/rename the wifi configuration information:

sudo cp /etc/wpa_supplicant/wpa_supplicant.conf /etc/wpa_supplicant/wpa_supplicant-wlan0.conf

Disable networking and dhcpcd and enable systemd-networkd:

sudo systemctl enable systemd-networkd
sudo systemctl disable dhcpcd
sudo systemctl disable networking
sudo systemctl enable systemd-resolved.service
sudo systemctl disable wpa_supplicant.service
sudo systemctl enable wpa_supplicant@wlan0.service

Create file /etc/systemd/network/wlan0.network:

[Match]
Name=wlan0
[Network]
DHCP=ipv4
MACVLAN=vlan0
LinkLocalAddressing=no

Create file /etc/systemd/network/vlan0.network:

[Match]
Name=vlan0
[Network]
DHCP=yes
LinkLocalAddressing=no

Create file /etc/systemd/network/vlan0.netdev:

[NetDev]
Name=vlan0
Kind=macvlan
MACAddress=2e:d5:1e:d7:a9:4f
[MACVLAN]
Mode=passthru

Apply the settings and view the IP address settings

systemctl restart systemd-networkd ; sleep 2 ; ip a

It can be seen that two wlan0 IPs are present, both are ping-able from the wider network:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether b8:27:eb:4e:c3:b6 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:eb:1b:96:e3 brd ff:ff:ff:ff:ff:ff
    inet 192.168.43.78/24 brd 192.168.43.255 scope global dynamic wlan0
       valid_lft 3318sec preferred_lft 3318sec
4: vlan0@wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether b8:27:eb:1b:96:e3 brd ff:ff:ff:ff:ff:ff
    inet 192.168.43.76/24 brd 192.168.43.255 scope global dynamic vlan0
       valid_lft 3318sec preferred_lft 3318sec

Repeating with eth0 instead of wlan0 works without issue. It even lets you add multiple macvlan interfaces.

Here are my sources: link link link link link link link link

Milliways · Answer 2 · 2021-02-07T05:18:22.017

0

This is an XY problem.

You have decided (for whatever reason) that you "need" multiple IP addresses for the same interface and are diving more deeply into that rabbit hole (mixing incompatible networking systems without understanding either).

It may be possible to achieve your primary goal, but first you have to clearly define exactly what you are trying to achieve - you certainly won't by mixing Debian networking and dhcpcd.

NOTE you are further complicating your problem by using the deprecated ifconfig rather than ip a.

edited Feb 07 '21 at 05:18

answered Feb 07 '21 at 05:06

Milliways

59,890
31
101
209

In stating "mixing incompatible networking systems without understanding either", it would appear you have some insight that a lack of understanding is occurring. Would you have any recommendations for where one could start the journey to attain this understanding in a structured manner? – Insert name here Feb 07 '21 at 06:10
There is extensive documentation on both - including the man pages. How to set up networking/WiFi is a start and has a number of links to more extensive documentation, but the bottom line is you have to pick a network manager and stick to it. You have 2 network managers (admittedly Debian networking has limitations which is why it is rarely used) operating at the same time. – Milliways Feb 07 '21 at 06:19
It is clear from reading through Stack Exchange posts that there are different networking systems available on the Raspberry Pi. Please note that (1) how many there are; (2) which is preferred; (3) which are deprecated; and (4) which particular source files (and their associated man pages) belong to which system; is not always clear to me. The link you provided looks like an excellent place to start; I would not have known that this post from 5 years ago was still relevant without your recommendation. – Insert name here Feb 07 '21 at 06:58
1

@Insertnamehere About the available networking systems you may have a look at Compare three available networking systems on Raspbian. Then you should decide what to use (I prefer systemd-networkd), and then only use that. By the way, I haven't understand what you're really trying to achieve. – Ingo Feb 07 '21 at 21:17
My primary goal is understanding; why do wlan0 and eth0 behave differently with respect to macvlan virtual interfaces? I try not to phrase my question in a way that makes it too specific to me; I would prefer it be general enough to be useful to the largest possible number of people, whilst still addressing the problem. The original question was based off something I read in serverfault, but there were no solutions compatible with the Raspberry Pi. The desire to have two IPs allocated by a DHCP server to a single NIC via WiFi has been around for quite some time. – Insert name here Feb 07 '21 at 22:11

Need Two IPs (using wlan0 interface) but do not have any control over static allocations

2 Answers2

Linked