[SOLVED][RTLWIFI-RTL8188EE] -> was a kernel issue

Myrage2000 · 2018-02-24 20:01:50

Hi,
Since the release of 4.15, my wifi is no longer working (I think that dhcpcd fails to retrieve a IP address).

Here are some infos about my system (I'm using a LiveUSB with the latest kernel 4.15.5):
lspci -k

Network controller: Realtek Company RTL8188EE Wireless Network Adapter
Kernel driver in use: rtl8188ee
Kernel modules: rtl8188ee

dmesg | grep rtlwifi

rtl8188ee: Using firmware rtlwifi/rtl8188efw.bin
rtlwifi: rtlwifi: wireless switch is on

Here is the manual connection to my wifi AP:
wpa_cli

scan
scan_results
-> [AP BSSID] 2437 -54 [WPA-PSK-CCMP+TKIP][WPA2-PSK-CCMP+TKIP][WPS][ESS] [AP SSID]
add_network
-> 0
set_network 0 ssid [AP SSID]
-> OK
set_network 0 psk [AP PASSWORD]
-> OK
enable_network 0
-> OK
-> Trying to associate with [AP BSSID]
-> ...
-> CTRL-EVENT-CONNECTED - Connection to [AP BSSID] completed [id=0 id_str=]

>> Connection to [AP BSSID] completed

And here is the issue:
dhcpcd

wlo1: soliciting an IPv6 router
wlo1: soliciting a DHCP lease
wlo1: no IPv6 Routers available
timed out

>> timed out

If build a LiveUSB with a 4.14.21 lts kernel, everything works.
I don't understand why dhcpcd would like to "solicite an IPv6 router" because I am not sure that my router supports IPv6, but I did not have this error with 4.14.21.

Could someone help me please ?

Last edited by Myrage2000 (2018-09-23 21:12:29)

lo1 · 2018-02-24 20:28:04

It's normal that it solicits an IPV6 router, because depending on your network you could have both of them.

You could try disabling it via kernel parameter "ipv6.disable_ipv6=1" but I'm not sure if this will provide any benefit at all.

Can you try increasing dhcpcd timeout to something higher (let's say 60 seconds) or sniffing the packets with wireshark? (given that we won't find a lot of packets to look through, you could just use the command `tshark -i interface` before attemtping a dhcp DORA cycle and post the output here).

Last edited by lo1 (2018-02-24 20:29:00)

Myrage2000 · 2018-02-24 21:11:25

I don't think setting a kernel parameter will fix to issue because everything works well on 4.14.21 (maybe I should take a look at the changelog from 4.14 to 4.15 ?).

dhcpcd -t 240 (240 seconds)

wlo1: soliciting an IPv6 router
wlo1: soliciting a DHCP lease
wlo1: no IPv6 Routers available
timed out

tshark -i wlo1 (I spoofed all mac addresses)

# The first 4 lines are the 4way handshake
    1 0.000000000 ***** → ***** EAPOL 113 Key (Message 1 of 4)
    2 0.000564247 ***** → ***** EAPOL 135 Key (Message 2 of 4)
    3 0.009253274 ***** → ***** EAPOL 217 Key (Message 3 of 4)
    4 0.009434124 ***** → ***** EAPOL 113 Key (Message 4 of 4)
    5 0.013100162 aa11::aa11:11aa:aa00:0aa0 → aa02::16     ICMPv6 90 Multicast Listener Report Message v2
    6 0.026123676 aa11::aa11:11aa:aa00:0aa0 → aa02::16     ICMPv6 90 Multicast Listener Report Message v2
    7 0.158621748 aa11::aa11:11aa:aa00:0aa0 → aa02::2      ICMPv6 70 Router Solicitation from a0:00:00:00:0a:a1
    8 0.899073163      0.0.0.0 → 255.255.255.255 DHCP 395 DHCP Discover - Transaction ID 0xaa0a0000
    9 1.040211155aa11::aa11:11aa:aa00:0aa0 → aa02::16     ICMPv6 90 Multicast Listener Report Message v2
   10 3.155845149  192.168.1.1 → 224.0.0.1    IGMPv2 46 Membership Query, general
   11 4.162759803 aa11::aa11:11aa:aa00:0aa0 → aa02::2      ICMPv6 70 Router Solicitation from a0:00:00:00:0a:a1
   13 6.536546039 192.168.1.** → ***.***.***.*** SSDP 216 M-SEARCH * HTTP/1.1 
   14 7.458156952 192.168.1.** → ***.***.***.*** SSDP 216 M-SEARCH * HTTP/1.1 
   15 7.763997891 192.168.1.** → ***.***.***.***  IGMPv2 46 Membership Report group 224.0.0.252
   16 8.165526619 aa11::aa11:11aa:aa00:0aa0 → aa02::2      ICMPv6 70 Router Solicitation from a0:00:00:00:0a:a1
   17 8.392814362 192.168.1.** → ***.***.***.*** SSDP 216 M-SEARCH * HTTP/1.1 
   18 10.835939013 192.168.1.** → ***.***.***.*** IGMPv2 46 Membership Report group ***.***.***.***
   19 12.169912340 aa11::aa11:11aa:aa00:0aa0 → aa02::2      ICMPv6 70 Router Solicitation from a0:00:00:00:0a:a1

lo1 · 2018-02-24 21:32:05

Reading what's changed between the kernel versions would be good at this point.

This is weird, because you are not receiving any DHCP offer from the DHCP server.

Do you mind posting the same command adding the -V flag?

EDIT: fixed the flag.

Last edited by lo1 (2018-02-24 21:35:00)

Palmitoxico · 2018-02-25 14:05:34

Have you tried downgrading the dhcpcd package? I'm having connection problems with dhcpcd 7.0.1-1 (wired connection) but the 6.11.5-1 version works fine.

Myrage2000 · 2018-02-26 16:15:46

Here is the network traffic log:
tshark -i wlo1 -V (I spoofed all mac addresses)
https://pastebin.com/TQMaePXH

I don't think downgrading dhcpcd is a good solution because everything works with a 4.14 kernel (I might be wrong).

Thanks for your help.

lo1 · 2018-02-27 17:28:24

Yup, seems what I thought: you ask for both ipv4 and ipv6, your gateway answer only with this dhcpv6 offer:

Internet Protocol Version 6, Src: fe80::585e:32db:e9e6:4811, Dst: ff02::1:2
    0110 .... = Version: 6
    .... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00 (DSCP: CS0, ECN: Not-ECT)
        .... 0000 00.. .... .... .... .... .... = Differentiated Services Codepoint: Default (0)
        .... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    .... .... .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000
    Payload Length: 118
    Next Header: UDP (17)
    Hop Limit: 1
    Source: fe80::585e:32db:e9e6:4811
    Destination: ff02::1:2
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 546, Dst Port: 547
    Source Port: 546
    Destination Port: 547
    Length: 118
    Checksum: 0x57c2 [unverified]
    [Checksum Status: Unverified]
    [Stream index: 1]

Try either connecting with `dhcpcd -4 wlo1` and disable ipv6.

P.S. I'll see if I can understand what's changed between the two kernel versions that's causing this issue (I doubt I'll even get closer to the slightest idea)

Myrage2000 · 2018-03-03 19:55:26

Hey,
The command "dhcpcd -4 wlo1" does the same thing, even if I disable ipv6 (I get some errors with my softwares because of IPv6 disabled).
Maybe my router is becoming too old and is missing something in its firmware ?

Thanks for your help

lo1 · 2018-03-03 20:56:57

Well it seems it wasn't such a big help, but you're welcome

Anyway, I don't think your router is to blame (especially since this is a fault of linux 4.15.*). What happens if you connect manually (no dhcp, no network manager of any kind) as stated by https://wiki.archlinux.org/index.php/Ne … assignment ?

Myrage2000 · 2018-03-12 17:18:45

Hey,
I'm sorry I have not tried manually for the moment, I don't have a lot of free time.

I noticed that when I boot on 4.15 (or 4.16), I get three "No IRQ handler for vector" errors. This does not happen on 4.14.

EndUserOnly · 2018-03-21 07:41:11

You have done extensive research and your skill level is above mine. However, I have the exact same problem with RTL8188EE. Fortunately, I use only wired connection. I was poking around trying to determine if IPv6 was actually working when I found out that wireless was no longer working. In my case I will simply wait awhile because this is common with kernel releases.... they will break something, and eventually fix it. Just wanted to confirm your issue.

EndUserOnly · 2018-03-21 16:06:44

I have just corrected my problem, communicating on wireless as we speak. I use wicd and dhcpcd. In the past dhcpcd has caused me problems where I have had to constantly reinstall. Looked for another dhcp method. Discovered dhclient. Installed dhclient "alongside" dhcpcd. Went into wicd and changed client from dhcpcd to dhclient; reboot. Wireless is still holding-up. Another good thing I noticed about dhclient (before the reboot fix) is that although wireless was failing, it automatically restored the previous connection (wired). Dhcpcd did not do this (no connection). After reboot, viola.... Not my post so will not mark "Solved".

Last edited by EndUserOnly (2018-03-21 16:10:38)

rsmarples · 2018-03-21 16:23:42

In the past dhcpcd has caused me problems where I have had to constantly reinstall.

Can you describe these problems in more detail please?
I dislike issues in dhcpcd and strive to fix them when I know about them.

EndUserOnly · 2018-03-22 19:33:16

Only the one discussed here. I tend to fix the problem and move on. This problem, as stated - wifi stopped working. In order to get wifi working I had to use dhclient with wicd, switching from dhcpcd with wicd. The odd thing is that dhcpcd cannot be removed because it is a dependent of wicd, despite having my settings in wicd set to use dhclient.

Myrage2000 · 2018-04-15 20:46:27

Hey, I have some news:
DHCPCD v7.0.2 (currently only in testing repos) is not fixing the issue.
I don't understand why DHCPCD would be the issue here, because everything is working with Linux 4.14 and below.
I'm also using NetworkManager with its internal DHCP module, so the issue would be NetworkManager and DHCPCD ? I don't think this is the issue.
DHClient is not working for me (It just seems to be stuck when launched).

I don't know what to do, please help I cannot update my kernel version.
I can connect to free hotspots (which means DHCP works sometimes), but I can't with my home router.
With the KDE NetworkManager applet, it gets stuck on "Setting network address".

lo1 · 2018-04-16 12:54:12

Last think I could think of: switch from duid to clientid (or viceversa) by setting your /etc/dhcpcd.conf properly. If using clientid, you can also try disabling ipv6 both by kernel parameter and dhcpcd.conf

# Use the hardware address of the interface for the Client ID.
clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
# Some non-RFC compliant DHCP servers do not reply with this set.
# In this case, comment out duid and enable clientid above.
#duid

...

noipv6rs
noipv6

EDIT: try it without NetworkManager first, hence classic combo wpa_supplicant + dhcpcd.

Last edited by lo1 (2018-04-16 12:55:52)

Myrage2000 · 2018-04-16 19:08:43

Hey,
Thanks for the answer but it's not working.
Today I tried the same thing on Fedora 28 beta (with a 4.16 kernel) and... same issue.
I really think this is a kernel issue and I would like to report this issue to a kernel developper now, because I know it's not a software issue.
Could somebody help me to find the right place to report the issue please ? I don't think we can report on Github, and I don't find documentation for this.

EDIT : I can connect to wpa routers, but the issue is for wpa2 routers.

Last edited by Myrage2000 (2018-04-16 19:58:33)

Arch Linux

#1 2018-02-24 20:01:50

[SOLVED][RTLWIFI-RTL8188EE] -> was a kernel issue

#2 2018-02-24 20:28:04

Re: [SOLVED][RTLWIFI-RTL8188EE] -> was a kernel issue

#3 2018-02-24 21:11:25

Re: [SOLVED][RTLWIFI-RTL8188EE] -> was a kernel issue

#4 2018-02-24 21:32:05

Re: [SOLVED][RTLWIFI-RTL8188EE] -> was a kernel issue

#5 2018-02-25 14:05:34

Re: [SOLVED][RTLWIFI-RTL8188EE] -> was a kernel issue

#6 2018-02-26 16:15:46

Re: [SOLVED][RTLWIFI-RTL8188EE] -> was a kernel issue

#7 2018-02-27 17:28:24

Re: [SOLVED][RTLWIFI-RTL8188EE] -> was a kernel issue

#8 2018-03-03 19:55:26

Re: [SOLVED][RTLWIFI-RTL8188EE] -> was a kernel issue

#9 2018-03-03 20:56:57

Re: [SOLVED][RTLWIFI-RTL8188EE] -> was a kernel issue

#10 2018-03-12 17:18:45

Re: [SOLVED][RTLWIFI-RTL8188EE] -> was a kernel issue

#11 2018-03-21 07:41:11

Re: [SOLVED][RTLWIFI-RTL8188EE] -> was a kernel issue

#12 2018-03-21 16:06:44

Re: [SOLVED][RTLWIFI-RTL8188EE] -> was a kernel issue

#13 2018-03-21 16:23:42

Re: [SOLVED][RTLWIFI-RTL8188EE] -> was a kernel issue

#14 2018-03-22 19:33:16

Re: [SOLVED][RTLWIFI-RTL8188EE] -> was a kernel issue

#15 2018-04-15 20:46:27

Re: [SOLVED][RTLWIFI-RTL8188EE] -> was a kernel issue

#16 2018-04-16 12:54:12

Re: [SOLVED][RTLWIFI-RTL8188EE] -> was a kernel issue

#17 2018-04-16 19:08:43

Re: [SOLVED][RTLWIFI-RTL8188EE] -> was a kernel issue

Board footer