Re: [PATCH] Ad-hoc channels: patches respin



On Thu, 2010-05-06 at 14:56 +0200, Jirka Klimes wrote:
> Hello,
> 
> The two patches in this mail obsolete previous patches.
> 
> The main change is moving band/channels stuff to libnm-util. It is used
> on many places and it thus deserves to be common code.

A few comments here...

> patch 1:
> Band/channel stuff in libnm-utils and its adjusting its usage in nm-wifi-ap.c

1) lets use "nm_utils_wifi_*" for the function names since they are clearly wifi specific.

2) for nm_utils_find_next_channel() can you describe the @direction
argument a bit more?  Something like:

@direction: whether going downward (0 or less) or upward (1 or more)

> patch2 :
> Allow ad-hoc connections using band/channel - reworked the previous patch to 
> use new libnm-util code.
> And one addition: when switched to infrastructure, band and channels are set 
> to automatic. (Because compatible checking has been enhanced to compare 
> channels too.)

For now, lets desensitize the band/channel widgets in the editor when in
infrastructure mode since the supplicant isn't capable of using those
values yet.  Have to get around to patching the supplicant.

> Jirka
> 
> PS:
> Dan,
> There are some explicit channels in nm-device-wifi.c:build_supplicant_config for 
> ad-hoc connections.
> Is it intentional to use just these channels?

The intention here was to only choose non-overlapping channels (1, 6, 11
and 13) when automatically picking a channel.  WiFi channels overlap
since the channel bandwidth is 20MHz, but the channels are only
separated by 5Mhz.  Putting an AP on channel 2 when something is already
on channel 1 just increases interference for both since they have a
15MHz overlap.

The 13 is there (even though it overlaps with 11) to ensure that France
or Japan (I forget which) got a valid channel since previously most of
the 802.11bg band was illegal in one of those countries.

Thanks!
Dan




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]