Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #69515 > unrolled thread

Spurious ARP entries...

Back to article view | Back to comp.os.linux.misc

Contents

  Spurious ARP entries... The Natural Philosopher <tnp@invalid.invalid> - 2025-07-12 11:30 +0100
    Re: Spurious ARP entries... Robert Heller <heller@deepsoft.com> - 2025-07-12 10:36 +0000
      Re: Spurious ARP entries... The Natural Philosopher <tnp@invalid.invalid> - 2025-07-12 11:52 +0100
    Re: Spurious ARP entries... Andy Burns <usenet@andyburns.uk> - 2025-07-12 11:41 +0100
      Re: Spurious ARP entries... The Natural Philosopher <tnp@invalid.invalid> - 2025-07-12 11:54 +0100
        Re: Spurious ARP entries... Andy Burns <usenet@andyburns.uk> - 2025-07-12 12:14 +0100
          Re: Spurious ARP entries... The Natural Philosopher <tnp@invalid.invalid> - 2025-07-12 13:06 +0100
            Re: Spurious ARP entries... Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-07-13 01:20 +0000
              Re: Spurious ARP entries... c186282 <c186282@nnada.net> - 2025-07-13 00:16 -0400
                Re: Spurious ARP entries... The Natural Philosopher <tnp@invalid.invalid> - 2025-07-13 12:01 +0100
                  Re: Spurious ARP entries... Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-07-13 22:10 +0000
                    Re: Spurious ARP entries... "Carlos E.R." <robin_listas@es.invalid> - 2025-07-14 10:19 +0200
                      Re: Spurious ARP entries... The Natural Philosopher <tnp@invalid.invalid> - 2025-07-14 14:54 +0100
                        Re: Spurious ARP entries... "Carlos E.R." <robin_listas@es.invalid> - 2025-07-15 11:58 +0200
                          Re: Spurious ARP entries... The Natural Philosopher <tnp@invalid.invalid> - 2025-07-15 15:20 +0100
                            Re: Spurious ARP entries... "Carlos E.R." <robin_listas@es.invalid> - 2025-07-16 11:21 +0200
                              Re: Spurious ARP entries... The Natural Philosopher <tnp@invalid.invalid> - 2025-07-16 16:46 +0100
                      Re: Spurious ARP entries... c186282 <c186282@nnada.net> - 2025-07-15 22:10 -0400
    Re: Spurious ARP entries... Richard Kettlewell <invalid@invalid.invalid> - 2025-07-12 11:43 +0100
      Re: Spurious ARP entries... The Natural Philosopher <tnp@invalid.invalid> - 2025-07-12 12:02 +0100
    Re: Spurious ARP entries... c186282 <c186282@nnada.net> - 2025-07-12 19:33 -0400
      Re: Spurious ARP entries... The Natural Philosopher <tnp@invalid.invalid> - 2025-07-13 11:52 +0100
        Re: Spurious ARP entries... c186282 <c186282@nnada.net> - 2025-07-14 00:08 -0400
    Re: Spurious ARP entries... Shadow <Sh@dow.br> - 2025-07-12 21:29 -0300
      Re: Spurious ARP entries... Robert Heller <heller@deepsoft.com> - 2025-07-13 00:55 +0000
        Re: Spurious ARP entries... Andy Burns <usenet@andyburns.uk> - 2025-07-13 06:35 +0100
          Re: Spurious ARP entries... c186282 <c186282@nnada.net> - 2025-07-13 02:30 -0400
            Re: Spurious ARP entries... John Ames <commodorejohn@gmail.com> - 2025-07-14 08:06 -0700
              Re: Spurious ARP entries... Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-07-14 22:05 +0000
                Re: Spurious ARP entries... c186282 <c186282@nnada.net> - 2025-07-15 22:21 -0400
                  Re: Spurious ARP entries... Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2025-07-16 15:53 +0000
                    Re: Spurious ARP entries... The Natural Philosopher <tnp@invalid.invalid> - 2025-07-16 19:19 +0100
                      Re: Spurious ARP entries... c186282 <c186282@nnada.net> - 2025-07-17 03:13 -0400
                Re: Spurious ARP entries... John Ames <commodorejohn@gmail.com> - 2025-07-16 08:05 -0700
                  Re: Spurious ARP entries... The Natural Philosopher <tnp@invalid.invalid> - 2025-07-16 16:47 +0100
                    Re: Spurious ARP entries... John Ames <commodorejohn@gmail.com> - 2025-07-16 09:02 -0700
                      Re: Spurious ARP entries... The Natural Philosopher <tnp@invalid.invalid> - 2025-07-16 19:17 +0100
                      Re: Spurious ARP entries... c186282 <c186282@nnada.net> - 2025-07-17 03:10 -0400
                    Re: Spurious ARP entries... c186282 <c186282@nnada.net> - 2025-07-17 03:08 -0400
                  Re: Spurious ARP entries... Richard Kettlewell <invalid@invalid.invalid> - 2025-07-16 19:18 +0100
                    Re: Spurious ARP entries... The Natural Philosopher <tnp@invalid.invalid> - 2025-07-16 19:21 +0100
                      Re: Spurious ARP entries... Pancho <Pancho.Jones@protonmail.com> - 2025-07-16 19:41 +0100
                        Re: Spurious ARP entries... Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-07-17 02:15 +0000
                        Re: Spurious ARP entries... c186282 <c186282@nnada.net> - 2025-07-17 03:38 -0400
                          Re: Spurious ARP entries... Pancho <Pancho.Jones@protonmail.com> - 2025-07-17 09:29 +0100
                            Re: Spurious ARP entries... The Natural Philosopher <tnp@invalid.invalid> - 2025-07-17 09:46 +0100
                              Re: Spurious ARP entries... Pancho <Pancho.Jones@protonmail.com> - 2025-07-17 10:39 +0100
                                Re: Spurious ARP entries... c186282 <c186282@nnada.net> - 2025-07-17 22:53 -0400
                                Re: Spurious ARP entries... Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-07-18 05:50 +0000
                                  Re: Spurious ARP entries... c186282 <c186282@nnada.net> - 2025-07-18 02:11 -0400
                            Re: Spurious ARP entries... c186282 <c186282@nnada.net> - 2025-07-17 22:42 -0400
                              Re: Spurious ARP entries... The Natural Philosopher <tnp@invalid.invalid> - 2025-07-18 11:05 +0100
                                Re: Spurious ARP entries... Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-07-18 23:19 +0000
                                  Re: Spurious ARP entries... c186282 <c186282@nnada.net> - 2025-07-18 23:06 -0400
                                  Re: Spurious ARP entries... Pancho <Pancho.Jones@protonmail.com> - 2025-07-19 10:50 +0100
                      Re: Spurious ARP entries... c186282 <c186282@nnada.net> - 2025-07-17 03:15 -0400
                        Re: Spurious ARP entries... The Natural Philosopher <tnp@invalid.invalid> - 2025-07-17 09:50 +0100
                          Re: Spurious ARP entries... c186282 <c186282@nnada.net> - 2025-07-17 22:48 -0400
                            Re: Spurious ARP entries... John Ames <commodorejohn@gmail.com> - 2025-07-18 09:02 -0700
                          Re: Spurious ARP entries... Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-07-18 05:48 +0000
                    Re: Spurious ARP entries... c186282 <c186282@nnada.net> - 2025-07-17 03:41 -0400
                      Re: Spurious ARP entries... Richard Kettlewell <invalid@invalid.invalid> - 2025-07-17 11:19 +0100
                        Re: Spurious ARP entries... c186282 <c186282@nnada.net> - 2025-07-17 22:58 -0400
                  Re: Spurious ARP entries... Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-07-17 02:14 +0000
                    Re: Spurious ARP entries... John Ames <commodorejohn@gmail.com> - 2025-07-17 07:52 -0700
                      Re: Spurious ARP entries... The Natural Philosopher <tnp@invalid.invalid> - 2025-07-17 19:59 +0100
                        Re: Spurious ARP entries... Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-07-18 05:47 +0000
              Re: Spurious ARP entries... c186282 <c186282@nnada.net> - 2025-07-15 22:20 -0400
    Re: Spurious ARP entries... jayjwa <jayjwa@atr2.ath.cx.invalid> - 2025-07-13 13:03 -0400
      Re: Spurious ARP entries... The Natural Philosopher <tnp@invalid.invalid> - 2025-07-13 21:46 +0100
        Re: Spurious ARP entries... vallor <vallor@cultnix.org> - 2025-07-13 22:14 +0000
        Re: Spurious ARP entries... c186282 <c186282@nnada.net> - 2025-07-14 00:10 -0400

Page 4 of 4 — ← Prev page 1 2 3 [4]

#69666

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.

[toc] | [prev] | [next] | [standalone]

#69675

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/

[toc] | [prev] | [next] | [standalone]

#69695

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.

[toc] | [prev] | [next] | [standalone]

#69654

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.

[toc] | [prev] | [next] | [standalone]

#69679

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.

[toc] | [prev] | [next] | [standalone]

#69689

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

[toc] | [prev] | [next] | [standalone]

#69698

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.

[toc] | [prev] | [next] | [standalone]

#69599

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.

[toc] | [prev] | [next] | [standalone]

#69547

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!"

[toc] | [prev] | [next] | [standalone]

#69552

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

[toc] | [prev] | [next] | [standalone]

#69556

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
scrutinizing my network as we switch over from the old network.  No
arp- or broadcast-storms so far...)

BTW, tcpdump always reports "EN10MB" for Ethernet -- you can see
actual link speed with ethtool(8):

# ethtool enp68s0f0
Settings for enp68s0f0:
	Supported ports: [ TP ]
	Supported link modes:   100baseT/Full
	                        1000baseT/Full
	                        10000baseT/Full
	                        2500baseT/Full
	                        5000baseT/Full
	Supported pause frame use: Symmetric
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  100baseT/Full
	                        1000baseT/Full
	                        10000baseT/Full
	Advertised pause frame use: Symmetric
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Speed: 10000Mb/s
	Duplex: Full
	Auto-negotiation: on
	Port: Twisted Pair
	PHYAD: 0
	Transceiver: internal
	MDI-X: Unknown
	Supports Wake-on: umbg
	Wake-on: g
        Current message level: 0x00000007 (7)
                               drv probe link

Happy networking!

-- 
-v System76 Thelio Mega v1.1 x86_64 NVIDIA RTX 3090Ti 24G
   OS: Linux 6.15.6 D: Mint 22.1 DE: Xfce 4.18 
   NVIDIA: 575.64.03 Mem: 258G
   "NETWORK: What fishermen do when not fishing."

[toc] | [prev] | [next] | [standalone]

#69563

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

[toc] | [prev] | [standalone]

Page 4 of 4 — ← Prev page 1 2 3 [4]

Back to top | Article view | comp.os.linux.misc

csiph-web