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$1@dont-email.me>
Pancho <Pancho.Jones@protonmail.com> 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 <Pancho.Jones@protonmail.com> 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 <Pancho.Jones@protonmail.com> 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 <attend@homesrv.net> 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 <Pancho.Jones@protonmail.com> writes:

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

In message <10iv40e$1e1ba$1@dont-email.me>
Pancho <Pancho.Jones@protonmail.com> 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 <Pancho.Jones@protonmail.com> writes:

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

In message <10iv40e$1e1ba$1@dont-email.me>
Pancho <Pancho.Jones@protonmail.com> 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 <Pancho.Jones@protonmail.com> writes:

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

In message <10iv40e$1e1ba$1@dont-email.me>
Pancho <Pancho.Jones@protonmail.com> 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 <jrwalliker@gmail.com> 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