Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

ghost interfaces in the sky

227 views
Skip to first unread message

The Natural Philosopher

unread,
Jun 1, 2021, 2:48:03 PM6/1/21
to
I have a server
Its name is cymbeline

Its been rebuilt several times. currently its a fairly vanilla linux
mint MATE 20.1

When it was installed, it came up on DHCP. 192.168.0.1

I used the network manager widget to create its correct static address
192.169.0.100

I made this default.

I rebooted it.

It still came up on 192.168.0.1

I deleted the DHCP entry in the network manager and rebooted it

It now responds on 192.168.0.100
ifconfig says that's what is attached to its Ethernet card

$ ifconfig -a
enp0s25: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.100 netmask 255.255.255.0 broadcast 192.168.0.255
inet6 fe80::7621:60d3:4849:77b prefixlen 64 scopeid 0x20<link>
ether 00:1c:c0:f2:b2:dc txqueuelen 1000 (Ethernet)
RX packets 40833491 bytes 22268734758 (22.2 GB)
RX errors 0 dropped 272 overruns 0 frame 0
TX packets 59333532 bytes 72323226135 (72.3 GB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 20 memory 0xd3400000-d3420000

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 1934977 bytes 34420707697 (34.4 GB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1934977 bytes 34420707697 (34.4 GB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

But in my router is the following DHCP record:

--------------------------------------------------------------------------------
Index IP Address MAC Address Leased Time HOST ID
--------------------------------------------------------------------------------
LAN1
1 192.168.0.1 00-1C-C0-F2-B2-DC 13:14:34 cymbeline


That is of course the correct MAC address for it.

If I ping that from another machine I get

shylock$ 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.801 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=255 time=0.737 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=255 time=0.791 ms
64 bytes from 192.168.0.1: icmp_seq=4 ttl=255 time=0.728 ms
64 bytes from 192.168.0.1: icmp_seq=5 ttl=255 time=0.727 ms
64 bytes from 192.168.0.1: icmp_seq=6 ttl=255 time=0.734 ms
64 bytes from 192.168.0.1: icmp_seq=7 ttl=255 time=0.738 ms
64 bytes from 192.168.0.1: icmp_seq=8 ttl=255 time=0.740 ms

which is a bit long....but something is responding

on its correct ip address it responds differently :
shylock$ 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.231 ms
64 bytes from 192.168.0.100: icmp_seq=2 ttl=64 time=0.232 ms
64 bytes from 192.168.0.100: icmp_seq=3 ttl=64 time=0.263 ms
64 bytes from 192.168.0.100: icmp_seq=4 ttl=64 time=0.368 ms
64 bytes from 192.168.0.100: icmp_seq=5 ttl=64 time=0.348 ms
64 bytes from 192.168.0.100: icmp_seq=6 ttl=64 time=0.293 ms
64 bytes from 192.168.0.100: icmp_seq=7 ttl=64 time=0.414 ms
^C

but it doesn't respond when pinged from the server itself

cymbeline:~$ 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
From 192.168.0.100 icmp_seq=3 Destination Host Unreachable
^C

cymbeline:~$ uptime
19:32:56 up 11 days, 57 min, 3 users, load average: 0.82, 0.61, 0.64


shylock$ arp -a
mipifi (192.168.0.200) at b8:27:eb:a6:48:7b [ether] on eth0
? (192.168.0.3) at 90:48:9a:e1:be:65 [ether] on eth0
? (192.168.0.248) at <incomplete> on eth0
? (192.168.0.1) at 00:1c:c0:f2:b2:dc [ether] on eth0
? (192.168.0.254) at 00:1d:aa:79:78:40 [ether] on eth0
? (192.168.0.102) at 3c:a8:2a:f6:3a:c8 [ether] on eth0
cymbeline (192.168.0.100) at 00:1c:c0:f2:b2:dc [ether] on eth0
shaman (192.168.0.105) at <incomplete> on eth0
? (192.168.0.2) at 1c:5a:3e:7e:37:1f [ether] on eth0

If I delete the arp entry for 192.168.0.1 it still reappears when I ping
that IP address

But the server arp cache is littered with machines on addresses that
have never been issued...

cymbeline:~$ arp -a
? (192.168.0.11) at <incomplete> on enp0s25
? (192.168.0.39) at <incomplete> on enp0s25
? (192.168.0.17) at <incomplete> on enp0s25
? (192.168.0.77) at <incomplete> on enp0s25
? (192.168.0.52) at <incomplete> on enp0s25
? (192.168.0.3) at 90:48:9a:e1:be:65 [ether] on enp0s25
? (192.168.0.200) at b8:27:eb:a6:48:7b [ether] on enp0s25
? (192.168.0.2) at 1c:5a:3e:7e:37:1f [ether] on enp0s25
? (192.168.0.93) at <incomplete> on enp0s25
? (192.168.0.19) at <incomplete> on enp0s25
? (192.168.0.195) at <incomplete> on enp0s25
? (192.168.0.18) at <incomplete> on enp0s25
? (192.168.0.5) at 08:62:66:4a:85:d8 [ether] on enp0s25
? (192.168.0.175) at <incomplete> on enp0s25
? (192.168.0.12) at <incomplete> on enp0s25
? (192.168.0.35) at <incomplete> on enp0s25
_gateway (192.168.0.254) at 00:1d:aa:79:78:40 [ether] on enp0s25
? (192.168.0.15) at <incomplete> on enp0s25
? (192.168.0.21) at <incomplete> on enp0s25
? (192.168.0.28) at <incomplete> on enp0s25
? (192.168.0.14) at <incomplete> on enp0s25
? (192.168.0.111) at <incomplete> on enp0s25
? (192.168.0.155) at <incomplete> on enp0s25
? (192.168.0.45) at <incomplete> on enp0s25
? (192.168.0.6) at 5c:51:81:bb:c2:85 [ether] on enp0s25
? (192.168.0.103) at <incomplete> on enp0s25
? (192.168.0.30) at <incomplete> on enp0s25
? (192.168.0.1) at <incomplete> on enp0s25
? (192.168.0.74) at <incomplete> on enp0s25
? (192.168.0.8) at 00:09:df:b7:8e:b9 [ether] on enp0s25
? (192.168.0.119) at <incomplete> on enp0s25

None of the <incomplete> entries here are valid, or should ever have
been used by anything.

What is on the network is as follows:

Shylock desktop DHCP 192.168.0.5 08-62-66-4A-85-D8
Titania wifi connected laptop DHCP 192.168.0.3 90-48-9A-E1-BE-65
Malvolio Android phone via wifi 192.168.0.6 5C-51-81-BB-C2-85
Probably Samsung TV 192.168.0.2 1C-5A-3E-7E-37-1F
Panasonic TV 192.168.0.8 00-09-DF-B7-8E-B9
Raspberry Pi Zero W 192.168.0.200 b8:27:eb:a6:48:7b
Main broadband router/DHCP server 192.168.0.254 00:1d:aa:79:78:40
Netgear POS used as wifi bridge 192.168.0.253 30:46:9a:a2:89:f6
Another wifi access point on 192.168.0.252 74:4d:28:4a:21:82
HP printer on 192.168.0.102 3c:a8:2a:f6:3a:c8

What is happening?

The router is set to clear disused DHCP allocations periodically,
although it seems to take a long old time

In short I seem to be able to ping this IP address from every machine on
the network EXCEPT the server that carries its mac address!


--
How fortunate for governments that the people they administer don't think.

Adolf Hitler

Anssi Saari

unread,
Jun 2, 2021, 2:29:53 AM6/2/21
to
The Natural Philosopher <t...@invalid.invalid> writes:

> $ ifconfig -a
> enp0s25: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
> inet 192.168.0.100 netmask 255.255.255.0 broadcast 192.168.0.255
> inet6 fe80::7621:60d3:4849:77b prefixlen 64 scopeid 0x20<link>
> ether 00:1c:c0:f2:b2:dc txqueuelen 1000 (Ethernet)
> RX packets 40833491 bytes 22268734758 (22.2 GB)
> RX errors 0 dropped 272 overruns 0 frame 0
> TX packets 59333532 bytes 72323226135 (72.3 GB)
> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
> device interrupt 20 memory 0xd3400000-d3420000

Is it possible this interface has two IP addresses? ifconfig can't show
that but ip addr would.

Nomen Nescio

unread,
Jun 2, 2021, 4:07:37 AM6/2/21
to
TNP> When it was installed, it came up on DHCP. 192.168.0.1
TNP>
TNP> I used the network manager widget to create its correct static
TNP> address 192.169.0.100

Is a DHCP client still running on the machine?

Have you disabled services like NetworkManager?


Can you monitor the ethernet traffic entering the router and
intercept the DHCP requests?

The Natural Philosopher

unread,
Jun 2, 2021, 4:27:53 AM6/2/21
to
Actually I think ifconfig would but no, ip address just shows the one



$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel
state UP group default qlen 1000
link/ether 00:1c:c0:f2:b2:dc brd ff:ff:ff:ff:ff:ff
inet 192.168.0.100/24 brd 192.168.0.255 scope global noprefixroute
enp0s25
valid_lft forever preferred_lft forever
inet6 fe80::7621:60d3:4849:77b/64 scope link noprefixroute
valid_lft forever preferred_lft forever

--
"What do you think about Gay Marriage?"
"I don't."
"Don't what?"
"Think about Gay Marriage."

Pascal Hambourg

unread,
Jun 2, 2021, 7:27:49 AM6/2/21
to
Le 01/06/2021 à 20:47, The Natural Philosopher a écrit :
> I have a server
> Its name is cymbeline

Physical or virtual machine ?

> If I ping that from another machine I get
>
> shylock$ 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.801 ms
> 64 bytes from 192.168.0.1: icmp_seq=2 ttl=255 time=0.737 ms
(...)
> which is a bit long....but something is responding
>
> on its correct ip address it responds differently :
> shylock$ 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.231 ms
> 64 bytes from 192.168.0.100: icmp_seq=2 ttl=64 time=0.232 ms

The different times suggest different hosts, maybe different link types
(ethernet vs wireless).

Did you try to unplug the server and see if something still responds at
192.168.0.1 ?

The Natural Philosopher

unread,
Jun 2, 2021, 8:36:01 AM6/2/21
to
On 02/06/2021 12:27, Pascal Hambourg wrote:
> Le 01/06/2021 à 20:47, The Natural Philosopher a écrit :
>> I have a server
>> Its name is cymbeline
>
> Physical or virtual machine ?

Oh. Physical, Pascal

>
>> If I ping that from another machine I get
>>
>> shylock$ 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.801 ms
>> 64 bytes from 192.168.0.1: icmp_seq=2 ttl=255 time=0.737 ms
> (...)
>> which is a bit long....but something is responding
>>
>> on its correct ip address it responds differently :
>> shylock$ 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.231 ms
>> 64 bytes from 192.168.0.100: icmp_seq=2 ttl=64 time=0.232 ms
>
> The different times suggest different hosts, maybe different link types
> (ethernet vs wireless).
>
> Did you try to unplug the server and see if something still responds at
> 192.168.0.1 ?

Ah. The only simple thing I didn't try. The ethernet MAC address however
matches that server
...

64 bytes from 192.168.0.1: icmp_seq=73 ttl=255 time=0.735 ms
64 bytes from 192.168.0.1: icmp_seq=74 ttl=255 time=0.729 ms
64 bytes from 192.168.0.1: icmp_seq=75 ttl=255 time=0.725 ms
64 bytes from 192.168.0.1: icmp_seq=76 ttl=255 time=0.775 ms

unplug...
replug...

64 bytes from 192.168.0.1: icmp_seq=121 ttl=255 time=3.00 ms
64 bytes from 192.168.0.1: icmp_seq=122 ttl=255 time=0.765 ms
64 bytes from 192.168.0.1: icmp_seq=123 ttl=255 time=0.789 ms

Nope something on that server underneath the hood is responding to pings
on an IP address it doesn't recognise itself...

neither does netstat show any services attached to that ip address

All it appears to do is to respond to pings from other machines and
exist in the router DHCP and other machines arp tables

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

- George Orwell

Robert Heller

unread,
Jun 2, 2021, 9:18:41 AM6/2/21
to
At Wed, 2 Jun 2021 13:35:56 +0100 The Natural Philosopher <t...@invalid.invalid> wrote:

>
> On 02/06/2021 12:27, Pascal Hambourg wrote:
> > Le 01/06/2021 à 20:47, The Natural Philosopher a écrit :
Restart the router.

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

The Natural Philosopher

unread,
Jun 2, 2021, 9:44:41 AM6/2/21
to
On 02/06/2021 14:18, Robert Heller wrote:
> At Wed, 2 Jun 2021 13:35:56 +0100 The Natural Philosopher <t...@invalid.invalid> wrote:
>
>>
>> On 02/06/2021 12:27, Pascal Hambourg wrote:
>>> Le 01/06/2021 à 20:47, The Natural Philosopher a écrit :
....
...
cleared the dhcp table but server still responds to pings on ghost
interface....



--
A lie can travel halfway around the world while the truth is putting on
its shoes.

Robert Heller

unread,
Jun 2, 2021, 11:43:20 AM6/2/21
to
At Wed, 2 Jun 2021 14:44:26 +0100 The Natural Philosopher <t...@invalid.invalid> wrote:

>
> On 02/06/2021 14:18, Robert Heller wrote:
> > At Wed, 2 Jun 2021 13:35:56 +0100 The Natural Philosopher <t...@invalid.invalid> wrote:
> >
> >>
> >> On 02/06/2021 12:27, Pascal Hambourg wrote:
> >>> Le 01/06/2021 à 20:47, The Natural Philosopher a écrit :
Can you ssh into the ghost interface? Does that identify what machine it is?

Pascal Hambourg

unread,
Jun 2, 2021, 1:46:35 PM6/2/21
to
Le 02/06/2021 à 14:35, The Natural Philosopher a écrit :
> On 02/06/2021 12:27, Pascal Hambourg wrote:
>>
>> Did you try to unplug the server and see if something still responds
>> at 192.168.0.1 ?
>
> Ah. The only simple thing I didn't try. The ethernet MAC address however
> matches that server
> ...
>
> 64 bytes from 192.168.0.1: icmp_seq=73 ttl=255 time=0.735 ms
> 64 bytes from 192.168.0.1: icmp_seq=74 ttl=255 time=0.729 ms
> 64 bytes from 192.168.0.1: icmp_seq=75 ttl=255 time=0.725 ms
> 64 bytes from 192.168.0.1: icmp_seq=76 ttl=255 time=0.775 ms
>
> unplug...
> replug...
>
> 64 bytes from 192.168.0.1: icmp_seq=121 ttl=255 time=3.00 ms
> 64 bytes from 192.168.0.1: icmp_seq=122 ttl=255 time=0.765 ms
> 64 bytes from 192.168.0.1: icmp_seq=123 ttl=255 time=0.789 ms

So it is probably in the server.
Causes I can think of :
- iptables DNAT , but that would not explain the ARP
- an entry in the local routing table (ip route ls table local), but
ping from the server would work
- Management Engine, Active Management Technology or the like
- some kind of virtual machine
- some kind of rootkit

Tests I can think of :
Run a packet capture on the ethernet interface and see if this traffic
is visible.
Bring the ethernet interface down and see if it still responds.
Stop the operating system without power off (or reboot and stop in the
boot loader) and see if it still responds.

The Natural Philosopher

unread,
Jun 3, 2021, 12:40:00 AM6/3/21
to
On 02/06/2021 16:43, Robert Heller wrote:
> At Wed, 2 Jun 2021 14:44:26 +0100 The Natural Philosopher <t...@invalid.invalid> wrote:
>
>>
>> On 02/06/2021 14:18, Robert Heller wrote:
>>> At Wed, 2 Jun 2021 13:35:56 +0100 The Natural Philosopher <t...@invalid.invalid> wrote:
>>>
>>>>
>>>> On 02/06/2021 12:27, Pascal Hambourg wrote:
>>>>> Le 01/06/2021 à 20:47, The Natural Philosopher a écrit :
nope.
no services seem to run on it.
It responds to ICMP echoes originating from *other machines*, but not
itself.
It appears in arp tables on other machines
it appears in the router DHCP table. - it has in fact reappeared since
yesterdays router reboot.
Its MAC address in those tables is the same Mac address as the server.

But that is it

Probably all about systemd :-)

>>
>>
>>
>


--
Climate Change: Socialism wearing a lab coat.

The Natural Philosopher

unread,
Jun 3, 2021, 1:06:09 AM6/3/21
to
On 02/06/2021 18:46, Pascal Hambourg wrote:
> Le 02/06/2021 à 14:35, The Natural Philosopher a écrit :
>> On 02/06/2021 12:27, Pascal Hambourg wrote:
>>>
>>> Did you try to unplug the server and see if something still responds
>>> at 192.168.0.1 ?
>>
>> Ah. The only simple thing I didn't try. The ethernet MAC address
>> however matches that server
>> ...
>>
>> 64 bytes from 192.168.0.1: icmp_seq=73 ttl=255 time=0.735 ms
>> 64 bytes from 192.168.0.1: icmp_seq=74 ttl=255 time=0.729 ms
>> 64 bytes from 192.168.0.1: icmp_seq=75 ttl=255 time=0.725 ms
>> 64 bytes from 192.168.0.1: icmp_seq=76 ttl=255 time=0.775 ms
>>
>> unplug...
>> replug...
>>
>> 64 bytes from 192.168.0.1: icmp_seq=121 ttl=255 time=3.00 ms
>> 64 bytes from 192.168.0.1: icmp_seq=122 ttl=255 time=0.765 ms
>> 64 bytes from 192.168.0.1: icmp_seq=123 ttl=255 time=0.789 ms
>
> So it is probably in the server.
I think so

> Causes I can think of :
> - iptables DNAT , but that would not explain the ARP
iptables not configutred - This is a fairly new installation - weeks
only as the upgrade failed. ISTR this issue existed before the upgraded,
and in fact has existed for years. Filred under 'weird. but works so...'
> - an entry in the local routing table (ip route ls table local), but
> ping from the server would work
$ ip route
default via 192.168.0.254 dev enp0s25 proto static metric 100
169.254.0.0/16 dev enp0s25 scope link metric 1000
192.168.0.0/24 dev enp0s25 proto kernel scope link src 192.168.0.100
metric 100


> - Management Engine, Active Management Technology or the like

no ideas what those are....

> - some kind of virtual machine

certainly I haven't installed such.
Only custom 'server' code is tvheadend and minidlna...its a media server
as well....

> - some kind of rootkit

That is faintly possible, but it's fairly well protected. there is a
public https exposed to the internet. Of course its running the most
nasty rootkit of them all - systemd...:-)

>
> Tests I can think of :
> Run a packet capture on the ethernet interface and see if this traffic
> is visible.

what's the command for that? That was my next thought too but its so
longs since I have done that i have actually forgotten.


> Bring the ethernet interface down and see if it still responds.

likewise cant remember

> Stop the operating system without power off (or reboot and stop in the
> boot loader) and see if it still responds.

that's a bit too brutal - don't like rebooting that - it requires a lot
of other kit to be taken down for safety's sake

No. I think that there is something else going on like a bug in the dhcp
client or possibly systemd that half brings up the interface, on boot,
but doesn't complete the job.


I didn't show the contents of the nm config files but this is the one...

more /etc/NetworkManager/system-connections/Wired connection 1.nmconnection

[connection]
id=Fixed IP
uuid=e7219850-4e33-370e-8fdb-cff8f65326e1
type=ethernet
autoconnect-priority=-999
interface-name=enp0s25
permissions=
timestamp=1619516963

[ethernet]
mac-address-blacklist=

[ipv4]
address1=192.168.0.100/24,192.168.0.254
dns=127.0.0.1;212.69.36.23;
dns-search=
may-fail=false
method=manual

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
ip6-privacy=0
method=auto

[proxy]

--
“But what a weak barrier is truth when it stands in the way of an
hypothesis!”

Mary Wollstonecraft

Pascal Hambourg

unread,
Jun 3, 2021, 3:15:53 AM6/3/21
to
Le 03/06/2021 à 07:06, The Natural Philosopher a écrit :
> On 02/06/2021 18:46, Pascal Hambourg wrote:
>> - an entry in the local routing table (ip route ls table local), but
>> ping from the server would work
> $ ip route

"ip route" alone only shows the main routing table, which contains only
remote destinations. Use the command I provided to show the local
routing table.

>> - Management Engine, Active Management Technology or the like
>
> no ideas what those are....

A management system embedded in the hardware. Wikpedia is your friend.

I also thought about network namespaces (which I know very little about)
but it seems that a network interface cannot be shared between namespaces.

>> Tests I can think of :
>> Run a packet capture on the ethernet interface and see if this traffic
>> is visible.
>
> what's the command for that? That was my next thought too but its so
> longs since I have done that i have actually forgotten.


For example with tcpdump :
# tcpdump -nei enp0s25 arp or ip and host 192.168.0.1

>> Bring the ethernet interface down and see if it still responds.
>
> likewise cant remember

# ip link set enp0s25 down

Not sure how NetworkManager will react though. Maybe it is better to
stop the interface with nmcli or the GUI but I don't know how to do this.

The Natural Philosopher

unread,
Jun 3, 2021, 4:12:07 AM6/3/21
to
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
06:49:31.029909 IP (tos 0x0, ttl 64, id 63048, offset 0, flags [DF],
proto ICMP (1), length 84)
192.168.0.5 > 192.168.0.1: ICMP echo request, id 14398, seq 2,
length 64
06:49:32.029955 IP (tos 0x0, ttl 64, id 63197, offset 0, flags [DF],
proto ICMP (1), length 84)
192.168.0.5 > 192.168.0.1: ICMP echo request, id 14398, seq 3,
length 64
06:49:33.030085 IP (tos 0x0, ttl 64, id 63361, offset 0, flags [DF],
proto ICMP (1), length 84)
192.168.0.5 > 192.168.0.1: ICMP echo request, id 14398, seq 4,
length 64
06:49:51.088078 IP (tos 0x0, ttl 64, id 14931, offset 0, flags [DF],
proto ICMP (1), length 84)


then (correct address)

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)
192.168.0.5 > cymbeline: ICMP echo request, id 14399, seq 2, length 64
06:49:52.087304 IP (tos 0x0, ttl 64, id 22535, offset 0, flags [none],
proto ICMP (1), length 84)
cymbeline > 192.168.0.5: ICMP echo reply, id 14399, seq 2, length 64
06:49:53.086128 IP (tos 0x0, ttl 64, id 15069, offset 0, flags [DF],
proto ICMP (1), length 84)
192.168.0.5 > cymbeline: ICMP echo request, id 14399, seq 3, length 64
06:49:53.086171 IP (tos 0x0, ttl 64, id 22598, offset 0, flags [none],
proto ICMP (1), length 84)
cymbeline > 192.168.0.5: ICMP echo reply, id 14399, seq 3, length 64

And yet something is responding...

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'

only the router and the printer normally set 255 ttls - everything else
seems to be 64..

network is 100MBps switched by and large plus wifi on laptop, Pi zero W
and android phone.

later:

I had to reboot the server after a kernel upgrade.

During the reboot 192.168.0.1 *was still responding*. even when the
'correct' interface was not. I wasn't quick enough to catch it pre boot
sequence starting tho


The only way to stop it is to physically unplug the server Ethernet.


Weirder still the server has come up OK on the right address except it
says that 'network manager is disabled'

So to summarise.

1/. It seems the ghost interface is tightly linked to the servers
ethernet. Has the same MAC address. disappears if ethernet to that
machine is unplugged
2/. However it responds to pings with a different TTL than the normal
interface.
3/. It periodically seems to request DHCP updates.
4/. Apart from responding to arp and ICMP requests and DHCP responses it
seems to have no services attached at all.
5/. It seems to exist before the main interface (enp0s25) is up
6/. It seems to want DHCP quite often. After I rebooted the server I
switched the router off, then on. It is now the only thing IN the DHCP
table.
7/. nmap reveals no open tcp or udp ports (below 1000)
8/. I am beginning to see the idiot Poettering grinning at me. The only
daemon running, now network manager is not, is
/usr/bin/python3 /usr/bin/networkd-dispatcher --run-startup-triggers

From what I can glean files in there still want to use DHCP, But its an
almost undocumented configuration mess worthy of a bureaucrat.
I am thinking that systemd is creating this interface before whatever it
is that DOES create the correct one, creates THAT

anyone know their way round systemd conf files for networking?

--
“Puritanism: The haunting fear that someone, somewhere, may be happy.”

H.L. Mencken, A Mencken Chrestomathy

The Natural Philosopher

unread,
Jun 3, 2021, 4:18:29 AM6/3/21
to
On 03/06/2021 08:15, Pascal Hambourg wrote:
> Le 03/06/2021 à 07:06, The Natural Philosopher a écrit :
>> On 02/06/2021 18:46, Pascal Hambourg wrote:
>>> - an entry in the local routing table (ip route ls table local), but
>>> ping from the server would work
>> $ ip route
>
> "ip route" alone only shows the main routing table, which contains only
> remote destinations. Use the command I provided to show the local
> routing table.
>
I don't recall you actually provioding such?

>>> - Management Engine, Active Management Technology or the like
>>
>> no ideas what those are....
>
> A management system embedded in the hardware. Wikpedia is your friend.

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
>
> I also thought about network namespaces (which I know very little about)
> but it seems that a network interface cannot be shared between namespaces.
>
>>> Tests I can think of :
>>> Run a packet capture on the ethernet interface and see if this
>>> traffic is visible.
>>
>> what's the command for that? That was my next thought too but its so
>> longs since I have done that i have actually forgotten.
>
>
> For example with tcpdump :
> # tcpdump -nei enp0s25 arp or ip and host 192.168.0.1
>
>>> Bring the ethernet interface down and see if it still responds.
>>
>> likewise cant remember
>
> # ip link set enp0s25 down
>
> Not sure how NetworkManager will react though. Maybe it is better to
> stop the interface with nmcli or the GUI but I don't know how to do this.

Things have moved on a bit - see later post
tcpdump patently doesn't find the interface that is responding. So I
doubt that downing the correct ethernet interface would affect it


--
“The fundamental cause of the trouble in the modern world today is that
the stupid are cocksure while the intelligent are full of doubt."

- Bertrand Russell

Pascal Hambourg

unread,
Jun 3, 2021, 4:46:20 AM6/3/21
to
Le 03/06/2021 à 10:18, The Natural Philosopher a écrit :
> On 03/06/2021 08:15, Pascal Hambourg wrote:
>> Le 03/06/2021 à 07:06, The Natural Philosopher a écrit :
>>> On 02/06/2021 18:46, Pascal Hambourg wrote:
>>>> - an entry in the local routing table (ip route ls table local), but
here ^^^^^^^^^^^^^^^^^^^^^^^

>>>> ping from the server would work
>>> $ ip route
>>
>> "ip route" alone only shows the main routing table, which contains
>> only remote destinations. Use the command I provided to show the local
>> routing table.
>>
> I don't recall you actually provioding such?

See above.

>>>> - Management Engine, Active Management Technology or the like
>>>
>>> no ideas what those are....
>>
>> A management system embedded in the hardware. Wikpedia is your friend.
>
> Mmm. Something at board BIOS level perhaps?

Even lower level. Seems to be embedded in the chipset or CPU. May be
disabled by BIOS settings.

> tcpdump patently doesn't find the interface that is responding. So I
> doubt that downing the correct ethernet interface would affect it

I expect not, but either result will provide information.

The Natural Philosopher

unread,
Jun 3, 2021, 6:38:22 AM6/3/21
to
On 03/06/2021 09:46, Pascal Hambourg wrote:
> ip route ls table local

ip route ls table local
broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1
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
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
broadcast 192.168.0.0 dev enp0s25 proto kernel scope link src 192.168.0.100
local 192.168.0.100 dev enp0s25 proto kernel scope host src 192.168.0.100
broadcast 192.168.0.255 dev enp0s25 proto kernel scope link src
192.168.0.100


--
“People believe certain stories because everyone important tells them,
and people tell those stories because everyone important believes them.
Indeed, when a conventional wisdom is at its fullest strength, one’s
agreement with that conventional wisdom becomes almost a litmus test of
one’s suitability to be taken seriously.”

Paul Krugman

Pascal Hambourg

unread,
Jun 3, 2021, 6:57:40 AM6/3/21
to
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.

The Natural Philosopher

unread,
Jun 3, 2021, 7:05:45 AM6/3/21
to
On 03/06/2021 09:46, Pascal Hambourg wrote:
>
>>>>> - Management Engine, Active Management Technology or the like
>>>>
>>>> no ideas what those are....
>>>
>>> A management system embedded in the hardware. Wikpedia is your friend.
>>
>> Mmm. Something at board BIOS level perhaps?
>
> Even lower level. Seems to be embedded in the chipset or CPU. May be
> disabled by BIOS settings.
>
surely if it existed dozens of people would have seen this issue? It
would be well known and well documented.


>> tcpdump patently doesn't find the interface that is responding. So I
>> doubt that downing the correct ethernet interface would affect it
>
> I expect not, but either result will provide information.
Ok

Well that was a bit of a bombshell. 'ifconfig enps025 down' shut it
down, *but not the ghost interface*.

Unfortunately 'ifconfig enps025 up' didn't seem to fully restore it
So rebooted.

THIS time network manager is 'up and running'

As is the ghost interface :-)




--
“I know that most men, including those at ease with problems of the
greatest complexity, can seldom accept even the simplest and most
obvious truth if it be such as would oblige them to admit the falsity of
conclusions which they have delighted in explaining to colleagues, which
they have proudly taught to others, and which they have woven, thread by
thread, into the fabric of their lives.”

― Leo Tolstoy

Pascal Hambourg

unread,
Jun 3, 2021, 7:41:14 AM6/3/21
to
Le 03/06/2021 à 13:05, The Natural Philosopher a écrit :
> On 03/06/2021 09:46, Pascal Hambourg wrote:
>>
>>>>>> - Management Engine, Active Management Technology or the like
>>>>>
>>>>> no ideas what those are....
>>>>
>>>> A management system embedded in the hardware. Wikpedia is your friend.
>>>
>>> Mmm. Something at board BIOS level perhaps?
>>
>> Even lower level. Seems to be embedded in the chipset or CPU. May be
>> disabled by BIOS settings.
>>
> surely if it existed dozens of people would have seen this issue? It
> would be well known and well documented.
>
> Well that was a bit of a bombshell. 'ifconfig enps025  down' shut it
> down, *but not the ghost interface*.

As I expected. So it is either buried deep in the kernel, or in the
hardware, or in some kind of hypervisor loaded before the kernel (like
Xen), but not in any userland process (including systemd). To check
whether it is in the hardware, boot without loading the OS (press <esc>
at the GRUB menu for instance).

> Unfortunately 'ifconfig enps025  up' didn't seem to fully restore it
> So rebooted.

You could have just restarted NetworkManager.

The Natural Philosopher

unread,
Jun 3, 2021, 8:00:33 AM6/3/21
to
Yes. it behaves as a little empire all on its own snuggled inside the
linux machine as a whole.

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*.

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

I am letting tcpdump on two machines try and trap the DHCP requests


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

- Stephen Vizinczey

The Natural Philosopher

unread,
Jun 3, 2021, 8:29:34 AM6/3/21
to
Well network manager said it was there but 'disabled'.

Well the interface said it was up, and it could ping itself, but *this*
machine was locked up because NFS wasn't working, so I rebooted the
(nfs) server machine , made a cup of coffee and when I got back this
machine had unlocked itself.

As I say elsewhere, beginning to zero in on where this is happening.
largely due to your helpful suggestions - So thanks for that.

tcpdump is now recording DHCP broadcast traffic and is working as its
picked up a couple of transactions already

--
There is nothing a fleet of dispatchable nuclear power plants cannot do
that cannot be done worse and more expensively and with higher carbon
emissions and more adverse environmental impact by adding intermittent
renewable energy.

Robert Heller

unread,
Jun 3, 2021, 9:15:17 AM6/3/21
to
At Thu, 3 Jun 2021 13:00:28 +0100 The Natural Philosopher <t...@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.

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


>
> I am letting tcpdump on two machines try and trap the DHCP requests
>
>

--

Robert Heller

unread,
Jun 3, 2021, 9:19:38 AM6/3/21
to
At Thu, 3 Jun 2021 13:29:29 +0100 The Natural Philosopher <t...@invalid.invalid> wrote:

>
> On 03/06/2021 12:41, Pascal Hambourg wrote:
> > Le 03/06/2021 à 13:05, The Natural Philosopher a écrit :
> >> On 03/06/2021 09:46, Pascal Hambourg wrote:
> >>>
> >>>>>>> - Management Engine, Active Management Technology or the like
> >>>>>>
> >>>>>> no ideas what those are....
> >>>>>
> >>>>> A management system embedded in the hardware. Wikpedia is your friend.
> >>>>
> >>>> Mmm. Something at board BIOS level perhaps?
> >>>
> >>> Even lower level. Seems to be embedded in the chipset or CPU. May be
> >>> disabled by BIOS settings.
> >>>
> >> surely if it existed dozens of people would have seen this issue? It
> >> would be well known and well documented.
> >>
> >> Well that was a bit of a bombshell. 'ifconfig enps025  down' shut it
> >> down, *but not the ghost interface*.
> >
> > As I expected. So it is either buried deep in the kernel, or in the
> > hardware, or in some kind of hypervisor loaded before the kernel (like
> > Xen), but not in any userland process (including systemd). To check
> > whether it is in the hardware, boot without loading the OS (press <esc>
> > at the GRUB menu for instance).
> >
> >> Unfortunately 'ifconfig enps025  up' didn't seem to fully restore it
> >> So rebooted.
> >
> > You could have just restarted NetworkManager.
>
> 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).

>
> Well the interface said it was up, and it could ping itself, but *this*
> machine was locked up because NFS wasn't working, so I rebooted the
> (nfs) server machine , made a cup of coffee and when I got back this
> machine had unlocked itself.
>
> As I say elsewhere, beginning to zero in on where this is happening.
> largely due to your helpful suggestions - So thanks for that.
>
> tcpdump is now recording DHCP broadcast traffic and is working as its
> picked up a couple of transactions already
>

--

Joe Beanfish

unread,
Jun 3, 2021, 10:10:01 AM6/3/21
to
+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.

Pascal Hambourg

unread,
Jun 3, 2021, 12:32:40 PM6/3/21
to
Le 03/06/2021 à 15:19, Robert Heller a écrit :
> At Thu, 3 Jun 2021 13:29:29 +0100 The Natural Philosopher <t...@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.

David W. Hodgins

unread,
Jun 3, 2021, 12:41:50 PM6/3/21
to
On Thu, 03 Jun 2021 04:18:24 -0400, The Natural Philosopher <t...@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 dwho...@nomail.afraid.org to davidw...@teksavvy.com for
email replies.

The Natural Philosopher

unread,
Jun 3, 2021, 3:04:31 PM6/3/21
to
On 03/06/2021 14:15, Robert Heller wrote:
> At Thu, 3 Jun 2021 13:00:28 +0100 The Natural Philosopher <t...@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

The Natural Philosopher

unread,
Jun 3, 2021, 3:07:12 PM6/3/21
to
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


The Natural Philosopher

unread,
Jun 3, 2021, 3:11:12 PM6/3/21
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.

The Natural Philosopher

unread,
Jun 3, 2021, 3:14:14 PM6/3/21
to
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

David W. Hodgins

unread,
Jun 3, 2021, 3:59:29 PM6/3/21
to
On Thu, 03 Jun 2021 15:14:10 -0400, The Natural Philosopher <t...@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.

The Natural Philosopher

unread,
Jun 3, 2021, 4:17:51 PM6/3/21
to
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.

Anssi Saari

unread,
Jun 3, 2021, 4:37:34 PM6/3/21
to
The Natural Philosopher <t...@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.

The Natural Philosopher

unread,
Jun 3, 2021, 5:19:47 PM6/3/21
to
On 03/06/2021 21:37, Anssi Saari wrote:
> The Natural Philosopher <t...@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

Richard Kettlewell

unread,
Jun 3, 2021, 5:27:43 PM6/3/21
to
The Natural Philosopher <t...@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/

The Natural Philosopher

unread,
Jun 3, 2021, 6:04:19 PM6/3/21
to
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

David W. Hodgins

unread,
Jun 3, 2021, 6:24:27 PM6/3/21
to
On Thu, 03 Jun 2021 17:19:42 -0400, The Natural Philosopher <t...@invalid.invalid> wrote:

> On 03/06/2021 21:37, Anssi Saari wrote:
>> The Natural Philosopher <t...@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"?

Richard Kettlewell

unread,
Jun 3, 2021, 6:29:37 PM6/3/21
to
The Natural Philosopher <t...@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/

The Natural Philosopher

unread,
Jun 3, 2021, 6:37:18 PM6/3/21
to
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

unread,
Jun 3, 2021, 6:39:19 PM6/3/21
to
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/

The Natural Philosopher

unread,
Jun 3, 2021, 6:42:59 PM6/3/21
to
On 03/06/2021 23:29, Richard Kettlewell wrote:
> The Natural Philosopher <t...@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.

The Natural Philosopher

unread,
Jun 3, 2021, 7:07:43 PM6/3/21
to
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

The Natural Philosopher

unread,
Jun 3, 2021, 7:35:12 PM6/3/21
to
On 03/06/2021 23:29, Richard Kettlewell wrote:
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

David W. Hodgins

unread,
Jun 3, 2021, 7:45:34 PM6/3/21
to
On Thu, 03 Jun 2021 19:07:38 -0400, The Natural Philosopher <t...@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.

Richard Kettlewell

unread,
Jun 4, 2021, 4:32:47 AM6/4/21
to
"David W. Hodgins" <dwho...@nomail.afraid.org> writes:
> The Natural Philosopher <t...@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/

Tauno Voipio

unread,
Jun 4, 2021, 8:04:51 AM6/4/21
to
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


The Natural Philosopher

unread,
Jun 4, 2021, 11:11:49 AM6/4/21
to
my switch like me is rather old and unmanaged


--
Climate Change: Socialism wearing a lab coat.

Tauno Voipio

unread,
Jun 4, 2021, 12:50:31 PM6/4/21
to
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

Marc Haber

unread,
Jun 5, 2021, 2:13:52 AM6/5/21
to
Richard Kettlewell <inv...@invalid.invalid> wrote:
>"David W. Hodgins" <dwho...@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

The Natural Philosopher

unread,
Jun 5, 2021, 4:54:58 AM6/5/21
to
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
0 new messages