Damnable NM failing to connect , again.
FedoraForum.org - Fedora Support Forums and Community
Results 1 to 11 of 11
  1. #1
    Join Date
    Nov 2009
    Posts
    305
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Damnable NM failing to connect , again. [SOLVED]

    Hi,

    it still seems that the biggest problem with installing Linux is getting networking working.

    Even though there has been much standardisation in hardware and network interfacing, Linux still seems unable to achieve the simply click and go reliability windows has had 20 years ago.

    I just picked up a Dell Vosto 130 with a 32 bit Windoze 7 , so of course I wanted to install my favorite 64 bit OS to get the best from the hardware. I grabbed a XFCE Fed 30 iso and did the basic installation with no trouble. But as soon as I wanted to connect to finish the installation my joy was over.

    I gave it the wifi password and it failed ... I checked it, it failed again. I got another laptop running an older Fedora , it connects no trouble. I put the two side by side and check all the tabs of network manager configuration ( especially, multiply, quadruply checking and rechecking the pass phrase if perfectly correct ). Everything seems the same.

    I ran dmesg on the defective machine and the stage it show "deauthenticating" is followed by ( Reason: 3=DEAUTH_LEAVING) , previous attempt shows ( Reason: 15=4WAY_HANDSHAKE_TIMEOUT) .

    iwlist scanning shows the ESSID of the AP and it shows up in the NM config. it just seems to fail using the same (alpha only) passphrase that works on two other Fedora machines on the same LAN.

    How can I chase down the cause of this failure to connect ?

    Many thanks.

    [EDIT] Bottom line changed to channel 1 on ISPs ( Free ) proprietary router, fixed it. See below for details and lack of error msg from Linux.
    Last edited by feddy; 1st August 2019 at 02:39 PM.

  2. #2
    Join Date
    Apr 2018
    Location
    bash shell
    Posts
    76
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Damnable NM failing to connect , again.

    Recently, someone told me he had a similar problem, everything appeared ok but wifi wouldn't connect.

    He brought me the laptop to check, it was a brand new laptop that came with a newer Realtek wifi chipset that was recognized by the kernel but the loaded module was incompatible with that particular device id. A little search revealed others with similar problems, so the solution was to use a USB wifi dongle and wait for an updated kernel.

    Unfortunately, I've had horrible experience with Realtek, their chips perform ok under low stress but when bandwidth increases closer to the top of their theoretical specifications, things immediately go bad, packets are dropped, the driver leaks memory, disconnections, high cpu usage, etc.

    Anyway, my suggestion is to find what kind of wifi chipset you have and search for others with similar problems. Its possible someone has already been in your shoes.

  3. #3
    Join Date
    Nov 2009
    Posts
    305
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Damnable NM failing to connect , again.

    Thanks, that makes sense.

    It's an Atheros AR9285, not Realtek so I suppose it could be worse.
    ath9k and ath9k_hw kernel modules.

    You dongle suggestion did get me connected. Many thanks, a great help. I still want to get the h/w working though.

    Are there log files where I can find more output? The trouble with GUI stuff like NM is that it just gobbles any error msgs and leaves you blind.
    Last edited by feddy; 30th July 2019 at 11:10 PM.

  4. #4
    Join Date
    Apr 2018
    Location
    bash shell
    Posts
    76
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Damnable NM failing to connect , again.

    First, find the device IDs and search for them, in case someone had the same problems with that particular chipset.

    All errors are logged in the journal, nothing is missed or hidden, just takes a different approach to find things. You can see all NM related messages in the journal with:

    journalctl -t NetworkManager

    maybe there is an error there that you can easily fix

  5. #5
    Join Date
    Nov 2009
    Posts
    305
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Damnable NM failing to connect , again.

    I assume the device ID is the AR9285, I posted above.

    Nothing more enlightening from journalctl

    I typed 'dnf update' while the NM popup was visible. Now I have an adhoc connection with ESSID of f and p/w of update :?

    It seems to have connected by accident !

  6. #6
    Join Date
    Apr 2018
    Location
    bash shell
    Posts
    76
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Damnable NM failing to connect , again.

    No, the device ID is a pair of hexadecimal numbers. Run the following command:

    lspci -nn

    You'll see output similar to (example from a DELL laptop):

    01:00.0 Network controller [0280]: Intel Corporation Wireless 3165 [8086:3165] (rev 79)

    The device ID is the pair in bold. 8086 is for Intel and 3165 is for that particular wireless chipset. The lspci command will also tell you the loaded module, run as "lspci -vvv", find the PCI device of your adapter and look for the following:

    Kernel driver in use: iwlwifi
    Kernel modules: iwlwifi

    Since this particular chipset is made by Intel, it uses the Intel module iwlwifi. You can unload and re-load the module, pass it various parameters to enable debug mode, so on and so forth. Maybe that way you can identify the problem.

  7. #7
    Join Date
    Nov 2009
    Posts
    305
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Damnable NM failing to connect , again.

    Ah, thanks, I've always seen that called vendorID and productID, that's why I did not catch on: [168c:002b]

    I did not know there was a third -v option to lspci , very useful, but I had already determined the drivers from lsmod.

    ath9k , which pulls in ath9k_hw, ath9k_common and ath. Unloading and reloading may give something. I had not thought of that.

    What I don't understand is how it is managing to connect "ad hoc" . I give it a spurious SSID f and an arbitrary pw and it connects. :?

    route -n shows it connects to 10.42.0.0 subnet but my AP is supposed to attribute on 192.168.0.0

    How is this even working and what can this tell me about the normal connection not managing to authenticate?

  8. #8
    Join Date
    Nov 2009
    Posts
    305
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Damnable NM failing to connect , again.

    You can unload and re-load the module, pass it various parameters to enable debug mode, so on and so forth. Maybe that way you can identify the problem.
    https://wireless.wiki.kernel.org/en/...rs/ath9k/debug

    Code:
    modprobe ath9k debug=0x00000200
    I reloaded the module with config debugging and do see files in /sys/kernel/debug

    phy_err contains a line SERVICE_ERR : 10

    Nothing obviously pertinent to the current problem except I suppose it looks like the module is loading and working .

    The only think I found which seemed relevent about problems with this device was someone on same ISP who fixed it by changing channels on the router ( which is specific to the ISP ). I did one change and it did not help. I have not tried walking through every possible value.

  9. #9
    Join Date
    Apr 2018
    Location
    bash shell
    Posts
    76
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Damnable NM failing to connect , again.

    well, there are tools that can scan all the available channel frequencies and report possible conflicts and channel overuse. This is typical when a popular ISP uses a specific channel for an entire country or city. In that case, it helps to jump, for example, from channel 6 to channel 11 or the other way around.

    I believe ubiquity access points have the ability to scan and report channel usage about their surroundings.

  10. #10
    Join Date
    Nov 2009
    Posts
    305
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Damnable NM failing to connect , again.

    thanks fedup. 6 and 11 were exactly the ones I'd tried, and neither worked. I just tried channel 1 and, low and behold, it works !

    So why does windowz 7 have no problem with the original config and Linux fails? That does not seem consistent with the ISP over using the channel.

    Also shouldn't there be some way to get a reason for failure from somewhere. I've wasted a full day chasing this before falling on a random internet post which fitted the bill.

  11. #11
    Join Date
    Apr 2018
    Location
    bash shell
    Posts
    76
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: Damnable NM failing to connect , again.

    I'm glad you solved the problem!

    I have no idea why there isn't a proper error message in this case. All I can tell you, is that this has happened to me as well, channel 11 wouldn't work at all but any channel below 8 worked fine. Again something similar happened to me when using 5GHz frequencies and some android phones.

    Its possible for Windows to work when Linux doesn't, maybe due to different driver implementations, for example the Windows one is better updated and maintained because its more "popular".

Similar Threads

  1. Gnome-shell failing - failback also failing
    By omgimdrunk in forum Using Fedora
    Replies: 3
    Last Post: 9th June 2012, 07:43 PM
  2. Connect / Dic-connect with modem lights
    By ailmarfarm in forum Using Fedora
    Replies: 1
    Last Post: 12th October 2005, 03:57 AM
  3. unable to connect to internet,able to connect through windows XP
    By Narasimha in forum Servers & Networking
    Replies: 1
    Last Post: 4th October 2005, 12:16 AM
  4. unable to connect to internet,able to connect through windows XP
    By Narasimha in forum Servers & Networking
    Replies: 0
    Last Post: 3rd October 2005, 06:35 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •