From Newsgroup: comp.sys.raspberry-pi

In message <10j1bob$223dq$[email protected]>
Lawrence D’Oliveiro <[email protected]d> wrote:

On Tue, 30 Dec 2025 20:00:52 GMT, David Higton wrote:

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.

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

No.

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

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
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 2025-12-30 at 01:49 AST, Lawrence D’Oliveiro <[email protected]d> wrote:

On Mon, 29 Dec 2025 10:59:29 +0000, Richard Kettlewell wrote:

i.e. the interface has two addresses after booting has completed. I
would put network boot at the bottom of the list of possible causes.
AIUI the kernel starts from a blank slate, it doesn’t inherit
interface configuration from the boot loader.

If my reading of this <https://en.wikipedia.org/wiki/Preboot_Execution_Environment> article
on PXE is correct, the kernel can indeed inherit network settings from
a PXE boot. But if you’re not using PXE, then that’s not relevant, of course. I don’t know of any other booting setup that could pass across network parameters from the bootloader to the kernel.

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

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
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 2025-12-29 at 21:38 AST, Lars Poulsen <[email protected]> wrote:

On 2025-12-30, Jim Diamond <[email protected]> wrote:

My router's DHCP function has a serious case of brain damage. (It is
supplied by my ISP and is not easy to avoid using, because of the way they >> control their fiber optic cable based system.) Right now it thinks the Pi >> in question is using the "mystery" IPv4 address, and it resolutely declares >> that the "proper" address is not connected. The Pi itself disagrees.

My current ISP is Frontier Fiber, and I have a business account with
a static IP address. While they supply a fiber termination unit in
my house wiring closet, they also supply a Sagemcom router/WiFi
device, which I *must* use because my static IP is the creation of a VPN feature inside the router, for which they do not provide any
usable documentation. So I had them bridge that IP to one of the
ethernet ports on the Sagemcom device, and then have my own edge
router attached to that. I can't turn off the WiFi on the Sagemcom, but
I have my own WiFi access point behind my router.

I am not very happy with the arrangement, but my bandwidth is 500 Mbps symmetric, although my (old) edge router is only 10/100 ethernet.
But after spending years on a 15Mbps symmetric network, I am happy to
get 100/100 that WORKS.

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
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 2025-12-30 at 01:42 AST, Lawrence D’Oliveiro <[email protected]d> wrote:

On Mon, 29 Dec 2025 21:00:19 -0400, Jim Diamond wrote:

My router's DHCP function has a serious case of brain damage. (It is
supplied by my ISP and is not easy to avoid using, because of the
way they control their fiber optic cable based system.)

I wonder why you would use an ISP-supplied router -- don’t you get to connect your own?

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.

That’s what I have done, here in 🇳🇿. I have turned off its DHCP function, and run my own DHCP server on a separate Linux box, so that I
can more easily keep track of lists of statically-assigned addresses for
my trusted machines.

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
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On Tue, 30 Dec 2025 17:07:46 -0400, Jim Diamond wrote:

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

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

I guess the mystery continues.

Another possibility: could the network address assignment be
in a startup script for some seemingly unrelated service?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On Tue, 30 Dec 2025 17:50:15 -0400, Jim Diamond wrote:

On 2025-12-30 at 01:42 AST, Lawrence D’Oliveiro <[email protected]d> wrote:

I wonder why you would use an ISP-supplied router -- don’t you get
to connect your own?

No. The fiber comes into a box and the box also has the wifi router.

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.

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.

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 ...
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 30/12/2025 20:00, David Higton wrote:

What I particularly like about IPv6 is that NAT/NAPT are simply not
necessary

So making the implementation of a firewall absolutely mandatory
--
Ideas are more powerful than guns. We would not let our enemies have
guns, why should we let them have ideas?

Josef Stalin

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

In message <10j31s0$2gptg$[email protected]>
The Natural Philosopher <[email protected]d> wrote:

On 30/12/2025 20:00, David Higton wrote:

What I particularly like about IPv6 is that NAT/NAPT are simply not necessary

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
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 30/12/2025 21:07, Jim Diamond wrote:

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.

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...
--
Microsoft : the best reason to go to Linux that ever existed.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 30/12/2025 01:00, Jim Diamond wrote:

However, it was worth a look. Maybe. According to the router, the
"mystery" address is paired with the wifi card's actual ethernet (MAC)

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

address, whereas the "proper" address is (currently) paired with the same ethernet address, except the last octet is 8C instead of 8D. This makes me think that it is showing "Connected" or "Disconnected" according to the ethernet address which is working, and it is not careful about pairing that with the correct IPv4 address.

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
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

druck <[email protected]> writes:

On 30/12/2025 01:00, Jim Diamond wrote:

However, it was worth a look. Maybe. According to the router, the
"mystery" address is paired with the wifi card's actual ethernet (MAC)

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

address, whereas the "proper" address is (currently) paired with the
same ethernet address, except the last octet is 8C instead of 8D.
This makes me think that it is showing "Connected" or "Disconnected"
according to the ethernet address which is working, and it is not
careful about pairing that with the correct IPv4 address.

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.

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.
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 12/30/25 20:00, David Higton wrote:

In message <10iv40e$1e1ba$[email protected]>
Pancho <[email protected]> wrote:

IPv6 seems like a world of pain.

In my experience it just works.

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.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 12/31/25 11:36, The Natural Philosopher wrote:

On 30/12/2025 20:00, David Higton wrote:

What I particularly like about IPv6 is that NAT/NAPT are simply not
necessary

So making the implementation of a firewall absolutely mandatory

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.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 2025-12-30 at 18:14 AST, Lawrence D’Oliveiro <[email protected]d> wrote:

On Tue, 30 Dec 2025 17:07:46 -0400, Jim Diamond wrote:

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

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

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

I guess the mystery continues.

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

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
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 2025-12-31 at 07:58 AST, The Natural Philosopher <[email protected]d> wrote:

On 30/12/2025 21:07, Jim Diamond wrote:

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.

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.

That will be a consideration, should push come to shove. So far, this
mystery IP hasn't caused any problems, but it is anomalous, which is bothersome.

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

Yes, I know about nmcli and even use it occasionally. Thanks.

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 agree 100% with that.

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...

Well, I haven't seen my mystery addr recently. Maybe a neutrino hit
the wrong spot during boot.

Jim
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 2025-12-31 at 09:15 AST, Richard Kettlewell <[email protected]d> wrote:

druck <[email protected]> writes:

On 30/12/2025 01:00, Jim Diamond wrote:

However, it was worth a look. Maybe. According to the router, the
"mystery" address is paired with the wifi card's actual ethernet (MAC)

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

address, whereas the "proper" address is (currently) paired with the
same ethernet address, except the last octet is 8C instead of 8D.
This makes me think that it is showing "Connected" or "Disconnected"
according to the ethernet address which is working, and it is not
careful about pairing that with the correct IPv4 address.

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.

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.

Mea culpa, I thought I did.

Here is today's output... but I have long since gotten rid of that extra
IP, so I'm not sure if this is at all interesting:

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 noprefixroute
valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether dc:a6:32:37:93:8c 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 dc:a6:32:37:93:8d brd ff:ff:ff:ff:ff:ff
inet 192.168.2.74/24 brd 192.168.2.255 scope global noprefixroute wlan0
valid_lft forever preferred_lft forever
inet6 fe80::d10a:4386:b7f7:43f9/64 scope link noprefixroute
valid_lft forever preferred_lft forever

Should it happen again I'll capture this output in case it helps find the source.

Jim
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

Pancho <[email protected]> writes:

The Natural Philosopher wrote:

David Higton wrote:

What I particularly like about IPv6 is that NAT/NAPT are simply not
necessary

So making the implementation of a firewall absolutely mandatory

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.

NAT does not offer any protection. The reason that a typical domestic NAT-equipped router protects you from inbound connections is that it has
a firewall as well.

(Getting a packet addressed to your internal addresses to your external interface is inconvenient for many attackers, for sure, but
striaghtforward for your ISP or anyone who can hack or coerce them.)
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

In message <10j3tmk$29ec2$[email protected]>
Pancho <[email protected]> wrote:

On 12/31/25 11:36, The Natural Philosopher wrote:

On 30/12/2025 20:00, David Higton wrote:

What I particularly like about IPv6 is that NAT/NAPT are simply not necessary

So making the implementation of a firewall absolutely mandatory

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.

I use Ubuntu, which gives itself two routable IPv6 addresses. One is
always the same (good if you have an internet-accessible server) and
the other is new each reboot (good for privacy). Maybe it's the same
for you?

David
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

In message <10j3tdq$29dt0$[email protected]>
Pancho <[email protected]> wrote:

On 12/30/25 20:00, David Higton wrote:

In message <10iv40e$1e1ba$[email protected]>
Pancho <[email protected]> wrote:

IPv6 seems like a world of pain.

In my experience it just works.

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.

I've not encountered anything that's more difficult in IPv6 than in IPv4.
I'm certain that IPv6 works just as well and as reliably as IPv4; after
all, it's been in global-scale use for many years now, so all the issues
have been solved. But there's always scope for something to go wrong,
like in the example I quoted earlier where there was an IPv6 interface
that didn't previously exist, and configuring it (which was no more
difficult than the original IPv4 config, which was done so long ago that everyone had forgotten it) simply hadn't been done. Since everything mainstream now defaults to IPv6, there were two fault symptoms, depending
which browser and OS were in use:

1) The site appeared unavailable;

2) The site was reached, but only after a delay.

Nothing about it was a problem of IPv6 per se.

I'd be interested to know what "policy routing rules based upon a host
computer IP" you're using. My router runs OpenWRT. Everything gets
its IPv6 address via DHCPv6. The traffic rules pick up the device by
name, so, if the IPv6 address changes, the rules change automatically
to match.

David
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On Wed, 31 Dec 2025 16:00:45 -0400, Jim Diamond wrote:

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

Interesting that you have anything in that directory at all; the one
on my Debian Unstable system is empty.

This symlinking to /dev/null is called “masking”. It explicitly
disables those service entries (originals present in
/lib/systemd/network in this case) so they cannot be
(easily/accidentally) enabled.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On Wed, 31 Dec 2025 16:04:11 -0400, Jim Diamond wrote:

As with most transient bugs, life is to frikkin short...

I agree 100% with that.

Depends on what you see your role as. I make part of my living as a
Linux sysadmin, so naturally odd behaviours on my own systems would
tend to be a matter of professional interest.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 31/12/2025 19:31, Pancho wrote:

On 12/31/25 11:36, The Natural Philosopher wrote:

On 30/12/2025 20:00, David Higton wrote:

What I particularly like about IPv6 is that NAT/NAPT are simply not
necessary

So making the implementation of a firewall absolutely mandatory

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.

No, its more that it imposes a different discipline, And that has to be learnt, taught and implemented.

And that takes time, costs money and always has gotchas.

Which is why most people (consumers and even businesses) are still
running V4 + NAT....
--
“A leader is best When people barely know he exists. Of a good leader,
who talks little,When his work is done, his aim fulfilled,They will say,
“We did this ourselves.”

― Lao Tzu, Tao Te Ching

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 31/12/2025 20:00, Jim Diamond wrote:

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.

Linux has had a fit about the naming of interfaces. wlan seems deprecated.
--
“A leader is best When people barely know he exists. Of a good leader,
who talks little,When his work is done, his aim fulfilled,They will say,
“We did this ourselves.”

― Lao Tzu, Tao Te Ching

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 31/12/2025 20:04, Jim Diamond wrote:

Maybe a neutrino hit
the wrong spot during boot.

Not sure a neutrino would do it. A muon however...
--
A lie can travel halfway around the world while the truth is putting on
its shoes.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 31/12/2025 20:18, Richard Kettlewell wrote:

Pancho <[email protected]> writes:

The Natural Philosopher wrote:

David Higton wrote:

What I particularly like about IPv6 is that NAT/NAPT are simply not
necessary

So making the implementation of a firewall absolutely mandatory

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.

NAT does not offer any protection. The reason that a typical domestic NAT-equipped router protects you from inbound connections is that it has
a firewall as well.

(Getting a packet addressed to your internal addresses to your external interface is inconvenient for many attackers, for sure, but
striaghtforward for your ISP or anyone who can hack or coerce them.)

How?
Genuine question.
--
A lie can travel halfway around the world while the truth is putting on
its shoes.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 12/31/25 20:19, David Higton wrote:

In message <10j3tdq$29dt0$[email protected]>
Pancho <[email protected]> wrote:

On 12/30/25 20:00, David Higton wrote:

In message <10iv40e$1e1ba$[email protected]>
Pancho <[email protected]> wrote:

IPv6 seems like a world of pain.

In my experience it just works.

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.

I've not encountered anything that's more difficult in IPv6 than in IPv4.

In general, I'm not claiming IPv6 is more difficult. However, I have 30+
years of dealing with and solving the problems of IPv4. Switching to
dual stack IPv6 is introducing new problems, which I need to understand
and solve.

The reason I was looking at IPv6 was to solve some poorly understood
problems I appear to have with a new VoIP SIP provider.

I'm certain that IPv6 works just as well and as reliably as IPv4; after
all, it's been in global-scale use for many years now, so all the issues
have been solved. But there's always scope for something to go wrong,
like in the example I quoted earlier where there was an IPv6 interface
that didn't previously exist, and configuring it (which was no more
difficult than the original IPv4 config, which was done so long ago that everyone had forgotten it) simply hadn't been done. Since everything mainstream now defaults to IPv6, there were two fault symptoms, depending which browser and OS were in use:

1) The site appeared unavailable;

2) The site was reached, but only after a delay.

Nothing about it was a problem of IPv6 per se.

But in practice, I am having IPv6 problems. Not caused by IPv6 itself,
but apparently by third party misconfiguration. It is no good IPv6 being
good, or my routing implementation being good, if in practice I'm
banging my head against third party problems.

At this stage it is quite possible I have misconfigured something, but
it takes a lot of effort for me to understand each problem, so I discuss
my experience in this public forum to gauge other people's practical experience.

I'd be interested to know what "policy routing rules based upon a host computer IP" you're using. My router runs OpenWRT. Everything gets
its IPv6 address via DHCPv6. The traffic rules pick up the device by
name, so, if the IPv6 address changes, the rules change automatically
to match.

I use permanent VPN tunnels to access the WAN, something like NordVPN.
Some LAN services I specifically want to route through the VPN, some I specifically want to route over the standard WAN. One way I have
traditionally done this is to using a pfSense router to use a service
internal LAN IP address to decide which external gateway to route over.
Other people might do something similar using VLANs, but my switch
hardware strips VLAN tags.

For the avoidance of doubt, I'm relatively naive w.r.t. networking. I
just knock up the first thing that works, rather than do something
technically orthodox.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 12/31/25 20:23, David Higton wrote:

In message <10j3tmk$29ec2$[email protected]>
Pancho <[email protected]> wrote:

On 12/31/25 11:36, The Natural Philosopher wrote:

On 30/12/2025 20:00, David Higton wrote:

What I particularly like about IPv6 is that NAT/NAPT are simply not
necessary

So making the implementation of a firewall absolutely mandatory

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.

I use Ubuntu, which gives itself two routable IPv6 addresses. One is
always the same (good if you have an internet-accessible server) and
the other is new each reboot (good for privacy). Maybe it's the same
for you?

Yes, I'm using an Ubuntu derivative. That is what I had. I had the IPv6 address DHCPv6/RA assigned, plus there was a temporary one. Most
external connections to the WAN went over the temporary one. I guess
this is to not expose my permanent routable IPv6 address, the one I'm
likely to have open ports on.

AIUI, the temporary IPv6 address is preferred for one day, but hangs
around for 7 days.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

The Natural Philosopher <[email protected]d> writes:

On 31/12/2025 20:18, Richard Kettlewell wrote:

Pancho <[email protected]> writes:

The Natural Philosopher wrote:

David Higton wrote:

What I particularly like about IPv6 is that NAT/NAPT are simply not
necessary

So making the implementation of a firewall absolutely mandatory

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.

NAT does not offer any protection. The reason that a typical domestic
NAT-equipped router protects you from inbound connections is that it
has a firewall as well. (Getting a packet addressed to your internal
addresses to your external interface is inconvenient for many
attackers, for sure, but straightforward for your ISP or anyone who
can hack or coerce them.)

How?
Genuine question.

Same as routing any other packet. Make sure there’s an appropriate
routing table entry for the customer addresses on the ISP’s
customer-facing router (and whatever intermediate routers there are
between that and the attack source), then call socket/connect/write.

The question is then what the customer router does with it.

* If it follows the strong end system then the packet is discarded
before NAT even comes into the question.
Linux follows the weak end system model by default, so this
possibility doesn’t apply to Linux-based router unless someone has
taken the trouble to change its behavior somehow.

* If there’s a basically competent firewall on the customer router then
the packet is discard by that.

* If there’s a NAT then it gets to look at the packet, but it won’t
match any of the rules that enable translation, so it will not be
modified at this stage.

* All that’s now left is normal routing, so the packet passes on to its
destination on the customer network.

https://www.greenend.org.uk/rjk/tech/nat.html has a worked example.
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 01/01/2026 11:34, Richard Kettlewell wrote:

The Natural Philosopher <[email protected]d> writes:

On 31/12/2025 20:18, Richard Kettlewell wrote:

Pancho <[email protected]> writes:

The Natural Philosopher wrote:

David Higton wrote:

What I particularly like about IPv6 is that NAT/NAPT are simply not >>>>>> necessary

So making the implementation of a firewall absolutely mandatory

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.

NAT does not offer any protection. The reason that a typical domestic
NAT-equipped router protects you from inbound connections is that it
has a firewall as well. (Getting a packet addressed to your internal
addresses to your external interface is inconvenient for many
attackers, for sure, but straightforward for your ISP or anyone who
can hack or coerce them.)

How?
Genuine question.

Same as routing any other packet. Make sure there’s an appropriate
routing table entry for the customer addresses on the ISP’s
customer-facing router (and whatever intermediate routers there are
between that and the attack source), then call socket/connect/write.

The question is then what the customer router does with it.

* If it follows the strong end system then the packet is discarded
before NAT even comes into the question.
Linux follows the weak end system model by default, so this
possibility doesn’t apply to Linux-based router unless someone has
taken the trouble to change its behavior somehow.

* If there’s a basically competent firewall on the customer router then
the packet is discard by that.

* If there’s a NAT then it gets to look at the packet, but it won’t
match any of the rules that enable translation, so it will not be
modified at this stage.

Ah. I misunderstood your original post. Sure the ISP can send an
internally addressed packet to your router. If it wants to lose its
customer base.

But will that get forwarded along?

* All that’s now left is normal routing, so the packet passes on to its
destination on the customer network.

https://www.greenend.org.uk/rjk/tech/nat.html has a worked example.

I can't believe that my router would accept arbitrary packets with an internal destination address on its external facing port...if the
destination is not in its tables, it will be automatically discarded...
--
"In our post-modern world, climate science is not powerful because it is
true: it is true because it is powerful."

Lucas Bergkamp

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

The Natural Philosopher <[email protected]d> writes:

On 01/01/2026 11:34, Richard Kettlewell wrote:

The Natural Philosopher <[email protected]d> writes:

On 31/12/2025 20:18, Richard Kettlewell wrote:

NAT does not offer any protection. The reason that a typical domestic
NAT-equipped router protects you from inbound connections is that it
has a firewall as well. (Getting a packet addressed to your internal
addresses to your external interface is inconvenient for many
attackers, for sure, but straightforward for your ISP or anyone who
can hack or coerce them.)

How?
Genuine question.

Same as routing any other packet. Make sure there’s an appropriate
routing table entry for the customer addresses on the ISP’s
customer-facing router (and whatever intermediate routers there are
between that and the attack source), then call socket/connect/write.
The question is then what the customer router does with it.
* If it follows the strong end system then the packet is discarded
before NAT even comes into the question.
Linux follows the weak end system model by default, so this
possibility doesn’t apply to Linux-based router unless someone has
taken the trouble to change its behavior somehow.
* If there’s a basically competent firewall on the customer router
then
the packet is discard by that.
* If there’s a NAT then it gets to look at the packet, but it won’t
match any of the rules that enable translation, so it will not be
modified at this stage.

Ah. I misunderstood your original post. Sure the ISP can send an
internally addressed packet to your router. If it wants to lose its
customer base.

* The police turn up with a warrant and inform you that if you don’t
help them break into a certain customer’s network, you will go to
prison.

* The mafia turn up with a gun, and inform you that if you don’t help
them break into a certain customer’s network, you will be shot.

* A teenager who follows full-disclosure exploits the latest zero day to
break into the ISP’s network, and from there to as many customers as
they can reach.

* An ISP staff member suspects that a friend who happens to be a
customer is having an affair with their wife. Overwhelmed by jealousy
they decide to attempt to hack the customer’s computers.

You can probably imagine more scenarios.

But will that get forwarded along?

* All that’s now left is normal routing, so the packet passes on to its
destination on the customer network.
https://www.greenend.org.uk/rjk/tech/nat.html has a worked example.

I can't believe that my router would accept arbitrary packets with
an internal destination address on its external facing port...

It probbaly doesn’t: it might use the strong end system model, and if
not it might have a firewall preventing it. But whatever its
configuration, it’s not NAT that stops it.

if the destination is not in its tables, it will be automatically discarded...

The internal network destination address _is_ in its routing table.
That’s how it sends legitimate packets back to the internal network
(e.g. when an internal host pings the router).

On my router:

$ ip route show|grep 172.17.207.0
172.17.207.0/24 dev br0 proto kernel scope link src 172.17.207.1

(172.17.207.0 is my internal network.)
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 01/01/2026 12:26, Richard Kettlewell wrote:

The internal network destination address_is_ in its routing table.

But not its port. And not in its NAT table,

The essence of NAT is that the originating port cannot be accessed directly.

And that *everything* gets translated, There is no concept of 'allowing
some shit through even though it's not in my NAT tables' beyond
theoretical.

Whether that is a feature of NAT or a firewall, is semantics, but *in practice* it is not a security risk.

If the police want to examine my server, they simply knock on the door
with a warrant. No matter what protocol is on the interface
--
All political activity makes complete sense once the proposition that
all government is basically a self-legalising protection racket, is
fully understood.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

The Natural Philosopher <[email protected]d> writes:

On 01/01/2026 12:26, Richard Kettlewell wrote:

The internal network destination address_is_ in its routing table.

But not its port. And not in its NAT table,

Irrelevant.

I literally did the experiment, you can see the results in the link
posted earlier.
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 2025-12-31 at 17:09 AST, Lawrence D’Oliveiro <[email protected]d> wrote:

On Wed, 31 Dec 2025 16:00:45 -0400, Jim Diamond wrote:

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

Interesting that you have anything in that directory at all; the one
on my Debian Unstable system is empty.

I didn't (explicitly) put those there. I don't know whether they were put there in the installation image or whether some initial configuration I did added those.

This symlinking to /dev/null is called “masking”. It explicitly
disables those service entries (originals present in
/lib/systemd/network in this case) so they cannot be
(easily/accidentally) enabled.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 2025-12-31 at 17:50 AST, The Natural Philosopher <[email protected]d> wrote:

On 31/12/2025 20:00, Jim Diamond wrote:

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.

Linux has had a fit about the naming of interfaces. wlan seems deprecated.

I don't think "Linux" has had a fit about naming of interfaces. All of my machines (RPi and otherwise) have "wlan0". But I have seen more exotic
names on some distros.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 2025-12-30 at 18:26 AST, Lawrence D’Oliveiro <[email protected]d> wrote:

On Tue, 30 Dec 2025 17:50:15 -0400, Jim Diamond wrote:

On 2025-12-30 at 01:42 AST, Lawrence D’Oliveiro <[email protected]d> wrote: >>>

I wonder why you would use an ISP-supplied router -- don’t you get
to connect your own?

No. The fiber comes into a box and the box also has the wifi router.

Here in NZ, the fibre terminates in a separate box called the “ONT”.

When I first got fiber, I had two separate boxes, one for fiber<->ethernet,
and a wifi router.

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.

Interesting! That sounds good, although perhaps there are some down sides
to that as well. (Do you think there are such downsides?)

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.

Also interesting. Is that NZ-wide? Or just in certain areas?

Someone I know moved (from Canada) to NZ a few years ago, and we have never talked about internet infrastructure. I might have thought that had there
been something interesting there, he would have mentioned it. But maybe not.

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.

My ISP heavily flogs their TV service, which the "all in one" box also
handles. Can you get TV through this? If so, does the TV just stream over
the ethernet like a "normal" network connection (as opposed to something
like a coax cable carrying many channels)?

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.

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

Yes, I could probably do something along those lines.

They upgraded the s/w in the router so that it isn't quite brain dead as it used to be. Formerly, if you wanted to tell it to reserve a particular IP
for a particular MAC address, 19 times out of 20 it wouldn't do it, which really pissed me off. The "support" (insert bitter laugh here) from the
ISP for anything like that was laughably bad, and there was no getting any
help from them on fixing their horrible router software. But it is less
bad recently.

Jim
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 2026-01-01, Pancho <[email protected]> wrote:

In general, I'm not claiming IPv6 is more difficult. However, I have 30+ years of dealing with and solving the problems of IPv4. Switching to
dual stack IPv6 is introducing new problems, which I need to understand
and solve.

+1

Many ISPs - especially cookie-cutter consumer-oriented ones - do
not support customers using IPv6. (Although it might be argued
that that is not very different from the level of support they provide
for IPv4)
--
Lars Poulsen - an old geek in Santa Barbara, California
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

Jim Diamond <[email protected]> writes:

The Natural Philosopher <[email protected]d> wrote:

On 31/12/2025 20:00, Jim Diamond wrote:

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.

Linux has had a fit about the naming of interfaces. wlan seems
deprecated.

I don't think "Linux" has had a fit about naming of interfaces. All
of my machines (RPi and otherwise) have "wlan0". But I have seen more
exotic names on some distros.

TNP is thinking of the ‘predictable interface names’ scheme, which is a misnomer since predicting the name depends on information you don’t necessarily have readily to hand. Really it is about keeping the mapping between names and specific hardware interfaces stable, which is valuable
in some situations and inconvenient in others.

IMHO they should have taken a lesson from filesystem naming, and allowed interfaces to be identified by their attributes, rather than depending
on a unique name.
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On Thu, 01 Jan 2026 17:54:34 +0000, Richard Kettlewell wrote:

IMHO they should have taken a lesson from filesystem naming, and
allowed interfaces to be identified by their attributes, rather than depending on a unique name.

What attributes would you use?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 31.12.2025 22.09, Jim Diamond wrote:

On 2025-12-31 at 09:15 AST, Richard Kettlewell <[email protected]d> wrote:

druck <[email protected]> writes:

On 30/12/2025 01:00, Jim Diamond wrote:

However, it was worth a look. Maybe. According to the router, the
"mystery" address is paired with the wifi card's actual ethernet (MAC)

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

address, whereas the "proper" address is (currently) paired with the
same ethernet address, except the last octet is 8C instead of 8D.
This makes me think that it is showing "Connected" or "Disconnected"
according to the ethernet address which is working, and it is not
careful about pairing that with the correct IPv4 address.

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.

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.

Mea culpa, I thought I did.

Here is today's output... but I have long since gotten rid of that extra
IP, so I'm not sure if this is at all interesting:

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 noprefixroute
valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether dc:a6:32:37:93:8c 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 dc:a6:32:37:93:8d brd ff:ff:ff:ff:ff:ff
inet 192.168.2.74/24 brd 192.168.2.255 scope global noprefixroute wlan0
valid_lft forever preferred_lft forever
inet6 fe80::d10a:4386:b7f7:43f9/64 scope link noprefixroute
valid_lft forever preferred_lft forever

Should it happen again I'll capture this output in case it helps find the source.

Jim

If your system is running NetworkManager, it is the culprit.

In my RasPi3B+ router, I disabled and stopped NetworkManager.
systemd-networkd is perfectly capable to handle the DHCP
client duties.

After this, you have to create the needed interface and
network descriptions into /etc/systemd/network, and that's it.

The two links in the directory are fine, do not mess with them.
--

Tauno Voipio

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 01/01/2026 17:54, Richard Kettlewell wrote:

Jim Diamond <[email protected]> writes:

The Natural Philosopher <[email protected]d> wrote:

On 31/12/2025 20:00, Jim Diamond wrote:

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.

Linux has had a fit about the naming of interfaces. wlan seems
deprecated.

I don't think "Linux" has had a fit about naming of interfaces. All
of my machines (RPi and otherwise) have "wlan0". But I have seen more
exotic names on some distros.

TNP is thinking of the ‘predictable interface names’ scheme, which is a misnomer since predicting the name depends on information you don’t necessarily have readily to hand. Really it is about keeping the mapping between names and specific hardware interfaces stable, which is valuable
in some situations and inconvenient in others.

Er no. On my HP laptop the interface is something like (runs to laptop
and returns) "wlo1"...

IMHO they should have taken a lesson from filesystem naming, and allowed interfaces to be identified by their attributes, rather than depending
on a unique name.

--
"Fanaticism consists in redoubling your effort when you have
forgotten your aim."

George Santayana

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 01/01/2026 15:23, Jim Diamond wrote:

On 2025-12-31 at 17:50 AST, The Natural Philosopher <[email protected]d> wrote:

On 31/12/2025 20:00, Jim Diamond wrote:

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.

Linux has had a fit about the naming of interfaces. wlan seems deprecated.

I don't think "Linux" has had a fit about naming of interfaces. All of my machines (RPi and otherwise) have "wlan0". But I have seen more exotic
names on some distros.

The raspi-config allows you to choose between simple names (such as
wlan0) and unique names (such as wl0sp3 on my laptop). With unique names
you can and another identical device, but the original one's name wont
change no matter what order they are enumerated in.

---druck
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 2026-01-01 at 16:37 AST, Tauno Voipio <[email protected]d> wrote:

On 31.12.2025 22.09, Jim Diamond wrote:

On 2025-12-31 at 09:15 AST, Richard Kettlewell <[email protected]d> wrote:

druck <[email protected]> writes:

On 30/12/2025 01:00, Jim Diamond wrote:

However, it was worth a look. Maybe. According to the router, the
"mystery" address is paired with the wifi card's actual ethernet (MAC) >>>>

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

address, whereas the "proper" address is (currently) paired with the >>>>> same ethernet address, except the last octet is 8C instead of 8D.
This makes me think that it is showing "Connected" or "Disconnected" >>>>> according to the ethernet address which is working, and it is not
careful about pairing that with the correct IPv4 address.

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.

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.

Mea culpa, I thought I did.

Here is today's output... but I have long since gotten rid of that extra
IP, so I'm not sure if this is at all interesting:

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 noprefixroute
valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether dc:a6:32:37:93:8c 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 dc:a6:32:37:93:8d brd ff:ff:ff:ff:ff:ff
inet 192.168.2.74/24 brd 192.168.2.255 scope global noprefixroute wlan0 >> valid_lft forever preferred_lft forever
inet6 fe80::d10a:4386:b7f7:43f9/64 scope link noprefixroute
valid_lft forever preferred_lft forever

Should it happen again I'll capture this output in case it helps find the
source.

Jim

If your system is running NetworkManager, it is the culprit.

Given that all of my systems have been running NetworkManager for many
years, and that I have only seen this happen once, I'm having a hard time seeing why you can make such a definitive statement. Care to elaborate?

In my RasPi3B+ router, I disabled and stopped NetworkManager. systemd-networkd is perfectly capable to handle the DHCP
client duties.

I run a number of systemd-free systems, and having as much commonality as possibly reduces admin time. So, for me, I would prefer to stay away from switching network configuration tools if at all possible. YMMV.

Jim

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 02/01/2026 15:39, druck wrote:

... and unique names (such as wl0sp3 on my laptop)

On my Thinkpad its wlp3s0. Those two couldn't possibly cause any
confusion for anyone, I'm sure!
--
Cheers,
Daniel.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 1/1/26 11:34, Richard Kettlewell wrote:

https://www.greenend.org.uk/rjk/tech/nat.html has a worked example.

Curiously <https://www.greenend.org.uk/rjk/tech/nat.html> is an example
of a website that fails to load when I use IPv6 but works fine under IPv4

curl -4 https://www.greenend.org.uk/rjk/tech/nat.html
works fine
.
curl -6 https://www.greenend.org.uk/rjk/tech/nat.html
times out.

Last thing I receive in IPv6 pcap from Greenend says
[TCP Previous segment not captured]


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

In message <10jdt2m$22a2d$[email protected]>
Pancho <[email protected]> wrote:

On 1/1/26 11:34, Richard Kettlewell wrote:

https://www.greenend.org.uk/rjk/tech/nat.html has a worked example.

Curiously <https://www.greenend.org.uk/rjk/tech/nat.html> is an example of
a website that fails to load when I use IPv6 but works fine under IPv4

curl -4 https://www.greenend.org.uk/rjk/tech/nat.html works fine
.
curl -6 https://www.greenend.org.uk/rjk/tech/nat.html times out.

Last thing I receive in IPv6 pcap from Greenend says
[TCP Previous segment not captured]

Curious. The curl -6 command works for me (and comes in like a rocket!)
and the link also works in Firefox, and I know that IPv6 is preferred.

That's the first instance I've hear of something failing to work correctly
in IPv6 with no obvious explanation.

David
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

Pancho <[email protected]> writes:

Richard Kettlewell wrote:

https://www.greenend.org.uk/rjk/tech/nat.html has a worked example.

Curiously <https://www.greenend.org.uk/rjk/tech/nat.html> is an
example of a website that fails to load when I use IPv6 but works fine
under IPv4

curl -4 https://www.greenend.org.uk/rjk/tech/nat.html
works fine
.
curl -6 https://www.greenend.org.uk/rjk/tech/nat.html
times out.

It works for me from a couple of locations (one with native IPv6 and
the other via a Hurricance Electric tunnel). traceroute -6 might reveal
where your problem is.

Last thing I receive in IPv6 pcap from Greenend says
[TCP Previous segment not captured]

AFAICT that just means you started tracing part way through a session.
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 02/01/2026 17:32, Daniel James wrote:

On 02/01/2026 15:39, druck wrote:

... and unique names (such as wl0sp3 on my laptop)

On my Thinkpad its wlp3s0. Those two couldn't possibly cause any
confusion for anyone, I'm sure!

Actually mine is wlp3s0 too, I remembered it wrong!

Also as someone else mentioned, it's actually predicable names rather
than unique names.

---druck
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 04/01/2026 19:02, druck wrote:

On 02/01/2026 17:32, Daniel James wrote:

On 02/01/2026 15:39, druck wrote:

... and unique names (such as wl0sp3 on my laptop)

On my Thinkpad its wlp3s0. Those two couldn't possibly cause any
confusion for anyone, I'm sure!

Actually mine is wlp3s0 too, I remembered it wrong!

Yes, it would be.

I wasn't thinking when I replied, but wl0sp3 isn't in the right format.

Also as someone else mentioned, it's actually predicable names rather
than unique names.

Yes, for some strange value of "predictable" that requires you to know
the naming scheme and also to know the hardware rather more intimately
than most people usually have any need or desire to do.

See:

https://www.freedesktop.org/software/systemd/man/latest/systemd.net-naming-scheme.html
--
Cheers,
Daniel.



--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On Mon, 5 Jan 2026 12:37:23 +0000, Daniel James wrote:

On 04/01/2026 19:02, druck wrote:

Also as someone else mentioned, it's actually predicable names
rather than unique names.

Yes, for some strange value of "predictable" that requires you to
know the naming scheme and also to know the hardware rather more
intimately than most people usually have any need or desire to do.

I had a look on my system, to see where network interface names come
from. I found those names used inside /sys/class/net, which is
low-level information directly from the Linux kernel, not obtained
from udev rules or systemd or any other such userland source.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 27/12/2025 17:34, Jim Diamond wrote:

I was looking at my network and discovered an IP which I didn't know about; after a few seconds of investigation I discovered that one of my Pis (which is on wifi only, and only has one wifi card) has two IPs.

Two of my other Pis are running the same version of Raspberry Pi OS (i.e., "Debian GNU/Linux 12 (bookworm)"). They don't do this.

Looking around the net, there are claims that this is because Pis might try to netboot, and that later on in the boot process they also get their usual IP the "usual" way. (In my case I am using networkmanager.)

I can't imagine what I did to make one of my Pis want to (try to) netboot.

Has anyone here seen this, and, if so, know what grievous sins I have committed to make this happen? And how to make it stop?

Thanks.
Jim

I had smililar problem when I upgraded to Bullseye. My solution was
deleted connman package.

Refer to https://raspberrypi.stackexchange.com/questions/133318/how-to-disable-the-dynamic-ip-address-after-assigning-a-static-ip-in-bullseye
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 1/4/26 15:20, Richard Kettlewell wrote:

Pancho <[email protected]> writes:

Richard Kettlewell wrote:

https://www.greenend.org.uk/rjk/tech/nat.html has a worked example.

Curiously <https://www.greenend.org.uk/rjk/tech/nat.html> is an
example of a website that fails to load when I use IPv6 but works fine
under IPv4

curl -4 https://www.greenend.org.uk/rjk/tech/nat.html
works fine
.
curl -6 https://www.greenend.org.uk/rjk/tech/nat.html
times out.

It works for me from a couple of locations (one with native IPv6 and
the other via a Hurricance Electric tunnel). traceroute -6 might reveal
where your problem is.

Last thing I receive in IPv6 pcap from Greenend says
[TCP Previous segment not captured]

AFAICT that just means you started tracing part way through a session.

Thanks both of you, that gave me confidence to investigate further.

I'm guessing it is due to a split TCP packet. TLS asks for a change of cipher, which is a big packet, and then it all goes wrong.

Anyway, setting MTU=1444 fixes the problem. Internet tells me that the
root problem is because the firewall is blocking ICMP too big, breaking
Path MTU Discovery (PMTUD) . I can't see where, so now I have to
understand that.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 2026-01-05 at 18:21 AST, attend <[email protected]> wrote:

On 27/12/2025 17:34, Jim Diamond wrote:

I was looking at my network and discovered an IP which I didn't know about; >> after a few seconds of investigation I discovered that one of my Pis (which >> is on wifi only, and only has one wifi card) has two IPs.

Two of my other Pis are running the same version of Raspberry Pi OS (i.e., >> "Debian GNU/Linux 12 (bookworm)"). They don't do this.

Looking around the net, there are claims that this is because Pis might try >> to netboot, and that later on in the boot process they also get their usual >> IP the "usual" way. (In my case I am using networkmanager.)

I can't imagine what I did to make one of my Pis want to (try to) netboot.

Has anyone here seen this, and, if so, know what grievous sins I have
committed to make this happen? And how to make it stop?

Thanks.
Jim

I had smililar problem when I upgraded to Bullseye. My solution was
deleted connman package.

Refer to https://raspberrypi.stackexchange.com/questions/133318/how-to-disable-the-dynamic-ip-address-after-assigning-a-static-ip-in-bullseye

Thanks for the pointer, but that wasn't it.

The system in question (as well as my other systems) doesn't (respectively, don't) have connman installed.

(I have a feeling I might not have named a piece of software "connman",
even though I can imagine where they got that name.)

Jim
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

Pancho <[email protected]> writes:

On 12/30/25 20:00, David Higton wrote:

In message <10iv40e$1e1ba$[email protected]>
Pancho <[email protected]> wrote:

IPv6 seems like a world of pain.

In my experience it just works.

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 actually do that. I route my IPTV boxes out via an alternate interface
due to some stupid contractual issues. So all I did was add routing
rules with ip -6 rule add from $addr table Magic and all the Magic table
has is a defaultroute out via the other interface. Same as IPv4. But
maybe your policy routing is something different?

For sure this would be a problem if the IPv6 addresses were changing all
the time but they haven't.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 14/01/2026 17:49, Anssi Saari wrote:

Pancho <[email protected]> writes:

On 12/30/25 20:00, David Higton wrote:

In message <10iv40e$1e1ba$[email protected]>
Pancho <[email protected]> wrote:

IPv6 seems like a world of pain.

In my experience it just works.

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 actually do that. I route my IPTV boxes out via an alternate interface
due to some stupid contractual issues. So all I did was add routing
rules with ip -6 rule add from $addr table Magic and all the Magic table
has is a defaultroute out via the other interface. Same as IPv4. But
maybe your policy routing is something different?

For sure this would be a problem if the IPv6 addresses were changing all
the time but they haven't.

Some routers will let you use the source mac address in routing rules
which nicely overcomes the problem with varying IPv6 addresses.

John

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On Wed, 14 Jan 2026 17:57:35 +0000, John R Walliker wrote:

Some routers will let you use the source mac address in routing rules
which nicely overcomes the problem with varying IPv6 addresses.

That could also be handled with a VLAN.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 1/14/26 17:49, Anssi Saari wrote:

Pancho <[email protected]> writes:

On 12/30/25 20:00, David Higton wrote:

In message <10iv40e$1e1ba$[email protected]>
Pancho <[email protected]> wrote:

IPv6 seems like a world of pain.

In my experience it just works.

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 actually do that. I route my IPTV boxes out via an alternate interface
due to some stupid contractual issues. So all I did was add routing
rules with ip -6 rule add from $addr table Magic and all the Magic table
has is a defaultroute out via the other interface. Same as IPv4. But
maybe your policy routing is something different?

For sure this would be a problem if the IPv6 addresses were changing all
the time but they haven't.

Yes, that is the kind of thing but.. there was a bug in the pfSense
firewall rules. pfSense is a freeBSD firewall/router.

The bug was that pfSense allows you to predicate firewall rules on an
"alias", which can be a list of Full Qualified Domain Names. Something
like if the source host FQDN is in this alias, route over this gateway
to the WAN. The FQDNs resolve to an IPv4 and IPv6 addresses and then
checks the IP value in a packet and routes accordingly. This works fine
for a WAN FQDN, like e.g. www.google.com, it includes both IPv4 and IPv6 addresses. However, for hosts on my LAN, e.g. myhost.home.arpa if there
was an IPv4 address it gave only IPv4 and ignored the IPv6 one. I can
work around it by creating an extra FQDN for IPv6 e.g.
myhost.ipv6.home.arpa, but it takes time to understand why things don't
work.

Then there is the issue of the extra random IPv6 addresses it was
creating, which aren't included in DNS, in the FQDN at all.

That is the second IPv6 bug in pfSense, after the MTU/packet
fragmentation bug I mentioned earlier, which I'm still trying to get to
the bottom of.

IPv6 seems surprisingly hard. Surprising if a significant proportion of
people are using it.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On Thu, 15 Jan 2026 01:17:23 +0000, Pancho wrote:

That is the second IPv6 bug in pfSense, after the MTU/packet
fragmentation bug I mentioned earlier, which I'm still trying to get
to the bottom of.

IPv6 seems surprisingly hard.

pfSense is built on FreeBSD and uses that network stack instead of
Linux, isn’t it?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 1/14/26 21:13, Lawrence D’Oliveiro wrote:

On Wed, 14 Jan 2026 17:57:35 +0000, John R Walliker wrote:

Some routers will let you use the source mac address in routing rules
which nicely overcomes the problem with varying IPv6 addresses.

That could also be handled with a VLAN.

If your network hardware handles VLAN tags.

I have numerous switches (unmanaged) and WiFi access points, none of the
ones I tested were compatible with VLAN tags (i.e. The network device
stripped the VLAN tag off packets rather than dumbly passed the packet
through with VLAN tag intact).

VLANs also aren't ideal as you may wish to implement policy routing on a protocol (e.g. VoIP) or WAN destination, not just upon a LAN host.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 1/15/26 05:10, Lawrence D’Oliveiro wrote:

On Thu, 15 Jan 2026 01:17:23 +0000, Pancho wrote:

That is the second IPv6 bug in pfSense, after the MTU/packet
fragmentation bug I mentioned earlier, which I'm still trying to get
to the bottom of.

IPv6 seems surprisingly hard.

pfSense is built on FreeBSD and uses that network stack instead of
Linux, isn’t it?

Yeah, I wasn't pointing out the bugs as directly relevant to Linux. I
was mentioning them to support my suspicions about a general lack of
maturity of IPv6 in products.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 15/01/2026 13:33, Pancho wrote:

On 1/14/26 21:13, Lawrence D’Oliveiro wrote:

On Wed, 14 Jan 2026 17:57:35 +0000, John R Walliker wrote:

Some routers will let you use the source mac address in routing rules
which nicely overcomes the problem with varying IPv6 addresses.

That could also be handled with a VLAN.

If your network hardware handles VLAN tags.

I have numerous switches (unmanaged) and WiFi access points, none of the ones I tested were compatible with VLAN tags (i.e. The network device stripped the VLAN tag off packets rather than dumbly passed the packet through with VLAN tag intact).

VLANs also aren't ideal as you may wish to implement policy routing on a protocol (e.g. VoIP) or WAN destination, not just upon a LAN host.

There does seem to be a lot of variation in how different switches
behave. The HP 1820 and 1810 series web managed switches along with
a variety of Netgear web managed switches all propagate vlan tags in
their default state.
They can can be configured to detag vlans on specific ports if
necessary.
I have some Allied Telesis managed switches that block vlans by default.

John

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On Thu, 15 Jan 2026 13:33:44 +0000, Pancho wrote:

On 1/14/26 21:13, Lawrence D’Oliveiro wrote:

On Wed, 14 Jan 2026 17:57:35 +0000, John R Walliker wrote:

Some routers will let you use the source mac address in routing
rules which nicely overcomes the problem with varying IPv6
addresses.

That could also be handled with a VLAN.

If your network hardware handles VLAN tags.

I’m sure this could be done using a Linux box as your network
switch/router.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

John R Walliker <[email protected]> writes:

Some routers will let you use the source mac address in routing rules
which nicely overcomes the problem with varying IPv6 addresses.

Indeed. I wish I could do that easily in Linux but it seems a bit of a
chore. But looks like nftables packet marking and policy based routing
together can accomplish it. So all I need is the marking part and a
little tweaking of my policy routing to use those marks instead of
source IPv6 addresses.

Something to do later, I'm working on something else right now.

--- Synchronet 3.21b-Linux NewsLink 1.2