On Thu, 03 Jun 2021 04:18:24 -0400, The Natural Philosopher <tnp@invalid.invalid> wrote:
> Mmm. Something at board BIOS level perhaps? Its a very OLD board
>
> inxi -M
> Machine: Type: Desktop Mobo: Intel model: DG43GT v: AAE62768-300
> serial: BTGT93200534 BIOS: Intel
> v: GTG4310H.86A.0035.2010.1006.1525 date: 10/06/2010

From ...
https://ark.intel.com/content/www/us/en/ark/products/41036/intel-desktop-board-dg43gt.html

After clicking on "Intel® Remote Wake Technology", it shows ...
====
Intel® Remote Wake technology (Intel® RWT) enables home PCs, enabled services, and mobile devices to communicate with one another remotely over the Internet, for 24/7 access while maintaining PC energy efficiency. Built on the Intel® Management Engine, Intel RWT allows you to remotely wake up home PCs from an enabled Internet application or service, while in energy efficient sleep mode.
====

Power off is not the same as pulling the plug. The system is always on at a low
level, so this very old mb does have the remote wake feature of the Management
Engine. Any packets received from the network may be intercepted by the hardware
and not seen by the os.

Regards, Dave Hodgins

--
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

On 03/06/2021 14:15, Robert Heller wrote:
> At Thu, 3 Jun 2021 13:00:28 +0100 The Natural Philosopher <tnp@invalid.invalid> wrote:
>
>>
>> On 03/06/2021 11:57, Pascal Hambourg wrote:
>>> Le 03/06/2021 à 12:38, The Natural Philosopher a écrit :
>>>>
>>>> ip route ls table local
>>>> local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
>>>> local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
>>>> local 192.168.0.100 dev enp0s25 proto kernel scope host src 192.168.0.100
>>> (broadcast entries removed for clarity)
>>>
>>> 192.168.0.1 is not listed so it is not considered as a local address by
>>>  the kernel, which confirms other observations.
>>
>> Yes. it behaves as a little empire all on its own snuggled inside the
>> linux machine as a whole.
>
> What kind of server hardware is this? Is it some kind of "data center" type
> of server or a common "desktop" machine repurposed as a server?
>
its a very old entry level intel motherboard repurposed from an XP
desktop. loaded up with a tad more RAM and a LOT of disks

> Try installing a port scanner (on one of the other machines) and do a port
> scan to see what ports are available on that IP. Or just try SNMP or even
> telnet (which might connect you to a "virtual" console port on the server).
>
>
No ports are available on that IP address. No interface with that IP
address exists as far as Linux tools are concerned BUT you cant ping
that IP address from the server, but from anywhere else you can,
suggesting that at some level linux IS aware of it

>>
>> Sort of Liechtenstein :-)
>>
>> So: to summarise
>> It appears to be absolutely associated with that server hardware
>> It exists outside of *normal* linux networking on that hardware
>> It appears to do nothing except respond to pings and issue DHCP client
>> commands. There are, for example no NAT sessions on the router with that
>> source address...
>> It persists between reboots
>> It comes up before normal networking does, on that hardware
>>
>> The oddest thing to date however is that the *server itself* reports
>> 'Destination Host Unreachable'
>>
>> PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
>> From 192.168.0.100 icmp_seq=1 Destination Host Unreachable
>>
>> So it MUST know *something* about that interface/IP address that tells
>> it it 'cannot be reached'.
>>
>> Which seems to rule out something below the linux level *completely*.
>
> Not necessarily. If this is hardware purpose built to be a server, it might
> have some sort of system management thing "built in" that is using the same
> NIC as the main machine, but totally without the O/S's "knowledge".
>
It isn't, I posted the hardware - its Intel model: DG43GT with a 2010 bios

> Reboot the machine and stop in BIOS Setup and poke around there.
>

>>
>> Also it appears as 'cymbeline' in the dhcp tables which is a linux level
>> name. And must be being passed as part of the DHCP request
>>
>> I know I am totally bigoted, but my money is on systemd...
>
> What happens if you uninstall dhcp-client? (sudo apt purge dhcp-client) If
> the server has a static IP address it has no need of dhcp-client and without
> dhcp-client it is not going to get an address from a DHCP server.
>
systemd has its own dhcp client :-)

I think that in the end the evidence points to something low level in
the linux boot process setting up this interface that is then only
partially dismantled

I dont want to break a working system that took me nearly a week to
upgrade all in all

I'll wait until the dhcp lease runs out overnight and see what is
requesting it.

>
>>
>> I am letting tcpdump on two machines try and trap the DHCP requests
>>
>>
>
And they are trapping the broadcast parts just fine

--
“It is dangerous to be right in matters on which the established
authorities are wrong.”

― Voltaire, The Age of Louis XIV

On 03/06/2021 17:32, Pascal Hambourg wrote:
> Le 03/06/2021 à 15:19, Robert Heller a écrit :
>> At Thu, 3 Jun 2021 13:29:29 +0100 The Natural Philosopher
>> <tnp@invalid.invalid> wrote:
>>>>
>>> Well network manager said it was there but 'disabled'.
>>
>> Just means that network manager is not managing the NIC, which makes
>> sense as
>> it has a static address (wired in /etc/network/interfaces).
>
> According to the OP in <s99nvt$fs0$1@dont-email.me>, the ethernet
> interface is statically configured by NetworkManager.

Well that's how I set it up, but who knows? so many tools are
'deprecated' and other bits of software invented to duplicate
functionality that its hard to say what does what these days.

Except like ClimateChange™, COVID19™ or Brexit™, we can all blame
everything on systemd.

--
You can get much farther with a kind word and a gun than you can with a
kind word alone.

Al Capone

On 03/06/2021 15:09, Joe Beanfish wrote:
> On Thu, 03 Jun 2021 08:15:13 -0500, Robert Heller wrote:
>
>> At Thu, 3 Jun 2021 13:00:28 +0100 The Natural Philosopher <tnp@invalid.invalid> wrote:
>>
>>>
>>> On 03/06/2021 11:57, Pascal Hambourg wrote:
>>>> Le 03/06/2021 à 12:38, The Natural Philosopher a écrit :
>>>>>
>>>>> ip route ls table local
>>>>> local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
>>>>> local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
>>>>> local 192.168.0.100 dev enp0s25 proto kernel scope host src 192.168.0.100
>>>> (broadcast entries removed for clarity)
>>>>
>>>> 192.168.0.1 is not listed so it is not considered as a local address by
>>>>  the kernel, which confirms other observations.
>>>
>>> Yes. it behaves as a little empire all on its own snuggled inside the
>>> linux machine as a whole.
>>
>> What kind of server hardware is this? Is it some kind of "data center" type
>> of server or a common "desktop" machine repurposed as a server?
>>
>> Try installing a port scanner (on one of the other machines) and do a port
>> scan to see what ports are available on that IP. Or just try SNMP or even
>> telnet (which might connect you to a "virtual" console port on the server).
>>
>>
>>>
>>> Sort of Liechtenstein :-)
>>>
>>> So: to summarise
>>> It appears to be absolutely associated with that server hardware
>>> It exists outside of *normal* linux networking on that hardware
>>> It appears to do nothing except respond to pings and issue DHCP client
>>> commands. There are, for example no NAT sessions on the router with that
>>> source address...
>>> It persists between reboots
>>> It comes up before normal networking does, on that hardware
>>>
>>> The oddest thing to date however is that the *server itself* reports
>>> 'Destination Host Unreachable'
>>>
>>> PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
>>> From 192.168.0.100 icmp_seq=1 Destination Host Unreachable
>>>
>>> So it MUST know *something* about that interface/IP address that tells
>>> it it 'cannot be reached'.
>>>
>>> Which seems to rule out something below the linux level *completely*.
>>
>> Not necessarily. If this is hardware purpose built to be a server, it might
>> have some sort of system management thing "built in" that is using the same
>> NIC as the main machine, but totally without the O/S's "knowledge".
>>
>> Reboot the machine and stop in BIOS Setup and poke around there.
>
> +1
>
> I'd suspect IPMI or other similar out of band BIOS level interface
> sharing the ethernet port. Those often have their own MAC address,
> but I suppose they don't *have* to.
>
So how would that software know that the machine is called 'cymbeline' them?

Only Linux knows that

Which is why I rejected that explanation - or art leasts placed it at a
very low probability.

As I said, I am waiting for a DHCP request. Hopefully the DHCP client
will reveal something of itself

If the request is from hostname 'cymbeline' it HAS to be a linux origin

--
WOKE is an acronym... Without Originality, Knowledge or Education.

On 03/06/2021 17:41, David W. Hodgins wrote:
> On Thu, 03 Jun 2021 04:18:24 -0400, The Natural Philosopher
> <tnp@invalid.invalid> wrote:
>> Mmm. Something at board BIOS level perhaps? Its a very OLD board
>>
>> inxi -M
>> Machine:   Type: Desktop Mobo: Intel model: DG43GT v: AAE62768-300
>> serial: BTGT93200534 BIOS: Intel
>>             v: GTG4310H.86A.0035.2010.1006.1525 date: 10/06/2010
>
> From ...
> https://ark.intel.com/content/www/us/en/ark/products/41036/intel-desktop-board-dg43gt.html
>
>
> After clicking on "Intel® Remote Wake Technology", it shows ...
> ====
> Intel® Remote Wake technology (Intel® RWT) enables home PCs, enabled
> services, and mobile devices to communicate with one another remotely
> over the Internet, for 24/7 access while maintaining PC energy
> efficiency. Built on the Intel® Management Engine, Intel RWT allows you
> to remotely wake up home PCs from an enabled Internet application or
> service, while in energy efficient sleep mode.
> ====
>
> Power off is not the same as pulling the plug. The system is always on
> at a low
> level, so this very old mb does have the remote wake feature of the
> Management
> Engine. Any packets received from the network may be intercepted by the
> hardware
> and not seen by the os.
>
> Regards, Dave Hodgins
>
As I said, something calling itself 'cymbeline', a linux hostname,
appears to be issuing this DHCP request. The BIOS doesn't know the name
of the machine.

Which is why I am waiting for a DHCP request from 'cymbeline'

--
"Anyone who believes that the laws of physics are mere social
conventions is invited to try transgressing those conventions from the
windows of my apartment. (I live on the twenty-first floor.) "

Alan Sokal

On Thu, 03 Jun 2021 15:14:10 -0400, The Natural Philosopher <tnp@invalid.invalid> wrote:
> As I said, something calling itself 'cymbeline', a linux hostname,
> appears to be issuing this DHCP request. The BIOS doesn't know the name
> of the machine.
> Which is why I am waiting for a DHCP request from 'cymbeline'

The system sending the ping request knows from other network responses that the
system is called cymbeline. It can't tell whether the response is coming from
the linux os on that system or from the intel management engine, since all
responses from that machine come from the same mac/ip.

Use the bios or uefi setup to turn off the wake on lan feature (and any other
intel management engine features) and the ghost responses will stop.

Regards, Dave Hodgins

--
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

On 03/06/2021 20:59, David W. Hodgins wrote:
> On Thu, 03 Jun 2021 15:14:10 -0400, The Natural Philosopher
> <tnp@invalid.invalid> wrote:
>> As I said, something calling itself 'cymbeline', a linux hostname,
>> appears to be issuing this DHCP request. The BIOS  doesn't know the name
>> of the machine.
>> Which is why I am waiting for a DHCP request from 'cymbeline'
>
> The system sending the ping request knows from other network responses
> that the
> system is called cymbeline. It can't tell whether the response is coming
> from
> the linux os on that system or from the intel management engine, since all
> responses from that machine come from the same mac/ip.
>
> Use the bios or uefi setup to turn off the wake on lan feature (and any
> other
> intel management engine features) and the ghost responses will stop.
>
> Regards, Dave Hodgins
>
Dear Dave. please read the WHOLE thread

the machine making the ping does NOT know that the machine responding to
it is called cymbeline.

Desktop $ ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=255 time=0.744 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=255 time=0.760 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=255 time=0.781 ms

Server$ ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
From 192.168.0.100 icmp_seq=1 Destination Host Unreachable
From 192.168.0.100 icmp_seq=2 Destination Host Unreachable

The DHCP server (a draytek router) does,because when making a DHCP
request, you can optionally present the host name you wish to be known as

Viz
# tcpdump -vnes0 port 67 or port 68

19:15:15.344005 00:09:df:b7:8e:b9 > ff:ff:ff:ff:ff:ff, ethertype IPv4
(0x0800), length 348: (tos 0x0, ttl 64, id 0, offset 0, flags [none],
proto UDP (17), length 334)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from
00:09:df:b7:8e:b9, length 306, xid 0x1e31174a, Flags [none]
Client-Ethernet-Address 00:09:df:b7:8e:b9
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Client-ID Option 61, length 7: ether 00:09:df:b7:8e:b9
Requested-IP Option 50, length 4: 192.168.0.2
Server-ID Option 54, length 4: 192.168.0.254
MSZ Option 57, length 2: 576
Parameter-Request Option 55, length 7:
Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
Domain-Name, BR, NTP
Vendor-Class Option 60, length 12: "udhcp 1.18.4"
Hostname Option 12, length 12: "PANASONIC TV"

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This name appears in the routers dhcp table
If no name is presented no name is stored

see these records allocating 192.168.0.4 - to a samsung smart TV

19:13:26.089174 1c:5a:3e:7e:37:1f > ff:ff:ff:ff:ff:ff, ethertype IPv4
(0x0800), length 347: (tos 0x0, ttl 64, id 0, offset 0, flags [none],
proto UDP (17), length 333)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from
1c:5a:3e:7e:37:1f, length 305, xid 0xeca94368, Flags [none]
Client-Ethernet-Address 1c:5a:3e:7e:37:1f
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Client-ID Option 61, length 7: ether 1c:5a:3e:7e:37:1f
MSZ Option 57, length 2: 576
Parameter-Request Option 55, length 7:
Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
Domain-Name, BR, NTP
Vendor-Class Option 60, length 37: "udhcp 1.18.1-VD Linux
VDLinux.1.2.1.x"
19:13:26.113304 1c:5a:3e:7e:37:1f > ff:ff:ff:ff:ff:ff, ethertype IPv4
(0x0800), length 359: (tos 0x0, ttl 64, id 0, offset 0, flags [none],
proto UDP (17), length 345)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from
1c:5a:3e:7e:37:1f, length 317, xid 0xeca94368, Flags [none]
Client-Ethernet-Address 1c:5a:3e:7e:37:1f
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Client-ID Option 61, length 7: ether 1c:5a:3e:7e:37:1f
Requested-IP Option 50, length 4: 192.168.0.4
Server-ID Option 54, length 4: 192.168.0.254
MSZ Option 57, length 2: 576
Parameter-Request Option 55, length 7:
Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
Domain-Name, BR, NTP
Vendor-Class Option 60, length 37: "udhcp 1.18.1-VD Linux
VDLinux.1.2.1.x"

Now what does the router DHCP table contain?
LAN1
1 192.168.0.1 00-1C-C0-F2-B2-DC 15:31:46 cymbeline
2 192.168.0.2 00-09-DF-B7-8E-B9 22:58:34 PANASONICTV
3 192.168.0.3 90-48-9A-E1-BE-65 19:17:03 Titania
4 192.168.0.4 1C-5A-3E-7E-37-1F 22:56:45
5 192.168.0.5 08-62-66-4A-85-D8 19:55:54 shylock
6 192.168.0.6 5C-51-81-BB-C2-85 16:38:24 Malvolio

All the clients except the samsung TV can be seen telling the DHCP
server who they are.

Ergo it is reasonable to assume that whatever issues the dhcp request
for 'cymbeline' originates *inside* linux in some way, and that is
confirmed by the fact the server responds to pings with a
Destination Host Unreachable when that interface is pinged *from the
server* , but no other machine on the network does.

--
All political activity makes complete sense once the proposition that
all government is basically a self-legalising protection racket, is
fully understood.

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

> systemd has its own dhcp client :-)

It's actually systemd-networkd which includes a DHCP client. If that
service is not running and you don't have some other client installed,
then nothing in Linux should be doing DHCP requests.

> I'll wait until the dhcp lease runs out overnight and see what is
> requesting it.

I noticed recently short lease times help when debugging this sort of
thing. For some reason my Mikrotik router defaults to 10 minutes but it
did come in handy when I tried to modify a DHCP script for the thing.

On 03/06/2021 21:37, Anssi Saari wrote:
> The Natural Philosopher <tnp@invalid.invalid> writes:
>
>> systemd has its own dhcp client :-)
>
> It's actually systemd-networkd which includes a DHCP client. If that
> service is not running and you don't have some other client installed,
> then nothing in Linux should be doing DHCP requests.

well I have no idea if its running or not. With systemd, as with
heffalumps, you never know :-)

("De heffalumpis semper dubitandum est.")

I would have assumed that some watcher would be altered when the lease
is running out, and the something would come along and fire up and then
renew it.

Certainly on *this* desktop I have dhclient running
$ ps -eadf | grep dhcp
root 14484 1107 0 07:01 ? 00:00:00 /sbin/dhclient -d -sf
/usr/lib/NetworkManager/nm-dhcp-client.action -pf
/run/sendsigs.omit.d/network-manager.dhclient-eth0.pid -lf
/var/lib/NetworkManager/dhclient-81c29c27-1846-4a8f-a3d0-0e999468e517-eth0.lease
-cf /var/lib/NetworkManager/dhclient-eth0.conf eth0

But no sign of that on the server

>
>> I'll wait until the dhcp lease runs out overnight and see what is
>> requesting it.
>
> I noticed recently short lease times help when debugging this sort of
> thing. For some reason my Mikrotik router defaults to 10 minutes but it
> did come in handy when I tried to modify a DHCP script for the thing.
>
yeah I am on 24 hour lease times - most machines come back in a few
hours. The TV every few minutes

so far that interface has, oddly enough, not requested a new lease in 8
hours

One interesting thing in syslog is this

cymbeline NetworkManager[850]: <info> [1622717305.0839] dhcp-init:
Using DHCP client 'internal'

apparently latest Network manager code does need any external dhclient

https://developer.gnome.org/NetworkManager/stable/NetworkManager.conf.html

"dhcp
This key sets up what DHCP client NetworkManager will use. Allowed
values are dhclient, dhcpcd, and internal. The dhclient and dhcpcd
options require the indicated clients to be installed. The internal
option uses a built-in DHCP client which is not currently as featureful
as the external clients. "

However I would not expect the network manager to create a crippled
interface, and earlier test showed that this ghost interface was up
BEFORE the one that network manager creates was..so its all still a mystery

--
Climate is what you expect but weather is what you get.
Mark Twain

The Natural Philosopher <tnp@invalid.invalid> writes:
> On 02/06/2021 18:46, Pascal Hambourg wrote:
>> Tests I can think of :
>> Run a packet capture on the ethernet interface and see if this
>> traffic is visible.
> Well, Pascal, this gets weirder.
>
> It's seeing the traffic to 192.168.0.1:any = which is reasonable since
> the traffic has its MAC address as corresponding so the ethernet
> switch will route it there - but its not responding!
>
> So WTF is?
>
> Its as if there is a virtual interface with another name than
> enp0s25...that tcpdump aint seeing...
>
> I've tried rebooting the 100Mbps switch. No difference
>
> # tcpdump -vv --interface=any icmp
> tcpdump: listening on any, link-type LINUX_SLL (Linux cooked v1),
> capture size 262144 bytes
> 06:49:30.029548 IP (tos 0x0, ttl 64, id 62895, offset 0, flags [DF],
> proto ICMP (1), length 84)
> 192.168.0.5 > 192.168.0.1: ICMP echo request, id 14398, seq 1,
> length 64
[...]
> 192.168.0.5 > cymbeline: ICMP echo request, id 14399, seq 1, length 64
> 06:49:51.088115 IP (tos 0x0, ttl 64, id 22498, offset 0, flags [none],
> proto ICMP (1), length 84)
> cymbeline > 192.168.0.5: ICMP echo reply, id 14399, seq 1, length 64
> 06:49:52.087261 IP (tos 0x0, ttl 64, id 15047, offset 0, flags [DF],
> proto ICMP (1), length 84)

You need to use at least the -e and -n options to tcpdump:
-e to see the link-level header (particularly important)
-n to see addresses rather than hostnames
....and you need tcpdumps both on a client machine (e.g. 192.168.0.5) and
the server, while a ping from the client is going.

> And yet something is responding...

I don’t think it’s yet proven that it’s cymbeline responding, though.

> xxx@shylock ~/Desktop $ ping 192.168.0.1
> PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
> 64 bytes from 192.168.0.1: icmp_seq=1 ttl=255 time=0.730 ms
> 64 bytes from 192.168.0.1: icmp_seq=2 ttl=255 time=0.777 ms
> 64 bytes from 192.168.0.1: icmp_seq=3 ttl=255 time=0.823 ms
> 64 bytes from 192.168.0.1: icmp_seq=4 ttl=255 time=0.743 ms
> ^C
> --- 192.168.0.1 ping statistics ---
> 4 packets transmitted, 4 received, 0% packet loss, time 3000ms
> rtt min/avg/max/mdev = 0.730/0.768/0.823/0.040 ms
> xxx@shylock ~/Desktop $ ping 192.168.0.100
> PING 192.168.0.100 (192.168.0.100) 56(84) bytes of data.
> 64 bytes from 192.168.0.100: icmp_seq=1 ttl=64 time=0.260 ms
> 64 bytes from 192.168.0.100: icmp_seq=2 ttl=64 time=0.417 ms
> 64 bytes from 192.168.0.100: icmp_seq=3 ttl=64 time=0.283 ms
> ^C
> --- 192.168.0.100 ping statistics ---
> 3 packets transmitted, 3 received, 0% packet loss, time 1998ms
> rtt min/avg/max/mdev = 0.260/0.320/0.417/0.069 ms
>
>
> The odd thing is that the *correct* IP response is ~half the
> delay... and the TTL is set differently on the 'ghost'

I think the anomalous delay is a big hint. Something quite different
must be happening on the network for .1 and .100.

Wild guesses:
- some other (slower) endpoint is responding, not cymbeline at all.
- something is accepting packets for .1 and forwarding them to
cymbeline (and presumably forwarding the responses back).

In both cases your router is the most likely candidate for ‘something’.
I have no idea why it would do either, but having met routers that
thought it a good idea to proxy-ARP for all non-local addresses and
forward the resulting stolen traffic over its WAN interface, I could
believe anything.

Probably wrong guesses:
- something crazy involving ICMP redirects.
(but I don’t think they work like that)
- something crazy involving SMM or other board features
(but while snooping network traffic is plausible, synthesizing echo
responses is much less so)

What make & model is the router?

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

On 03/06/2021 22:27, Richard Kettlewell wrote:
> The Natural Philosopher <tnp@invalid.invalid> writes:
>> On 02/06/2021 18:46, Pascal Hambourg wrote:
>>> Tests I can think of :
>>> Run a packet capture on the ethernet interface and see if this
>>> traffic is visible.
>> Well, Pascal, this gets weirder.
>>
>> It's seeing the traffic to 192.168.0.1:any = which is reasonable since
>> the traffic has its MAC address as corresponding so the ethernet
>> switch will route it there - but its not responding!
>>
>> So WTF is?
>>
>> Its as if there is a virtual interface with another name than
>> enp0s25...that tcpdump aint seeing...
>>
>> I've tried rebooting the 100Mbps switch. No difference
>>
>> # tcpdump -vv --interface=any icmp
>> tcpdump: listening on any, link-type LINUX_SLL (Linux cooked v1),
>> capture size 262144 bytes
>> 06:49:30.029548 IP (tos 0x0, ttl 64, id 62895, offset 0, flags [DF],
>> proto ICMP (1), length 84)
>> 192.168.0.5 > 192.168.0.1: ICMP echo request, id 14398, seq 1,
>> length 64
> [...]
>> 192.168.0.5 > cymbeline: ICMP echo request, id 14399, seq 1, length 64
>> 06:49:51.088115 IP (tos 0x0, ttl 64, id 22498, offset 0, flags [none],
>> proto ICMP (1), length 84)
>> cymbeline > 192.168.0.5: ICMP echo reply, id 14399, seq 1, length 64
>> 06:49:52.087261 IP (tos 0x0, ttl 64, id 15047, offset 0, flags [DF],
>> proto ICMP (1), length 84)
>
> You need to use at least the -e and -n options to tcpdump:
> -e to see the link-level header (particularly important)
> -n to see addresses rather than hostnames
> ...and you need tcpdumps both on a client machine (e.g. 192.168.0.5) and
> the server, while a ping from the client is going.
>
>> And yet something is responding...
>
> I don’t think it’s yet proven that it’s cymbeline responding, though.
>
>> xxx@shylock ~/Desktop $ ping 192.168.0.1
>> PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
>> 64 bytes from 192.168.0.1: icmp_seq=1 ttl=255 time=0.730 ms
>> 64 bytes from 192.168.0.1: icmp_seq=2 ttl=255 time=0.777 ms
>> 64 bytes from 192.168.0.1: icmp_seq=3 ttl=255 time=0.823 ms
>> 64 bytes from 192.168.0.1: icmp_seq=4 ttl=255 time=0.743 ms
>> ^C
>> --- 192.168.0.1 ping statistics ---
>> 4 packets transmitted, 4 received, 0% packet loss, time 3000ms
>> rtt min/avg/max/mdev = 0.730/0.768/0.823/0.040 ms
>> xxx@shylock ~/Desktop $ ping 192.168.0.100
>> PING 192.168.0.100 (192.168.0.100) 56(84) bytes of data.
>> 64 bytes from 192.168.0.100: icmp_seq=1 ttl=64 time=0.260 ms
>> 64 bytes from 192.168.0.100: icmp_seq=2 ttl=64 time=0.417 ms
>> 64 bytes from 192.168.0.100: icmp_seq=3 ttl=64 time=0.283 ms
>> ^C
>> --- 192.168.0.100 ping statistics ---
>> 3 packets transmitted, 3 received, 0% packet loss, time 1998ms
>> rtt min/avg/max/mdev = 0.260/0.320/0.417/0.069 ms
>>
>>
>> The odd thing is that the *correct* IP response is ~half the
>> delay... and the TTL is set differently on the 'ghost'
>
> I think the anomalous delay is a big hint. Something quite different
> must be happening on the network for .1 and .100.
>
> Wild guesses:
> - some other (slower) endpoint is responding, not cymbeline at all.

I think that I have eliminated that by physically unplugging cymbeline
from the network. The echoes stop.

> - something is accepting packets for .1 and forwarding them to
> cymbeline (and presumably forwarding the responses back).
>
Then why does a ping from cymbeline not get a response? But gets a host
unreachable?

Check my reasoning.
1/. DHCP is registered for 'cymbeline' - that implies that that name has
been passed by the dhcp client. That means its coming from the linux
subsystem
2/. The mac address registered with DHCP is cymbeline's ethernet MAC
3/. The interface does not respond when cymbeline is unplugged
4/. The interface does not respond when cymbeline is rebooted, but
starts to respond BEFORE its main interface is up. which suggests a
redirection is not the way its working
5/. the only machine that can't ping that IP address is cymbeline
itself. Cymbeline 'knows' something about that interface that no other
machine does.

> In both cases your router is the most likely candidate for ‘something’.
> I have no idea why it would do either, but having met routers that
> thought it a good idea to proxy-ARP for all non-local addresses and
> forward the resulting stolen traffic over its WAN interface, I could
> believe anything.
>
Well yes, I have had some crap routers in my time. I switched off the
router at one point. Changed nothing.

I haven't tried switching off the other bits of crap on the network -
wireless access points - but I can't see how they could be doing this..

> Probably wrong guesses:
> - something crazy involving ICMP redirects.
> (but I don’t think they work like that)
> - something crazy involving SMM or other board features
> (but while snooping network traffic is plausible, synthesizing echo
> responses is much less so)
>
> What make & model is the router?
>
Model Name Vigor2762Vac
Router Name DrayTek
Current Time Thu Jun 03 2021 22:48:56
Firmware Version 3.8.9.2_BT
Build Date/Time Jul 30 2018 14:33:57
DSL Version 07-07-03-0F-00-01

--
In a Time of Universal Deceit, Telling the Truth Is a Revolutionary Act.

- George Orwell

On Thu, 03 Jun 2021 17:19:42 -0400, The Natural Philosopher <tnp@invalid.invalid> wrote:

> On 03/06/2021 21:37, Anssi Saari wrote:
>> The Natural Philosopher <tnp@invalid.invalid> writes:
>>
>>> systemd has its own dhcp client :-)
>>
>> It's actually systemd-networkd which includes a DHCP client. If that
>> service is not running and you don't have some other client installed,
>> then nothing in Linux should be doing DHCP requests.
>
> well I have no idea if its running or not. With systemd, as with
> heffalumps, you never know :-)

What's the output of "systemctl status systemd-networkd.service"?

Regards, Dave Hodgins

--
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

The Natural Philosopher <tnp@invalid.invalid> writes:
> On 03/06/2021 22:27, Richard Kettlewell wrote:
>> I think the anomalous delay is a big hint. Something quite different
>> must be happening on the network for .1 and .100.
>>
>> Wild guesses:
>> - some other (slower) endpoint is responding, not cymbeline at all.
>
> I think that I have eliminated that by physically unplugging cymbeline
> from the network. The echoes stop.

Agreed.

>> - something is accepting packets for .1 and forwarding them to
>> cymbeline (and presumably forwarding the responses back).
>
> Then why does a ping from cymbeline not get a response? But gets a
> host unreachable?
>
> Check my reasoning.
> 1/. DHCP is registered for 'cymbeline' - that implies that that name
> has been passed by the dhcp client. That means its coming from the
> linux subsystem
> 2/. The mac address registered with DHCP is cymbeline's ethernet MAC

I don’t think any of the tcpdumps I’ve yet seen show ongoing DHCP
requests mentioning that hostname. The fact that it’s in the DHCP
server’s table just tells us that there was at least one request some
time in the past (i.e. perhaps the DHCP server is slow to expire stale
entries). So I think that #1/#2 are suggestive at best.

> 3/. The interface does not respond when cymbeline is unplugged
> 4/. The interface does not respond when cymbeline is rebooted, but
> starts to respond BEFORE its main interface is up. which suggests a
> redirection is not the way its working

Agreed that #3 and #4 strongly suggest cymbeline is involved
somehow. That’s pushing me closer to crazy platform feature nonsense
(SMM etc).

> 5/. the only machine that can't ping that IP address is cymbeline
> itself. Cymbeline 'knows' something about that interface that no other
> machine does.

Until we have a better model for why the other endpoints _can_ ping .1,
I don’t think the fact that cymbeline can’t tells us much.

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

On 03/06/2021 22:57, David W. Hodgins wrote:
> systemctl status systemd-networkd.service

systemctl status systemd-networkd.service
● systemd-networkd.service - Network Service
Loaded: loaded (/lib/systemd/system/systemd-networkd.service;
disabled; vendor preset: enabled)
Active: inactive (dead)
Docs: man:systemd-networkd.service(8)

--
"When a true genius appears in the world, you may know him by this sign,
that the dunces are all in confederacy against him."

Jonathan Swift.

Richard Kettlewell <invalid@invalid.invalid> writes:
> The Natural Philosopher <tnp@invalid.invalid> writes:
>> 5/. the only machine that can't ping that IP address is cymbeline
>> itself. Cymbeline 'knows' something about that interface that no other
>> machine does.
>
> Until we have a better model for why the other endpoints _can_ ping .1,
> I don’t think the fact that cymbeline can’t tells us much.

To expand on this point:

Suppose, hypothetically, some platform feature is intercepting inbound
packets and generating ICMP echo responses. In that case the reason that
cymbeline, uniquely, can’t ping .1 would be that the ICMP echo requests
would be outbound rather than inbound. In this hypothetical, cymbeline
doesn’t “know” anything special, it’s just that the issue lies between
cymbeline’s kernel and the rest of the network.

Other (more or less crazy) possibilities may be structurally similar.

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

On 03/06/2021 23:29, Richard Kettlewell wrote:
> The Natural Philosopher <tnp@invalid.invalid> writes:
>> On 03/06/2021 22:27, Richard Kettlewell wrote:
>>> I think the anomalous delay is a big hint. Something quite different
>>> must be happening on the network for .1 and .100.
>>>
>>> Wild guesses:
>>> - some other (slower) endpoint is responding, not cymbeline at all.
>>
>> I think that I have eliminated that by physically unplugging cymbeline
>> from the network. The echoes stop.
>
> Agreed.
>
>>> - something is accepting packets for .1 and forwarding them to
>>> cymbeline (and presumably forwarding the responses back).
>>
>> Then why does a ping from cymbeline not get a response? But gets a
>> host unreachable?
>>
>> Check my reasoning.
>> 1/. DHCP is registered for 'cymbeline' - that implies that that name
>> has been passed by the dhcp client. That means its coming from the
>> linux subsystem
>> 2/. The mac address registered with DHCP is cymbeline's ethernet MAC
>
> I don’t think any of the tcpdumps I’ve yet seen show ongoing DHCP
> requests mentioning that hostname.

No, but I am watching for them now

The fact that it’s in the DHCP
> server’s table just tells us that there was at least one request some
> time in the past (i.e. perhaps the DHCP server is slow to expire stale
> entries). So I think that #1/#2 are suggestive at best.
No. I cleared that table.
*And* rebooted the router
its appeared since then.
>
>> 3/. The interface does not respond when cymbeline is unplugged
>> 4/. The interface does not respond when cymbeline is rebooted, but
>> starts to respond BEFORE its main interface is up. which suggests a
>> redirection is not the way its working
>
> Agreed that #3 and #4 strongly suggest cymbeline is involved
> somehow. That’s pushing me closer to crazy platform feature nonsense
> (SMM etc).
social media marketing?

Expand that?

>
>> 5/. the only machine that can't ping that IP address is cymbeline
>> itself. Cymbeline 'knows' something about that interface that no other
>> machine does.
>
> Until we have a better model for why the other endpoints _can_ ping .1,
> I don’t think the fact that cymbeline can’t tells us much.
>
I am not in total disagreement with that.

--
"When a true genius appears in the world, you may know him by this sign,
that the dunces are all in confederacy against him."

Jonathan Swift.

On 03/06/2021 23:39, Richard Kettlewell wrote:
> Richard Kettlewell <invalid@invalid.invalid> writes:
>> The Natural Philosopher <tnp@invalid.invalid> writes:
>>> 5/. the only machine that can't ping that IP address is cymbeline
>>> itself. Cymbeline 'knows' something about that interface that no other
>>> machine does.
>>
>> Until we have a better model for why the other endpoints _can_ ping .1,
>> I don’t think the fact that cymbeline can’t tells us much.
>
> To expand on this point:
>
> Suppose, hypothetically, some platform feature is intercepting inbound
> packets and generating ICMP echo responses. In that case the reason that
> cymbeline, uniquely, can’t ping .1 would be that the ICMP echo requests
> would be outbound rather than inbound. In this hypothetical, cymbeline
> doesn’t “know” anything special, it’s just that the issue lies between
> cymbeline’s kernel and the rest of the network.
>
> Other (more or less crazy) possibilities may be structurally similar.
>
yes...I misunderstood what host unreachable meant - simply that no
response is recieved. I thought it was an actual ICMP response saying
'i'm not here' whereas in fact it seems to mean the ARP request failed

And that is confirmed. Other machines have ARP entries for 192.168.0.1
but cymbeline does not.

I found out what you meant by SMM

the chips in play are these:

CPU: Dual Core Intel Core2 Duo E6850 (-MCP-) speed/min/max:
2569/1998/2997 MHz Kernel: 5.4.0-702104061620-generic x86_64
Network: Device-1: Intel 82567V-2 Gigabit Network driver: e1000e
IF: enp0s25 state: up speed: 100 Mbps duplex: full mac:
00:1c:c0:f2:b2:dc

--
"Strange as it seems, no amount of learning can cure stupidity, and
higher education positively fortifies it."

- Stephen Vizinczey

On 03/06/2021 23:29, Richard Kettlewell wrote:
> The Natural Philosopher <tnp@invalid.invalid> writes:
>> On 03/06/2021 22:27, Richard Kettlewell wrote:
>>> I think the anomalous delay is a big hint. Something quite different
>>> must be happening on the network for .1 and .100.
>>>
>>> Wild guesses:
>>> - some other (slower) endpoint is responding, not cymbeline at all.
>>
>> I think that I have eliminated that by physically unplugging cymbeline
>> from the network. The echoes stop.
>
> Agreed.
>
>>> - something is accepting packets for .1 and forwarding them to
>>> cymbeline (and presumably forwarding the responses back).
>>
>> Then why does a ping from cymbeline not get a response? But gets a
>> host unreachable?
>>
>> Check my reasoning.
>> 1/. DHCP is registered for 'cymbeline' - that implies that that name
>> has been passed by the dhcp client. That means its coming from the
>> linux subsystem
>> 2/. The mac address registered with DHCP is cymbeline's ethernet MAC
>
> I don’t think any of the tcpdumps I’ve yet seen show ongoing DHCP
> requests mentioning that hostname. The fact that it’s in the DHCP
> server’s table just tells us that there was at least one request some
> time in the past (i.e. perhaps the DHCP server is slow to expire stale
> entries). So I think that #1/#2 are suggestive at best.
>
>> 3/. The interface does not respond when cymbeline is unplugged
>> 4/. The interface does not respond when cymbeline is rebooted, but
>> starts to respond BEFORE its main interface is up. which suggests a
>> redirection is not the way its working
>
> Agreed that #3 and #4 strongly suggest cymbeline is involved
> somehow. That’s pushing me closer to crazy platform feature nonsense
> (SMM etc).
>
>> 5/. the only machine that can't ping that IP address is cymbeline
>> itself. Cymbeline 'knows' something about that interface that no other
>> machine does.
>
> Until we have a better model for why the other endpoints _can_ ping .1,
> I don’t think the fact that cymbeline can’t tells us much.
>
Well I caught a dhcp packet but only on cymbelines interface -
unsurprising since it wasn't a broadcast.
It has reset the timer in the router dhcp table

00:00:06.220639 00:1d:aa:79:78:40 > 00:1c:c0:f2:b2:dc, ethertype IPv4
(0x0800), length 335: (tos 0x0, ttl 255, id 22522, offset 0, flags
[none], proto UDP (17), length 321)
192.168.0.254.67 > 192.168.0.1.68: BOOTP/DHCP, Reply, length 293,
xid 0x331c78, Flags [none]
Your-IP 192.168.0.1
Server-IP 192.168.0.254
Client-Ethernet-Address 00:1c:c0:f2:b2:dc
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: ACK
Server-ID Option 54, length 4: 192.168.0.254
RN Option 58, length 4: 43200
RB Option 59, length 4: 75600
Lease-Time Option 51, length 4: 86400
Netbios-Node Option 46, length 1: m-node
Subnet-Mask Option 1, length 4: 255.255.255.0
Default-Gateway Option 3, length 4: 192.168.0.254
Domain-Name-Server Option 6, length 8: 192.168.0.100,212.69.36.23

Frankly I am not sure what it means. IT seems that dhcp leases are
extended by sending a request, and this is a response to that but it
doesn't really say where the request originated beyond it being the MAC
address of cymbeline.

Its late. I will leave the next stage = rebooting cymbeline with tcpdump
running on another machine - until tomorrow, if I get a chance.

I had hoped that lease renewal would reveal more, but it didnt :-)

--
Ideas are more powerful than guns. We would not let our enemies have
guns, why should we let them have ideas?

Josef Stalin

On Thu, 03 Jun 2021 19:07:38 -0400, The Natural Philosopher <tnp@invalid.invalid> wrote:
> yes...I misunderstood what host unreachable meant - simply that no
> response is recieved. I thought it was an actual ICMP response saying
> 'i'm not here' whereas in fact it seems to mean the ARP request failed
>
> And that is confirmed. Other machines have ARP entries for 192.168.0.1
> but cymbeline does not.

I have no idea how the router is getting the name cymbeline if dhcp is not
being used in the linux install, unless it's stored the name for that mac address
when it was using dhcp, rather then storing it by ip address, and keeping that
name stored for that mac until it gets overwritten or the router reset to factory
defaults.

As far as the second ip address for the same mac, I still think it's the intel
management engine. In order for the wake on lan feature to work, it probably has to
be able to receive a packet, so needs an internet address (I've never used wake on
lan, so have no experience with it). While I haven't found anything in the limited
documentation I've looked at for it, it makes sense that it would use dhcp to get the
address to avoid conflicts with other systems. The router knows both ip addresses go
to the same network interface by it's mac address.

Please do try disabling the wake on lan feature.

Regards, Dave Hodgins

--
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

"David W. Hodgins" <dwhodgins@nomail.afraid.org> writes:
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>> yes...I misunderstood what host unreachable meant - simply that no
>> response is recieved. I thought it was an actual ICMP response saying
>> 'i'm not here' whereas in fact it seems to mean the ARP request
>> failed
>>
>> And that is confirmed. Other machines have ARP entries for 192.168.0.1
>> but cymbeline does not.
>
> I have no idea how the router is getting the name cymbeline if dhcp is
> not being used in the linux install, unless it's stored the name for
> that mac address when it was using dhcp, rather then storing it by ip
> address, and keeping that name stored for that mac until it gets
> overwritten or the router reset to factory defaults.
>
> As far as the second ip address for the same mac, I still think it's
> the intel management engine. In order for the wake on lan feature to
> work, it probably has to be able to receive a packet, so needs an
> internet address (I've never used wake on lan, so have no experience
> with it).

No IP address is required for Wake-on-LAN, just the MAC address. The
magic packet may be formatted as an IP packet but the firmware that
recognizes it doesn’t care about that, any appropriately formatted
ethernet frame will do. It certainly doesn’t bring up a second address
just for Wake-on-LAN.

Some kind of strange platform feature remains a possibility although
TNP’s board doesn’t really have many to choose from:

https://ark.intel.com/content/www/us/en/ark/products/41036/intel-desktop-board-dg43gt.html

I’m unclear on whether “Intel® Remote Wake Technology” is traditional
Wake-on-LAN with a fancy name or whether they reinvented a wheel there,
and the web is really not helping.

> Please do try disabling the wake on lan feature.

It’s worth doing the experiment, but my current guess is that it is not
the cause.

The anomalous ping timings and TTLs still make me suspect some other
network device, possibly the router, is involved, hence wanting to see
more detailed tcpdump output.

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

On 4.6.21 2.35, The Natural Philosopher wrote:
> On 03/06/2021 23:29, Richard Kettlewell wrote:
>> The Natural Philosopher <tnp@invalid.invalid> writes:
>>> On 03/06/2021 22:27, Richard Kettlewell wrote:
>>>> I think the anomalous delay is a big hint. Something quite different
>>>> must be happening on the network for .1 and .100.
>>>>
>>>> Wild guesses:
>>>> - some other (slower) endpoint is responding, not cymbeline at all.
>>>
>>> I think that I have eliminated that by physically unplugging cymbeline
>>> from the network. The echoes stop.
>>
>> Agreed.
>>
>>>> - something is accepting packets for .1 and forwarding them to
>>>>     cymbeline (and presumably forwarding the responses back).
>>>
>>> Then why does a ping from cymbeline not get a response? But gets a
>>> host unreachable?
>>>
>>> Check my reasoning.
>>> 1/. DHCP is registered for 'cymbeline' - that implies that that name
>>> has been passed by the dhcp client. That means its coming from the
>>> linux subsystem
>>> 2/. The mac address registered with DHCP is cymbeline's ethernet MAC
>>
>> I don’t think any of the tcpdumps I’ve yet seen show ongoing DHCP
>> requests mentioning that hostname. The fact that it’s in the DHCP
>> server’s table just tells us that there was at least one request some
>> time in the past (i.e. perhaps the DHCP server is slow to expire stale
>> entries). So I think that #1/#2 are suggestive at best.
>>
>>> 3/. The interface does not respond when cymbeline is unplugged
>>> 4/. The interface does not respond when cymbeline is rebooted, but
>>> starts to respond BEFORE its main interface is up. which suggests a
>>> redirection is not the way its working
>>
>> Agreed that #3 and #4 strongly suggest cymbeline is involved
>> somehow. That’s pushing me closer to crazy platform feature nonsense
>> (SMM etc).
>>
>>> 5/. the only machine that can't ping that IP address is cymbeline
>>> itself. Cymbeline 'knows' something about that interface that no other
>>> machine does.
>>
>> Until we have a better model for why the other endpoints _can_ ping .1,
>> I don’t think the fact that cymbeline can’t tells us much.
>>
> Well I caught a dhcp packet but only on cymbelines interface -
> unsurprising since it wasn't a broadcast.
> It has reset the timer in the router dhcp table
>
>
> 00:00:06.220639 00:1d:aa:79:78:40 > 00:1c:c0:f2:b2:dc, ethertype IPv4
> (0x0800), length 335: (tos 0x0, ttl 255, id 22522, offset 0, flags
> [none], proto UDP (17), length 321)
>     192.168.0.254.67 > 192.168.0.1.68: BOOTP/DHCP, Reply, length 293,
> xid 0x331c78, Flags [none]
>       Your-IP 192.168.0.1
>       Server-IP 192.168.0.254
>       Client-Ethernet-Address 00:1c:c0:f2:b2:dc
>       Vendor-rfc1048 Extensions
>         Magic Cookie 0x63825363
>         DHCP-Message Option 53, length 1: ACK
>         Server-ID Option 54, length 4: 192.168.0.254
>         RN Option 58, length 4: 43200
>         RB Option 59, length 4: 75600
>         Lease-Time Option 51, length 4: 86400
>         Netbios-Node Option 46, length 1: m-node
>         Subnet-Mask Option 1, length 4: 255.255.255.0
>         Default-Gateway Option 3, length 4: 192.168.0.254
>         Domain-Name-Server Option 6, length 8: 192.168.0.100,212.69.36.23
>
> Frankly I am not sure what it means. IT seems that dhcp leases are
> extended by sending a request, and this is a response to that but it
> doesn't really say where the request originated beyond it being the MAC
> address of cymbeline.
>
>
> Its late. I will leave the next stage = rebooting cymbeline with tcpdump
> running on another machine - until tomorrow, if I get a chance.
>
> I had hoped that lease renewal would reveal more, but it didnt :-)

It would help tracing the cause if you could trace the ARP exchanges
for .1 and .100 after a cold start. In a switched network, you may
need to have a managed switch with aq mirror port for the tracing
host, so you'll not lose directed frmes.

--

-TV

On 04/06/2021 13:04, Tauno Voipio wrote:
> On 4.6.21 2.35, The Natural Philosopher wrote:
>> On 03/06/2021 23:29, Richard Kettlewell wrote:
>>> The Natural Philosopher <tnp@invalid.invalid> writes:
>>>> On 03/06/2021 22:27, Richard Kettlewell wrote:
>>>>> I think the anomalous delay is a big hint. Something quite different
>>>>> must be happening on the network for .1 and .100.
>>>>>
>>>>> Wild guesses:
>>>>> - some other (slower) endpoint is responding, not cymbeline at all.
>>>>
>>>> I think that I have eliminated that by physically unplugging cymbeline
>>>> from the network. The echoes stop.
>>>
>>> Agreed.
>>>
>>>>> - something is accepting packets for .1 and forwarding them to
>>>>>     cymbeline (and presumably forwarding the responses back).
>>>>
>>>> Then why does a ping from cymbeline not get a response? But gets a
>>>> host unreachable?
>>>>
>>>> Check my reasoning.
>>>> 1/. DHCP is registered for 'cymbeline' - that implies that that name
>>>> has been passed by the dhcp client. That means its coming from the
>>>> linux subsystem
>>>> 2/. The mac address registered with DHCP is cymbeline's ethernet MAC
>>>
>>> I don’t think any of the tcpdumps I’ve yet seen show ongoing DHCP
>>> requests mentioning that hostname. The fact that it’s in the DHCP
>>> server’s table just tells us that there was at least one request some
>>> time in the past (i.e. perhaps the DHCP server is slow to expire stale
>>> entries). So I think that #1/#2 are suggestive at best.
>>>
>>>> 3/. The interface does not respond when cymbeline is unplugged
>>>> 4/. The interface does not respond when cymbeline is rebooted, but
>>>> starts to respond BEFORE its main interface is up. which suggests a
>>>> redirection is not the way its working
>>>
>>> Agreed that #3 and #4 strongly suggest cymbeline is involved
>>> somehow. That’s pushing me closer to crazy platform feature nonsense
>>> (SMM etc).
>>>
>>>> 5/. the only machine that can't ping that IP address is cymbeline
>>>> itself. Cymbeline 'knows' something about that interface that no other
>>>> machine does.
>>>
>>> Until we have a better model for why the other endpoints _can_ ping .1,
>>> I don’t think the fact that cymbeline can’t tells us much.
>>>
>> Well I caught a dhcp packet but only on cymbelines interface -
>> unsurprising since it wasn't a broadcast.
>> It has reset the timer in the router dhcp table
>>
>>
>> 00:00:06.220639 00:1d:aa:79:78:40 > 00:1c:c0:f2:b2:dc, ethertype IPv4
>> (0x0800), length 335: (tos 0x0, ttl 255, id 22522, offset 0, flags
>> [none], proto UDP (17), length 321)
>>      192.168.0.254.67 > 192.168.0.1.68: BOOTP/DHCP, Reply, length 293,
>> xid 0x331c78, Flags [none]
>>        Your-IP 192.168.0.1
>>        Server-IP 192.168.0.254
>>        Client-Ethernet-Address 00:1c:c0:f2:b2:dc
>>        Vendor-rfc1048 Extensions
>>          Magic Cookie 0x63825363
>>          DHCP-Message Option 53, length 1: ACK
>>          Server-ID Option 54, length 4: 192.168.0.254
>>          RN Option 58, length 4: 43200
>>          RB Option 59, length 4: 75600
>>          Lease-Time Option 51, length 4: 86400
>>          Netbios-Node Option 46, length 1: m-node
>>          Subnet-Mask Option 1, length 4: 255.255.255.0
>>          Default-Gateway Option 3, length 4: 192.168.0.254
>>          Domain-Name-Server Option 6, length 8:
>> 192.168.0.100,212.69.36.23
>>
>> Frankly I am not sure what it means. IT seems that dhcp leases are
>> extended by sending a request, and this is a response to that but it
>> doesn't really say where the request originated beyond it being the
>> MAC address of cymbeline.
>>
>>
>> Its late. I will leave the next stage = rebooting cymbeline with
>> tcpdump running on another machine - until tomorrow, if I get a chance.
>>
>> I had hoped that lease renewal would reveal more, but it didnt :-)
>
>
> It would help tracing the cause if you could trace the ARP exchanges
> for .1 and .100 after a cold start. In a switched network, you may
> need to have a managed switch with aq mirror port for the tracing
> host, so you'll not lose directed frmes.
>
my switch like me is rather old and unmanaged

--
Climate Change: Socialism wearing a lab coat.

On 4.6.21 18.11, The Natural Philosopher wrote:
> On 04/06/2021 13:04, Tauno Voipio wrote:
>> On 4.6.21 2.35, The Natural Philosopher wrote:
>>> On 03/06/2021 23:29, Richard Kettlewell wrote:
>>>> The Natural Philosopher <tnp@invalid.invalid> writes:
>>>>> On 03/06/2021 22:27, Richard Kettlewell wrote:
>>>>>> I think the anomalous delay is a big hint. Something quite different
>>>>>> must be happening on the network for .1 and .100.
>>>>>>
>>>>>> Wild guesses:
>>>>>> - some other (slower) endpoint is responding, not cymbeline at all.
>>>>>
>>>>> I think that I have eliminated that by physically unplugging cymbeline
>>>>> from the network. The echoes stop.
>>>>
>>>> Agreed.
>>>>
>>>>>> - something is accepting packets for .1 and forwarding them to
>>>>>>     cymbeline (and presumably forwarding the responses back).
>>>>>
>>>>> Then why does a ping from cymbeline not get a response? But gets a
>>>>> host unreachable?
>>>>>
>>>>> Check my reasoning.
>>>>> 1/. DHCP is registered for 'cymbeline' - that implies that that name
>>>>> has been passed by the dhcp client. That means its coming from the
>>>>> linux subsystem
>>>>> 2/. The mac address registered with DHCP is cymbeline's ethernet MAC
>>>>
>>>> I don’t think any of the tcpdumps I’ve yet seen show ongoing DHCP
>>>> requests mentioning that hostname. The fact that it’s in the DHCP
>>>> server’s table just tells us that there was at least one request some
>>>> time in the past (i.e. perhaps the DHCP server is slow to expire stale
>>>> entries). So I think that #1/#2 are suggestive at best.
>>>>
>>>>> 3/. The interface does not respond when cymbeline is unplugged
>>>>> 4/. The interface does not respond when cymbeline is rebooted, but
>>>>> starts to respond BEFORE its main interface is up. which suggests a
>>>>> redirection is not the way its working
>>>>
>>>> Agreed that #3 and #4 strongly suggest cymbeline is involved
>>>> somehow. That’s pushing me closer to crazy platform feature nonsense
>>>> (SMM etc).
>>>>
>>>>> 5/. the only machine that can't ping that IP address is cymbeline
>>>>> itself. Cymbeline 'knows' something about that interface that no other
>>>>> machine does.
>>>>
>>>> Until we have a better model for why the other endpoints _can_ ping .1,
>>>> I don’t think the fact that cymbeline can’t tells us much.
>>>>
>>> Well I caught a dhcp packet but only on cymbelines interface -
>>> unsurprising since it wasn't a broadcast.
>>> It has reset the timer in the router dhcp table
>>>
>>>
>>> 00:00:06.220639 00:1d:aa:79:78:40 > 00:1c:c0:f2:b2:dc, ethertype IPv4
>>> (0x0800), length 335: (tos 0x0, ttl 255, id 22522, offset 0, flags
>>> [none], proto UDP (17), length 321)
>>>      192.168.0.254.67 > 192.168.0.1.68: BOOTP/DHCP, Reply, length
>>> 293, xid 0x331c78, Flags [none]
>>>        Your-IP 192.168.0.1
>>>        Server-IP 192.168.0.254
>>>        Client-Ethernet-Address 00:1c:c0:f2:b2:dc
>>>        Vendor-rfc1048 Extensions
>>>          Magic Cookie 0x63825363
>>>          DHCP-Message Option 53, length 1: ACK
>>>          Server-ID Option 54, length 4: 192.168.0.254
>>>          RN Option 58, length 4: 43200
>>>          RB Option 59, length 4: 75600
>>>          Lease-Time Option 51, length 4: 86400
>>>          Netbios-Node Option 46, length 1: m-node
>>>          Subnet-Mask Option 1, length 4: 255.255.255.0
>>>          Default-Gateway Option 3, length 4: 192.168.0.254
>>>          Domain-Name-Server Option 6, length 8:
>>> 192.168.0.100,212.69.36.23
>>>
>>> Frankly I am not sure what it means. IT seems that dhcp leases are
>>> extended by sending a request, and this is a response to that but it
>>> doesn't really say where the request originated beyond it being the
>>> MAC address of cymbeline.
>>>
>>>
>>> Its late. I will leave the next stage = rebooting cymbeline with
>>> tcpdump running on another machine - until tomorrow, if I get a chance.
>>>
>>> I had hoped that lease renewal would reveal more, but it didnt :-)
>>
>>
>> It would help tracing the cause if you could trace the ARP exchanges
>> for .1 and .100 after a cold start. In a switched network, you may
>> need to have a managed switch with aq mirror port for the tracing
>> host, so you'll not lose directed frmes.
>>
> my switch like me is rather old and unmanaged

You may still attempt to capture the ARP's on the machine
sending the pings.

A Zyxel GS1200-5 is just above 30 EUR at the local store here.

--

-TV

Richard Kettlewell <invalid@invalid.invalid> wrote:
>"David W. Hodgins" <dwhodgins@nomail.afraid.org> writes:
>> As far as the second ip address for the same mac, I still think it's
>> the intel management engine. In order for the wake on lan feature to
>> work, it probably has to be able to receive a packet, so needs an
>> internet address (I've never used wake on lan, so have no experience
>> with it).
>
>No IP address is required for Wake-on-LAN, just the MAC address. The
>magic packet may be formatted as an IP packet but the firmware that
>recognizes it doesn’t care about that, any appropriately formatted
>ethernet frame will do. It certainly doesn’t bring up a second address
>just for Wake-on-LAN.

I think this is a misunderstanding here. Wake-on-LAN is a function of
the NIC itself. It just does stupid pattern-matching in incoming
frames. Putting the magic Wake-on-LAN bit pattern into a proper IP
packet comes in handy wenn you want to send a WoL packet from another
network segment (only IP packets can be routed).

The Management Engine (whether it be IPMI, Intel, $VENDOR or some kind
of Lights-Out Management) is an entirely different cup of tea.
Especially the ones that share the same physical Ethernet port with
the running OS do really weird things with the network setup to get
access to their traffic.

I have never been particularly fond of those shared-Interface
approaches since they might expose the system to various local and/or
non-local threads and recommend using hardware that has a dedicated
management port, giving additional security and the possibility to
protect the management port from the Internet at the price of more
expensive hardware and one additional switch port. Those Management
Engines are notorious for lighting up like a christmas tree in
security scans and for getting security updates next to never.

Greetings
MArc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

On 05/06/2021 07:13, Marc Haber wrote:
> Richard Kettlewell <invalid@invalid.invalid> wrote:
>> "David W. Hodgins" <dwhodgins@nomail.afraid.org> writes:
>>> As far as the second ip address for the same mac, I still think it's
>>> the intel management engine. In order for the wake on lan feature to
>>> work, it probably has to be able to receive a packet, so needs an
>>> internet address (I've never used wake on lan, so have no experience
>>> with it).
>>
>> No IP address is required for Wake-on-LAN, just the MAC address. The
>> magic packet may be formatted as an IP packet but the firmware that
>> recognizes it doesn’t care about that, any appropriately formatted
>> ethernet frame will do. It certainly doesn’t bring up a second address
>> just for Wake-on-LAN.
>
> I think this is a misunderstanding here. Wake-on-LAN is a function of
> the NIC itself. It just does stupid pattern-matching in incoming
> frames. Putting the magic Wake-on-LAN bit pattern into a proper IP
> packet comes in handy wenn you want to send a WoL packet from another
> network segment (only IP packets can be routed).
>
> The Management Engine (whether it be IPMI, Intel, $VENDOR or some kind
> of Lights-Out Management) is an entirely different cup of tea.
> Especially the ones that share the same physical Ethernet port with
> the running OS do really weird things with the network setup to get
> access to their traffic.
>
> I have never been particularly fond of those shared-Interface
> approaches since they might expose the system to various local and/or
> non-local threads and recommend using hardware that has a dedicated
> management port, giving additional security and the possibility to
> protect the management port from the Internet at the price of more
> expensive hardware and one additional switch port. Those Management
> Engines are notorious for lighting up like a christmas tree in
> security scans and for getting security updates next to never.
>
> Greetings
> MArc
>
Thanks for that information Marc.

I don't think it can be that however as I have used many similar MoBos
with identical Intel ether chipsets, some on fixed IP and they have
never exhibited this behaviour, and it it was common I am sure that it
would be fully documented.

And such a low level access would not know the (linux) machine name..

I am 85% convinced that what happened during installation is that the
default Mint setup is DHCP, and that my clumsy attempts to go
manual/fixed IP resulted in some chain of events that left a base level
DHCP system running somehow, that isn't attached to the standard linux
ethernet device.

I mean to establish that somewhat better by bringing the machine up with
tcpdump monitoring DHCP broadcasts.

(It reminds me of some code I wrote years ago - and was called back 6
months later to 'fix'

"It used to do it a lot, when I was first learning how to use your
system" said the woman in charge of it "but it hasn't happened so much
recently"

That was a clue. And indeed my *error* handling was failing to close
file handles ...after enough errors that DOS machine ran out of
them...but the operator wasn't making so many errors any more...)

I think I have managed to accidentally create something that shouldn't
be there. And probably represents some [sytemd?] bug that has been
there since forever waiting for the right random monkey to enter the
exact magic sequence of keystrokes...And I am that random monkey...

....Anyway, the server runs fine and the ghost interface appears to be
harmless, but it irritates me.

It will take me some time to ensure everything that relies on the server
is in a safe state, and set up the tcpdumps, to watch the reboot
sequence, but that is the logical next phase, given that I don't have a
managed switch.

I've got the router syslogging DHCP allocations, although unfortunately
that is to the server I want to monitor so if rsyslogd ain't up when
that happens...

I would like to thank the people who have offered advice, yes, its
Usenet, and 90% of it is irrelevant, wrong, already been tested for etc.
etc, but the 10% that isn't has been the key in moving the problem from
completely unknown to a much more bounded state.

I hope to get time to reboot the machine later.

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