Arch Linux

irrexp

Member

Registered: 2025-05-22

Posts: 5

[SOLVED] Unidentified traffic on network interface

After having been very loose with the security of my system I started to monitor the traffic with iftop, which I never did before.

I noticed that on my network interface (wired) I constantly have these two addresses sending packets to all-systems.mcast.net:
- 52.132.2.42 (whois says it belongs to Microsoft - a real bummer in itself)
- node-81s.pool-1.1.dynamic.totinternet.net

This happens even when nothing is running but a terminal and after I stop all services I can think of.

Could someone be kind enough to explain me what that is and what actions are required, if any?

Last edited by irrexp (Yesterday 09:11:22)

cryptearth

Member

Registered: 2024-02-03

Posts: 1,432

Re: [SOLVED] Unidentified traffic on network interface

you can use

sudo lsof -i

to get which process opens these connections

// edit

the M$ ip also comes up in combination with Minecraft - so it's likely the authentication uplink when playing Minecraft

the other one seems some issue with 192.168.1.1 been presented backwards as 1.1.168.192 - hints to some network / dns issue

Last edited by cryptearth (2025-05-22 07:31:35)

irrexp

Member

Registered: 2025-05-22

Posts: 5

Re: [SOLVED] Unidentified traffic on network interface

Interesting. I've been triggering lsof -i whenever the two addresses showed up in iftop 

Noticed on the occasion that they appear concomitantly. It seems that mdns is involved as suggested.

systemd-r 3264 systemd-resolve 11u  IPv4  34393      0t0  UDP *:llmnr
systemd-r 3264 systemd-resolve 12u  IPv4  34394      0t0  TCP *:llmnr (LISTEN)
systemd-r 3264 systemd-resolve 13u  IPv6  34401      0t0  UDP *:llmnr
systemd-r 3264 systemd-resolve 14u  IPv6  34402      0t0  TCP *:llmnr (LISTEN)
systemd-r 3264 systemd-resolve 15u  IPv4  34403      0t0  UDP *:mdns
systemd-r 3264 systemd-resolve 16u  IPv6  34404      0t0  UDP *:mdns
systemd-r 3264 systemd-resolve 22u  IPv4  34409      0t0  UDP _localdnsstub:domain
systemd-r 3264 systemd-resolve 23u  IPv4  34410      0t0  TCP _localdnsstub:domain (LISTEN)
systemd-r 3264 systemd-resolve 24u  IPv4  34411      0t0  UDP _localdnsproxy:domain
systemd-r 3264 systemd-resolve 25u  IPv4  34412      0t0  TCP _localdnsproxy:domain (LISTEN)

Now I started running iftop on other machines on my network and I noticed that the same IP also appears but together with a slightly different domain (node-81s.pool-1.1.dynamic.nt-isp.net) on a Debian machine where it is the the avahi-daemon that is involved  (so again mdns).

Does the plot thicken?

I guess my question now becomes: what does an IP address belonging to M$ (or related to Minecraft, which I do not play) have to do with multicast dns on my local network?

Last edited by irrexp (2025-05-22 10:05:23)

teckk

Member

Registered: 2013-02-21

Posts: 529

Re: [SOLVED] Unidentified traffic on network interface

Another tool that I just noticed recently.

lsfd -J | less

cryptearth

Member

Registered: 2024-02-03

Posts: 1,432

Re: [SOLVED] Unidentified traffic on network interface

well - if we apply that somethings being backwards and ignore the spacing we would end up with something 242.x.y.z - but this is in an unusable space even above the multicast range between 224.0.0.0 - 239.255.255.255
so whatever this is it seems likely something mdns related
have you tried to just disable mdns and instead use upstream dns through your router?

Last edited by cryptearth (2025-05-22 21:23:42)

irrexp

Member

Registered: 2025-05-22

Posts: 5

Re: [SOLVED] Unidentified traffic on network interface

Another tool that I just noticed recently.

lsfd -J | less

cool, thx

have you tried to just disable mdns and instead use upstream dns through your router?

I now edited resolved.conf with

MulticastDNS=no
LLMNR=no
DNSStubListener=no

After stop/start systemd-resolved.conf the two initial addresses still appear in iftop although lsof -i only gives

systemd-n 395 systemd-network 34u IPv4   6301    0t0   UDP myhostname:bootpc

-thc

Member

Registered: 2017-03-15

Posts: 886

Re: [SOLVED] Unidentified traffic on network interface

Maybe you're chasing ghosts here.

I noticed that on my network interface (wired) I constantly have these two addresses sending packets to all-systems.mcast.net

I presume you see something like this in iftop:

52.132.2.42                                                                                      => all-systems.mcast.net
node-81s.pool-1.1.dynamic.totinternet.net                                                        => all-systems.mcast.net

This means your system is receiving those packages because your system accepts multicast packets addressed to 224.0.0.1 (all-systems.mcast.net).
The source of those packets is outside of your system.

irrexp

Member

Registered: 2025-05-22

Posts: 5

Re: [SOLVED] Unidentified traffic on network interface

Maybe you're chasing ghosts here.

It certainly looks like it

I presume you see something like this in iftop:

52.132.2.42                                                                                      => all-systems.mcast.net
node-81s.pool-1.1.dynamic.totinternet.net                                                        => all-systems.mcast.net

This means your system is receiving those packages because your system accepts multicast packets addressed to 224.0.0.1 (all-systems.mcast.net).
The source of those packets is outside of your system.

It is exactly what I see and you are totally right. The confusion came from the fact that most of the traffic looks like this:

hostname                              =>  outside IP
                                             <=

which suggests that the left column is for outgoing traffic from hostname while the arrow pointing left rather shows the packets received by the local machine.

But that is not the case and passing the -n argument to iftop allowed me to see more clearly what's going on with the IP addresses, all dns issues aside

While most of the traffic goes back and forth between my local IP and the outside world, the two recurring ones have a one-way discussion with 224.0.0.1 (as you rightfully pointed out).

It is indeed reassuring that nothing is being sent. But while I totally get that my router (spelled backwards as 1.1.168.192) is regularly talking to the entire local network, I still don't fully understand how 52.132.2.42 comes into play.

On a side note, assuming that it also follows the weird backwards-spelling rule, that would be 42.2.132.52 which is related to some ISP in Hong-Kong...

cryptearth

Member

Registered: 2024-02-03

Posts: 1,432

Re: [SOLVED] Unidentified traffic on network interface

well - wild guess in the blue for the sake of just having asked: do you have any "smart" IoT devices connected to your network? like anything: automated switches, fancy light bulbs, thermostats ... it's just a stupid wild guess - but when it's not M$ and this backwards-theory is right then some iot-crap from china is likely to phone home

-thc

Member

Registered: 2017-03-15

Posts: 886

Re: [SOLVED] Unidentified traffic on network interface

The next step would be to take a packet capture of this traffic and analyze the Ethernet frames that transport those packets (Wireshark).

Presuming the source Ethernet address of those multicast packets is your router - the source may be a bad routing decision inside the router.

irrexp

Member

Registered: 2025-05-22

Posts: 5

Re: [SOLVED] Unidentified traffic on network interface

well - wild guess in the blue for the sake of just having asked: do you have any "smart" IoT devices connected to your network? like anything: automated switches, fancy light bulbs, thermostats ... it's just a stupid wild guess - but when it's not M$ and this backwards-theory is right then some iot-crap from china is likely to phone home

Well well, it crossed my mind because I indeed have a wireless repeater that I knew was from China (it came from my ISP btw). The maker is SDMCTech. So I disabled it and monitored the traffic but it changed nothing.

Then I came to realize that I had mentioned the two addresses appearing concomitantly. Assuming that 1.1.168.192 was the router itself, I decided to check the MAC address of the said router. It is indeed Chinese and it is also produced by SDMTech.

The next step would be to take a packet capture of this traffic and analyze the Ethernet frames that transport those packets (Wireshark).

Which I did. Both packets (coming from 1.1.168.192 and 52.132.2.42 are ICMP protocol coming from the router (unambiguously named Shenzen_83) and while the Source address is indeed 52.132.2.42, under "Internet Control Message Protocol" - besides the fact that it is of Type 9 (Mobile IP Advertisement) and of Code 0 (Normal router advertisement) - it says that the router address is (ta-da) 42.2.132.52 (it seems that the backwards spelling is related to the ICMP Protocol somehow).

So all in all:
[x] chasing ghosts
[x] common router activity
[x] some device from China is very likely to phone home one day

As it is a very widely spread router and that I am not too much interested in national security issues, I won't dig deeper hence marking this thread as solved.

Thank you all for the assistance in mission ghostbuster.

cryptearth

Member

Registered: 2024-02-03

Posts: 1,432

Re: [SOLVED] Unidentified traffic on network interface

I'm usually not someone to be found among hermit crab people - but this is some unexpected turn of events
so this is caused by a device from your ISP? and from your way of looking at it I guess you not living around that suspicious area? I would contact your ISP about that and the device in question and either ask for a replacement from a different brand or for the required details to use your own
if it's DSL or fiber you should be able to use any off the shelf from your nearest store - as for cable: usually you have to suplly the modems MAC to be registrered - if your ISP doesn't allow you using your own device look for different one
this is just unacceptable - no matter if the ISP does this on purpose or they just don't now because they don't care but just after the money and chose the cheapest device they could get thier hands on in bulk
no matter what this is - even if it's "just" "telemetry" of some chinese device "phoning home" or there's something more to hit (insert your favorite conspirarcy here) - it's something a consumer-grade device just should not do (well, I guess unless you live in china anyway - but that's a different world)