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.
December 17, 2020 at 10:23 pm #47632Memberskidoo
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:
December 17, 2020 at 10:37 pm #47636Forum Adminanticapitalista
- This topic was modified 4 months, 3 weeks ago by skidoo.
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.December 18, 2020 at 12:03 am #47640Memberskidoo
sudo watch -n 1 netstat -aenp
no traffic attributable to processes other than connmand and avahi-daemon.
OOTB as-shipped network settings.
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_supplicantDecember 18, 2020 at 2:53 am #47650Forum AdminDave
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 UnknownDecember 18, 2020 at 9:48 am #47672ModeratorModdIt
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..December 18, 2020 at 1:07 pm #47674Memberpepitofer
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:December 18, 2020 at 6:14 pm #47686Forum AdminDave
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 UnknownDecember 20, 2020 at 7:15 pm #47843MemberRobin
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.
December 20, 2020 at 8:28 pm #47857Memberskidoo
- 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
(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.December 20, 2020 at 9:55 pm #47868ModeratorModdIt
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.December 20, 2020 at 10:34 pm #47870Forum AdminDave
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 UnknownDecember 21, 2020 at 1:38 am #47876Memberskidoo
> 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.December 21, 2020 at 8:55 am #47885ModeratorModdIt
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.December 21, 2020 at 9:19 am #47886ModeratorModdIt
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.
December 26, 2020 at 10:27 am #48098MemberXecure
- 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:
[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:
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?
- You must be logged in to reply to this topic.