Bug 438813
Summary: | iwl4965 unreliable connecting to LEAP | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Traxtopel <traxtopel> | ||||
Component: | kernel | Assignee: | John W. Linville <linville> | ||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | low | ||||||
Version: | 8 | CC: | dcbw, dzickus, grgustaf, jrb, kernel-maint, walicki | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | i386 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | 2.6.25.6-55.fc9 | Doc Type: | Bug Fix | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2008-06-23 19:24:05 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Traxtopel
2008-03-25 13:03:46 UTC
Can you recreate this issue with the F9 kernels here? http://koji.fedoraproject.org/koji/buildinfo?buildID=49743 Latest compat-wireless-20080603 on fc9 works. See log in https://bugzilla.redhat.com/show_bug.cgi?id=431894 Can these updated drivers be added to you el5 jwl kernel, please. Did you try the kernels from comment 1? It normally doesn't make a lot of sense to run the compat-wireless stuff on Fedora, because the latest Koji kernels will generally have the same code as in compate-wireles... Also, it would probably be best to keep discussion of el5 to bug 431894 as this is a fedora bug. John, I will download the fc9 koji kernels and test, I'll see if I can between which kernels the code changed, does that sound ok? Yes, that sounds very helpful...thanks! John, tested 2.6.25-10.fc9, it associates but hangs there and almost never authenticates. tested 2.6.25-3-18.fc9, it associates but hangs there and almost never authenticates. tested 2.6.25.4.29.fc9, this works. Associates and I can authenticate (I noticed there were changes made to the wireless code in 2.6.25.4.26.fc9, however this kernel is not available hence 2.6.25.4.29.fc9) Also latest kernel 2.6.25.4.40.fc9 works every time. I do not see any other kernels out there to try, does this narrow it down enough for you? If not point me to a specific fc9 kernel version and I will test. Thanks. Created attachment 308466 [details]
wireless-2_6_25_4-26_fc9.shortlog
Shortlog of wireless changes between 2.6.25.3-18.fc9 and
2.6.25.4-26.fc9...unfortunately, not short enough to be immediately helpful...
John, took a different approach, went back to compat-wireless tarballs. Something changed in April ... 2008-04-07 - does not connect 2008-04-26 - connects There are no tarballs available in between these dates. In those 19 days there are more than 4000 line changes to the iwlwifi directory alone. The snapshots do not seem to download from gitweb. Do you have any other pointers how I can checkout archives in between those dates. Just trying to narrow it down. Ignore compat-wireless tarballs test. Do you have the individual patches mentioned in the wireless-2_6_25_4-26_fc9.shortlog I can try to apply/compile them individually(if possible). You sure you want to do that? :-) The individual patches are all in wireless-testing tree (available through git): git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git You'll have to use git-log to find the patch from its entry in the short log, then git-show based on each patch's commit ID. Good luck! You must be really motivated... :-) To be honest I do not want to, if the patch is something trivial(big doubt), then I can use it to create an updated module for my el5.2 t61 wireless users. It's fixed upstream, when can I hope to see the fix in your jwl test el5.2 kernels? Those kernels already have wireless bit up-to-date with 2.6.25. Since 2.6.26 is not released, I currently have no plans to move them forward from there unless I identify specific fixes. One thing that is curious, using the same version of wpa_supplicant. I do see one difference. In the case it fails, it sends my "identity" before "EAPOL: startWhen --> 0" starts. Could this be the problem. I repeated this multiple times, everytime I see the same results. I will call it bad code/good code(bad naming but makes it clear) i.e. #Bad Code# Associates Sends Identity starts "EAPOL: startWhen --> 0" #Good Code# Associates starts "EAPOL: startWhen --> 0" Sends Identity ################################################################ #Bad code# Setting authentication timeout: 70 sec 0 usec EAPOL: Received EAP-Packet frame EAPOL: SUPP_PAE entering state RESTART EAP: EAP entering state INITIALIZE EAP: EAP entering state IDLE EAPOL: SUPP_PAE entering state AUTHENTICATING EAPOL: SUPP_BE entering state REQUEST EAPOL: getSuppRsp EAP: EAP entering state RECEIVED EAP: Received EAP-Request id=1 method=1 vendor=0 vendorMethod=0 EAP: EAP entering state IDENTITY CTRL-EVENT-EAP-STARTED EAP authentication started EAP: EAP-Request Identity data - hexdump_ascii(len=42): 00 6e 65 74 77 6f 72 6b 69 64 3d 49 42 4d 2c 6e _networkid=IBM,n 61 73 69 64 3d 72 63 78 2d 61 70 2d 30 35 31 2d asid=rcx-ap-051- 31 2c 70 6f 72 74 69 64 3d 30 1,portid=0 EAP: using real identity - hexdump_ascii(len=27): 67 72 61 6e 74 5f 77 69 6c 6c 69 61 6d 73 6f 6e grant_williamson 40 6e 6c 2e 69 62 6d 2e 63 6f 6d @nl.ibm.com EAP: EAP entering state SEND_RESPONSE EAP: EAP entering state IDLE EAPOL: SUPP_BE entering state RESPONSE EAPOL: txSuppRsp TX EAPOL: dst=00:0e:83:60:04:70 TX EAPOL - hexdump(len=36): 01 00 00 20 02 01 00 20 01 67 72 61 6e 74 5f 77 69 6c 6c 69 61 6d 73 6f 6e 40 6e 6c 2e 69 62 6d 2e 63 6f 6d EAPOL: SUPP_BE entering state RECEIVE EAPOL: startWhen --> 0 ################################################################ Where as using the newer modules. ################################################################ # Good Code # Setting authentication timeout: 70 sec 0 usec EAPOL: Received EAP-Packet frame EAPOL: SUPP_PAE entering state RESTART EAP: EAP entering state INITIALIZE EAP: EAP entering state IDLE EAPOL: SUPP_PAE entering state AUTHENTICATING EAPOL: SUPP_BE entering state REQUEST EAPOL: getSuppRsp EAP: EAP entering state RECEIVED EAP: Received EAP-Request id=2 method=1 vendor=0 vendorMethod=0 EAP: EAP entering state IDENTITY CTRL-EVENT-EAP-STARTED EAP authentication started EAP: EAP-Request Identity data - hexdump_ascii(len=42): 00 6e 65 74 77 6f 72 6b 69 64 3d 49 42 4d 2c 6e _networkid=IBM,n 61 73 69 64 3d 72 63 78 2d 61 70 2d 30 34 74 2d asid=rcx-ap-04t- 31 2c 70 6f 72 74 69 64 3d 30 1,portid=0 EAP: using real identity - hexdump_ascii(len=27): 67 72 61 6e 74 5f 77 69 6c 6c 69 61 6d 73 6f 6e grant_williamson 40 6e 6c 2e 69 62 6d 2e 63 6f 6d @nl.ibm.com EAP: EAP entering state SEND_RESPONSE EAP: EAP entering state IDLE EAPOL: SUPP_BE entering state RESPONSE EAPOL: txSuppRsp TX EAPOL: dst=00:0e:83:39:a6:80 ################################################################ Wrong paste, these are the correct logs #Bad Modules# Setting authentication timeout: 70 sec 0 usec EAPOL: Received EAP-Packet frame EAPOL: SUPP_PAE entering state RESTART EAP: EAP entering state INITIALIZE EAP: EAP entering state IDLE EAPOL: SUPP_PAE entering state AUTHENTICATING EAPOL: SUPP_BE entering state REQUEST EAPOL: getSuppRsp EAP: EAP entering state RECEIVED EAP: Received EAP-Request id=1 method=1 vendor=0 vendorMethod=0 EAP: EAP entering state IDENTITY CTRL-EVENT-EAP-STARTED EAP authentication started EAP: EAP-Request Identity data - hexdump_ascii(len=42): 00 6e 65 74 77 6f 72 6b 69 64 3d 49 42 4d 2c 6e _networkid=IBM,n 61 73 69 64 3d 72 63 78 2d 61 70 2d 30 35 31 2d asid=rcx-ap-051- 31 2c 70 6f 72 74 69 64 3d 30 1,portid=0 EAP: using real identity - hexdump_ascii(len=27): 67 72 61 6e 74 5f 77 69 6c 6c 69 61 6d 73 6f 6e grant_williamson 40 6e 6c 2e 69 62 6d 2e 63 6f 6d @nl.ibm.com EAP: EAP entering state SEND_RESPONSE EAP: EAP entering state IDLE EAPOL: SUPP_BE entering state RESPONSE EAPOL: txSuppRsp TX EAPOL: dst=00:0e:83:60:04:70 TX EAPOL - hexdump(len=36): 01 00 00 20 02 01 00 20 01 67 72 61 6e 74 5f 77 69 6c 6c 69 61 6d 73 6f 6e 40 6e 6c 2e 69 62 6d 2e 63 6f 6d EAPOL: SUPP_BE entering state RECEIVE EAPOL: startWhen --> 0 #Good Modules# EAPOL: startWhen --> 0 EAPOL: SUPP_PAE entering state CONNECTING EAPOL: txStart TX EAPOL: dst=00:0e:83:39:a6:80 TX EAPOL - hexdump(len=4): 01 01 00 00 RX EAPOL from 00:0e:83:39:a6:80 RX EAPOL - hexdump(len=51): 01 00 00 2f 01 02 00 2f 01 00 6e 65 74 77 6f 72 6b 69 64 3d 49 42 4d 2c 6e 61 73 69 64 3d 72 63 78 2d 61 70 2d 30 34 74 2d 31 2c 70 6f 72 74 69 64 3d 30 Setting authentication timeout: 70 sec 0 usec EAPOL: Received EAP-Packet frame EAPOL: SUPP_PAE entering state RESTART EAP: EAP entering state INITIALIZE EAP: EAP entering state IDLE EAPOL: SUPP_PAE entering state AUTHENTICATING EAPOL: SUPP_BE entering state REQUEST EAPOL: getSuppRsp EAP: EAP entering state RECEIVED EAP: Received EAP-Request id=2 method=1 vendor=0 vendorMethod=0 EAP: EAP entering state IDENTITY CTRL-EVENT-EAP-STARTED EAP authentication started EAP: EAP-Request Identity data - hexdump_ascii(len=42): 00 6e 65 74 77 6f 72 6b 69 64 3d 49 42 4d 2c 6e _networkid=IBM,n 61 73 69 64 3d 72 63 78 2d 61 70 2d 30 34 74 2d asid=rcx-ap-04t- 31 2c 70 6f 72 74 69 64 3d 30 1,portid=0 EAP: using real identity - hexdump_ascii(len=27): 67 72 61 6e 74 5f 77 69 6c 6c 69 61 6d 73 6f 6e grant_williamson 40 6e 6c 2e 69 62 6d 2e 63 6f 6d @nl.ibm.com EAP: EAP entering state SEND_RESPONSE EAP: EAP entering state IDLE EAPOL: SUPP_BE entering state RESPONSE EAPOL: txSuppRsp Dan, you are much better at interpreting wpa_supplicant trances than I am...? The latest kernel 2.6.25.6-55.fc9 works. Connects everytime. This bug for fc9 can be closed, will continue on el5 bug report. |