Modify

Opened 7 years ago

Closed 7 years ago

#1170 closed bug (cannotreproduce)

Driver does not autoselect AES in n-only mode

Reported by: bright_plastik Owned by:
Priority: normal Milestone: Firmware 2.3.7.0
Component: fon-wifi Version: 2.3.7.0 beta2
Severity: unknown
Cc: Hardware: 2.0n (FON2300)

Description

Hello, since the upgrade to the dev 2.3.7.0 beta 2 firmware my connection is stuck at 54mbps. I even completely disabled the G mode, leaving the Fonera deal with HT20/HT40 N mode.

Even doing this, every sniffer I used (see Cain, for example) recognizes the connection running on G mode, like if it was only pretending to operate in N mode.

Are you sure you implemented correctly the N protocol?

I thought it was a virtually clean release, without major (at least for me) bugs, but considering my problem, it is quite useless, if my observation came to be true. The fonera would end up being a very nice piece of retrogarde.

Can you double check? or point me n the right direction, if I'm wrong?

Attachments (0)

Change History (7)

comment:1 Changed 7 years ago by matthijs

  • Status changed from new to infoneeded

Did you perhaps select TKIP instead of AES? By the 802.11n spec, N speeds cannot be used with TKIP encryption, only with AES.

Also note that the wifi driver in the beta1 and beta2 releases are known to have some stability issues, which are expected to be fixed in the beta3 release.

comment:2 Changed 7 years ago by bright_plastik

Hello, thanks for the help.

At the moment, I succesfully managed to return to the N speed rates, but one thing was missing, when you pointed me to the AES encryption.

I noticed if you select just "N mode", instead of "G+N mode" or whatever other mode, the menus of encryption methods just desappears. This means if someone wants just the "N mode" will not be able to toggle between different encryptions, and won't be neither aware of what will be the default one, selected by system. It is only possible from "G+N mode" downward.

I don't know if this is meant to be, and wanted. Anyway I solved my problem, but there seem to be anyhow some flows in the wireless configuration page.

I thank you very much, totally satisfied with the response times, and hope to be usefull with my observations to the future releases.

Regards, Gabriel

comment:3 Changed 7 years ago by matthijs

  • Milestone set to Firmware 2.3.7.0
  • Severity changed from unknown to minor
  • Status changed from infoneeded to confirmed
  • Summary changed from ghost 300mbps connection on FON2300 to Driver does not autoselect AES in n-only mode

Ah, it seems there is an oversight in the web interface: If you select "n-only", the AES/TKIP choice disappears (which is intended, since TKIP does not make sense in n-only mode). However, the driver apparently does not automatically select AES in this case, resulting in low speeds.

I'll have a look at automatically selecting AES in n-only mode.

Thanks for your detailed report and followup!

comment:4 Changed 7 years ago by matthijs

  • Severity changed from minor to unknown
  • Status changed from confirmed to investigate

Apparently it is more complicated than that: The driver script _does_ already select AES in the n-only case (see trunk/fon/ra_wifi/files/lib/wifi/rt3052.sh#L206). I could also no long reproduce this behaviour, but I think I did see one or two cases where simply switching from AES to TKIP did not work. I suspect this might be the real problem here, but it's probably some kind of race condition that makes this behaviour show up only in very specific cases. I considered that fact that ConfigFON and ConfigWifi? might be ran at the same time, so ConfiWifi?/rt3052.sh would read the old values, but it seems fonstated really runs the queued scripts sequentially, so that doesn't seem to be it...

comment:5 Changed 7 years ago by bright_plastik

Ehhmmm. Sorry, but I can't follow you. Dunno if it's me, with random brain connections, or the case, which also seems a bit too random.

I can nevertheless confirm that I wasn't running two different istances of the config page.

Can you confirm me you successfully set the N mode only with AES encryption?

Just another random connection:

Did you consider it might be a sort of imposed autonegotiation with other subnetworks?

I have a SAMBA network, for example, linked with a bare linux ethernet NAS. Nothing to do with wireless, but who knows. Communication conditions, maybe.

Doh. I'm too superficial to propose solutions, but that's my € 0.2 cents.

Waiting for a quantum leap toward its potential,

Gabriel

comment:6 Changed 7 years ago by matthijs

Reading back my own comment, it does seem a little dense with information, I'm not sure if I still follow myself there :-)

In any case, IIRC I did get my Fonera to run in n-only mode with AES encryption (and thus high speeds) in a few tests, but not in others. In other words, there is something else involved other than the actual settings (some kind of timing issue probably).

I'll have to dive deeper into this in an attempt to really find the cause for this, but I'm working on some other more obvious bugs first :-)

As for your suggestion about autonegotiation, I don't expect the cause to be in another (wired) network, given the way networking stacks are built.

In the meanwhile, did you get a chance to try the beta3 release? Is this issue still occuring for you or did you find a workaround?

comment:7 Changed 7 years ago by matthijs

  • Resolution set to cannotreproduce
  • Status changed from investigate to closed

I just had another try at reproducing this, but now it works every time. I tried switching from n-only back and forth to bgn, b-only, gn, etc, with WPS enabled and disabled, with WPA, WPA2 and WPA1/WPA2 selected, but I got the expected result everytime (checked using iwlist scan output, which shows "TKIP" or "CCMP" (~= AES).

I also tried associating few times and iwconfig reports bitrates over 54M as well.

So, either this was fixed by some other recent change (r2195 perhaps?), or this really occurs only very sporadically. In the latter case, it's hard for me to fix, in the former case, there's nothing to fix anymore.

For now, I'm closing this ticket. If this problem is still occurring for you, please leave a comment so we can further investigate.

Add Comment

Modify Ticket

Action
as closed The ticket will remain with no owner.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.