Currently the frequencies (5910 - 5980) cannot be used because they
are mapped into the 4.9GHz channels; this patch closes that hole.
Signed-off-by: Dennis H Jensen <[email protected]>
---
net/wireless/util.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/wireless/util.c b/net/wireless/util.c
index 3c8be61..59b763f 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -79,6 +79,8 @@ int ieee80211_channel_to_frequency(int chan, enum ieee80211_band band)
case IEEE80211_BAND_5GHZ:
if (chan >= 182 && chan <= 196)
return 4000 + chan * 5;
+ else if (chan > 196)
+ return 5000 + (chan - 15) * 5;
else
return 5000 + chan * 5;
break;
@@ -102,6 +104,8 @@ int ieee80211_frequency_to_channel(int freq)
return (freq - 2407) / 5;
else if (freq >= 4910 && freq <= 4980)
return (freq - 4000) / 5;
+ else if (freq >= 5910)
+ return (freq - 5000) / 5 + 15;
else if (freq <= 45000) /* DMG band lower limit */
return (freq - 5000) / 5;
else if (freq >= 58320 && freq <= 64800)
--
1.7.9.5
On Fri, 2013-10-11 at 13:59 +0200, Dennis H Jensen wrote:
> Currently the frequencies (5910 - 5980) cannot be used because they
> are mapped into the 4.9GHz channels; this patch closes that hole.
> @@ -79,6 +79,8 @@ int ieee80211_channel_to_frequency(int chan, enum ieee80211_band band)
> case IEEE80211_BAND_5GHZ:
> if (chan >= 182 && chan <= 196)
> return 4000 + chan * 5;
> + else if (chan > 196)
> + return 5000 + (chan - 15) * 5;
Where does the +/- 15 come from? I can't find any evidence for this in
Annex E.
johannes
On Tue, 2013-10-15 at 11:40 +0200, Dennis H Jensen wrote:
> > Yes, but then before 5910 would have been channel 182. Now you're making
> > it channel 197. That doesn't really make sense at all.
>
> OK, fair enough, but the fact is that there is a hole in the frequencies
> that were added in 802.11p.
802.11p ... yeah, that's an issue.
> > > In case that doesn't do it. What is needed to get channel 182 to be 5910
> > > MHz as Annex E defines for the US and Europe? Channel to frequency
> > > mapping based on operating class?
> >
> > Annex E is the 802.11 spec, to get something into that ...
>
> You misunderstood me; the European operating class 14, for example,
> states that channel 182 is to be 5910.
That's a 10MHz channel only.
In any case, I don't see a good way out. Pretending that the channel
number is something else like you did in this patch is clearly wrong and
will obviously lead to interoperability issues.
I think we need to actually start taking the operating class (or maybe
just the starting frequency) into account in the kernel. How we do that
I don't really know.
johannes
On Fri, 2013-10-11 at 15:56 +0200, Johannes Berg wrote:
> On Fri, 2013-10-11 at 13:59 +0200, Dennis H Jensen wrote:
> > Currently the frequencies (5910 - 5980) cannot be used because they
> > are mapped into the 4.9GHz channels; this patch closes that hole.
>
> > @@ -79,6 +79,8 @@ int ieee80211_channel_to_frequency(int chan, enum ieee80211_band band)
> > case IEEE80211_BAND_5GHZ:
> > if (chan >= 182 && chan <= 196)
> > return 4000 + chan * 5;
> > + else if (chan > 196)
> > + return 5000 + (chan - 15) * 5;
>
> Where does the +/- 15 come from? I can't find any evidence for this in
> Annex E.
I didn't double check Annex E. I just wanted to recover the lost
frequencies that the 15 channels (182 - 196), map into 4.9 GHz.
//Dennis
On Mon, 2013-10-14 at 16:02 +0200, Johannes Berg wrote:
> On Mon, 2013-10-14 at 14:16 +0200, Dennis H Jensen wrote:
> > On Mon, 2013-10-14 at 14:02 +0200, Johannes Berg wrote:
> > > On Fri, 2013-10-11 at 17:45 +0200, Dennis H Jensen wrote:
> > >
> > > > > > + else if (chan > 196)
> > > > > > + return 5000 + (chan - 15) * 5;
> > > > >
> > > > > Where does the +/- 15 come from? I can't find any evidence for this in
> > > > > Annex E.
> > > >
> > > > I didn't double check Annex E. I just wanted to recover the lost
> > > > frequencies that the 15 channels (182 - 196), map into 4.9 GHz.
> > >
> > > "Recover"? When did they work? What broke them?
> >
> > The commit 59eb21a6504731fc16db4cf9463065dd61093e08 moved those channels
> > to 4.9 GHz but left a hole in the 5.9 Ghz range.
>
> But there was no +/- 15 before, so what gives?
Well no :) but there also wasn't a special case for that particular
channel set (182 - 196).
So now, when you configure the frequency 5910, it is mapped to channel
182 which is mapped back to 4910 and nothing works, at least let the
functions be the inverse of the other.
In case that doesn't do it. What is needed to get channel 182 to be 5910
MHz as Annex E defines for the US and Europe? Channel to frequency
mapping based on operating class?
//Dennis
On Fri, 2013-10-11 at 17:45 +0200, Dennis H Jensen wrote:
> > > + else if (chan > 196)
> > > + return 5000 + (chan - 15) * 5;
> >
> > Where does the +/- 15 come from? I can't find any evidence for this in
> > Annex E.
>
> I didn't double check Annex E. I just wanted to recover the lost
> frequencies that the 15 channels (182 - 196), map into 4.9 GHz.
"Recover"? When did they work? What broke them?
johannes
On Mon, 2013-10-14 at 17:06 +0200, Johannes Berg wrote:
> On Mon, 2013-10-14 at 16:58 +0200, Dennis H Jensen wrote:
>
> > > > The commit 59eb21a6504731fc16db4cf9463065dd61093e08 moved those channels
> > > > to 4.9 GHz but left a hole in the 5.9 Ghz range.
> > >
> > > But there was no +/- 15 before, so what gives?
> >
> > Well no :) but there also wasn't a special case for that particular
> > channel set (182 - 196).
>
> Yes, but then before 5910 would have been channel 182. Now you're making
> it channel 197. That doesn't really make sense at all.
OK, fair enough, but the fact is that there is a hole in the frequencies
that were added in 802.11p.
> > In case that doesn't do it. What is needed to get channel 182 to be 5910
> > MHz as Annex E defines for the US and Europe? Channel to frequency
> > mapping based on operating class?
>
> Annex E is the 802.11 spec, to get something into that ...
You misunderstood me; the European operating class 14, for example,
states that channel 182 is to be 5910.
Best regards,
Dennis
On Mon, 2013-10-14 at 14:16 +0200, Dennis H Jensen wrote:
> On Mon, 2013-10-14 at 14:02 +0200, Johannes Berg wrote:
> > On Fri, 2013-10-11 at 17:45 +0200, Dennis H Jensen wrote:
> >
> > > > > + else if (chan > 196)
> > > > > + return 5000 + (chan - 15) * 5;
> > > >
> > > > Where does the +/- 15 come from? I can't find any evidence for this in
> > > > Annex E.
> > >
> > > I didn't double check Annex E. I just wanted to recover the lost
> > > frequencies that the 15 channels (182 - 196), map into 4.9 GHz.
> >
> > "Recover"? When did they work? What broke them?
>
> The commit 59eb21a6504731fc16db4cf9463065dd61093e08 moved those channels
> to 4.9 GHz but left a hole in the 5.9 Ghz range.
But there was no +/- 15 before, so what gives?
johannes
On Mon, 2013-10-14 at 16:58 +0200, Dennis H Jensen wrote:
> > > The commit 59eb21a6504731fc16db4cf9463065dd61093e08 moved those channels
> > > to 4.9 GHz but left a hole in the 5.9 Ghz range.
> >
> > But there was no +/- 15 before, so what gives?
>
> Well no :) but there also wasn't a special case for that particular
> channel set (182 - 196).
Yes, but then before 5910 would have been channel 182. Now you're making
it channel 197. That doesn't really make sense at all.
> So now, when you configure the frequency 5910, it is mapped to channel
> 182 which is mapped back to 4910 and nothing works, at least let the
> functions be the inverse of the other.
>
> In case that doesn't do it. What is needed to get channel 182 to be 5910
> MHz as Annex E defines for the US and Europe? Channel to frequency
> mapping based on operating class?
Annex E is the 802.11 spec, to get something into that ...
johannes
On Mon, 2013-10-14 at 14:02 +0200, Johannes Berg wrote:
> On Fri, 2013-10-11 at 17:45 +0200, Dennis H Jensen wrote:
>
> > > > + else if (chan > 196)
> > > > + return 5000 + (chan - 15) * 5;
> > >
> > > Where does the +/- 15 come from? I can't find any evidence for this in
> > > Annex E.
> >
> > I didn't double check Annex E. I just wanted to recover the lost
> > frequencies that the 15 channels (182 - 196), map into 4.9 GHz.
>
> "Recover"? When did they work? What broke them?
The commit 59eb21a6504731fc16db4cf9463065dd61093e08 moved those channels
to 4.9 GHz but left a hole in the 5.9 Ghz range.
//Dennis