Some software is referencing those IP addresses. Did you run nmap or
something like that?

At Sat, 12 Jul 2025 11:30:26 +0100 The Natural Philosopher <tnp@invalid.invalid> wrote:

For unrelated reasons I took a look at my desktop ARP cache just now..

$arp -a
_gateway (192.168.0.254) at 00:1d:aa:79:78:40 [ether] on eno1
pifi2 (192.168.0.202) at 2c:cf:67:88:c9:4b [ether] on eno1
? (192.168.0.248) at <incomplete> on eno1
? (192.168.0.2) at 1c:5a:3e:7e:37:1f [ether] on eno1
? (192.168.0.221) at <incomplete> on eno1
? (192.168.0.223) at <incomplete> on eno1
Coriolanus (192.168.0.101) at d8:3a:dd:85:22:b1 [ether] on eno1
? (192.168.0.141) at <incomplete> on eno1
? (192.168.0.10) at <incomplete> on eno1
? (192.168.0.58) at <incomplete> on eno1
? (192.168.0.247) at <incomplete> on eno1
heating-controller (192.168.0.201) at b8:27:eb:c3:31:3d [ether] on eno1
? (192.168.0.27) at <incomplete> on eno1
? (192.168.0.203) at <incomplete> on eno1
? (192.168.0.180) at <incomplete> on eno1
? (192.168.0.83) at <incomplete> on eno1
cymbeline (192.168.0.100) at 08:62:66:4a:85:d8 [ether] on eno1
? (192.168.0.102) at 3c:a8:2a:f6:3a:c8 [ether] on eno1
? (192.168.0.16) at <incomplete> on eno1
? (192.168.0.227) at <incomplete> on eno1
? (192.168.0.11) at <incomplete> on eno1
? (192.168.0.239) at <incomplete> on eno1
? (192.168.0.28) at <incomplete> on eno1

The incomplete entries are for IP addresses I simply never have used.

Anyone recognise this behaviour?

After clearing, at least one is back...

--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller@deepsoft.com -- Webhosting Services

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

For unrelated reasons I took a look at my desktop ARP cache just now..

$arp -a
_gateway (192.168.0.254) at 00:1d:aa:79:78:40 [ether] on eno1
pifi2 (192.168.0.202) at 2c:cf:67:88:c9:4b [ether] on eno1
? (192.168.0.248) at <incomplete> on eno1
? (192.168.0.2) at 1c:5a:3e:7e:37:1f [ether] on eno1
? (192.168.0.221) at <incomplete> on eno1
? (192.168.0.223) at <incomplete> on eno1
Coriolanus (192.168.0.101) at d8:3a:dd:85:22:b1 [ether] on eno1
? (192.168.0.141) at <incomplete> on eno1
? (192.168.0.10) at <incomplete> on eno1
? (192.168.0.58) at <incomplete> on eno1
? (192.168.0.247) at <incomplete> on eno1
heating-controller (192.168.0.201) at b8:27:eb:c3:31:3d [ether] on eno1
? (192.168.0.27) at <incomplete> on eno1
? (192.168.0.203) at <incomplete> on eno1
? (192.168.0.180) at <incomplete> on eno1
? (192.168.0.83) at <incomplete> on eno1
cymbeline (192.168.0.100) at 08:62:66:4a:85:d8 [ether] on eno1
? (192.168.0.102) at 3c:a8:2a:f6:3a:c8 [ether] on eno1
? (192.168.0.16) at <incomplete> on eno1
? (192.168.0.227) at <incomplete> on eno1
? (192.168.0.11) at <incomplete> on eno1
? (192.168.0.239) at <incomplete> on eno1
? (192.168.0.28) at <incomplete> on eno1

The incomplete entries are for IP addresses I simply never have used.

Anyone recognise this behaviour?

After clearing, at least one is back...

--
Labour - a bunch of rich people convincing poor people to vote for rich
people by telling poor people that "other" rich people are the reason
they are poor.

Peter Thompson

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/07/2025 11:36, Robert Heller wrote:

Some software is referencing those IP addresses.

Well obiously

Did you run nmap or

something like that?

Nope.

Is it possible that some unpleasant web site is using AJAX/JavaScript
to scan the internal network?

At Sat, 12 Jul 2025 11:30:26 +0100 The Natural Philosopher <tnp@invalid.invalid> wrote:

For unrelated reasons I took a look at my desktop ARP cache just now..

$arp -a
_gateway (192.168.0.254) at 00:1d:aa:79:78:40 [ether] on eno1
pifi2 (192.168.0.202) at 2c:cf:67:88:c9:4b [ether] on eno1
? (192.168.0.248) at <incomplete> on eno1
? (192.168.0.2) at 1c:5a:3e:7e:37:1f [ether] on eno1
? (192.168.0.221) at <incomplete> on eno1
? (192.168.0.223) at <incomplete> on eno1
Coriolanus (192.168.0.101) at d8:3a:dd:85:22:b1 [ether] on eno1
? (192.168.0.141) at <incomplete> on eno1
? (192.168.0.10) at <incomplete> on eno1
? (192.168.0.58) at <incomplete> on eno1
? (192.168.0.247) at <incomplete> on eno1
heating-controller (192.168.0.201) at b8:27:eb:c3:31:3d [ether] on eno1
? (192.168.0.27) at <incomplete> on eno1
? (192.168.0.203) at <incomplete> on eno1
? (192.168.0.180) at <incomplete> on eno1
? (192.168.0.83) at <incomplete> on eno1
cymbeline (192.168.0.100) at 08:62:66:4a:85:d8 [ether] on eno1
? (192.168.0.102) at 3c:a8:2a:f6:3a:c8 [ether] on eno1
? (192.168.0.16) at <incomplete> on eno1
? (192.168.0.227) at <incomplete> on eno1
? (192.168.0.11) at <incomplete> on eno1
? (192.168.0.239) at <incomplete> on eno1
? (192.168.0.28) at <incomplete> on eno1

The incomplete entries are for IP addresses I simply never have used.

Anyone recognise this behaviour?

After clearing, at least one is back...

--
Microsoft : the best reason to go to Linux that ever existed.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/07/2025 11:41, Andy Burns wrote:

The Natural Philosopher wrote:

? (192.168.0.28) at <incomplete> on eno1

The incomplete entries are for IP addresses I simply never have used.

Anyone recognise this behaviour?

After clearing, at least one is back...

Something scanning the subnet?

Well clearly, but what? And why not all of it?

And why only the desktop machine - the laptop is used as much for
internet surfing

--
Microsoft : the best reason to go to Linux that ever existed.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/07/2025 11:43, Richard Kettlewell wrote:

The Natural Philosopher <tnp@invalid.invalid> writes:

? (192.168.0.248) at <incomplete> on eno1

Something tried to reach that address (ping, TCP connect, anything) but nothing responded (yet).

I got that far unaided :-)

My query was, is there any RATware that is known to do this?

whether this exact pattern is familiar to someone?

Hmm. I had an old WIN XP running in a VM. I'll stop that. Maybe it was that


--
Microsoft : the best reason to go to Linux that ever existed.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

The Natural Philosopher wrote:

Andy Burns wrote:

Something scanning the subnet?

Well clearly, but what?

tcpdump capturing the relevant IPs, will tell you if "something" is
looking at specific ports or random ones, netstat will help you find
what process is doing it ...

And why not all of it?

Maybe the process is trying to be sneaky to avoid detection, looks like
it should have scanned at a slower rate in that case, because you
noticed it ...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

The Natural Philosopher wrote:

? (192.168.0.28) at <incomplete> on eno1

The incomplete entries are for IP addresses I simply never have used.

Anyone recognise this behaviour?

After clearing, at least one is back...

Something scanning the subnet?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

The Natural Philosopher <tnp@invalid.invalid> writes:

? (192.168.0.248) at <incomplete> on eno1

Something tried to reach that address (ping, TCP connect, anything) but
nothing responded (yet).

--
https://www.greenend.org.uk/rjk/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/07/2025 12:14, Andy Burns wrote:

The Natural Philosopher wrote:

Andy Burns wrote:

Something scanning the subnet?

Well clearly, but what?

tcpdump capturing the relevant IPs, will tell you if "something" is
looking at specific ports or random ones, netstat will help you find
what process is doing it ...

And why not all of it?

Maybe the process is trying to be sneaky to avoid detection, looks like
it should have scanned at a slower rate in that case, because you
noticed it ...

Well...with the Windows VM shut down I seem to have resolved it...

One IP address may be from many years ago as a printer address using a
Jet Direct unit that is no longer on the network.

But may still be configured in the Windows setup.



--
“There are two ways to be fooled. One is to believe what isn’t true; the other is to refuse to believe what is true.”

—Soren Kierkegaard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/12/25 6:30 AM, The Natural Philosopher wrote:

For unrelated reasons I took a look at my desktop ARP cache just now..

$arp -a
_gateway (192.168.0.254) at 00:1d:aa:79:78:40 [ether] on eno1
pifi2 (192.168.0.202) at 2c:cf:67:88:c9:4b [ether] on eno1
? (192.168.0.248) at <incomplete> on eno1
? (192.168.0.2) at 1c:5a:3e:7e:37:1f [ether] on eno1
? (192.168.0.221) at <incomplete> on eno1
? (192.168.0.223) at <incomplete> on eno1
Coriolanus (192.168.0.101) at d8:3a:dd:85:22:b1 [ether] on eno1
? (192.168.0.141) at <incomplete> on eno1
? (192.168.0.10) at <incomplete> on eno1
? (192.168.0.58) at <incomplete> on eno1
? (192.168.0.247) at <incomplete> on eno1
heating-controller (192.168.0.201) at b8:27:eb:c3:31:3d [ether] on eno1
? (192.168.0.27) at <incomplete> on eno1
? (192.168.0.203) at <incomplete> on eno1
? (192.168.0.180) at <incomplete> on eno1
? (192.168.0.83) at <incomplete> on eno1
cymbeline (192.168.0.100) at 08:62:66:4a:85:d8 [ether] on eno1
? (192.168.0.102) at 3c:a8:2a:f6:3a:c8 [ether] on eno1
? (192.168.0.16) at <incomplete> on eno1
? (192.168.0.227) at <incomplete> on eno1
? (192.168.0.11) at <incomplete> on eno1
? (192.168.0.239) at <incomplete> on eno1
? (192.168.0.28) at <incomplete> on eno1

The incomplete entries are for IP addresses I simply never have used.

Anyone recognise this behaviour?

After clearing, at least one is back...

This could be a case of your router remembering
where DHCP addresses USED to be. Even if you later
set the devices to static, the old associations
are't necessarily cleared. ARP may just be
smelling traces of the missing devices.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

At Sat, 12 Jul 2025 21:29:32 -0300 Shadow <Sh@dow.br> wrote:

On Sat, 12 Jul 2025 11:30:26 +0100, The Natural Philosopher <tnp@invalid.invalid> wrote:

For unrelated reasons I took a look at my desktop ARP cache just now..

$arp -a
_gateway (192.168.0.254) at 00:1d:aa:79:78:40 [ether] on eno1
pifi2 (192.168.0.202) at 2c:cf:67:88:c9:4b [ether] on eno1
? (192.168.0.248) at <incomplete> on eno1
? (192.168.0.2) at 1c:5a:3e:7e:37:1f [ether] on eno1
? (192.168.0.221) at <incomplete> on eno1
? (192.168.0.223) at <incomplete> on eno1
Coriolanus (192.168.0.101) at d8:3a:dd:85:22:b1 [ether] on eno1
? (192.168.0.141) at <incomplete> on eno1
? (192.168.0.10) at <incomplete> on eno1
? (192.168.0.58) at <incomplete> on eno1
? (192.168.0.247) at <incomplete> on eno1
heating-controller (192.168.0.201) at b8:27:eb:c3:31:3d [ether] on eno1
? (192.168.0.27) at <incomplete> on eno1
? (192.168.0.203) at <incomplete> on eno1
? (192.168.0.180) at <incomplete> on eno1
? (192.168.0.83) at <incomplete> on eno1
cymbeline (192.168.0.100) at 08:62:66:4a:85:d8 [ether] on eno1
? (192.168.0.102) at 3c:a8:2a:f6:3a:c8 [ether] on eno1
? (192.168.0.16) at <incomplete> on eno1
? (192.168.0.227) at <incomplete> on eno1
? (192.168.0.11) at <incomplete> on eno1
? (192.168.0.239) at <incomplete> on eno1
? (192.168.0.28) at <incomplete> on eno1

The incomplete entries are for IP addresses I simply never have used.

Anyone recognise this behaviour?

After clearing, at least one is back...

My TV is always in my arp cache. I kind of got used to the
intrusion.
[]'s

Likely it is because you have the "instant on" (whatever it may be called) feature on. I suspect this means that the TV is in "sleep" mode rather than fully powered down. The processor is "running" in some minimual state and is maintaining a minimual network connection.

--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller@deepsoft.com -- Webhosting Services

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 12 Jul 2025 11:30:26 +0100, The Natural Philosopher <tnp@invalid.invalid> wrote:

For unrelated reasons I took a look at my desktop ARP cache just now..

$arp -a
_gateway (192.168.0.254) at 00:1d:aa:79:78:40 [ether] on eno1
pifi2 (192.168.0.202) at 2c:cf:67:88:c9:4b [ether] on eno1
? (192.168.0.248) at <incomplete> on eno1
? (192.168.0.2) at 1c:5a:3e:7e:37:1f [ether] on eno1
? (192.168.0.221) at <incomplete> on eno1
? (192.168.0.223) at <incomplete> on eno1
Coriolanus (192.168.0.101) at d8:3a:dd:85:22:b1 [ether] on eno1
? (192.168.0.141) at <incomplete> on eno1
? (192.168.0.10) at <incomplete> on eno1
? (192.168.0.58) at <incomplete> on eno1
? (192.168.0.247) at <incomplete> on eno1
heating-controller (192.168.0.201) at b8:27:eb:c3:31:3d [ether] on eno1
? (192.168.0.27) at <incomplete> on eno1
? (192.168.0.203) at <incomplete> on eno1
? (192.168.0.180) at <incomplete> on eno1
? (192.168.0.83) at <incomplete> on eno1
cymbeline (192.168.0.100) at 08:62:66:4a:85:d8 [ether] on eno1
? (192.168.0.102) at 3c:a8:2a:f6:3a:c8 [ether] on eno1
? (192.168.0.16) at <incomplete> on eno1
? (192.168.0.227) at <incomplete> on eno1
? (192.168.0.11) at <incomplete> on eno1
? (192.168.0.239) at <incomplete> on eno1
? (192.168.0.28) at <incomplete> on eno1

The incomplete entries are for IP addresses I simply never have used.

Anyone recognise this behaviour?

After clearing, at least one is back...

My TV is always in my arp cache. I kind of got used to the
intrusion.
[]'s
--
Don't be evil - Google 2004
We have a new policy - Google 2012
Google Fuchsia - 2021

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 12 Jul 2025 13:06:22 +0100, The Natural Philosopher wrote:

Well...with the Windows VM shut down I seem to have resolved it...

It’s always Windows, isn’t it?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/12/25 9:20 PM, Lawrence D'Oliveiro wrote:

On Sat, 12 Jul 2025 13:06:22 +0100, The Natural Philosopher wrote:

Well...with the Windows VM shut down I seem to have resolved it...

It’s always Windows, isn’t it?

Heh, heh ... keep Winders out of EVERYTHING, or else.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Robert Heller wrote:

I suspect this means that the TV is in "sleep" mode rather than
fully powered down. The processor is "running" in some minimual state and is maintaining a minimual network connection.

I've got two devices with a horrible ARP implementation, they don't send
ARP replies in response to ARP requests, instead they constantly
broadcast ARP replies for their own IP/MAC combination.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/13/25 1:35 AM, Andy Burns wrote:

Robert Heller wrote:

I suspect this means that the TV is in "sleep" mode rather than
fully powered down.  The processor is "running" in some minimual state
and is
maintaining a minimual network connection.

I've got two devices with a horrible ARP implementation, they don't send
ARP replies in response to ARP requests, instead they constantly
broadcast ARP replies for their own IP/MAC combination.

Old DCHP addresses tend to hang-out in routers.
Change them to static later - doesn't matter.
The device/IP info remains in router memory.
Some utilities WILL note this, and try to
send packets.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 13/07/2025 05:16, c186282 wrote:

On 7/12/25 9:20 PM, Lawrence D'Oliveiro wrote:

On Sat, 12 Jul 2025 13:06:22 +0100, The Natural Philosopher wrote:

Well...with the Windows VM shut down I seem to have resolved it...

It’s always Windows, isn’t it?

  Heh, heh ... keep Winders out of EVERYTHING, or else.

For once,. you may be right.

That 'winders' was installed about 2005, and the VM has been faithfully
copied across at least 4 new hosts as the original hardware died.

During that time devices - especially networked printers - have come and
gone

The extraordinary thing is that the winders remembers where they were...

I found a magic spell on line to clear the winders ARP cache. Then
deleted all the ghosts of the printers it had once known. Then rebooted
it, then cleared the cache again and after leaving it running overnight...

$ arp -a
_gateway (192.168.0.254) at 00:1d:aa:79:78:40 [ether] on eno1
? (192.168.0.248) at <incomplete> on eno1
Coriolanus (192.168.0.101) at d8:3a:dd:85:22:b1 [ether] on eno1 heating-controller (192.168.0.201) at b8:27:eb:c3:31:3d [ether] on eno1 cymbeline (192.168.0.100) at 08:62:66:4a:85:d8 [ether] on eno1

It still seems to be looking for a printer on 192.168.0.248...which was
where the default old B & W laserjet was, years ago.

Simply cant seem to purge that one.
Still its answered the qustion. Where was all that shit?
Answer? In windows XPs arp cache.

I am content to discover its harmless enough.

--
"The most difficult subjects can be explained to the most slow witted
man if he has not formed any idea of them already; but the simplest
thing cannot be made clear to the most intelligent man if he is firmly persuaded that he knows already, without a shadow of doubt, what is laid
before him."

- Leo Tolstoy

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 13/07/2025 00:33, c186282 wrote:

On 7/12/25 6:30 AM, The Natural Philosopher wrote:

For unrelated reasons I took a look at my desktop ARP cache just now..

$arp -a
_gateway (192.168.0.254) at 00:1d:aa:79:78:40 [ether] on eno1
pifi2 (192.168.0.202) at 2c:cf:67:88:c9:4b [ether] on eno1
? (192.168.0.248) at <incomplete> on eno1
? (192.168.0.2) at 1c:5a:3e:7e:37:1f [ether] on eno1
? (192.168.0.221) at <incomplete> on eno1
? (192.168.0.223) at <incomplete> on eno1
Coriolanus (192.168.0.101) at d8:3a:dd:85:22:b1 [ether] on eno1
? (192.168.0.141) at <incomplete> on eno1
? (192.168.0.10) at <incomplete> on eno1
? (192.168.0.58) at <incomplete> on eno1
? (192.168.0.247) at <incomplete> on eno1
heating-controller (192.168.0.201) at b8:27:eb:c3:31:3d [ether] on eno1
? (192.168.0.27) at <incomplete> on eno1
? (192.168.0.203) at <incomplete> on eno1
? (192.168.0.180) at <incomplete> on eno1
? (192.168.0.83) at <incomplete> on eno1
cymbeline (192.168.0.100) at 08:62:66:4a:85:d8 [ether] on eno1
? (192.168.0.102) at 3c:a8:2a:f6:3a:c8 [ether] on eno1
? (192.168.0.16) at <incomplete> on eno1
? (192.168.0.227) at <incomplete> on eno1
? (192.168.0.11) at <incomplete> on eno1
? (192.168.0.239) at <incomplete> on eno1
? (192.168.0.28) at <incomplete> on eno1

The incomplete entries are for IP addresses I simply never have used.

Anyone recognise this behaviour?

After clearing, at least one is back...

  This could be a case of your router remembering
  where DHCP addresses USED to be. Even if you later
  set the devices to static, the old associations
  are't necessarily cleared. ARP may just be
  smelling traces of the missing devices.

Er no. This cache existed in the desktop computer only, not the router,
at all.
And its nothing to do with DHCP.

Its an ARP cache. Not DHCP.

--
"The most difficult subjects can be explained to the most slow witted
man if he has not formed any idea of them already; but the simplest
thing cannot be made clear to the most intelligent man if he is firmly persuaded that he knows already, without a shadow of doubt, what is laid
before him."

- Leo Tolstoy

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

The Natural Philosopher <tnp@invalid.invalid> writes:

For unrelated reasons I took a look at my desktop ARP cache just now..

$arp -a
? (192.168.0.248) at <incomplete> on eno1

Something is handing out ip4 addresses in the block 192.168.0.* and
those entries are hanging around. You don't see what is being handed out
unless you keep a close eye on your DHCP server.

Here's one example from mine:

? (192.168.20.12) at <incomplete> on br0
? (192.168.20.52) at aa:00:04:00:14:04 [ether] on br0
? (192.168.20.61) at aa:00:04:00:10:04 [ether] on br0
? (192.168.20.56) at 5c:84:3c:f1:23:2f [ether] on br0
? (192.168.20.10) at 3e:04:51:7a:a5:d8 [ether] on br0

What is .20.12? According to the lease it is:
lease 192.168.20.12 {
starts 0 2024/10/13 21:13:07;
ends 0 2024/10/13 23:13:07;
tstp 0 2024/10/13 23:13:07;
cltt 0 2024/10/13 21:13:07;
binding state free;
hardware ethernet 14:1f:78:85:66:72;
uid "\001\024\037x\205fr";
set vendor-class-identifier = "android-dhcp-7.1.1";
}

Which according to /etc/ethers
#14:1f:78:85:66:72 SAMSUNG-SM-J320

is a Samsung smartphone I've not had powered on in some time. It's in
the ARP cache because something (likley dhcpd) is still referencing
it. It can't respond back because it is powered off as I don't use it
anymore but for a rare test.

--
PGP Key ID: 781C A3E2 C6ED 70A6 B356 7AF5 B510 542E D460 5CAE
"The Internet should always be the Wild West!"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 13/07/2025 18:03, jayjwa wrote:

The Natural Philosopher <tnp@invalid.invalid> writes:

For unrelated reasons I took a look at my desktop ARP cache just now..

$arp -a
? (192.168.0.248) at <incomplete> on eno1

Something is handing out ip4 addresses in the block 192.168.0.* and
those entries are hanging around. You don't see what is being handed out unless you keep a close eye on your DHCP server.

Here's one example from mine:

? (192.168.20.12) at <incomplete> on br0
? (192.168.20.52) at aa:00:04:00:14:04 [ether] on br0
? (192.168.20.61) at aa:00:04:00:10:04 [ether] on br0
? (192.168.20.56) at 5c:84:3c:f1:23:2f [ether] on br0
? (192.168.20.10) at 3e:04:51:7a:a5:d8 [ether] on br0

What is .20.12? According to the lease it is:
lease 192.168.20.12 {
starts 0 2024/10/13 21:13:07;
ends 0 2024/10/13 23:13:07;
tstp 0 2024/10/13 23:13:07;
cltt 0 2024/10/13 21:13:07;
binding state free;
hardware ethernet 14:1f:78:85:66:72;
uid "\001\024\037x\205fr";
set vendor-class-identifier = "android-dhcp-7.1.1";
}

Which according to /etc/ethers
#14:1f:78:85:66:72 SAMSUNG-SM-J320

is a Samsung smartphone I've not had powered on in some time. It's in
the ARP cache because something (likley dhcpd) is still referencing
it. It can't respond back because it is powered off as I don't use it
anymore but for a rare test.

Yes. clearing the ARP cache clears that though
I have some spuriosities (sic?) that are definitely transient devices
that have come and gone, but my DHCP range stops short of most of the rest.

But having cleared the cache, the only one that has returned is the long
gone laserjet ...

which I cant seem to erase out of windows.

--
"A point of view can be a dangerous luxury when substituted for insight
and understanding".

Marshall McLuhan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 13 Jul 2025 21:46:30 +0100, The Natural Philosopher <tnp@invalid.invalid> wrote in <10515v7$2u46l$17@dont-email.me>:

On 13/07/2025 18:03, jayjwa wrote:

The Natural Philosopher <tnp@invalid.invalid> writes:

For unrelated reasons I took a look at my desktop ARP cache just now..

$arp -a ? (192.168.0.248) at <incomplete> on eno1

Something is handing out ip4 addresses in the block 192.168.0.* and
those entries are hanging around. You don't see what is being handed
out unless you keep a close eye on your DHCP server.

Here's one example from mine:

? (192.168.20.12) at <incomplete> on br0 ? (192.168.20.52) at
aa:00:04:00:14:04 [ether] on br0 ? (192.168.20.61) at aa:00:04:00:10:04
[ether] on br0 ? (192.168.20.56) at 5c:84:3c:f1:23:2f [ether] on br0 ?
(192.168.20.10) at 3e:04:51:7a:a5:d8 [ether] on br0

What is .20.12? According to the lease it is:
lease 192.168.20.12 {
starts 0 2024/10/13 21:13:07;
ends 0 2024/10/13 23:13:07;
tstp 0 2024/10/13 23:13:07;
cltt 0 2024/10/13 21:13:07;
binding state free;
hardware ethernet 14:1f:78:85:66:72;
uid "\001\024\037x\205fr";
set vendor-class-identifier = "android-dhcp-7.1.1";
}

Which according to /etc/ethers #14:1f:78:85:66:72 SAMSUNG-SM-J320

is a Samsung smartphone I've not had powered on in some time. It's in
the ARP cache because something (likley dhcpd) is still referencing it.
It can't respond back because it is powered off as I don't use it
anymore but for a rare test.

(responding to jayjwa):
Something is trying to ping or otherwise contact your phone address,
which could even be dhcpd itself.

Yes. clearing the ARP cache clears that though I have some spuriosities (sic?) that are definitely transient devices that have come and gone,
but my DHCP range stops short of most of the rest.

But having cleared the cache, the only one that has returned is the long
gone laserjet ...

which I cant seem to erase out of windows.

To summarize your discoveries: if your host tries to contact an
address that isn't there, you'll end up with incomplete arp
entries, which are harmless[*].

Here's an example using 192.168.23.3, which doesn't exist on my network:

$ ping -c 1 192.168.23.3
PING 192.168.23.3 (192.168.23.3) 56(84) bytes of data.
From 192.168.23.254 icmp_seq=1 Destination Host Unreachable

--- 192.168.23.3 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

$ arp -a 192.168.23.3
? (192.168.23.3) at <incomplete> on enp68s0f0

[*] Incomplete arp entries are harmless, but could indicate
a problem -- there used to be a problem known as an "arp storm"
that could happen before network stacks got a little more...robust.

You can used tcpdump to make sure your network is healthy:

# tcpdump -s1500 -pn -v -v arp
tcpdump: listening on enp68s0f0, link-type EN10MB (Ethernet), snapshot
length 1500 bytes
15:05:23.283910 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.23.254 tell 192.168.23.1, length 46
15:05:23.283926 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.23.254
is-at xx:xx:xx:xx:xx:xx, length 28

...where "xx:xx:xx:xx:xx:xx" is the MAC address of the machine
at 192.168.23.254. This tcpdump command should be fairly quiet,
unless there is a problem.

(I just got a 10G fiber connection(!!! woohoo!), and so I've been

On Sun, 13 Jul 2025 12:01:30 +0100, The Natural Philosopher wrote:

I found a magic spell on line to clear the [Dimdows] ARP cache.

I wonder why you needed one? On *nix, the cache is kept entirely in
volatile storage, so nothing persists across a reboot.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/13/25 6:52 AM, The Natural Philosopher wrote:

On 13/07/2025 00:33, c186282 wrote:

On 7/12/25 6:30 AM, The Natural Philosopher wrote:

For unrelated reasons I took a look at my desktop ARP cache just now..

$arp -a
_gateway (192.168.0.254) at 00:1d:aa:79:78:40 [ether] on eno1
pifi2 (192.168.0.202) at 2c:cf:67:88:c9:4b [ether] on eno1
? (192.168.0.248) at <incomplete> on eno1
? (192.168.0.2) at 1c:5a:3e:7e:37:1f [ether] on eno1
? (192.168.0.221) at <incomplete> on eno1
? (192.168.0.223) at <incomplete> on eno1
Coriolanus (192.168.0.101) at d8:3a:dd:85:22:b1 [ether] on eno1
? (192.168.0.141) at <incomplete> on eno1
? (192.168.0.10) at <incomplete> on eno1
? (192.168.0.58) at <incomplete> on eno1
? (192.168.0.247) at <incomplete> on eno1
heating-controller (192.168.0.201) at b8:27:eb:c3:31:3d [ether] on eno1
? (192.168.0.27) at <incomplete> on eno1
? (192.168.0.203) at <incomplete> on eno1
? (192.168.0.180) at <incomplete> on eno1
? (192.168.0.83) at <incomplete> on eno1
cymbeline (192.168.0.100) at 08:62:66:4a:85:d8 [ether] on eno1
? (192.168.0.102) at 3c:a8:2a:f6:3a:c8 [ether] on eno1
? (192.168.0.16) at <incomplete> on eno1
? (192.168.0.227) at <incomplete> on eno1
? (192.168.0.11) at <incomplete> on eno1
? (192.168.0.239) at <incomplete> on eno1
? (192.168.0.28) at <incomplete> on eno1

The incomplete entries are for IP addresses I simply never have used.

Anyone recognise this behaviour?

After clearing, at least one is back...

   This could be a case of your router remembering
   where DHCP addresses USED to be. Even if you later
   set the devices to static, the old associations
   are't necessarily cleared. ARP may just be
   smelling traces of the missing devices.

Er no. This cache existed in the desktop computer only, not the router,
at all.
And its nothing to do with DHCP.

Its an ARP cache. Not DHCP.

Ummm ... "cache" is the key-word.

I think the OP is seeing junk associated
with OLD addresses. MOST likely source is
the router - but old junk CAN persist on
a local PC too.

In short, I don't think he's seeing anything
REAL or RELEVANT.

I did IT for a smallish company for 20+ years.
This sort of weird stuff was NOT unusual at
all. It didn't MEAN anything ... just an artifact
of old caches/logs/tables.

"Small-ish" was an ADVANTAGE here - the data
volume/depth was NOT overwhelming ... you could
have time to probe and analyze.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/13/25 4:46 PM, The Natural Philosopher wrote:

On 13/07/2025 18:03, jayjwa wrote:

The Natural Philosopher <tnp@invalid.invalid> writes:

For unrelated reasons I took a look at my desktop ARP cache just now..

$arp -a
? (192.168.0.248) at <incomplete> on eno1

Something is handing out ip4 addresses in the block 192.168.0.* and
those entries are hanging around. You don't see what is being handed out
unless you keep a close eye on your DHCP server.

Here's one example from mine:

? (192.168.20.12) at <incomplete> on br0
? (192.168.20.52) at aa:00:04:00:14:04 [ether] on br0
? (192.168.20.61) at aa:00:04:00:10:04 [ether] on br0
? (192.168.20.56) at 5c:84:3c:f1:23:2f [ether] on br0
? (192.168.20.10) at 3e:04:51:7a:a5:d8 [ether] on br0

What is .20.12? According to the lease it is:
lease 192.168.20.12 {
   starts 0 2024/10/13 21:13:07;
   ends 0 2024/10/13 23:13:07;
   tstp 0 2024/10/13 23:13:07;
   cltt 0 2024/10/13 21:13:07;
   binding state free;
   hardware ethernet 14:1f:78:85:66:72;
   uid "\001\024\037x\205fr";
   set vendor-class-identifier = "android-dhcp-7.1.1";
}

Which according to /etc/ethers
#14:1f:78:85:66:72    SAMSUNG-SM-J320

is a Samsung smartphone I've not had powered on in some time. It's in
the ARP cache because something (likley dhcpd) is still referencing
it. It can't respond back because it is powered off as I don't use it
anymore but for a rare test.

Yes. clearing the ARP cache clears that though
I have some spuriosities (sic?) that are definitely transient devices
that have come and gone, but my DHCP range stops short of most of the rest.

But having cleared the cache, the only one that has returned is the long
gone laserjet ...

which I cant seem to erase out of windows.

Never, EVER, use WINDERS ... :-)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-07-14 00:10, Lawrence D'Oliveiro wrote:

On Sun, 13 Jul 2025 12:01:30 +0100, The Natural Philosopher wrote:

I found a magic spell on line to clear the [Dimdows] ARP cache.

I wonder why you needed one? On *nix, the cache is kept entirely in
volatile storage, so nothing persists across a reboot.

Because the Windows virtual machine recreates it across a reboot.

--
Cheers, Carlos.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 14/07/2025 09:19, Carlos E.R. wrote:

On 2025-07-14 00:10, Lawrence D'Oliveiro wrote:

On Sun, 13 Jul 2025 12:01:30 +0100, The Natural Philosopher wrote:

I found a magic spell on line to clear the [Dimdows] ARP cache.

I wonder why you needed one? On *nix, the cache is kept entirely in
volatile storage, so nothing persists across a reboot.

Because the Windows virtual machine recreates it across a reboot.

I think this is, in the end the correct answer.
And my windows VM seldom gets 'rebooted' it normally gets 'suspended'

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 14 Jul 2025 08:06:42 -0700, John Ames wrote:

DHCP was a mistake, full stop.

The Microsoft implementation of it is where the mistake lies. DHCP itself
is extremely useful, and works fine across a range of systems as long as Microsoft is not involved.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-07-14 15:54, The Natural Philosopher wrote:

On 14/07/2025 09:19, Carlos E.R. wrote:

On 2025-07-14 00:10, Lawrence D'Oliveiro wrote:

On Sun, 13 Jul 2025 12:01:30 +0100, The Natural Philosopher wrote:

I found a magic spell on line to clear the [Dimdows] ARP cache.

I wonder why you needed one? On *nix, the cache is kept entirely in
volatile storage, so nothing persists across a reboot.

Because the Windows virtual machine recreates it across a reboot.

I think this is, in the end the correct answer.
And my windows VM seldom gets 'rebooted' it normally gets 'suspended'

Yeah. But that it remembered machines from years before, is a surprise.

--
Cheers, Carlos.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 15/07/2025 10:58, Carlos E.R. wrote:

On 2025-07-14 15:54, The Natural Philosopher wrote:

On 14/07/2025 09:19, Carlos E.R. wrote:

On 2025-07-14 00:10, Lawrence D'Oliveiro wrote:

On Sun, 13 Jul 2025 12:01:30 +0100, The Natural Philosopher wrote:

I found a magic spell on line to clear the [Dimdows] ARP cache.

I wonder why you needed one? On *nix, the cache is kept entirely in
volatile storage, so nothing persists across a reboot.

Because the Windows virtual machine recreates it across a reboot.

I think this is, in the end the correct answer.
And my windows VM seldom gets 'rebooted' it normally gets 'suspended'

Yeah. But that it remembered machines from years before, is a surprise.

Not with Winders!

Especially a VM that has remained essentially unchanged for 20 years.

No Windows on a real computer could last the long!

WMRN is the winders motto. Write many remove never.

--
The biggest threat to humanity comes from socialism, which has utterly
diverted our attention away from what really matters to our existential survival, to indulging in navel gazing and faux moral investigations
into what the world ought to be, whilst we fail utterly to deal with
what it actually is.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/14/25 4:19 AM, Carlos E.R. wrote:

On 2025-07-14 00:10, Lawrence D'Oliveiro wrote:

On Sun, 13 Jul 2025 12:01:30 +0100, The Natural Philosopher wrote:

I found a magic spell on line to clear the [Dimdows] ARP cache.

I wonder why you needed one? On *nix, the cache is kept entirely in
volatile storage, so nothing persists across a reboot.

Because the Windows virtual machine recreates it across a reboot.

Well, that's so "helpful" .......

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/14/25 6:05 PM, Lawrence D'Oliveiro wrote:

On Mon, 14 Jul 2025 08:06:42 -0700, John Ames wrote:

DHCP was a mistake, full stop.

The Microsoft implementation of it is where the mistake lies. DHCP itself
is extremely useful, and works fine across a range of systems as long as Microsoft is not involved.

Everything works better when M$ is not involved ...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/14/25 11:06 AM, John Ames wrote:

On Sun, 13 Jul 2025 02:30:11 -0400
c186282 <c186282@nnada.net> wrote:

Old DCHP addresses tend to hang-out in routers. Change them to static
later - doesn't matter. The device/IP info remains in router memory.
Some utilities WILL note this, and try to send packets.

Causes no end of trouble in $DAYJOB - try to maintina a local file-
share between customers' office PCs and even if Windows isn't being
stubborn about NetBIOS name resolution, it's guaranteed that at some
point the host machine will get a new IP and yet the same damn router
that handed it out will respond to DNS requests with the old IP!

Yep - was IT Guy for an office - almost all Win desktops,
but -IX file servers. Seen this effect often. A number of
things can make the desktop/device change IPs, but not
everything in the system notes the change, doesn't suddenly
forget What Was. "Phantom" machines start to populate
every cache.

(Set it to a static IP and, guaranteed, some "helpful" local IT mook
will come along a couple months later and switch it back...)

DHCP was a mistake, full stop.

Agreed. DHCP made things "easier" - but not
better/safer.

As much as possible I always set every box, every
printer, every IP cam, every useful PI, to static.
A bit "more work", but you knew where everything
was and didn't have to worry so much about those
"phantoms".

IMHO, all new devices should come set to xxx.xxx.xxx.254
and then you immediately set them to the static IP that
fits your scheme.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-07-15 16:20, The Natural Philosopher wrote:

On 15/07/2025 10:58, Carlos E.R. wrote:

On 2025-07-14 15:54, The Natural Philosopher wrote:

On 14/07/2025 09:19, Carlos E.R. wrote:

On 2025-07-14 00:10, Lawrence D'Oliveiro wrote:

On Sun, 13 Jul 2025 12:01:30 +0100, The Natural Philosopher wrote:

I found a magic spell on line to clear the [Dimdows] ARP cache.

I wonder why you needed one? On *nix, the cache is kept entirely in
volatile storage, so nothing persists across a reboot.

Because the Windows virtual machine recreates it across a reboot.

I think this is, in the end the correct answer.
And my windows VM seldom gets 'rebooted' it normally gets 'suspended'

Yeah. But that it remembered machines from years before, is a surprise.

Not with Winders!

Especially a VM that has remained essentially unchanged for 20 years.

No Windows on a real computer could last the long!

WMRN is the winders motto. Write many remove never.

You have never rebooted it in 20 years? You must have.
Usually software has code to time out entries.

--
Cheers, Carlos.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16/07/2025 10:21, Carlos E.R. wrote:

On 2025-07-15 16:20, The Natural Philosopher wrote:

On 15/07/2025 10:58, Carlos E.R. wrote:

On 2025-07-14 15:54, The Natural Philosopher wrote:

On 14/07/2025 09:19, Carlos E.R. wrote:

On 2025-07-14 00:10, Lawrence D'Oliveiro wrote:

On Sun, 13 Jul 2025 12:01:30 +0100, The Natural Philosopher wrote: >>>>>>

I found a magic spell on line to clear the [Dimdows] ARP cache.

I wonder why you needed one? On *nix, the cache is kept entirely in >>>>>> volatile storage, so nothing persists across a reboot.

Because the Windows virtual machine recreates it across a reboot.

I think this is, in the end the correct answer.
And my windows VM seldom gets 'rebooted' it normally gets 'suspended'

Yeah. But that it remembered machines from years before, is a surprise.

Not with Winders!

Especially a VM that has remained essentially unchanged for 20 years.

No Windows on a real computer could last the long!

WMRN is the winders motto. Write many remove never.

You have never rebooted it in 20 years? You must have.
Usually software has code to time out entries.

Oh I have rebooted it, yes, but never reinstalled it. So no config changes.
In practice it simply gets suspended unless something crashed in it


--
“The ultimate result of shielding men from the effects of folly is to
fill the world with fools.”

Herbert Spencer

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-07-16, c186282 <c186282@nnada.net> wrote:

On 7/14/25 6:05 PM, Lawrence D'Oliveiro wrote:

On Mon, 14 Jul 2025 08:06:42 -0700, John Ames wrote:

DHCP was a mistake, full stop.

The Microsoft implementation of it is where the mistake lies. DHCP itself
is extremely useful, and works fine across a range of systems as long as
Microsoft is not involved.

Everything works better when M$ is not involved ...

Q: Why is a computer like an air conditioner?
A: It stops working when you open Windows.

--
/~\ Charlie Gibbs | Growth for the sake of
\ / <cgibbs@kltpzyxm.invalid> | growth is the ideology
X I'm really at ac.dekanfrus | of the cancer cell.
/ \ if you read it the right way. | -- Edward Abbey

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16/07/2025 16:05, John Ames wrote:

On Mon, 14 Jul 2025 22:05:20 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

DHCP was a mistake, full stop.

The Microsoft implementation of it is where the mistake lies. DHCP
itself is extremely useful, and works fine across a range of systems
as long as Microsoft is not involved.

If it was *just* Windows it wouldn't be difficult to rig up a scheduled
task to flush the DNS cache; stupid, yes, but surmountable. What really
drivs *me* up the wall is when the *router* can't even keep its own
records straight.

My router does impeccably.

The difference between the crap mass market routers I used to have and
the current Draytek, is chalk and cheese.

--
“The ultimate result of shielding men from the effects of folly is to
fill the world with fools.”

Herbert Spencer

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16/07/2025 17:02, John Ames wrote:

On Wed, 16 Jul 2025 16:47:43 +0100
The Natural Philosopher <tnp@invalid.invalid> wrote:

My router does impeccably.

The difference between the crap mass market routers I used to have
and the current Draytek, is chalk and cheese.

For sure - but when you're dealing with penny-pinching small-business
owners, it's pulling teeth to even get them to replace a *failing*
router, let alone one that does stupid things which cause daily head-
aches but "works just fine!" :/

I've got a dreadful old ADSL Netgear router acting as a Wifi Point -
its ADSL capability vanished in a thunderstorm.

Ive got a really good old Cisco badged SOHO router as well...


--
Climate Change: Socialism wearing a lab coat.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16/07/2025 16:53, Charlie Gibbs wrote:

On 2025-07-16, c186282 <c186282@nnada.net> wrote:

On 7/14/25 6:05 PM, Lawrence D'Oliveiro wrote:

On Mon, 14 Jul 2025 08:06:42 -0700, John Ames wrote:

DHCP was a mistake, full stop.

The Microsoft implementation of it is where the mistake lies. DHCP itself >>> is extremely useful, and works fine across a range of systems as long as >>> Microsoft is not involved.

Everything works better when M$ is not involved ...

Q: Why is a computer like an air conditioner?
A: It stops working when you open Windows.

Q:Why is a Vax computer like an erect penis?
A: It will stay up as long as you don't fuck with it.


--
"A point of view can be a dangerous luxury when substituted for insight
and understanding".

Marshall McLuhan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John Ames <commodorejohn@gmail.com> writes:

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

DHCP was a mistake, full stop.

The Microsoft implementation of it is where the mistake lies. DHCP
itself is extremely useful, and works fine across a range of systems
as long as Microsoft is not involved.

If it was *just* Windows it wouldn't be difficult to rig up a scheduled
task to flush the DNS cache; stupid, yes, but surmountable. What really
drivs *me* up the wall is when the *router* can't even keep its own
records straight.

That’s not a DHCP problem, that’s a useless router problem.

Personally I have far too many IP endpoints for manual address
assignment to be remotely attractive, and that’s before counting guests’ laptops and phones, etc.

--
https://www.greenend.org.uk/rjk/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/16/25 19:21, The Natural Philosopher wrote:

On 16/07/2025 19:18, Richard Kettlewell wrote:

John Ames <commodorejohn@gmail.com> writes:

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

DHCP was a mistake, full stop.

The Microsoft implementation of it is where the mistake lies. DHCP
itself is extremely useful, and works fine across a range of systems
as long as Microsoft is not involved.

If it was *just* Windows it wouldn't be difficult to rig up a scheduled
task to flush the DNS cache; stupid, yes, but surmountable. What really
drivs *me* up the wall is when the *router* can't even keep its own
records straight.

That’s not a DHCP problem, that’s a useless router problem.

Personally I have far too many IP endpoints for manual address
assignment to be remotely attractive, and that’s before counting guests’ >> laptops and phones, etc.

I figured out that only servers need to be on fixed addresses.
So they are. The rest are clients and can be wherever the Gods of DHCP decree.

I use DHCP static mappings for most of my LAN devices. I can't quite
remember why, but I think it is because I commonly experienced problems
with my router DNS server, so it was useful to know an IP.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16/07/2025 19:18, Richard Kettlewell wrote:

John Ames <commodorejohn@gmail.com> writes:

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

DHCP was a mistake, full stop.

The Microsoft implementation of it is where the mistake lies. DHCP
itself is extremely useful, and works fine across a range of systems
as long as Microsoft is not involved.

If it was *just* Windows it wouldn't be difficult to rig up a scheduled
task to flush the DNS cache; stupid, yes, but surmountable. What really
drivs *me* up the wall is when the *router* can't even keep its own
records straight.

That’s not a DHCP problem, that’s a useless router problem.

Personally I have far too many IP endpoints for manual address
assignment to be remotely attractive, and that’s before counting guests’ laptops and phones, etc.

I figured out that only servers need to be on fixed addresses.
So they are. The rest are clients and can be wherever the Gods of DHCP
decree.


--
Canada is all right really, though not for the whole weekend.

"Saki"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 16 Jul 2025 08:05:31 -0700, John Ames wrote:

On Mon, 14 Jul 2025 22:05:20 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

DHCP was a mistake, full stop.

The Microsoft implementation of it is where the mistake lies. DHCP
itself is extremely useful, and works fine across a range of systems as
long as Microsoft is not involved.

If it was *just* Windows it wouldn't be difficult to rig up a scheduled
task to flush the DNS cache; stupid, yes, but surmountable. What really
drivs *me* up the wall is when the *router* can't even keep its own
records straight.

I have the DHCP function in my internet router disabled. Instead, that
function is performed by my backup Linux machine. I can maintain things
like one custom address range for trusted machines, with fixed IP
addresses for each known MAC address, and a separate address range for everything else.

And I can do clever things like map both the wired and wireless interfaces
on a laptop to the same IP address. Because bulk transfers (when I need to
do them) go a lot faster over an actual wire than over the air.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 16 Jul 2025 19:41:56 +0100, Pancho wrote:

I use DHCP static mappings for most of my LAN devices. I can't quite remember why, but I think it is because I commonly experienced problems
with my router DNS server, so it was useful to know an IP.

That’s a good reason to do it. Even better is to have recognizable names assigned to those fixed IPs in a local DNS table somewhere.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/16/25 2:19 PM, The Natural Philosopher wrote:

On 16/07/2025 16:53, Charlie Gibbs wrote:

On 2025-07-16, c186282 <c186282@nnada.net> wrote:

On 7/14/25 6:05 PM, Lawrence D'Oliveiro wrote:

On Mon, 14 Jul 2025 08:06:42 -0700, John Ames wrote:

DHCP was a mistake, full stop.

The Microsoft implementation of it is where the mistake lies. DHCP
itself
is extremely useful, and works fine across a range of systems as
long as
Microsoft is not involved.

    Everything works better when M$ is not involved ...

Q: Why is a computer like an air conditioner?
A: It stops working when you open Windows.

Q:Why is a Vax computer like an erect penis?
A: It will stay up as long as you don't fuck with it.

Ha - DO have some VAX/VMS experience. WISH someone
would create a Neo-VMS as a Linux alt.

But yea, go with the paradigm.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/16/25 11:47 AM, The Natural Philosopher wrote:

On 16/07/2025 16:05, John Ames wrote:

On Mon, 14 Jul 2025 22:05:20 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

DHCP was a mistake, full stop.

The Microsoft implementation of it is where the mistake lies. DHCP
itself is extremely useful, and works fine across a range of systems
as long as Microsoft is not involved.

If it was *just* Windows it wouldn't be difficult to rig up a scheduled
task to flush the DNS cache; stupid, yes, but surmountable. What really
drivs *me* up the wall is when the *router* can't even keep its own
records straight.

My router does impeccably.

The difference between the crap mass market routers I used to have and
the current Draytek, is chalk and cheese.

Proper linux-based routers are indeed the Best Way.

I mostly used the "IPFire" disto - yea, funny name but
fully functional - on a SuperMicro mini-box. There are
a number of others.

Unlike Win - these give you much finer control, and
the ability to run custom scripts once you find
the "in".

"Sophos" is quite popular and even a bit more
customizable. Downside, more complicated.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/16/25 12:02 PM, John Ames wrote:

On Wed, 16 Jul 2025 16:47:43 +0100
The Natural Philosopher <tnp@invalid.invalid> wrote:

My router does impeccably.

The difference between the crap mass market routers I used to have
and the current Draytek, is chalk and cheese.

For sure - but when you're dealing with penny-pinching small-business
owners, it's pulling teeth to even get them to replace a *failing*
router, let alone one that does stupid things which cause daily head-
aches but "works just fine!" :/

Know what you mean.

Basically, never TELL them you're changing
routers/paradigms - just DO it. Wait for
permission and NOTHING changes. BCrats
live by doing NOTHING.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/16/25 2:41 PM, Pancho wrote:

On 7/16/25 19:21, The Natural Philosopher wrote:

On 16/07/2025 19:18, Richard Kettlewell wrote:

John Ames <commodorejohn@gmail.com> writes:

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

DHCP was a mistake, full stop.

The Microsoft implementation of it is where the mistake lies. DHCP
itself is extremely useful, and works fine across a range of systems >>>>> as long as Microsoft is not involved.

If it was *just* Windows it wouldn't be difficult to rig up a scheduled >>>> task to flush the DNS cache; stupid, yes, but surmountable. What really >>>> drivs *me* up the wall is when the *router* can't even keep its own
records straight.

That’s not a DHCP problem, that’s a useless router problem.

Personally I have far too many IP endpoints for manual address
assignment to be remotely attractive, and that’s before counting guests’
laptops and phones, etc.

I figured out that only servers need to be on fixed addresses.
So they are. The rest are clients and can be wherever the Gods of DHCP
decree.

I use  DHCP static mappings for most of my LAN devices. I can't quite remember why, but I think it is because I commonly experienced problems
with my router DNS server, so it was useful to know an IP.

After suffering with fickle DHCP, I changed all my
office boxes/devices to static. THEN you knew where
everything was.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/16/25 2:18 PM, Richard Kettlewell wrote:

John Ames <commodorejohn@gmail.com> writes:

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

DHCP was a mistake, full stop.

The Microsoft implementation of it is where the mistake lies. DHCP
itself is extremely useful, and works fine across a range of systems
as long as Microsoft is not involved.

If it was *just* Windows it wouldn't be difficult to rig up a scheduled
task to flush the DNS cache; stupid, yes, but surmountable. What really
drivs *me* up the wall is when the *router* can't even keep its own
records straight.

That’s not a DHCP problem, that’s a useless router problem.

Personally I have far too many IP endpoints for manual address
assignment to be remotely attractive, and that’s before counting guests’ laptops and phones, etc.

Ummm ... "far too many" ???

It CAN be a prob IF you need more than 255
addresses. Gets weird thereafter.

I never needed THAT many addresses, so I made
a point of setting everything static. THEN you
knew what was where forever and ever.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/16/25 2:21 PM, The Natural Philosopher wrote:

On 16/07/2025 19:18, Richard Kettlewell wrote:

John Ames <commodorejohn@gmail.com> writes:

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

DHCP was a mistake, full stop.

The Microsoft implementation of it is where the mistake lies. DHCP
itself is extremely useful, and works fine across a range of systems
as long as Microsoft is not involved.

If it was *just* Windows it wouldn't be difficult to rig up a scheduled
task to flush the DNS cache; stupid, yes, but surmountable. What really
drivs *me* up the wall is when the *router* can't even keep its own
records straight.

That’s not a DHCP problem, that’s a useless router problem.

Personally I have far too many IP endpoints for manual address
assignment to be remotely attractive, and that’s before counting guests’ >> laptops and phones, etc.

I figured out that only servers need to be on fixed addresses.
So they are. The rest are clients and can be wherever the Gods of DHCP decree.

Ummmmmm ... tried that long ago. DHCP is just
TOO fickle. Wound up setting static IPs for
*everything*. THEN you knew what was what,
where was where, for sure.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/17/25 08:38, c186282 wrote:

I use  DHCP static mappings for most of my LAN devices. I can't quite
remember why, but I think it is because I commonly experienced
problems with my router DNS server, so it was useful to know an IP.

  After suffering with fickle DHCP, I changed all my
  office boxes/devices to static. THEN you knew where
  everything was.

The problem was not DHCP. DHCP allocated IP addresses and registered the
host names on the LAN DNS server (dnsmasq or unbound). I found DHCP
very reliable.

The problem was the LAN DNS server, on my router, froze occasionally,
stopped responding to queries, all queries. Pretty catastrophic in
itself, but I could still use some LAN services if I knew the IP address.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 17/07/2025 08:15, c186282 wrote:

  Ummmmmm ... tried that long ago. DHCP is just
  TOO fickle. Wound up setting static IPs for
  *everything*. THEN you knew what was what,
  where was where, for sure.

I guess you are the epitome of the old joke:

"I run a Linux operating system and my PC crashes about as often as I
get laid"

My guests want to enter a name and password on their ShiniShit™ devices
and certainly not to assign fixed IP.

I myself don't even know how to do that on a mobile phobe



--
Renewable energy: Expensive solutions that don't work to a problem that
doesn't exist instituted by self legalising protection rackets that
don't protect, masquerading as public servants who don't serve the public.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 17/07/2025 09:29, Pancho wrote:

On 7/17/25 08:38, c186282 wrote:

I use  DHCP static mappings for most of my LAN devices. I can't quite
remember why, but I think it is because I commonly experienced
problems with my router DNS server, so it was useful to know an IP.

   After suffering with fickle DHCP, I changed all my
   office boxes/devices to static. THEN you knew where
   everything was.

The problem was not DHCP. DHCP allocated IP addresses and registered the
host names  on the LAN DNS server (dnsmasq or unbound). I found DHCP
very reliable.

The problem was the LAN  DNS server, on my router, froze occasionally, stopped responding to queries, all queries. Pretty catastrophic in
itself, but I could still use some LAN services if I knew the IP address.

My DNS server is my new raspberry Pi experimental NAS or the current
Linux NAS.

Why would I need a router to do that job?

--
Renewable energy: Expensive solutions that don't work to a problem that
doesn't exist instituted by self legalising protection rackets that
don't protect, masquerading as public servants who don't serve the public.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/17/25 09:46, The Natural Philosopher wrote:

On 17/07/2025 09:29, Pancho wrote:

On 7/17/25 08:38, c186282 wrote:

I use  DHCP static mappings for most of my LAN devices. I can't
quite remember why, but I think it is because I commonly experienced
problems with my router DNS server, so it was useful to know an IP.

   After suffering with fickle DHCP, I changed all my
   office boxes/devices to static. THEN you knew where
   everything was.

The problem was not DHCP. DHCP allocated IP addresses and registered
the host names  on the LAN DNS server (dnsmasq or unbound). I found
DHCP very reliable.

The problem was the LAN  DNS server, on my router, froze occasionally,
stopped responding to queries, all queries. Pretty catastrophic in
itself, but I could still use some LAN services if I knew the IP address.

My DNS server is my new raspberry Pi experimental NAS or the current
Linux NAS.

Why would I need a router to do that job?

Router does it, why would I need something else to do the job.

When I say DNS crashed, that may be historic, my sense of time slips.
I've been using a pfSense router for 15 years, and the current hardware
is over 10 years old. The problems could easily be 5+ years ago.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

c186282 <c186282@nnada.net> writes:

On 7/16/25 2:18 PM, Richard Kettlewell wrote:

Personally I have far too many IP endpoints for manual address
assignment to be remotely attractive, and that’s before counting
guests’ laptops and phones, etc.

Ummm ... "far too many" ???

It CAN be a prob IF you need more than 255
addresses. Gets weird thereafter.

That’s not the issue. Please take a little longer to read what you’re responding to.

--
https://www.greenend.org.uk/rjk/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 17/07/2025 15:52, John Ames wrote:

On Thu, 17 Jul 2025 02:14:01 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

I have the DHCP function in my internet router disabled. Instead,
that function is performed by my backup Linux machine. I can maintain
things like one custom address range for trusted machines, with fixed
IP addresses for each known MAC address, and a separate address range
for everything else.

Yeah, that's a good solution when you have the option.

Every router that I have ever had has had that option.



--
If you tell a lie big enough and keep repeating it, people will
eventually come to believe it. The lie can be maintained only for such
time as the State can shield the people from the political, economic
and/or military consequences of the lie. It thus becomes vitally
important for the State to use all of its powers to repress dissent, for
the truth is the mortal enemy of the lie, and thus by extension, the
truth is the greatest enemy of the State.

Joseph Goebbels

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/17/25 4:50 AM, The Natural Philosopher wrote:

On 17/07/2025 08:15, c186282 wrote:

   Ummmmmm ... tried that long ago. DHCP is just
   TOO fickle. Wound up setting static IPs for
   *everything*. THEN you knew what was what,
   where was where, for sure.

I guess you are the epitome of the old joke:

"I run a Linux operating system and my PC crashes about as often as I
get laid"

My guests want to enter a name and password on their ShiniShit™ devices
and certainly not to assign fixed IP.

"Dynamic", often temporary, connections are where DHCP
does best, most easily.

However for permanent workstations/devices/servers ...

Old printer dies, replace with similar model at
the same IP address.

I myself don't even know how to do that on a mobile phobe

Umm ... I did it once or twice, but it wasn't fun.
A temporary user doesn't even know what addresses
are available.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/17/25 4:29 AM, Pancho wrote:

On 7/17/25 08:38, c186282 wrote:

I use  DHCP static mappings for most of my LAN devices. I can't quite
remember why, but I think it is because I commonly experienced
problems with my router DNS server, so it was useful to know an IP.

   After suffering with fickle DHCP, I changed all my
   office boxes/devices to static. THEN you knew where
   everything was.

The problem was not DHCP. DHCP allocated IP addresses and registered the
host names  on the LAN DNS server (dnsmasq or unbound). I found DHCP
very reliable.

"Reliable" is a somewhat context-sensitive def here.
Yes, DHCP will easily assign an address, but MAY decide
to CHANGE it later, and/or not quite forget where the
old address was. It is possible to query to find what
the (current) address of a PC/device is, based mostly
on a couple kinds of naming features. However that's
not nearly as clean as a static IP. Why add layers
and layers to what SHOULD be simple ?

The problem was the LAN  DNS server, on my router, froze occasionally, stopped responding to queries, all queries. Pretty catastrophic in
itself, but I could still use some LAN services if I knew the IP address.

Yep. Happens.

As said, for "home" use DHCP is OK ... but if you're
biz/govt and have 200+ devices - really might want to
think about static. A little more trouble, but it'll
get you OUT of other kinds of trouble.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/17/25 5:39 AM, Pancho wrote:

On 7/17/25 09:46, The Natural Philosopher wrote:

On 17/07/2025 09:29, Pancho wrote:

On 7/17/25 08:38, c186282 wrote:

I use  DHCP static mappings for most of my LAN devices. I can't
quite remember why, but I think it is because I commonly
experienced problems with my router DNS server, so it was useful to
know an IP.

   After suffering with fickle DHCP, I changed all my
   office boxes/devices to static. THEN you knew where
   everything was.

The problem was not DHCP. DHCP allocated IP addresses and registered
the host names  on the LAN DNS server (dnsmasq or unbound). I found
DHCP very reliable.

The problem was the LAN  DNS server, on my router, froze
occasionally, stopped responding to queries, all queries. Pretty
catastrophic in itself, but I could still use some LAN services if I
knew the IP address.

My DNS server is my new raspberry Pi experimental NAS or the current
Linux NAS.

Why would I need a router to do that job?

Router does it, why would I need something else to do the job.

When I say DNS crashed, that may be historic, my sense of time slips.
I've been using a pfSense router for 15 years, and the current hardware
is over 10 years old. The problems could easily be 5+ years ago.

I replaced store-bought routers a long time ago
for Linux-based router/firewall distros. Much
better control, more frequent updates. Good.

GIANT operations, maybe expensive Cisco routers are
the easier path, but on a somewhat smaller scale ...

What is "best" is context sensitive - scale, scope,
needs. Research and choose well.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/17/25 6:19 AM, Richard Kettlewell wrote:

c186282 <c186282@nnada.net> writes:

On 7/16/25 2:18 PM, Richard Kettlewell wrote:

Personally I have far too many IP endpoints for manual address
assignment to be remotely attractive, and that’s before counting
guests’ laptops and phones, etc.

Ummm ... "far too many" ???

It CAN be a prob IF you need more than 255
addresses. Gets weird thereafter.

That’s not the issue. Please take a little longer to read what you’re responding to.

Managing a single subnet is easy. Ops that spread out
over several are much more annoying to set up and
cross-connect.

As I've said to others, "temporary" connections - phones
or whatever - really ARE best managed with DHCP. But the
more permanent stuff, workstations/devices/servers, it's
better to use static. It's more solid, easier.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 17 Jul 2025 19:59:58 +0100, The Natural Philosopher wrote:

On 17/07/2025 15:52, John Ames wrote:

On Thu, 17 Jul 2025 02:14:01 -0000 (UTC)

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

I have the DHCP function in my internet router disabled. Instead, that
function is performed by my backup Linux machine. I can maintain
things like one custom address range for trusted machines, with fixed
IP addresses for each known MAC address, and a separate address range
for everything else.

Yeah, that's a good solution when you have the option.

Every router that I have ever had has had that option.

Doing it on a Linux box saves having to type MAC addresses in manually. I
turn on the new machine, check my logs to see which new MAC address has
just started trying to get an IP address, and then I can copy and paste
that into the DHCP server config.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 17 Jul 2025 09:50:15 +0100, The Natural Philosopher wrote:

I myself don't even know how to do that on a mobile phobe

Freudian slip ... ?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 17 Jul 2025 10:39:01 +0100, Pancho wrote:

I've been using a pfSense router for 15 years, and the current hardware
is over 10 years old.

There was an issue with pfSense incorrectly calculating expiry dates for
TLS certs at one point -- did your version have that bug?

Stupid PHP programmers‡ couldn’t get a simple date calculation correct.

‡But I repeat myself

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/18/25 1:50 AM, Lawrence D'Oliveiro wrote:

On Thu, 17 Jul 2025 10:39:01 +0100, Pancho wrote:

I've been using a pfSense router for 15 years, and the current hardware
is over 10 years old.

There was an issue with pfSense incorrectly calculating expiry dates for
TLS certs at one point -- did your version have that bug?

Stupid PHP programmers‡ couldn’t get a simple date calculation correct.

‡But I repeat myself

DID learn to do PHP fortunately :-)

But some of that 'deep system' stuff, a REAL pain
in the ass. There is where you want to leave it up
to corporate experts. Not ALWAYS wise, but you have
to do the Worth It equation.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 18/07/2025 03:42, c186282 wrote:

On 7/17/25 4:29 AM, Pancho wrote:

On 7/17/25 08:38, c186282 wrote:

I use  DHCP static mappings for most of my LAN devices. I can't
quite remember why, but I think it is because I commonly experienced
problems with my router DNS server, so it was useful to know an IP.

   After suffering with fickle DHCP, I changed all my
   office boxes/devices to static. THEN you knew where
   everything was.

The problem was not DHCP. DHCP allocated IP addresses and registered
the host names  on the LAN DNS server (dnsmasq or unbound). I found
DHCP very reliable.

  "Reliable" is a somewhat context-sensitive def here.
  Yes, DHCP will easily assign an address, but MAY decide
  to CHANGE it later, and/or not quite forget where the
  old address was. It is possible to query to find what
  the (current) address of a PC/device is, based mostly
  on a couple kinds of naming features. However that's
  not nearly as clean as a static IP. Why add layers
  and layers to what SHOULD be simple ?

Yeah,. Right, A trusted vistor comes into your office and says 'may I
use your internet connection., and you wrest his laptop or mobile phone
from him, install a fixed IP address having looked up in the paper log
of already allocated IP addresses to make sure it doesn't collide, add
in te DNS address and te default route and you hand it back and say 'go
ahead'

Or you run DHCP and say 'SSID is 'guest', and the password is
stlnkingBishop' and that is that.

The problem was the LAN  DNS server, on my router, froze occasionally,
stopped responding to queries, all queries. Pretty catastrophic in
itself, but I could still use some LAN services if I knew the IP address.

  Yep. Happens.

...To people who cant configure servers

  As said, for "home" use DHCP is OK ... but if you're
  biz/govt and have 200+ devices - really might want to
  think about static. A little more trouble, but it'll
  get you OUT of other kinds of trouble.

It was precisely when we got to 200 users on static addresses and the
nightmare of having to set each one up individually that the blessings
of DHCP became apparent
Static is OK for home, or a small number of servers, but for offices
full of clients its a fucking nightmare.

You soon find out what happens when people modify their setup to be on
someone else's IP addresses.



--
It’s easier to fool people than to convince them that they have been fooled. Mark Twain

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 18 Jul 2025 11:05:10 +0100, The Natural Philosopher wrote:

It was precisely when we got to 200 users on static addresses and the nightmare of having to set each one up individually that the blessings
of DHCP became apparent

I set up DHCP at the offices of a former client so only known MAC
addresses, corresponding to known machines on their inventory, would be assigned IP addresses. Every time I checked the logs, I would find a few unknown MAC addresses popping up and asking for IP addresses.

(As far as I knew, there were no wi-fi access points lurking on their LAN anywhere.)

I sent lists of them to the IT manager a few times, but given that I
couldn’t suggest any easy way of tracking down where those machines might
be, I don’t think he took any action.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/18/25 7:19 PM, Lawrence D'Oliveiro wrote:

On Fri, 18 Jul 2025 11:05:10 +0100, The Natural Philosopher wrote:

It was precisely when we got to 200 users on static addresses and the
nightmare of having to set each one up individually that the blessings
of DHCP became apparent

I set up DHCP at the offices of a former client so only known MAC
addresses, corresponding to known machines on their inventory, would be assigned IP addresses. Every time I checked the logs, I would find a few unknown MAC addresses popping up and asking for IP addresses.

(As far as I knew, there were no wi-fi access points lurking on their LAN anywhere.)

I sent lists of them to the IT manager a few times, but given that I couldn’t suggest any easy way of tracking down where those machines might be, I don’t think he took any action.

You can apply more comprehensive rules to wannabe
connections if using static addresses. That one
thing is KNOWN, prob also the MACs.

DHCP does have its place, esp for 'temporary' connections.
Even then, find ways to apply limits.

Still, your office full of boxes/devices, static is still
the better way. A little more set-up work, but worth it
down the line.

A gazillion little hacks, those in pure error, dangerous
foreign and internal entities - they're ALWAYS pounding
at yer office systems. Sometimes the logs aren't even
worth printing out, too large, much less trying to
pursue.

Modern world, it's kinda like being Ukraine ...
missiles coming in from all directions all day
long. Miserable.

Smarter firewalls/routers, shielding software and
some custom scripts to add IQ ... it's about the
best you can do. Linux is a help WAY over anything
with Winders. Alas, even thus, it is still best
to be "obscure", "uninteresting".

The cyber-wars ARE heating up fast now ....... and
there's a point where even your boring home systems
will become targets. They WANT your bank numbers,
your logins. We knew this day would come, but liked
to PRETEND it wouldn't. Used to keep my logins in
plain text files for ref, now I encrypt them.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/19/25 00:19, Lawrence D'Oliveiro wrote:

On Fri, 18 Jul 2025 11:05:10 +0100, The Natural Philosopher wrote:

It was precisely when we got to 200 users on static addresses and the
nightmare of having to set each one up individually that the blessings
of DHCP became apparent

I set up DHCP at the offices of a former client so only known MAC
addresses, corresponding to known machines on their inventory, would be assigned IP addresses. Every time I checked the logs, I would find a few unknown MAC addresses popping up and asking for IP addresses.

(As far as I knew, there were no wi-fi access points lurking on their LAN anywhere.)

I sent lists of them to the IT manager a few times, but given that I couldn’t suggest any easy way of tracking down where those machines might be, I don’t think he took any action.

The first three octets of a MAC address indicate hardware manufacturer,
this might give a clue to the type of unknown equipment making DHCP
requests.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)