Bug 802386

Summary: 802.11a channels are changed in "ZZJ"
Product: [Fedora] Fedora Reporter: ANEZAKI, Akira <fireblade1230>
Component: kernelAssignee: Stanislaw Gruszka <sgruszka>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 16CC: gansalmon, itamar, jonathan, kernel-maint, linville, madhu.chinakonda
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-03-13 21:51:28 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
This patch enables connect with both of old and new access points in Japan("ZZJ"). none

Description ANEZAKI, Akira 2012-03-12 12:47:53 UTC
Created attachment 569379 [details]
This patch enables connect with both of old and new access points in Japan("ZZJ").

Description of problem:
Centrino(ipw2200) cannot connect to 802.11a access points those are sold in Japan now.
ipw2200.c is coded with very old 802.11a channels but current access points use different channels in Japan ("ZZJ").

Version-Release number of selected component (if applicable):
All kernel versions those include ipw2200.c.

How reproducible:

Steps to Reproduce:
1.Try to access 802.11a AP with centrino/ipw2200 driver.
Old 802.11a AP is rare so that you cannot find any access points.

Actual results:
Cannot find any access points. It can find only very old access points.

Expected results:
Find access point and connect it.

Comment 1 Josh Boyer 2012-03-12 14:09:37 UTC
Stanislaw, John: I know ipw2200 is abandoned upstream, but does the attached patch make sense?

Comment 2 ANEZAKI, Akira 2012-03-12 14:25:43 UTC
(In reply to comment #1)
> Stanislaw, John: I know ipw2200 is abandoned upstream, but does the attached
> patch make sense?

At least, ipw2200.c is still included as linux-3.[1-3].*/drivers/net/wireless/ipw2x00/ipw2200.c

Comment 3 John W. Linville 2012-03-12 15:36:38 UTC
From a technical perspective (i.e. does it "work"), the patch seems OK.  But the fact remains that the ipw2200 hardware was not certified to work with those frequencies.  I cannot support taking that patch due to the possible legal implications as I understand them.

Patches to fully convert ipw2x00 to use the regulatory infrastructure under the net/wireless directory would be a most welcome alternative.  However, I still cannot guarantee that patches to expand the channels available for these specific devices would be acceptable upstream.

Comment 4 ANEZAKI, Akira 2012-03-12 16:58:00 UTC
(In reply to comment #3)

Thank you for your quick response. As you described, I understand there is a legal issue. ( Of course Windows has been approved. ) 

I withdraw this patch.

Thank you for your supports.

PS.
For your information, some channels ( from 124 to 140 ) are rejected by chip [2945ABG] but most of them works.

Comment 5 ANEZAKI, Akira 2012-03-12 19:55:40 UTC
(In reply to comment #4)

> PS.
> For your information, some channels ( from 124 to 140 ) are rejected by chip
> [2945ABG] but most of them works.

I set AP with channel 136 and 2945ABG could connect with it.
I thought that some channels were rejected because iwlist doesn't display channels from 124 to 140, but it may be limitation of iwlist.

Of course, ipw2200.c should be patched. Or no 802.11a AP can be connected.

Comment 6 Stanislaw Gruszka 2012-03-13 21:51:28 UTC
Akira,

Thanks for your patch. However as John already pointed out, the best possible fix for the issue is converting ipw2x00 driver to use linux regulatory infrastructure (http://linuxwireless.org/en/developers/Regulatory). I do not have time/interest to write such patch. If you want to write such patch you are welcome. Please then submit it to linux-wireless mailing list according to http://linuxwireless.org/en/developers/Documentation/SubmittingPatches . Thanks.

I'm closing bug with upstream resolution since proper work should be done upstream before we could add patch to Fedora.