1

I am working on a packet sniffer app and have it setup so that there is one capture thread per interface (as opposed to one thread capturing on 'all'). It works fine but the code needs to listen to changes to the list of interfaces so that it can manage the capture threads.

I wrote a small function that does what I want using the netlink api using RTMGRP_LINK in the nl_groups field and specifically acting upon RTM_DELLINK and RTM_NEWLINK message types. It works as expected but I don't really understand the logic when a docker container starts in terms of the messages that are being received from the kernel.

For example, running docker run -it centos:7 /bin/bash creates the following flow of messages:

RTM_NEWLINK NAME: vethaec0b80 MAC: a2:a1:2c:48:72:f4
RTM_NEWLINK NAME: vethb4ca0db MAC: fe:e8:79:7a:ce:d9
RTM_NEWLINK NAME: vethb4ca0db MAC: fe:e8:79:7a:ce:d9
RTM_NEWLINK NAME: vethb4ca0db MAC: fe:e8:79:7a:ce:d9
RTM_NEWLINK NAME: docker0 MAC: 02:42:0d:8f:a2:f9
RTM_NEWLINK NAME: vethb4ca0db MAC: fe:e8:79:7a:ce:d9
RTM_NEWLINK NAME: vethb4ca0db MAC: fe:e8:79:7a:ce:d9
RTM_NEWLINK NAME: vethb4ca0db MAC: fe:e8:79:7a:ce:d9
RTM_NEWLINK NAME: vethb4ca0db MAC: fe:e8:79:7a:ce:d9
RTM_NEWLINK NAME: vethb4ca0db MAC: fe:e8:79:7a:ce:d9
RTM_NEWLINK NAME: vethb4ca0db MAC: fe:e8:79:7a:ce:d9
RTM_NEWLINK NAME: vethb4ca0db MAC: fe:e8:79:7a:ce:d9
RTM_NEWLINK NAME: vethb4ca0db MAC: fe:e8:79:7a:ce:d9
RTM_NEWLINK NAME: docker0 MAC: 02:42:0d:8f:a2:f9
RTM_DELLINK NAME: vethaec0b80 MAC: a2:a1:2c:48:72:f4
RTM_NEWLINK NAME: vethb4ca0db MAC: fe:e8:79:7a:ce:d9
RTM_NEWLINK NAME: vethb4ca0db MAC: fe:e8:79:7a:ce:d9
RTM_NEWLINK NAME: vethb4ca0db MAC: fe:e8:79:7a:ce:d9
RTM_NEWLINK NAME: vethb4ca0db MAC: fe:e8:79:7a:ce:d9
RTM_NEWLINK NAME: docker0 MAC: 02:42:0d:8f:a2:f9

and exiting the container generates:

RTM_NEWLINK NAME: vethaec0b80 MAC: 02:42:ac:11:00:02
RTM_NEWLINK NAME: vethb4ca0db MAC: fe:e8:79:7a:ce:d9
RTM_NEWLINK NAME: vethb4ca0db MAC: fe:e8:79:7a:ce:d9
RTM_NEWLINK NAME: vethb4ca0db MAC: fe:e8:79:7a:ce:d9
RTM_NEWLINK NAME: vethb4ca0db MAC: fe:e8:79:7a:ce:d9
RTM_NEWLINK NAME: vethb4ca0db MAC: fe:e8:79:7a:ce:d9
RTM_NEWLINK NAME: vethb4ca0db MAC: fe:e8:79:7a:ce:d9
RTM_DELLINK NAME: vethaec0b80 MAC: 02:42:ac:11:00:02
RTM_NEWLINK NAME: vethb4ca0db MAC: fe:e8:79:7a:ce:d9
RTM_DELLINK NAME: vethb4ca0db MAC: fe:e8:79:7a:ce:d9
RTM_NEWLINK NAME: docker0 MAC: 02:42:0d:8f:a2:f9
RTM_DELLINK NAME: vethb4ca0db MAC: fe:e8:79:7a:ce:d9
RTM_NEWLINK NAME: docker0 MAC: 02:42:0d:8f:a2:f9

As you can see from starting the container, a RTM_NEWLINK message is received for 2 virtual interfaces (one of which is destroyed) and the docker bridge which was already up and running. Terminating the container has a similar situation; 2 virtual interfaces created (both destroyed after RTM_NEWLINK called on them again).

Questions

1) Why are 2 virtual interfaces created and only one kept when starting the container?

2) Why is the RTM_NEWLINK messages sent so many times?

3) On terminating the container, why does it send so many RTM_NEWLINK messages before sending the RTM_DELLINK message?

incubus
  • 681
  • 1
  • 5
  • 21

1 Answers1

1

1) Why are 2 virtual interfaces created and only one kept when starting the container?

A guess: Docker creates a pair of connected interfaces, then it moves one inside the container, which is a separate network namespace. Since you are looking in the default namespace, you see it disappear. If you were in the container's namespace, you would see it appear.

2) Why is the RTM_NEWLINK messages sent so many times?

3) On terminating the container, why does it send so many RTM_NEWLINK messages before sending the RTM_DELLINK message?

RTM_NEWLINK is not only sent when an interface is created. It is also sent when an interface is modified.

user253751
  • 57,427
  • 7
  • 48
  • 90
  • Re: 1) The extra link gets deleted and the mac address doesn't match that of the one in the container. 2) What sort of things that can change? There are specific messages for modifying route and altering ip addresses. The rest of the fields in the ifinfo struct and rtattr didn't change on each of the RTM_NEWLINK messages. – incubus Mar 16 '20 at 21:10