On occasion, no internet at startup

[Moderator Brian Masinick]

Helpful

Up

0

::

@xunzi_23
I’ve been having intermittent issues with Connman since our current release 23 which I think started having issues following a connman package update.

In antiX 22 I had no issues with Connman so I think the network manager introduced defects during one of it’s package updates some time between the end of Spring and sometime relatively early in the Summer.I wonder if reinstalling a previous release of Connman would solve the problem?

Also since you have the message displayed is it possible to identify the exact steps to reproduce the issue and write a defect report against Connman? I’ve not been able to consistently reproduce the defect nor have I caught a log error in time to report anything.

It’s working but stability is shaky.

--
Brian Masinick

[Member abc-nix]

Helpful

Up

0

::

Thanks, calciumsodium and Brian. Great feedback. Good to know that the proposed fix helps. We can point to it in the future for users with wifi and connection problems. As reported by calciumsodium, it does increase the boot time, even if less than 1 second, so I am still reluctant to set it as default for slimski,

Related to pipewire.

PPC wrote:

I reported that antiX 23.1, version 2 Live, requires me to toggle pipewire off and back on to have sound, but only on my more powerful desktop

To me, this sounds like the desktop starts so fast that something that should be running before pipewire starts isn’t, so the initial start fails. If possible, when you have time (in the main 23.1 testing thread), you could check what wire programs started on your desktop when pipewire fails (pgrep -l wire) and see the timings (start-t pipewire, start-t dbus), and share it in a post there. If wireplumber isn’t on, and/or if pipewire shows a timing smaller than dbus, then we can explore this issue further, either with sleeps before pipewire starting, or with dbus started before slimski.

calciumsodium wrote:

A question, can one start pipewire in slimski similar to starting connman in your modification? If so, would this solve the wireplumber starting issue that was so troubling to many users, prior to your recent modifications of pipewire startup? Just a thought.

Pipewire needs to be started by the user. The reason that there is no runit service for pipewire and we need to use a startup script is because of this (runit services are started and managed by root/the system). On systemd, some services can be started as user-services (managed by the user account), which start with the user session (enabled by logingd). On sysvinit, I think this is impossible. On runit, there is a way, but it isn’t as automatic. I set this up initially (and it worked), but after some updates, because it wasn’t as reliable, I opted for using a startup script, and we eventually found a fix for the pipewire.conf system/user file. So adding this to slimski will not work, but maybe starting dbus before slimski does. We can explore this in a different thread.

Back with the ethernet.issue.

Xunzi_23 wrote:

I use conmann, and on the troublesome system only ethernet.

This is an important issue, and it would be best to try to solve this before the 23.1 release. If possible, Xunzi_23, do 2 things:

1. Disable the line in .desktop-session/startup for network-check-antix (comment it out). We don’t want another program to interfere with connman and pollute the logs.

2. Enable logging for connman. Follow the steps as I explained further up the thread (the last paragraph on this reply). Next time you experience the ethernet issue, please go to /var/log/runit/connman/current and copy the logs from the current session (if possible, starting from the boot time, and nothing from previous days or hours). Save the logs in a file on your home folder, and note down the time.
You can then try to restart connman and see if ethernet reconnects
sudo service connman restart
If it doesn’t, restart the computer and continue with your day. Ỳou can then disable logging so that there is no disk writes). When you have time, you can share the log here. We may be able to study it and figure out what problems connman with the ethernet or with other devices. No obligations here, only if time permits.

• This reply was modified 1 week, 4 days ago by abc-nix.

[Member PPC]

Helpful

Up

0

::

abc-nix wrote:

you could check what wire programs started on your desktop when pipewire fails

I don’t have my antiX 23.1 flashdrive with me. When I can I’ll try to test that and report back- note: antiX 23 and 23.1v1 worked without that problem on the very same hardware, always on live mode.

P.

[Member abc-nix]

Helpful

Up

0

::

PPC wrote:

At home, I use only wi-fi: I think I never ever had problems connecting to wi-fi when booting- but I reported that I sometimes lose wi-fi when my computers come off sleep mode

@ppc
You are right. This just happened to me. I didn’t have it happen for a while, so I thought it was fixed, but I just woke my laptop from sleep and was forced to restart the connman service to connect again to my wireless access point. I will be checking the acpi wake from sleep hooks later on to see if there is a way to fix this. Tonight when I have more time I will have a look. No easy fix for it right now.

[Member Xunzi_23]

Helpful

Up

0

::

Hi abc-nix, I had already made the changes you suggested. Will submit log next time issue occurs.

[Member PPC]

Helpful

Up

0

::

abc-nix wrote:

you could check what wire programs started on your desktop when pipewire fails (pgrep -l wire) and see the timings (start-t pipewire, start-t dbus), and share it in a post there.

@abc-nix:

pgrep -l wire
8060 pipewire
8122 pipewire-pulse
start-t pipewire
       23.71
       24.02
start-t dbus
       15.25
       36.47
       36.50
       48.17

After toggling pulsewire off and back on, all is well:

pgrep -l wire
2521235 pipewire
2521257 wireplumber
2521259 pipewire-pulse

And just in case this is needed:

start-t pipewire
     2432.95
     2432.97

(of course, dbus reports the same results as it previously did)

[Member lgj100]

Helpful

Up

0

::

@abc-nix Thanks for this suggestion. I implemented it, and since then, the internet has come up on every boot-up. On occasion, I still have issues with the system being very slow and requiring a reboot after wake-up from suspend. This happens at every 10’th wake-up, or so.

Sincerely,
Lars.

• This reply was modified 19 hours, 37 minutes ago by lgj100.

[Moderator Brian Masinick]

Helpful

Up

0

::

One more thing to report regarding the use of the Command, the network manager daemon process for the Connman/cmst wireless network:

As far as the startup is concerned, this always works. I do, however occasionally have issues that may be a combination of the data flow from my local ISP (Internet Service Provider) and Connman: when the service is steady Connman works perfectly with the solution we’ve been discussing. However I see inconsistent performance of my senior community WiFi; last night we also noticed our TV coming up with the “circle spin” when waiting for the streaming service to have sufficient available bandwidth.

The Ceni solution is more stable but it takes a long time to initially connect. I’ve never seen it go offline (at least when there is a service response).

So I am guessing that Connman is less tolerant than Ceni to brief signal delays when the service still shows available but the network response is slower than what the service is expecting to have. Handling of this event MAY contain limitations and/or defects, explaining the behavior.

Proving all of this is much more difficult. After months I’m only beginning to establish use and behavioral patterns and yet these are not easy to prove, replicate consistently or adequately substantiate and report.

--
Brian Masinick

[Author]

Posts