RPi associating two IPs with its one and only wifi interface

If my reading of this

Places I know of where the kernel can get network interface setups: * DHCP client * /etc/network/interfaces file (or distro-specific equivalent) * systemd.network files * NetworkManager

Well that depends on what constitutes the 'Pi'' Its software did the association, not the Pi...

You never know, with Heffalumps

Handy way to talk to an unconfigured router on some random default address.

Routers do not retain memory of statically assigned addresses. You might find it in the arp table

I thought this was a wifi issue. There is no 'Ethernet' address.

In my experience it just works.

There was one (very recent) exception, where a website had been moved to a new provider and IPv6 was now available. They copied across their config files from the old site. What they forgot was that the old config files didn't enable IPv6. A simple fault that was quickly fixed, and was not a fault of IPv6 in itself. Since then the site has just worked over IPv6 and IPv4.

I moved my own website to a new provider a few weeks ago, specifically because the old provider didn't do IPv6 on their low cost shared servers (despite saying on their own website that IPv6 was supported everywhere!). The new website just worked from the get-go over IPv6 and IPv4.

The analysis I've seen of the world's internet traffic indicates that over 50% is now IPv6, and rising.

What I particularly like about IPv6 is that NAT/NAPT are simply not necessary, and it's possible to have multiple servers on the same port (e.g. multiple web servers on port 80/443) on one site, because you have effectively unlimited internet-accessible addresses.

David

What happens if/when you switch provider? Are you allowed to take your IPv6 address block with you?

Because if not, you end up having to assign new addresses to everything on your LAN.

No.

That's what DHCPv6 is for.

In terms of external DNS, most routers support dynamic DNS with several protocols; but it's normally a very simple operation to update your AAAA records manually. Or even by a shell script, like I run on my Ubuntu and RISC OS boxes, to automate it. Most domestic users have very few internet-facing IP addresses and therefore very few DNS entries to update, so the task doesn't comsume much time.

David

All good thoughts, thanks. But...

- There is no dhcp client running (at least by the time I am able to ssh in to the machine after it boots).

- All /etc/network/interfaces does is source any files in interfaces.d, and there are no files there.

- "sudo locate systemd.network" only shows the man page.

- the "mystery" IPv4 address doesn't show up anywhere in the /etc/NetworkManager directory or sub-directories.

I guess the mystery continues.

Jim

There are things to be said for systems that actually work.

In my case, the fiber termination is in the same one and only box that also houses the router/wifi. I did run some Cat 5 across my house and put a better wifi router in the diagonally opposite corner, and that one is a much better router. From what I've read (from people with the same service as me) replacing the ISP's router functions with your own involves a Herculean amount of effort, so I put up with the brain damage.

I laughed reading your comment "I had them bridge that IP...", because my ISP (the local phone company) goes out of their way to be difficult and obnoxious. I can't imagine trying to get them to do anything out of their default "this is how it is".

Jim

No. The fiber comes into a box and the box also has the wifi router. (I attached a second wifi router to give me better coverage, but that one just operates in some "pass through" mode (if that is the correct term).)

According to things I've read on the internet, some people have bought their own fiber hardware and then managed to do some end-run around the security (and so on) that the phone company puts in place. But I decided that I wasn't going down that road.

I could try turning off the DHCP server in the ISP's box. However, they have a habit of resetting and updating the software in their box, and I'm not sure how long turning off that DHCP server would last. I am not sure what would happen when two DHCP servers are on the same LAN, but I imagine Bad Things would happen.

Jim

The individual network interface configs should be in /etc/systemd/network/.

Another possibility: could the network address assignment be in a startup script for some seemingly unrelated service?

Here in NZ, the fibre terminates in a separate box called the “ONT”. Everything up to and including that box is the responsibility of a company called “Tuatahi Fibre”, which is *not* an ISP (and is not allowed to become one). Basically they provide a layer-2 connection between my house and the routers/switches/whatever for the service providers, and their job is to treat all service providers equally.

Also, that box is to be considered part of the fittings of the house, so it stays with the house, and doesn’t move if/when the residents move house. The installation of the box (and the physical fibre connection to it) was done free of charge, under a Government-funded plan.

The particular ONT box in my house has 4 Ethernet ports and 2 telephone landline ports. These can be independently assigned to different services, coming from different providers. E.g. the one that’s live for my ISP connection has an Ethernet cable running between it and my actual router, which I bought from a local store.

Hmmm ... I’m thinking it might be possible to isolate that box on a dedicated Ethernet port on a Linux box, so you could use a packet filter to block anything DHCP-related, and only let through the stuff you want ...

So making the implementation of a firewall absolutely mandatory

Of course, as possessed by all routers. The default state is to reject all incoming connections. If you want to expose a device to the internet, you punch a pinhole in the firewall, normally for one address and one port.

David

That was where I got to with my one.

At some stage that mobo died and I took the opportunity to switch mobos and install an updated linux version, using a GUI and network manager to set up the fixed IP, and the problem vanished.

If you can do a fresh install its probably the shortest route.

Now even if its headless there is a CLI to network manager and you might investigate that.

It's called in a fit of stunning originality, 'nmcli'

Try #nmcli device show

Also ifconfig -a should show up any active interfaces on odd addresses.

BUT IIRC I never could identify that interface that way - it seemed to be some sort of low level zombie.

It existed in the router DHCP table, showing it had been issues by the router in response to a request from the machine, but it only ever responded to pings, IIRC.

No listening process beyond that was ever bound to it.

I assumed it was some bug either induced by me hand editing files that network manager was supposed to edit, or as a changeover from earlier methods of setting up IP, not fully ignored by the new NM control system

All I know is that rigorous adherence to the GUI CLI on a fresh install eliminated it. Whether it was one or the other factor that was crucial, I cannot say. As with most transient bugs, life is to frikkin short...

I am sorry I cannot help beyond noting that yes, I have seen it happen, and no, I cant reproduce it any more, and at a given point it vanished, never to reappear...

MAC's aren't just Ethernet, WiFi and Bluetooth interfaces also have them.

You often see a difference of 1 when something creates a virtual network interface for use by a virtual machine or container. The virtual network card is assigned the second IP address and can operate independently from anything using the hosts primary interface and IP address.

---druck

At least on my 3B and 4B, the wired and wireless interfaces have adjacent MACs.

PS C:\Users\rjk> ssh shairo ip link show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether dc:a6:32:cb:73:6b brd ff:ff:ff:ff:ff:ff 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DORMANT group default qlen 1000 link/ether dc:a6:32:cb:73:6c brd ff:ff:ff:ff:ff:ff

If both interfaces were connected to the same network then I might see something similar to Jim’s situation.

I did ask Jim for ‘ip addr show’ output but it has not appeared.

I'm surprised. Accepting that you do not do some of the things I do, like policy routing rules based upon a host computer IP, I'm still seeing servers on the internet that advertise they should work with IPv6 but don't. This means they don't fall back to IPv4.

I'm not far enough along in my understanding to be entirely confident, but I would be surprised if I were wrong.

Linux IPv6 does appear to use random IPv6 address for outbound connections, which have a limited lifespan. This appears to be something like 1-7 days, but if very short lifespans were used it could offer a protection similar to NAT. I need to investigate a bit further, but I don't think IPv6 needs to be inherently less safe.

rpi4-4b ls -l /etc/systemd/network total 0 lrwxrwxrwx 1 root root 9 Dec 5 2023 73-usb-net-by-mac.link -> /dev/null lrwxrwxrwx 1 root root 9 Dec 5 2023 99-default.link -> /dev/null

Given that this mystery IP didn't show up the next time I rebooted (or again just now (to test)), I consider that unlikely. And grepping through /etc I don't see any unexpected instances of either (a) the mystery IP, or (b) the string "wlan". Not that this is an exhaustive hunt.

Jim