Incoming and outgoing traffic when NOTHING is running

Question

In a system with nothing running (at least nothing I know of). Listening of incoming and outgoing traffic prints this output:

192.168.1.1              => all-systems.mcast.net             0b     26b     19b
                         <=                                   0b      0b      0b
192.168.1.2              => 224.0.0.251                     128b     26b     19b
                         <=                                   0b      0b      0b

(sometimes it doesn't show just 26b or 128b, but instead jumps to big numbers like there's actual information being sent)

What is the meaning of this?

192.168.1.1 is the gateway, my router

192.168.1.2 is me, my machine

But who is all-systems.mcast.net?? Also who is 224.0.0.251?? And more importantly, why there are packets being sent?

Found this: https://davidsimpson.me/2015/11/16/why-is-my-machine-contacting-all-systems-mcast-net/ But I'm running no DLNA server. So who am I broadcasting to?

One last (and also important question) is: I can understand 192.168.1.2 contacting with something, and I can understand 192.168.1.1 contacting with me, but I can't understand why I am seeing 192.168.1.1 in contact with all-systems.mcast.net, so how is it possible that monitoring my machine shows traffic from my router that is not being sent to me? I shouldn't be able to see that, right?

The utility I am using is:

   iftop - display bandwidth usage on an interface by host

Utilities tcptrack and netstat show nothing at all. Therefore the only plausible explanation is that this utility is the one responsible of that traffic??

---

Question UPDATE

So there's this multicast stuff apparently integrated in the kernel of my system and also in my router with a very rudimentary system of question&answer, a timer, once every 60 seconds. I don't quite understand why, and after some good people has tried to explain it to me, I don't think I ever will. So I would like to turn it off. Is it possible?

Answer 1

Those packets you are seeing are regular multicast services (and while the process is similar to broadcast packets, they are not broadcasts per se); their output traffic in the network is also (usually) negligible.

Actually not only you see traffic generated by yourself, you also see traffic for those addresses generated by other machines on your network.

• 224.0.0.1 is all-systems.mcast.net

By default, all (Linux) servers announce themselves in the network multicasting to 224.0.0.1 regularly, for reporting to nearby routers they are able to talk multicast. These packets should be the Linux kernel sending them.

• 224.0.0.251 is mDNS

As for 224.0.0.251, it is used by Avahi/zeroconf for service announcement and discovery.

Avahi is a free zero-configuration networking (zeroconf) implementation, including a system for multicast DNS/DNS-SD service discovery.

see Cisco - Introduction to multicast

see also TLDP - Multicast over TCP/IP HOWTO

Class D Address - Multicast address / 224.0.0.0 - 239.255.255.255

o 224.0.0.1 is the all-hosts group. If you ping that group, all multicast capable hosts on the network should answer, as every multicast capable host must join that group at start-up on all it's multicast capable interfaces.

As for seeing packets that are not for you, you are supposed to listen to broadcasts and multicast packets/announcements as they are (normally) sent to all stations. There are nuances, which I will not delve here. See the introductions I am linking.

Lastly, while iftop sees the traffic, it is not the responsible for generating it.

You can also see the multicast groups the server belongs to with:

netstat -g

Lastly, not having regular users/your user running programs does not mean the system is doing nothing. Linux is a multi-user/multi-tasking system, and there is a lot of housekeeping functions happening on the background.

Answer 2

Multicast IP traffic has different rules from the ordinary unicast or broadcast traffic. A multicast IP address is never used as a source address: it is always a destination address only. A system that is sending multicasts will use its regular IP address as the source address. Each multicast IP address will designate a multicast group: anything sent to that multicast address will be received by all hosts belonging to that group. (Or that's the theory. In practice, unless you've made specific arrangements to route multicasts beyond your subnet or organization, multicast traffic tends to stop at those limits by default.)

When some software in a host wants to receive multicast traffic, it will tell the host's kernel "I wish to receive multicasts addressed to this multicast IP address." The kernel will then add that multicast IP address to the list of multicast addresses it will listen for, and send out an IGMP report message: "I wish to receive multicast traffic addressed to these multicast IPs: ". This IGMP report is itself a multicast IP message. In Linux, IGMP is handled at the kernel level: this is why you see no processes responsible for it.

Multicast-capable routers will also periodically (typically every 60 seconds) send IGMP query messages, essentially: "To all systems on this segment: report now if you're still interested in any multicast traffic." This is also a multicast IP message, sent to 224.0.0.1 = all-systems.mcast.net. This is probably what your router is sending. As the DNS name given to that address implies, all multicast-capable hosts must always listen for multicast traffic addressed to 224.0.0.1.

A multicast-capable host is supposed to send an IGMP report in two situations:

• when it wants to start or stop listening for traffic addressed to a particular multicast IP, or
• when it receives an IGMP query message.

Typically the host's kernel will handle this automatically. In Linux, you can use cat /proc/net/igmp to see which multicast IPs your system is currently listening for on each network interface. Unfortunately the multicast IPs are reported in hexadecimal, and the byte order is reversed from the usual IP address format: for example, 224.0.0.1 is presented as "010000E0"; 224.0.0.251 is "FB0000E0".

A multicast-capable router will send IGMP queries to each network segment it's part of and keeps track of the IGMP reports it gets as a response. This is how it knows whether or not multicast traffic to some multicast IP address needs to be routed from one network segment to another.

Exception: if there is already another source if IGMP queries in a segment and it has a lower source IP address than this router, then this router will not send queries and instead will just listen. It may attempt to communicate with the other IGMP query source using some multicast routing protocol in order to coordinate multicast traffic between routers, though.

If a multicast-capable host does not answer to three consecutive IGMP queries (i.e. 180 seconds), the router assumes the host is no longer interested in any multicast traffic. This cleans up any unnecessary multicast streams if a host reboots, loses power or loses network connectivity.

In a simple home Wi-Fi network, multicasting is of limited utility: any group of hosts in a Wi-Fi network will still consume the shared radio bandwidth for everyone, whether they use multicasting or simply broadcast. But in a wired network, or in a mesh Wi-Fi network, multicasting allows switches and/or APs to monitor the IGMP messages and thus know whether a particular multicast packet needs to be sent to a particular switch port or Wi-Fi cell or not. This saves bandwidth for those that are not interested in a particular multicast, at the expense of more work for switches/APs. This feature is known as "IGMP snooping".