WIFI loss during routine update

  • This topic has 14 replies, 4 voices, and was last updated Feb 14-1:46 pm by Xecure.
Viewing 15 posts - 1 through 15 (of 15 total)
  • Author
    Posts
  • #54169
    Member
    roland

    Yesterday I was running a routine apt update followd by apt upgrade when part way through the upgrade I noticed the Conky panel had lost the up down status reports.

    The upgrade finished normally, BUT reported 2 modules missing right at the end, Sadly I was not alert enough to take a screenshot nor can I remember the module names.

    Now I can connect to my service provider as before using Ceni and can see both 2.4ghz and 5ghz wlan networks, but no browser will connect to either, returning ‘page no found’ or similar.

    My repos were set to Frankfurt and no changes have been made to a working installation since Nvidia drivers were successfully installed last week.

    I am not sure where to look for the disgnostic logs required but I attach what I thought may be relevant. The screenshot shows that Conky thinks the network is present and working while any browser fails to connect.

    #54172
    Member
    roland
    Helpful
    Up
    0
    :D

    history file refused by system post for inacceptable format.

    Attachments:
    #54174
    Forum Admin
    anticapitalista
    Helpful
    Up
    0
    :D

    Menu > Applications > antiX > Change Wifi Program

    You might need a reboot.

    If you do not use connman and always use ceni, remove connman and its components

    You might also need to sudo apt install --reinstall resolvconf

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

    antiX with runit - leaner and meaner.

    #54175
    Member
    Xecure
    Helpful
    Up
    0
    :D

    anticapitalista is probably right.
    With connman update, it may have started the service again, which conflicts with resolveconf to manage the resolv.conf file.

    Try using antix-wifi-switch to restore ceni’s operation.

    #54206
    Member
    roland
    Helpful
    Up
    0
    :D

    Dear friends,

    Thanks for the suggestions, unfortunately I still have no connexion to my wifi wlan despite it being very clearly present and in working order, as I am using it on this PC side by side with the offending one, running almost the same installation and equally up to date.

    I removed connman, please see bash session log. I was unable to reinstall resolvconf, cannot be downloaded was reported. I then ran a restart session (warm reboot) and tried again, same result, please see bash session log. 2 modules reported failed to load, gail and atk-bridge. I have no idea what these are. This message has recently started to appear.

    To sum up, Ceni is now the only wifi handler. Therefore I have working wifi but cannot connect to it.

    I stick to Ceni because it is simple and dependable although has certain shortcomings that I would be happy to see improved upon. On the laptop I use downstairs under 17.4.1 it runs seamlessly and invisibly, a first rate connexion tool. Up here on PCs under 19.3 I have to manually make every connexion, it does not attempt to connect seamlessly. I would also like to be able to see the networks available at any moment, as available in Wicd.

    Any further suggestions will be thankfully received.

    #54209
    Member
    roland
    Helpful
    Up
    0
    :D

    sorry, wrong format again!

    #54212
    Member
    Xecure
    Helpful
    Up
    0
    :D

    You don’t make it clear. Did you click on “Ceni” on the antix-wifi-switch? This should fix any problem with resolve.conf (if there is any).
    Launch this from terminal first and, if there is any error, paste the output between code tags
    antix-wifi-switch --gui ceni

    #54245
    Member
    roland
    Helpful
    Up
    0
    :D

    As usual you guys are right and I am wrong, I clearly did not run the Wifi-switch when I saw that Ceni was now the only candidate having previously removed Connman, assuming wrongly that Ceni would now handle wifi matters. I have now run Wifi-switch and all is well, thanks for your patience. My only remaining question is – will this happen again next time I run a routine apt update and upgrade? At least I know the way to put matters right if it does. I am left with the feeling that all is not yet quite in order with wifi processing under Debian linux.

    I realise the recommendation is to move up to Connman, I tried it some while back when it was being discussed in the forum and found that even though I could see my wlan and had input the name and key string correctly, it just did nothing at all, and there was no button that I could see to push it into making a connexion. I was also confused about the ‘tethering’ parameter, whether or not to set it.

    So I returned to dependable Ceni, although I could wish for Ceni to connect automatically which it refuses to do at the weaker extremity of wifi strength, but does so where the signal is stronger and it finds the wlan during the boot process. Maybe some other influence is also at work here?

    Thanks for all your contributions.

    #54275
    Member
    roland
    Helpful
    Up
    0
    :D

    Sadly the above summary is not the end of the story.

    I now have to run ‘Change WIFI program’ every time I wish to connect to wlan1 after a cold boot. If I run a cold boot, then run Ceni and successfully connect to wlan1, no other application can use wlan1 until I have run the Wifi switch selection from the menu, even though there is only Ceni to choose from.

    A curiosity is that this process leaves the Conky screen display truncated from half way down the ‘down’ panel. I can restore the full conky display by running a ‘Restart session’ or warm reboot.

    I feel that while I can get along with this situation, it is concealing some more serious defect. All these troubles involving Wifi and wlan connexion have appeared since Connman was introduced, when I was using releases 13 and 16 there was never any issue despite there being both Ceni and Wicd to choose from, and they never seemed to get in each others way, I could connect with either and at random. Even under release 17 I never personally hit this conflict as I avoided Connman from the very start, having hit trouble with it on a laptop I also use, and which still works impeccably under 17.4.1 and running Ceni.

    I welcome any comments. I am giving serious thought to a regression to release 17.4.1, except that I have had several problems getting release 19.3 stable on this PC and going back will be a big step with potential hardware issues.

    Best wishes

    #54276
    Member
    Xecure
    Helpful
    Up
    0
    :D

    UPDATE-EDIT: I found out that on some reboots, /resolv.conf symlink defaults to /run/connman/resolv.conf which doesn’t exist. I will try downgrading the connman package to antiX repo version.

    UPDATE2: I have confirmed that downgrading connman to the antiX version fixes the resolv.conf symlink problem.
    Follow these steps:

    1. Use antix-wifi-switch to start ceni (it should autoconnect without having to recofigure your wifi).
    antix-wifi-switch --gui ceni
    2. Install the connman version found in the antix repos.
    sudo apt update && sudo apt install connman=1.36-2.0antix2
    3. Run again antix-wifi-switch to disable connman (in case the service autostarted)
    antix-wifi-switch --gui ceni
    4. Reboot and report if wifi auto-reconnects properly on next boot.

    ———————-

    [REMOVED EXPERIMENTS]

    The problem you have experienced with connman recently is related not to antiX’s connman package, but to a connman update coming from Debian. This update restarted the connman service and took hold of managing the resolv.conf file (even when the connman service was not running), which lead to ceni not working properly.

    • This reply was modified 4 months, 1 week ago by Xecure.
    • This reply was modified 4 months, 1 week ago by Xecure. Reason: Described steps to fix
    • This reply was modified 4 months, 1 week ago by Xecure. Reason: removed extra text to avoid confusion
    #54282
    Member
    roland
    Helpful
    Up
    0
    :D

    I logged into antix-forum and in a superuser bash terminal session, then ran the 3 bash commands exactly as per Xecure’s response, session copy is attached.

    After a cold reboot I waited over 5 minutes to give Ceni chance to locate the wifi network on wlan1, but it failed to do so.

    Loading Chromium web browser had no effect on that and I was obliged to run Ceni manually and make the connexion myself. I am not disturbed at this stage that no automatic network location and connexion was made, as up here I am far away from the service providers adapter and with a much weakened signal, and there are both 2.4ghz and 5.0ghz networks up both with the same name and key texts, one on channel 100 and the other on channel 11, not sure which frequency is assigned to which channel. How would Ceni make such a choice, given that my wifi card can handle both frequencies?

    I attach the ceni view of the networks in this area, nos. 00 and 01 are my own, but which is which and what the signal strength figures mean I do not know and would like to know.

    The laptop I use downstairs where signal is stronger connects automatically using Ceni if the network is available at boot time. iF not present the boot is held up awaiting it, after some minutes the boot proceeds without it. If the network then becomes available ceni will pick it up after a delay, a process which I realised is going on when I run Ceni manually, and see that a connexion in process is abandoned in favour of my manual Ceni run. But this laptop is running 17.4.1, and I am very pleased with it, as the once missing desktop icons have now appeared after some tinkering with the boot wait time from 2 to 5 seconds.

    Thanks for your response Xecure, I’m still unsure if this is the end of the story. And I still have Connman installed following your bash scripts, should I physically remove it? Also I have not run another apt update and apt upgrade since this trouble began, nor did anyone make remarks about the missing modules I referred to earlier in the post.

    #54285
    Member
    linuxdaddy
    Helpful
    Up
    0
    :D

    hi roland,

    regarding the signal strength lower is better. go with the -64 one as -90
    is really poor. I usually use ceni and get rid of connman as they conflict.

    wifi strength

    • This reply was modified 4 months, 1 week ago by linuxdaddy. Reason: added link

    Normal == 🙂
    depends on the surrounding crowd ?!

    #54286
    Member
    Xecure
    Helpful
    Up
    0
    :D

    After the last update, ceni doesn’t reconnect automatically for me either.
    I experimented while I waited for your response, and I can give you 2 options:

    A) Keep using ceni but it takes about 30 seconds to 1 minute or so to autoconnect.
    You need to edit /etc/rc.local with root privileges and add this entry before exit 0

    #restart wlan0
    /sbin/ifdown wlan1 && /sbin/ifup wlan1

    Save and close the text editor. Then, make sure rc.local autostarts with this command:
    sudo update-rc.d rc.local defaults
    Reboot and wait. It will/should autoconnect (30 sec to 1 minute after boot).
    I am trying to figure out the reason for this problem. I think it must be related to ifup not loading dhclient properly or something, but I cannot figure this out yet.
    After this, if you are happy with the current ceni behavior, remove connman
    sudo apt purge connman

    B) Make the switch to connman. [NON root terminal, please normal user terminal session).
    I assure you that this is the best you can do right now (if it works out of the box). After all the work put into learning it, I find that it works the best.
    First, remove the /etc/rc.local (ifdown/ifup) configuration that was explained above for ceni (if you already made that change).
    Then, install the connman gui app “cmst”
    sudo apt install cmst
    Use antix-wifi-switch to switch to connman (a pop up will ask you if you want to edit /etc/network/interfaces, say “Yes”).
    antix-wifi-switch --gui connman

    When cmst pops up (or if it doesn’t, click the icon in the systemtray), go to “Wireless” Tab and select the router access point with best signal (it will probably be the 2.4GHz connection) and click “Connect”. Enter the wifi password in the “Passphrase” entry and click OK. Before closing, go to the “Preferences” tab and enable “Retry failed connection”. Then, once you can connect to your Access Point, in the “Details” Tab, select your Connected Access Point (You will know that it is the correct one if in the properties you see “Service state: Online”) access point and click “Configuration”. Make sure that “Autoconnect” is enabled (or else enable and click OK).

    If everything goes right, connman should work from there on. I can assure you it is very reliable, and only the first time setting it up may give problems.

    • This reply was modified 4 months, 1 week ago by Xecure. Reason: Remove connman instructions for "happy ceni exp"
    #54366
    Member
    roland
    Helpful
    Up
    0
    :D

    An excellent response by Xecure, my wlan is now detected and connected automatically as intended, and Connman purged, thanks for that.

    I have a spare PC running 19.3 and will give Connman a try on that before extending it to this new build. However with Ceni now working as designed I can hardly justify the move to something I realise has caused difficulties, if only in implimentation.

    I can only repeat my feeling that Ceni is a highly adequate tool which could be made even better with minor enhancements, that the panel showing available networks be made available at any time from the tray, and that this panel show the channel number and frequency.

    I still have to cross the bridge of running a routine update, which I shall delay while the dust settles.

    Thanks again Xecure!

    #54376
    Member
    Xecure
    Helpful
    Up
    0
    :D

    Good to know it worked, roland.
    Next thing I was going to suggest is using
    /sbin/service networking reload
    instead of ifdown/ifup command in /etc/rc.local, so it is much more generic and doesn’t depend on the interface name.

    Hopefully some day we can have a perfect method to get connman to work out of the box. For now, keep enjoying ceni.

    Regards.

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