2

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?

  • Could you show the results of ps aux? My guess is that you are running avahi-daemon or some mDNS client, but it could be another service. – ErikF Feb 22 '18 at 0:05
  • @ErikF yes I'm running avahi-daemon. I've been reading about what Avahi does but it didn't clarify anything for me. I still don't understand a thing. Could you give me a few more hints on how a mDNS daemon relates to my questions? – bunden Feb 22 '18 at 1:40
  • mDNS uses multicast addresses to implement "zero configuration" which allows you to locate resources on your network: multicast addresses are like broadcast addresses but are opt-in for interested hosts. Check the linked articles for more information, as they're out of scope to the original question. – ErikF Feb 22 '18 at 1:54
5

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.

  • Good answer. I killed avahi and got rid of the second line in iftop. Still one line to get rid of :D. Could you give me a simple explanation about the relationship between 192.168.1.1 (router) and all-systems.mcast.net? Could it be wifi related? I am not very smart and these "introductions" you've linked are more like books written in chinese for me. – bunden Feb 22 '18 at 2:24
  • @bunden not wifi related. I wrote "By default, all (Linux) servers announce themselves in the network multicasting to 224.0.0.1 regularly, also for reporting to nearby routers they are able to talk multicast." and that is the kernel doing that. You can try to disable multicast in your interfaces, sudo ifconfig eth0 -multicast but while that machine will stop sending all-systems.mcast.net, you will still see it from other machines in the network. – Rui F Ribeiro Feb 22 '18 at 8:09
  • Corrected the wording about all-systems.mcast.net – Rui F Ribeiro Feb 22 '18 at 8:12
  • Tried sudo ifconfig eth0 -multicast but it didn't work. Avahi removal didn't actually work either. I still see the two packets from the original post plus a new one from google dns servers :/ – bunden Feb 23 '18 at 2:41
  • @bunden as I implied before, multicast is sent to all meighbours, and whilst you stop sending, you keep seeing the other machines unless your filter for the source of your IP address – Rui F Ribeiro Feb 23 '18 at 3:13
0

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

  • So somehow -not sure HOW- I'm listening to all-systems.mcast.net, which is kind of a subnetwork inside my router, right? and that's why I see traffic from 192.168.1.1 to all-systems.mcast.net, because I AM all-systems.mcast.net or at least I'm "connected" to it or inside its "group". 192.168.1.1 is asking 224.0.0.1: is anyone there? and I am replying to another address (224.0.0.251), not sure why. Shouldn't I reply to 224.0.0.1? I don't think I am interested in multicast traffic, I don't even know what multicast is, so can't I just turn it off? Let's get rid of this thing I can't comprehend. – bunden Feb 23 '18 at 3:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.