We are working on integrating mender connect into our product. Our product has both WiFi and cellular connectivity. In order to not use too much data we want to limit mender connect to just use the WiFi unless the user explicitly enables it over cell for diagnostics.
When mender-connect does not have any active connections to it, what sort of behavior is it using to wait for connections to come in?
Are there ways to limit mender-connect to only use particular network interfaces so that we can keep it off of the cell network other than just disabling the service when the cell network connection is active?
How much network data does mender connect typically use when it is just waiting for a session?
With mender itself we use state scripts to control what networks are used but there does not seem to be a similar mechanism for mender-connect.
If mender doesn’t support this directly then you should be able to achieve the desired behaviour by dynamically adding and removing routing tables entries with iptables I would of thought.
Do you have an example of how to do this? From the research I have done it looks like blocking a specific program or PID in iptables is not straightforward. Blocking a user or group is straightforward but that would require more setup than I want to do at this point to move the user that mender-connect runs as.
mender-connect opens a websocket connection to the Mender backend and basically waits for incoming messages (for example GUI opening a Terminal session). I don’t have figures on how much data uses this “idle mode” and as per today we don’t have a way to limit it.
Maybe @merlin can fill up the holes and give a proper technical explanation
and thank you for trying Mender.
mender-connect, as @lluiscampos pointed out, maintains a permanent websocket connection. It means, that there is a standard websocket ping/pong keep alive exchange, every minute or so. Other than and if there are no open Remote Terminal sessions mender-connect does not send any data. If you are interested I can try to capture some traffic from a live system, to give you exact numbers.
Please note that if the backend cannot be reached, mender-connect by default tries to reconnect indefinitely (unless configured otherwise), that will mean that some packets are going to go out.
as a follow up here is the summary of an hour of traffic from an accepted device running mender-connect without any live Remote Terminal session:
# capinfos tcpdump.out
File name: tcpdump.out
File type: Wireshark/tcpdump/... - pcap
File encapsulation: Ethernet
File timestamp precision: microseconds (6)
Packet size limit: file hdr: 262144 bytes
Number of packets: 710
File size: 72 kB
Data size: 60 kB
Capture duration: 3598.092098 seconds
First packet time: 2021-05-31 12:18:58.761608
Last packet time: 2021-05-31 13:18:56.853706
Data byte rate: 16 bytes/s
Data bit rate: 135 bits/s
Average packet size: 85.90 bytes
Average packet rate: 0 packets/s
SHA256: xx
RIPEMD160: xx
SHA1: xx
Strict time order: True
Number of interfaces in file: 1
Interface #0 info:
Encapsulation = Ethernet (1 - ether)
Capture length = 262144
Time precision = microseconds (6)
Time ticks per second = 1000000
Number of stat entries = 0
Number of packets = 710
The tcpdump.out file is the product of the following command:
tcpdump -X -s0 -eni $if -w tcpdump.out '( src $menderserverip or dst $menderserver ) and port 443'
Please note that the above does not include any mender-client generated traffic which periodically checks for updates or sends inventory, and which depends on the configuration of poll intervals.
