#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 23 months ago.
In this case, the connection stopped working after a bit under 15 minutes, as described previously
ifconfig (1.1 KB ) - added by pakyr 23 months ago.
ifconfig output after connection stopped working
syslog.2 (212.6 KB ) - added by pakyr 23 months 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 23 months 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 23 months ago.
syslog.4 (148.0 KB ) - added by pakyr 23 months ago.
NetworkStatus stayed green; ping did not work; packets sent increased but packets recieved did not
ifconfig.3 (1.1 KB ) - added by pakyr 23 months ago.
screenshot2.png (17.2 KB ) - added by vidrep 22 months ago.
screenshot3.png (38.8 KB ) - added by vidrep 22 months ago.

Download all attachments as: .zip

Change History (26)

comment:1 by pakyr, 23 months ago

Description: modified (diff)

comment:2 by waddlesplash, 23 months 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, 23 months ago

Attachment: syslog added

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

by pakyr, 23 months ago

Attachment: ifconfig added

ifconfig output after connection stopped working

comment:3 by waddlesplash, 23 months 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, 23 months 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, 23 months 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, 23 months ago

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

by pakyr, 23 months 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, 23 months ago

Attachment: ifconfig.2 added

comment:6 by waddlesplash, 23 months 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, 23 months 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, 23 months 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, 23 months ago

Attachment: syslog.4 added

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

by pakyr, 23 months ago

Attachment: ifconfig.3 added

comment:9 by waddlesplash, 23 months 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, 22 months 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, 22 months ago

Blocked By: 17820 added

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

comment:12 by pakyr, 22 months 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 22 months ago by pakyr (previous) (diff)

comment:13 by waddlesplash, 22 months ago

Blocking: 17823 added

comment:14 by vidrep, 22 months ago

Check that you these two things:

Keyring notification (see screenshot 2)

Gateway: (see screenshot3)

by vidrep, 22 months ago

Attachment: screenshot2.png added

by vidrep, 22 months ago

Attachment: screenshot3.png added

comment:15 by waddlesplash, 22 months ago

Please retest after hrev56258; it may fix this.

comment:16 by pakyr, 22 months 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 22 months ago by pakyr (previous) (diff)

comment:17 by waddlesplash, 22 months 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.