Odd Wireless Behaviour
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
I'm using a Realtek rtl8192eu chip. I spent ages trying to connect to my router. Eventually, I reloaded the rtl8xxxu module. That fixed it until next boot. Once again I had to do the same. This time I checked kernel messages specific to rtl8192eu. To my shock, the exact same messages appeared when I reloaded the module as when the system did. I just want to understand this behaviour. So, can anybody shed some light on this? A fix would be great, too, but I'd settle on an explanation since there are plenty quick 'n dirty tricks I could apply (although I seldom restart, my average uptime being weeks per PC).
Basic Info:
*. Debian Stable 9.5 (+ non-free).
*. Kernel: 4.9.0-7 (AMD64)
*. No other OS (so nothing to mess with the chip).
*. USB Unbranded Wifi Dongle with Realtek chip RTL8192EU.
*. Error message: "rtl8192eu_rx_iqk_path_b: Path B RX IQK failed!"
*. Scanning fails until reloading module.
*. Before reload: "Hardware modes: Master, Monitor, [blah, blah...] Software modes: Monitor." No mention of Managed.
debian wifi realtek
asked Sep 8 at 15:42
Jay
82
add a comment |Â
up vote
1
down vote
favorite
I'm using a Realtek rtl8192eu chip. I spent ages trying to connect to my router. Eventually, I reloaded the rtl8xxxu module. That fixed it until next boot. Once again I had to do the same. This time I checked kernel messages specific to rtl8192eu. To my shock, the exact same messages appeared when I reloaded the module as when the system did. I just want to understand this behaviour. So, can anybody shed some light on this? A fix would be great, too, but I'd settle on an explanation since there are plenty quick 'n dirty tricks I could apply (although I seldom restart, my average uptime being weeks per PC).
Basic Info:
*. Debian Stable 9.5 (+ non-free).
*. Kernel: 4.9.0-7 (AMD64)
*. No other OS (so nothing to mess with the chip).
*. USB Unbranded Wifi Dongle with Realtek chip RTL8192EU.
*. Error message: "rtl8192eu_rx_iqk_path_b: Path B RX IQK failed!"
*. Scanning fails until reloading module.
*. Before reload: "Hardware modes: Master, Monitor, [blah, blah...] Software modes: Monitor." No mention of Managed.
debian wifi realtek
asked Sep 8 at 15:42
Jay
82
@Theophrastus Yes, systemd. Since Debian's official change. As far as that thread you linked, it's nearly verbatim. I modprobe -r the rtlxxxu module, then modprobe it, then it "just works" (which makes me nervous). I decided on auto-removing & auto-loading it at start. I just wondered about it technically. At least that thread mentioned a device ready delay. Thanks for that. Still confused why the error messages were the same. I guess "Realtek" should be an answer unto itself (I didn't choose it, I got it free).
– Jay
Sep 8 at 16:16
related unix.stackexchange.com/questions/252210/…
– Rui F Ribeiro
Sep 8 at 17:00
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I'm using a Realtek rtl8192eu chip. I spent ages trying to connect to my router. Eventually, I reloaded the rtl8xxxu module. That fixed it until next boot. Once again I had to do the same. This time I checked kernel messages specific to rtl8192eu. To my shock, the exact same messages appeared when I reloaded the module as when the system did. I just want to understand this behaviour. So, can anybody shed some light on this? A fix would be great, too, but I'd settle on an explanation since there are plenty quick 'n dirty tricks I could apply (although I seldom restart, my average uptime being weeks per PC).
Basic Info:
*. Debian Stable 9.5 (+ non-free).
*. Kernel: 4.9.0-7 (AMD64)
*. No other OS (so nothing to mess with the chip).
*. USB Unbranded Wifi Dongle with Realtek chip RTL8192EU.
*. Error message: "rtl8192eu_rx_iqk_path_b: Path B RX IQK failed!"
*. Scanning fails until reloading module.
*. Before reload: "Hardware modes: Master, Monitor, [blah, blah...] Software modes: Monitor." No mention of Managed.
debian wifi realtek
asked Sep 8 at 15:42
Jay
82
I'm using a Realtek rtl8192eu chip. I spent ages trying to connect to my router. Eventually, I reloaded the rtl8xxxu module. That fixed it until next boot. Once again I had to do the same. This time I checked kernel messages specific to rtl8192eu. To my shock, the exact same messages appeared when I reloaded the module as when the system did. I just want to understand this behaviour. So, can anybody shed some light on this? A fix would be great, too, but I'd settle on an explanation since there are plenty quick 'n dirty tricks I could apply (although I seldom restart, my average uptime being weeks per PC).
Basic Info:
*. Debian Stable 9.5 (+ non-free).
*. Kernel: 4.9.0-7 (AMD64)
*. No other OS (so nothing to mess with the chip).
*. USB Unbranded Wifi Dongle with Realtek chip RTL8192EU.
*. Error message: "rtl8192eu_rx_iqk_path_b: Path B RX IQK failed!"
*. Scanning fails until reloading module.
*. Before reload: "Hardware modes: Master, Monitor, [blah, blah...] Software modes: Monitor." No mention of Managed.
debian wifi realtek
debian wifi realtek
asked Sep 8 at 15:42
Jay
82
asked Sep 8 at 15:42
Jay
82
asked Sep 8 at 15:42
Jay
82
asked Sep 8 at 15:42
Jay
82
asked Sep 8 at 15:42
Jay
82
82
@Theophrastus Yes, systemd. Since Debian's official change. As far as that thread you linked, it's nearly verbatim. I modprobe -r the rtlxxxu module, then modprobe it, then it "just works" (which makes me nervous). I decided on auto-removing & auto-loading it at start. I just wondered about it technically. At least that thread mentioned a device ready delay. Thanks for that. Still confused why the error messages were the same. I guess "Realtek" should be an answer unto itself (I didn't choose it, I got it free).
– Jay
Sep 8 at 16:16
related unix.stackexchange.com/questions/252210/…
– Rui F Ribeiro
Sep 8 at 17:00
add a comment |Â
@Theophrastus Yes, systemd. Since Debian's official change. As far as that thread you linked, it's nearly verbatim. I modprobe -r the rtlxxxu module, then modprobe it, then it "just works" (which makes me nervous). I decided on auto-removing & auto-loading it at start. I just wondered about it technically. At least that thread mentioned a device ready delay. Thanks for that. Still confused why the error messages were the same. I guess "Realtek" should be an answer unto itself (I didn't choose it, I got it free).
– Jay
Sep 8 at 16:16
related unix.stackexchange.com/questions/252210/…
– Rui F Ribeiro
Sep 8 at 17:00
@Theophrastus Yes, systemd. Since Debian's official change. As far as that thread you linked, it's nearly verbatim. I modprobe -r the rtlxxxu module, then modprobe it, then it "just works" (which makes me nervous). I decided on auto-removing & auto-loading it at start. I just wondered about it technically. At least that thread mentioned a device ready delay. Thanks for that. Still confused why the error messages were the same. I guess "Realtek" should be an answer unto itself (I didn't choose it, I got it free).
– Jay
Sep 8 at 16:16
@Theophrastus Yes, systemd. Since Debian's official change. As far as that thread you linked, it's nearly verbatim. I modprobe -r the rtlxxxu module, then modprobe it, then it "just works" (which makes me nervous). I decided on auto-removing & auto-loading it at start. I just wondered about it technically. At least that thread mentioned a device ready delay. Thanks for that. Still confused why the error messages were the same. I guess "Realtek" should be an answer unto itself (I didn't choose it, I got it free).
– Jay
Sep 8 at 16:16
related unix.stackexchange.com/questions/252210/…
– Rui F Ribeiro
Sep 8 at 17:00
related unix.stackexchange.com/questions/252210/…
– Rui F Ribeiro
Sep 8 at 17:00
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
0
down vote
accepted
I can shed some light on this, though I can't fully explain it. In
rtl8192eu_rx_iqk_path_b: Path B RX IQK failed
rx stands for "receive", and says something along the line "something unexpected happened, even though I should be able to receive something on this part of the hardware, it didn't work". In other words, the hardware ended up in a state that was not meant to happen, which is why everything after fails.
When you reload the module, you reinitialize the hardware, so now it's again in a good state. While the module initializes the hardware, it spits out some messages, and of course these will be the same each time (after all, it's doing the same stuff).
So now it will work, until whatever throws it into a bad state happens again.
To sum up, it's a driver bug: It's a situation the driver writers didn't think about, or don't handle correctly. You can file a bug report, and pray for an updated driver. That's about all you can do.
answered Sep 8 at 17:53
dirkt
14.9k2932
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
accepted
I can shed some light on this, though I can't fully explain it. In
rtl8192eu_rx_iqk_path_b: Path B RX IQK failed
rx stands for "receive", and says something along the line "something unexpected happened, even though I should be able to receive something on this part of the hardware, it didn't work". In other words, the hardware ended up in a state that was not meant to happen, which is why everything after fails.
When you reload the module, you reinitialize the hardware, so now it's again in a good state. While the module initializes the hardware, it spits out some messages, and of course these will be the same each time (after all, it's doing the same stuff).
So now it will work, until whatever throws it into a bad state happens again.
To sum up, it's a driver bug: It's a situation the driver writers didn't think about, or don't handle correctly. You can file a bug report, and pray for an updated driver. That's about all you can do.
answered Sep 8 at 17:53
dirkt
14.9k2932
add a comment |Â
up vote
0
down vote
accepted
I can shed some light on this, though I can't fully explain it. In
rtl8192eu_rx_iqk_path_b: Path B RX IQK failed
rx stands for "receive", and says something along the line "something unexpected happened, even though I should be able to receive something on this part of the hardware, it didn't work". In other words, the hardware ended up in a state that was not meant to happen, which is why everything after fails.
When you reload the module, you reinitialize the hardware, so now it's again in a good state. While the module initializes the hardware, it spits out some messages, and of course these will be the same each time (after all, it's doing the same stuff).
So now it will work, until whatever throws it into a bad state happens again.
To sum up, it's a driver bug: It's a situation the driver writers didn't think about, or don't handle correctly. You can file a bug report, and pray for an updated driver. That's about all you can do.
answered Sep 8 at 17:53
dirkt
14.9k2932
add a comment |Â
up vote
0
down vote
accepted
up vote
0
down vote
accepted
I can shed some light on this, though I can't fully explain it. In
rtl8192eu_rx_iqk_path_b: Path B RX IQK failed
rx stands for "receive", and says something along the line "something unexpected happened, even though I should be able to receive something on this part of the hardware, it didn't work". In other words, the hardware ended up in a state that was not meant to happen, which is why everything after fails.
When you reload the module, you reinitialize the hardware, so now it's again in a good state. While the module initializes the hardware, it spits out some messages, and of course these will be the same each time (after all, it's doing the same stuff).
So now it will work, until whatever throws it into a bad state happens again.
To sum up, it's a driver bug: It's a situation the driver writers didn't think about, or don't handle correctly. You can file a bug report, and pray for an updated driver. That's about all you can do.
answered Sep 8 at 17:53
dirkt
14.9k2932
I can shed some light on this, though I can't fully explain it. In
rtl8192eu_rx_iqk_path_b: Path B RX IQK failed
rx stands for "receive", and says something along the line "something unexpected happened, even though I should be able to receive something on this part of the hardware, it didn't work". In other words, the hardware ended up in a state that was not meant to happen, which is why everything after fails.
When you reload the module, you reinitialize the hardware, so now it's again in a good state. While the module initializes the hardware, it spits out some messages, and of course these will be the same each time (after all, it's doing the same stuff).
So now it will work, until whatever throws it into a bad state happens again.
To sum up, it's a driver bug: It's a situation the driver writers didn't think about, or don't handle correctly. You can file a bug report, and pray for an updated driver. That's about all you can do.
answered Sep 8 at 17:53
dirkt
14.9k2932
answered Sep 8 at 17:53
dirkt
14.9k2932
answered Sep 8 at 17:53
dirkt
14.9k2932
answered Sep 8 at 17:53
dirkt
14.9k2932
14.9k2932
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f467732%2fodd-wireless-behaviour%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
@Theophrastus Yes, systemd. Since Debian's official change. As far as that thread you linked, it's nearly verbatim. I modprobe -r the rtlxxxu module, then modprobe it, then it "just works" (which makes me nervous). I decided on auto-removing & auto-loading it at start. I just wondered about it technically. At least that thread mentioned a device ready delay. Thanks for that. Still confused why the error messages were the same. I guess "Realtek" should be an answer unto itself (I didn't choose it, I got it free).
– Jay
Sep 8 at 16:16
related unix.stackexchange.com/questions/252210/…
– Rui F Ribeiro
Sep 8 at 17:00