incessant (er, periodic, rhythmic, neverending) network activity

[Anonymous]

distrowatch.com/images/ktyxqzobhgijab/antix.png

Noticed a detail today in this screenshot embedded in antiX page at distrowatch.
This, exactly this, is what I had observed and reported during antiX19 betatesting ~~ a symptom which other testers were reputedly unable to reproduce.

At the dw page, if you click to view the fullsize image you can note that no appwindow buttons are visible in the icewm toolbar and conky mem usage looks baseline/normal for start of session (IOW,no torrent client or other net UP -service to explain/blame/justify the network activity)

In my use, this “symptom” has been predictably repeatable.
Screencap from today, an instance running in virtualbox:

[Forum Admin anticapitalista]

Helpful

Up

0

::

Does iftop show anything suspicious?

Philosophers have interpreted the world in many ways; the point is to change it.

antiX with runit - leaner and meaner.

[Anonymous]

Helpful

Up

0

::

sudo watch -n 1 netstat -aenp

no traffic attributable to processes other than connmand and avahi-daemon.

OOTB as-shipped network settings.
virtualbox, eth0
all non-essential “services” configured to not autostart.

$ sudo service --status-all | grep '+'
 [ ? ]  alsa-utils
 [ + ]  avahi-daemon
 [ ? ]  bootchart-done
 [ + ]  connman
 [ ? ]  cpufrequtils
 [ ? ]  cryptdisks
 [ ? ]  cryptdisks-early
 [ + ]  dbus
 [ + ]  elogind
 [ + ]  gpm
 [ ? ]  hwclock.sh
 [ + ]  irqbalance
 [ ? ]  kmod
 [ ? ]  loadcpufreq
 [ ? ]  networking
 [ ? ]  pppd-dns
 [ + ]  resolvconf
 [ + ]  slim
 [ + ]  udev
 [ ? ]  umountnfs-alternative.sh

$ sudo pstree -aT
init
  |-VBoxService
  |-at-spi-bus-laun
  |   \-dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3
  |-at-spi2-registr --use-gnome-session
  |-avahi-daemon
  |   \-avahi-daemon
  |-conky
  |-connman-vpnd -n
  |-connmand
  |-dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7 --session
  |-dbus-daemon --system
  |-dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7 --session
  |-dbus-launch --autolaunch 168f0f357b9b9cc02b97832e5fd7fbbf --binary-syntax --close-stderr
  |-dbus-launch --autolaunch 168f0f357b9b9cc02b97832e5fd7fbbf --binary-syntax --close-stderr
  |-dconf-service
  |-devmon /usr/bin/devmon --exec-on-drive desktop-defaults-run -fm "%d" --exec-on-disc desktop-defaults-run -fm "%d"
  |   \-udevil --monitor
  |-elogind-daemon
  |-gconfd-2
  |-gconfd-2
  |-getty --noclear 38400 tty1
  |-getty 38400 tty2
  |-getty 38400 tty3
  |-getty 38400 tty4
  |-getty 38400 tty5
  |-getty 38400 tty6
  |-gksu -u demo roxterm
  |   \-roxterm
  |       \-bash
  |           \-pstree -asT
  |-gpm -m /dev/input/mice -t exps2
  |-slim -d
  |   |-Xorg -nolisten tcp -background none -auth /var/run/slim.auth vt07
  |   \-desktop-session /usr/local/bin/desktop-session
  |       \-fluxbox
  |-udevd
  |-volumeicon
  \-wpa_supplicant -u -s -O /run/wpa_supplicant

[Forum Admin Dave]

Helpful

Up

0

::

Chances are that some component on the network is spamming the broadcast address.

Numerous times I have seen it from a “smart” (stupid?) led light bulb or power controller/plug to work with alexa / google devices.
I feel they should be installed on their own separated network if used.

Edit:
You can use wireshark to verify this.

• This reply was modified 2 years, 4 months ago by Dave.

Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown

[Member ModdIt]

Helpful

Up

0

::

My box shows same sort of behaviour on a wired connection, I have always thought it is constant router pinging of some kind,
signal about every three seconds. If I disconnect from the network applications take a very long time to start.
Might be somehow connected. i use default Connman..

[Member pepitofer]

Helpful

Up

0

::

I have noticed the same “idle” traffic.
I checked with Wireshark and there are many NTP packets, more than 50% of the total. Also there usually are some multicast by other network devices and in my case ICMP from the router, I have that last one restricted.

So it seems that the clock synchronization is the cause of this permanent network traffic, at least in may case.

Nothing really suspicious 🙂

Attachments:

1. 

   traffic.png
   

[Forum Admin Dave]

Helpful

Up

0

::

Hmm yes.
I think the default polling is set to every 2 seconds to see if the ntp server is reachable than 64 seconds to sync the clock?
It could probably be made longer, though IIUC this happens automatically the longer the machine stays running. Of course a reboot (service restart) would reset this making it poll very frequently again. I am not entirely clear on ntp setup though.

Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown

[Member Robin]

Helpful

Up

0

::

Hello all,
I can confirm this behaviour, I have observed these continuous regular spikes also for a long period of time, but not in the 19.x version which I don’t have installed due to hardware driver issues, but in 17.4.1. (having installed all upgrades from apt near-term always).

Whether this is true already in a fresh (persistent )install I can’t tell at the moment, but it has happened in a varying intensity. I thought of the connection to the samba file server being the cause, and also suspected NTP of this, since when I remember things correctly it attracted my attention for the first time after I activated one of these. But also it may have started for the first time after installing virtualbox potentially.

Since there seem to be transmitted very small amounts of data on every spike only, they are hidden by normal traffic usually and will not show up before several minutes of idle state of network connection, giving the conky display a chance to zoom up scale of network activity monitor.

I will report here when I observe this behaviour again, right at the moment I can’t see the spikes at all, though just having restarted NTP. Strange thing this.

• This reply was modified 2 years, 4 months ago by Robin.
• This reply was modified 2 years, 4 months ago by Robin. Reason: word order corrected

Windows is like a submarine. Open a window and serious problems will start.

[Anonymous]

Helpful

Up

0

::

Confirmed via wireshark, it is indeed NTP related.
Something is, stupidly, asking ~~ every 2 seconds ~~ to re-verify the DNS address of an NTP server.

Considered (by me) to be a non-essential service, ntp was not running when I tested, screencapped, and opened this topic.

Further testing, following “sudo apt purge ntp”… the 2sec loopy behavior persists.
minpoll is apparently governed by some implicit default; “grep -ir ‘minpoll’ /etc” finds nothing

Further testing, discovered and purged package “ntpdate”. The 2sec loopy behavior persists.

In the wireshark output, the only active entities are “avahi-daemon” and “connmand”.
^–v
sudo ps -aux | grep -e avahi grep -e connman
^–v
via “strace -p <high-numbered pid connman process>”, we can note this is the culprit process.

/etc/connmand/main.conf
its content (as shipped) is entirely outcommented

/etc/connmand/resolv.conf
is (as shipped?) a broken symlink
pointing to
“../run/connman/resolv.conf”
(not pointing to the existing file present in the “/run/…” tree)
I don’t know whether the broken symlink is the cause, or is an unrelated detail.

[Member ModdIt]

Helpful

Up

0

::

On my box connman is showing router adress 192.168.0.1 as NTP Server.

Tomorrow will see what happens when I add Custom Timeserver adresses, ie direct access
to internet NTP servers. I read the connect interval should get longer when the time
data stabilises.

[Forum Admin Dave]

Helpful

Up

0

::

I may be incorrect but IIRC ntpdate is the client for configuring and manually running ntp.
The package / service that actually runs the ntp update is the ntpd service provided by the package ntp if I understand correctly.

So perhaps purging the ntp package (as well as ntpdate) will stop the “ping” every 2 seconds.

Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown

[Anonymous]

Helpful

Up

0

::

> perhaps purging the ntp package (as well as ntpdate) will stop the “ping” every 2 seconds.

Tested. Following purging those 2 and rebooting the behavior is unchanged.

[Member ModdIt]

Helpful

Up

0

::

Setting a list of timeservers in the connmann setup interface has changed the rythm. Now have longer periods with 0bytes
increasing time between blips. Disk write after data received.

Guess connman was constantly retrying to set NTP time but failing due constantly calling my router setup interface 192.168.0.1
Probably that is set as a backup adress in code.

[Member ModdIt]

Helpful

Up

0

::

To fix the problem in the distribution a List of Fallback timeservers separated by “,”.
added to etc/connmann main config looks like it might be best solution.

We will always still have NTP query blips in conky, but as the data stabilises the time between querys will increase,
If my memory is correct maximum time between querys can be somewhere near 20 Minutes.

Edit: excellent manpage : https://www.mankier.com/1/connmanctl

Settings made from within the gui are stored in var/lib/connman (in my case) ethernet settings.

• This reply was modified 2 years, 4 months ago by ModdIt.
• This reply was modified 2 years, 4 months ago by ModdIt.

[Member Xecure]

Helpful

Up

0

::

ModdIt is right on the money. Switching to ceni stops the incessant pings, so this problem is related to connman.
See: https://www.toradex.com/community/questions/926/disable-automatic-manipulation-of-clock-linux-coli.html

The solution is to add the lines to disable automatic time check to the global configuration in /var/lib/connman/settings, as ModdIt suggested:

[global]
OfflineMode=false
TimeUpdates=manual
TimezoneUpdates=auto

This will disable automatic Time updates.

Now, restart the connman service.
sudo service connman restart

Thanks for finding the reason for this, ModdIt.

I will try it latter, but if we add the lines:

[WiFi]
Enable=true

to this file and have it as a configuration file for Build-iso, would this solve the problem with connman disabling wifi on first boot from live ISO?

antiX Live system enthusiast.
General Live Boot Parameters for antiX.

[Author]

Posts