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

Forum Forums Official Releases antiX-19 “Marielle Franco, Hannie Schaft, Manolis Glezos” incessant (er, periodic, rhythmic, neverending) network activity

  • This topic has 40 replies, 9 voices, and was last updated Apr 3-4:16 pm by rokytnji.
Viewing 15 posts - 1 through 15 (of 41 total)
  • Author
  • #47632

    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:


    • This topic was modified 4 months, 3 weeks ago by skidoo.
    Forum Admin

    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.


    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
     [ ? ]
     [ + ]  irqbalance
     [ ? ]  kmod
     [ ? ]  loadcpufreq
     [ ? ]  networking
     [ ? ]  pppd-dns
     [ + ]  resolvconf
     [ + ]  slim
     [ + ]  udev
     [ ? ]
    $ sudo pstree -aT
      |   \-dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3
      |-at-spi2-registr --use-gnome-session
      |   \-avahi-daemon
      |-connman-vpnd -n
      |-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
      |-devmon /usr/bin/devmon --exec-on-drive desktop-defaults-run -fm "%d" --exec-on-disc desktop-defaults-run -fm "%d"
      |   \-udevil --monitor
      |-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
      \-wpa_supplicant -u -s -O /run/wpa_supplicant
    Forum Admin

    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.

    You can use wireshark to verify this.

    • This reply was modified 4 months, 3 weeks ago by Dave.

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


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


    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 🙂

    Forum Admin

    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


    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 4 months, 2 weeks ago by Robin.
    • This reply was modified 4 months, 2 weeks ago by Robin. Reason: word order corrected

    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”.
    sudo ps -aux | grep -e avahi grep -e connman
    via “strace -p <high-numbered pid connman process>”, we can note this is the culprit process.

    its content (as shipped) is entirely outcommented

    is (as shipped?) a broken symlink
    pointing to
    (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.


    On my box connman is showing router adress 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

    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


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


    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
    Probably that is set as a backup adress in code.


    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 :

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

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

    ModdIt is right on the money. Switching to ceni stops the incessant pings, so this problem is related to connman.

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


    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:


    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?

Viewing 15 posts - 1 through 15 (of 41 total)
  • You must be logged in to reply to this topic.