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.
On 27/12/2025 17:34, Jim Diamond wrote:
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?
For years my main *86 server would register itself with DHCP first, then manually set its IP address to something else.
In the end I plugged in a screen and used the GUI and net manager to
sort it all out, and it stayed sorted out.
The problem is that there have been so many ways to set up IP over the
last few years that any online guidance has at best a 25% chance of
doing it the way the distro thinks it ought to be done,
On 27/12/2025 18:17, The Natural Philosopher wrote:
On 27/12/2025 17:34, Jim Diamond wrote:
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?
For years my main *86 server would register itself with DHCP first,
then manually set its IP address to something else.
In the end I plugged in a screen and used the GUI and net manager to
sort it all out, and it stayed sorted out.
The problem is that there have been so many ways to set up IP over the
last few years that any online guidance has at best a 25% chance of
doing it the way the distro thinks it ought to be done,
Did the Pi itself think that it had two addresses on the WiFi interface
or was it your router / dhcp server that had two records?
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?
No, the Pi thought two IPs were associated with the one and only
wifi card.
On 27/12/2025 18:17, The Natural Philosopher wrote:
On 27/12/2025 17:34, Jim Diamond wrote:
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?
For years my main *86 server would register itself with DHCP first, then
manually set its IP address to something else.
In the end I plugged in a screen and used the GUI and net manager to
sort it all out, and it stayed sorted out.
The problem is that there have been so many ways to set up IP over the
last few years that any online guidance has at best a 25% chance of
doing it the way the distro thinks it ought to be done,
Did the Pi itself think that it had two addresses on the WiFi interface
or was it your router / dhcp server that had two records?
On 12/27/25 23:25, Theo wrote:
Jim Diamond <zsd@jdvb.ca> 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?
Is this two IPv4 addresses? Having multiple IPv6 addresses is completely
routine. As is having one IPv4 and one or more IPv6s.
Yes, I have recently been experimenting with IPv6.
IPv6 uses: Static Addresses, Link-Local, DHCPv6, Router Advertisements,
and SLAAC. Proving me with multiple, often random, IPv6 addresses. This totally broke my IP rule based routing.
Unlike my Linux machines, My Android devices take a whole IPv6 block
(prefix delegation). I think I'll change all my Linux hosts to this too.
I quite like the protection of random addresses, but want them
constrained to a recognisable range for each host.
Some websites fail, some apt repos fail under IPv6.
IPv6 seems like a world of pain.
Richard Kettlewell <invalid@invalid.invalid> wrote:
Jim Diamond <zsd@jdvb.ca> writes:
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.
Where are you finding the two addresses?
What does
ip addr show
display?
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.)
What does
rpi-eeprom-config
display?
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
(Nothing there about BOOT_ORDER, altho my Pi5 (not the computer that showed up with two IPs) does have BOOT_ORDER=0xf461. But it would appear I'd need
a 0x2 in there fairly early for it to try a netboot.)
No, the Pi thought two IPs were associated with the one and only wifi
card. (In fact, I discovered which device it was by ssh-ing in after
nmap told me that it was listening on the sshd port.)
It was in fact two IPv4 addresses. One which the Network Manager configYou can check the routers DHCP table and the MAC addresses associated
file specifies, and the other was some other address which I speculate
came from the router's DHCP server.
Jim
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.
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?
Jim Diamond <zsd@jdvb.ca> 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?
Is this two IPv4 addresses? Having multiple IPv6 addresses is completely routine. As is having one IPv4 and one or more IPv6s.
Jim Diamond <zsd@jdvb.ca> writes:
Richard Kettlewell <invalid@invalid.invalid> wrote:
Jim Diamond <zsd@jdvb.ca> writes:
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.
Where are you finding the two addresses?
What does
ip addr show
display?
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.)
What does
rpi-eeprom-config
display?
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
What model of Pi is it?
(Nothing there about BOOT_ORDER, altho my Pi5 (not the computer that showed >> up with two IPs) does have BOOT_ORDER=0xf461. But it would appear I'd need >> a 0x2 in there fairly early for it to try a netboot.)
Elsewhere:
No, the Pi thought two IPs were associated with the one and only wifi
card. (In fact, I discovered which device it was by ssh-ing in after
nmap told me that it was listening on the sshd port.)
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.
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.
On 2025-12-29 at 13:31 AST, The Natural Philosopher <tnp@invalid.invalid> wrote:
On 29/12/2025 15:08, Jim Diamond wrote:
It was in fact two IPv4 addresses. One which the Network Manager config >>> file specifies, and the other was some other address which I speculate
came from the router's DHCP server.
You can check the routers DHCP table and the MAC addresses associated
with it.
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.
However, it was worth a look. Maybe. According to the router, the
"mystery" address is paired with the wifi card's actual ethernet (MAC) 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.
Jim
On 2025-12-28 at 23:51 AST, Lawrence D?Oliveiro <ldo@nz.invalid> wrote:
On Sun, 28 Dec 2025 23:14:09 -0400, Jim Diamond wrote:
No, the Pi thought two IPs were associated with the one and only
wifi card.
Just a note that this itself is not an error; the Pi doesn?t *think*
the interface has two IPs, it *knows*, because it was configured that
way.
OK... If we want to be really careful with our English, I suppose we should say "The Pi associated two IPv4 addresses with the one and only WiFi card."
Not running any AI on my Pi, I don't think it knows or thinks anything. ;-)
There are legitimate uses for this sort of thing, even though it
was not a deliberate setup in your case.
Quite true, I have used it once or twice in the past myself. (Why I did it is now lost in the depths of time.)
Jim
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?
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.
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?
Because if not, you end up having to assign new addresses to everything on your LAN.
IPv6 seems like a world of pain.
On 2025-12-30 at 01:42 AST, Lawrence D?Oliveiro <ldo@nz.invalid> 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.
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.
The Natural Philosopher wrote:
David Higton wrote:
What I particularly like about IPv6 is that NAT/NAPT are simply notSo making the implementation of a firewall absolutely mandatory
necessary
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.
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...
What I particularly like about IPv6 is that NAT/NAPT are simply not
necessary
Pancho <Pancho.Jones@protonmail.com> writes:
The Natural Philosopher wrote:
David Higton wrote:
What I particularly like about IPv6 is that NAT/NAPT are simply notSo making the implementation of a firewall absolutely mandatory
necessary
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.)
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.
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.
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.
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.
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.
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
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
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
Maybe a neutrino hit
the wrong spot during boot.
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'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.
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.
In message <10j3tmk$29ec2$1@dont-email.me>
Pancho <Pancho.Jones@protonmail.com> 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?
In message <10j3tdq$29dt0$1@dont-email.me>
Pancho <Pancho.Jones@protonmail.com> wrote:
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'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.
On 31/12/2025 20:18, Richard Kettlewell wrote:
Pancho <Pancho.Jones@protonmail.com> writes:
The Natural Philosopher wrote:
David Higton wrote:
What I particularly like about IPv6 is that NAT/NAPT are simply notSo making the implementation of a firewall absolutely mandatory
necessary
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.
The internal network destination address_is_ in its routing table.
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.
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,
On 01/01/2026 11:34, Richard Kettlewell wrote:
The Natural Philosopher <tnp@invalid.invalid> writes:
On 31/12/2025 20:18, Richard Kettlewell wrote:Same as routing any other packet. Make sure there?s an appropriate
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.
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 itsI can't believe that my router would accept arbitrary packets with
destination on the customer network.
https://www.greenend.org.uk/rjk/tech/nat.html has a worked example.
an internal destination address on its external facing port...
if the destination is not in its tables, it will be automatically discarded...
Jim Diamond <zsd@jdvb.ca> writes:
The Natural Philosopher <tnp@invalid.invalid> 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.
The Natural Philosopher <tnp@invalid.invalid> 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.
On 2025-12-31 at 09:15 AST, Richard Kettlewell <invalid@invalid.invalid> wrote:
druck <news@druck.org.uk> 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
The Natural Philosopher <tnp@invalid.invalid> writes:
On 31/12/2025 20:18, Richard Kettlewell wrote:
Pancho <Pancho.Jones@protonmail.com> writes:
The Natural Philosopher wrote:
David Higton wrote:
What I particularly like about IPv6 is that NAT/NAPT are simply not >>>>>> necessarySo 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.
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.
| Sysop: | Coz |
|---|---|
| Location: | Anoka, MN |
| Users: | 2 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 21:54:57 |
| Calls: | 370 |
| Files: | 6,491 |
| Messages: | 238,629 |