Opened 2 years ago

Closed 2 years ago

#17814 closed bug (fixed)

Wifi issues with Intel 7260

Reported by: pakyr Owned by: waddlesplash
Priority: normal Milestone: R1/beta4
Component: Drivers/Network/idualwifi7260 Version: R1/Development
Keywords: Cc:
Blocked By: #17820 Blocking: #17823
Platform: All

Description (last modified by pakyr)

I have a Dell Latitude E5410 with an Intel 7260 wifi card. After the updating, several issues have cropped up -

  1. Never autoconnects to known wifi network on startup like before.
  2. When I connect to a network, it will sometimes only work for a few seconds then totally stop working (ping to google returns nothing), even though NetworkStatus shows green.
  3. When a connection does last, I get frequent notifications saying the connection is ready even though I changed nothing.
  4. Even when a connection does last, it will eventually (~15 minutes or so) stop working even as NetworkStatus shows green and connected.
  5. When the connection stops working like this, the computer still shows as having an IP address, and I have not yet been able to successfully reconnect without restarting.

When it is working, it works great (noticably faster than before). I'm not sure what diagnostic info is required; please advise what, if anything, I should attach here.

I am on hrev56217.

Attachments (9)

syslog (434.5 KB ) - added by pakyr 2 years ago.
In this case, the connection stopped working after a bit under 15 minutes, as described previously
ifconfig (1.1 KB ) - added by pakyr 2 years ago.
ifconfig output after connection stopped working
syslog.2 (212.6 KB ) - added by pakyr 2 years ago.
I tried connecting to a different network that shouldn't have any beamforming or settings to kick users; I was never able to connect, after trying ~a dozen times or so. Was a standard WPA2 network.
syslog.3 (483.3 KB ) - added by pakyr 2 years ago.
The network I couldn't connect to was 2.4ghz. I was told that the original network had beamforming enabled, and I was able to get a connection to an AP without it. The connection still dropped, but the syslog and ifconfig looked superficially different to me so I have attached them in case there is anything useful.
ifconfig.2 (1.1 KB ) - added by pakyr 2 years ago.
syslog.4 (148.0 KB ) - added by pakyr 2 years ago.
NetworkStatus stayed green; ping did not work; packets sent increased but packets recieved did not
ifconfig.3 (1.1 KB ) - added by pakyr 2 years ago.
screenshot2.png (17.2 KB ) - added by vidrep 2 years ago.
screenshot3.png (38.8 KB ) - added by vidrep 2 years ago.

Download all attachments as: .zip

Change History (26)

comment:1 by pakyr, 2 years ago

Description: modified (diff)

comment:2 by waddlesplash, 2 years ago

Component: - GeneralDrivers/Network/idualwifi7260
Owner: changed from nobody to waddlesplash
Version: R1/beta3R1/Development

1 was flaky before and has never worked for me even with the old driver, so that may be a fluke.

The rest might be a stack issue. As with all driver issues, you need to attach a syslog. Please note the exact conditions of what had happened with the specific log you attach (e.g., worked for N minutes then failed, pings stopped, etc.) Please also paste the output of ifconfig at the same time you copy the syslog.

by pakyr, 2 years ago

Attachment: syslog added

In this case, the connection stopped working after a bit under 15 minutes, as described previously

by pakyr, 2 years ago

Attachment: ifconfig added

ifconfig output after connection stopped working

comment:3 by waddlesplash, 2 years ago

KERN: iwm: RUN -> AUTH

So, we just de-associate for some reason.

The 54 transmit errors are concerning, but it's also possible they happened after the problems began.

comment:4 by waddlesplash, 2 years ago

stsp@ from OpenBSD notes this may have to do with your access point kicking you off for some reason. He recommended checking the AP's configuration to see if it has some kind of options that look like "kick off clients with bad signal/speed/quality/etc."; disabling them may make a difference. Band-steering may also be part of the problem here.

by pakyr, 2 years ago

Attachment: syslog.2 added

I tried connecting to a different network that shouldn't have any beamforming or settings to kick users; I was never able to connect, after trying ~a dozen times or so. Was a standard WPA2 network.

comment:5 by waddlesplash, 2 years ago

Is the other network a 5GHz network? See if a 2.4GHz network works any better.

by pakyr, 2 years ago

Attachment: syslog.3 added

The network I couldn't connect to was 2.4ghz. I was told that the original network had beamforming enabled, and I was able to get a connection to an AP without it. The connection still dropped, but the syslog and ifconfig looked superficially different to me so I have attached them in case there is anything useful.

by pakyr, 2 years ago

Attachment: ifconfig.2 added

comment:6 by waddlesplash, 2 years ago

As far as I can tell, this is still in a connected state as of when you took these two?

comment:7 by pakyr, 2 years ago

Yeah, as I mentioned earlier, often the status stays green and everything looks fine, but I can't browse and a ping doesn't go through at all. I'm not sure if there's any other diagnostic info that would be more useful, but the connection was definitely not working when I took those files.

comment:8 by waddlesplash, 2 years ago

This sounds like we are dealing with some separate issues, then. The deauth from the first AP is probably unrelated to the traffic stall with green status.

Do the packet counts in ifconfig increase while you are running ping in this state?

by pakyr, 2 years ago

Attachment: syslog.4 added

NetworkStatus stayed green; ping did not work; packets sent increased but packets recieved did not

by pakyr, 2 years ago

Attachment: ifconfig.3 added

comment:9 by waddlesplash, 2 years ago

Please try disconnecting via ifconfig <interface> leave <network> and see if you can reconnect after that.

If you can't, do you have the time/ability to test on OpenBSD? (You can install OpenBSD to USB drives just like Haiku.) You'll have to run fw_update iwm to get the firmware on OpenBSD however, it doesn't come with the base system like it does on Haiku.)

comment:10 by waddlesplash, 2 years ago

Strangely enough, I can now reproduce this. I hadn't seen it at all before, but now it seems to happen rather consistently. Very strange.

comment:11 by waddlesplash, 2 years ago

Blocked By: 17820 added

This is definitely related to #17820. Sometimes I get this, sometimes I get the other.

comment:12 by pakyr, 2 years ago

After disconnecting like that, I was able to reconnect to the network, and NetworkStatus showed green again, but the connection still wouldn't work. Regarding BSD, I could when I have time, but that might not be for a bit.

Last edited 2 years ago by pakyr (previous) (diff)

comment:13 by waddlesplash, 2 years ago

Blocking: 17823 added

comment:14 by vidrep, 2 years ago

Check that you these two things:

Keyring notification (see screenshot 2)

Gateway: (see screenshot3)

by vidrep, 2 years ago

Attachment: screenshot2.png added

by vidrep, 2 years ago

Attachment: screenshot3.png added

comment:15 by waddlesplash, 2 years ago

Please retest after hrev56258; it may fix this.

comment:16 by pakyr, 2 years ago

Difficulties establishing a connection still remain, but once I have one going it seems reliable as of hrev56261 (in my limited testing). Since the issues around establishing a connection seem to be covered by other tickets, this one can probably be closed; I will comment again if the issues resurface.

Edit: I stand somewhat corrected; I have yet to reencounter any of those 'stalls' where the status stays green but the connection stops working; I have though had it drop the connection (checkmark still next to the ssid name in NetworkStatus, but the status goes yellow and says 'No link'). Definitely far less frequent though.

Last edited 2 years ago by pakyr (previous) (diff)

comment:17 by waddlesplash, 2 years ago

Milestone: UnscheduledR1/beta4
Resolution: fixed
Status: newclosed

Dropping the connection may still be AP misbehavior. As long as it doesn't stall, let's consider this one fixed indeed.

Note: See TracTickets for help on using tickets.