[Cerowrt-devel] treating 2.4ghz as -legacy?

[Cerowrt-devel] treating 2.4ghz as -legacy?

[Dave Taht]

I have long used "5" as an indicator that the 5ghz channel was better.
This goes back to a long thread on nanog, like 4? 5? years ago, where
the hope was to train users that "5" was better.

Well, it's turned out that 5 is frequently better, but not always, AND
that clients tend to go for the shortest of the SSIDs available. So a
thought would be to create another ad-hoc standard for deprecating 2.4
ghz, and have the shorter SSID be the 5ghz one.

Ideas for the 2ghz channel:

CEROwrt-legacy
CEROwrt2

I'm not huge on "legacy" because it's rather long but am stuck for
standards, I'd like a default 2.4 ghz SSID that clearly indicates the
real use to which 2.4ghz is suitable, like:
CEROwrt-GET-OFF-MY-BABY-MONITOR-YOU-FREAK

ideas for another ssid naming standard slightly longer than a single
digit that would make sense to mom?

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] treating 2.4ghz as -legacy?

[Sebastian Moeller]

Hi Dave,

On Dec 16, 2013, at 20:46 , Dave Taht <dave.taht@gmail.com> wrote:

> I have long used "5" as an indicator that the 5ghz channel was better.
> This goes back to a long thread on nanog, like 4? 5? years ago, where
> the hope was to train users that "5" was better.
> 
> Well, it's turned out that 5 is frequently better, but not always, AND
> that clients tend to go for the shortest of the SSIDs available. So a
> thought would be to create another ad-hoc standard for deprecating 2.4
> ghz, and have the shorter SSID be the 5ghz one.
> 
> Ideas for the 2ghz channel:
> 
> CEROwrt-legacy
> CEROwrt2
> 
> I'm not huge on "legacy" because it's rather long but am stuck for
> standards, I'd like a default 2.4 ghz SSID that clearly indicates the
> real use to which 2.4ghz is suitable, like:
> CEROwrt-GET-OFF-MY-BABY-MONITOR-YOU-FREAK
> 
> ideas for another ssid naming standard slightly longer than a single
> digit that would make sense to mom?

	While being not really for mom, I went for name_2.4GHz
and name_5GHz. Pretty clear, and the her name is shorter :)

best
	Sebastian

> 
> -- 
> Dave Täht
> 
> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] treating 2.4ghz as -legacy?

[Toke Høiland-Jørgensen]

[-- Attachment #1: Type: text/plain, Size: 273 bytes --]

Dave Taht <dave.taht@gmail.com> writes:

> ideas for another ssid naming standard slightly longer than a single
> digit that would make sense to mom?

-backup / -bak?

Also, many phones don't support 5ghz unfortunately, so it probably
shouldn't be too offputting...

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [Cerowrt-devel] treating 2.4ghz as -legacy?

[Kelvin Edmison]

[-- Attachment #1: Type: text/plain, Size: 1734 bytes --]

I believe that generally, users understand versions and speeds but not the
implications of certain frequencies.  So, rather than focusing on the
frequency I would throw these out there as suggestions: (even though the
nit-picker in me is cringing a bit)

For the 2.4GHz SSID:
- CEROwrt-old
- CEROwrt-slow

and just CEROwrt for the 5GHz SSID, with the intent that the the choice
offered to the users nudges them towards the better choice.

Cheers,
  Kelvin



On Mon, Dec 16, 2013 at 2:46 PM, Dave Taht <dave.taht@gmail.com> wrote:

> I have long used "5" as an indicator that the 5ghz channel was better.
> This goes back to a long thread on nanog, like 4? 5? years ago, where
> the hope was to train users that "5" was better.
>
> Well, it's turned out that 5 is frequently better, but not always, AND
> that clients tend to go for the shortest of the SSIDs available. So a
> thought would be to create another ad-hoc standard for deprecating 2.4
> ghz, and have the shorter SSID be the 5ghz one.
>
> Ideas for the 2ghz channel:
>
> CEROwrt-legacy
> CEROwrt2
>
> I'm not huge on "legacy" because it's rather long but am stuck for
> standards, I'd like a default 2.4 ghz SSID that clearly indicates the
> real use to which 2.4ghz is suitable, like:
> CEROwrt-GET-OFF-MY-BABY-MONITOR-YOU-FREAK
>
> ideas for another ssid naming standard slightly longer than a single
> digit that would make sense to mom?
>
> --
> Dave Täht
>
> Fixing bufferbloat with cerowrt:
> http://www.teklibre.com/cerowrt/subscribe.html
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>

[-- Attachment #2: Type: text/html, Size: 2515 bytes --]

Re: [Cerowrt-devel] treating 2.4ghz as -legacy?

[David Lang]

On Mon, 16 Dec 2013, Dave Taht wrote:

> I have long used "5" as an indicator that the 5ghz channel was better.
> This goes back to a long thread on nanog, like 4? 5? years ago, where
> the hope was to train users that "5" was better.
>
> Well, it's turned out that 5 is frequently better, but not always, AND
> that clients tend to go for the shortest of the SSIDs available. So a
> thought would be to create another ad-hoc standard for deprecating 2.4
> ghz, and have the shorter SSID be the 5ghz one.
>
> Ideas for the 2ghz channel:
>
> CEROwrt-legacy
> CEROwrt2
>
> I'm not huge on "legacy" because it's rather long but am stuck for
> standards, I'd like a default 2.4 ghz SSID that clearly indicates the
> real use to which 2.4ghz is suitable, like:
> CEROwrt-GET-OFF-MY-BABY-MONITOR-YOU-FREAK
>
> ideas for another ssid naming standard slightly longer than a single
> digit that would make sense to mom?

for the Scale conference this year, we are going to use scale and scale-slow to 
try and discourage people from using 2.4

David Lang

Re: [Cerowrt-devel] treating 2.4ghz as -legacy?

[Fred Stratton]

For best 5GHz results, get rid of your walls and doors...

http://www.theregister.co.uk/2011/09/14/virgin_media_superhub_update_modem_mode/


On 16/12/13 21:28, David Lang wrote:
> On Mon, 16 Dec 2013, Dave Taht wrote:
>
>> I have long used "5" as an indicator that the 5ghz channel was better.
>> This goes back to a long thread on nanog, like 4? 5? years ago, where
>> the hope was to train users that "5" was better.
>>
>> Well, it's turned out that 5 is frequently better, but not always, AND
>> that clients tend to go for the shortest of the SSIDs available. So a
>> thought would be to create another ad-hoc standard for deprecating 2.4
>> ghz, and have the shorter SSID be the 5ghz one.
>>
>> Ideas for the 2ghz channel:
>>
>> CEROwrt-legacy
>> CEROwrt2
>>
>> I'm not huge on "legacy" because it's rather long but am stuck for
>> standards, I'd like a default 2.4 ghz SSID that clearly indicates the
>> real use to which 2.4ghz is suitable, like:
>> CEROwrt-GET-OFF-MY-BABY-MONITOR-YOU-FREAK
>>
>> ideas for another ssid naming standard slightly longer than a single
>> digit that would make sense to mom?
>
> for the Scale conference this year, we are going to use scale and 
> scale-slow to try and discourage people from using 2.4
>
> David Lang
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] treating 2.4ghz as -legacy?

[Michael Richardson]

Fred Stratton <fredstratton@imap.cc> wrote:
    > For best 5GHz results, get rid of your walls and doors...

    > http://www.theregister.co.uk/2011/09/14/virgin_media_superhub_update_modem_mode/

Yeah, in my house, my experience with 5Ghz is that it means the network
doesn't work.

Re: [Cerowrt-devel] treating 2.4ghz as -legacy?

[Jim Gettys]

[-- Attachment #1: Type: text/plain, Size: 980 bytes --]

On Tue, Dec 17, 2013 at 12:54 PM, Michael Richardson <mcr@sandelman.ca>wrote:

>
> Fred Stratton <fredstratton@imap.cc> wrote:
>     > For best 5GHz results, get rid of your walls and doors...
>
>     >
> http://www.theregister.co.uk/2011/09/14/virgin_media_superhub_update_modem_mode/
>
> Yeah, in my house, my experience with 5Ghz is that it means the network
> doesn't work.
>

I sometimes have a similar situation in my house.  And I live in a radio
quiet area, so I don't face the usual tradeoff of polluted 2.4ghz.


But it does make it very hard to simply recommend 5 over 2.4ghz; there is
no single "right answer"; the answer is "it depends" for the simple one
router case.

And the right solution is more routers, and using 5ghz once you have them.

Sigh...
                          - Jim



>
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>

[-- Attachment #2: Type: text/html, Size: 2630 bytes --]

Re: [Cerowrt-devel] treating 2.4ghz as -legacy?

[dpreed]

[-- Attachment #1: Type: text/plain, Size: 2293 bytes --]


I know it will just trigger raging arguments, but it turns out that 5 GHz propagates far better in normal housing than does 2.4 GHz.
 
In particular, actual scientific measurements of penetration of wood, fiberboard, concrete, brick, etc. have been done, and I can provide many of them (they are on my computer at home, I am in CA at the moment).  The absorption of those materials is the same for both bands.
 
Second, the Fresnel zone is 1/4 the size for 5 GHz than 2.4 GHz.  This means that energy passes through holes far more intensely (6 dB better) on 5 GHz.
 
Finally, 5 GHz modulations used in WiFi do not include the really lousy 802.11b modulations that are required for beacon signals to have legacy compatibility back to the beginning of 802.11b.
 
Please don't repeat this urban legend.   Don't believe *anything* you read in The Register about EM waves, and don't believe computer scientists about electrical and electronic engineering.
 
In fact, 5 GHz, at the same power, is far superior for indoor signaling.
 


On Tuesday, December 17, 2013 1:51pm, "Jim Gettys" <jg@freedesktop.org> said:







On Tue, Dec 17, 2013 at 12:54 PM, Michael Richardson <[mailto:mcr@sandelman.ca] mcr@sandelman.ca> wrote:


 Fred Stratton <fredstratton@imap.cc> wrote:
 > For best 5GHz results, get rid of your walls and doors...

 > [http://www.theregister.co.uk/2011/09/14/virgin_media_superhub_update_modem_mode/] http://www.theregister.co.uk/2011/09/14/virgin_media_superhub_update_modem_mode/

Yeah, in my house, my experience with 5Ghz is that it means the network
 doesn't work.

I sometimes have a similar situation in my house.  And I live in a radio quiet area, so I don't face the usual tradeoff of polluted 2.4ghz.
But it does make it very hard to simply recommend 5 over 2.4ghz; there is no single "right answer"; the answer is "it depends" for the simple one router case.

And the right solution is more routers, and using 5ghz once you have them.
Sigh...
- Jim





 _______________________________________________
 Cerowrt-devel mailing list
[mailto:Cerowrt-devel@lists.bufferbloat.net] Cerowrt-devel@lists.bufferbloat.net
[https://lists.bufferbloat.net/listinfo/cerowrt-devel] https://lists.bufferbloat.net/listinfo/cerowrt-devel

[-- Attachment #2: Type: text/html, Size: 4060 bytes --]

Re: [Cerowrt-devel] treating 2.4ghz as -legacy?

[Jim Gettys]

[-- Attachment #1: Type: text/plain, Size: 2762 bytes --]

On Tue, Dec 17, 2013 at 5:25 PM, <dpreed@reed.com> wrote:

> I know it will just trigger raging arguments, but it turns out that 5 GHz
> propagates far better in normal housing than does 2.4 GHz.
>
>
>
> In particular, actual scientific measurements of penetration of wood,
> fiberboard, concrete, brick, etc. have been done, and I can provide many of
> them (they are on my computer at home, I am in CA at the moment).  The
> absorption of those materials is the same for both bands.
>
>
>
> Second, the Fresnel zone is 1/4 the size for 5 GHz than 2.4 GHz.  This
> means that energy passes through holes far more intensely (6 dB better) on
> 5 GHz.
>
>
>
> Finally, 5 GHz modulations used in WiFi do not include the really lousy
> 802.11b modulations that are required for beacon signals to have legacy
> compatibility back to the beginning of 802.11b.
>
>
>
> Please don't repeat this urban legend.   Don't believe *anything* you read
> in The Register about EM waves, and don't believe computer scientists about
> electrical and electronic engineering.
>
>
>
> In fact, 5 GHz, at the same power, is far superior for indoor signaling.
>

Dave,

I'm happy to believe you...

But then my personal observations of behavior of 2.4 vs. 5ghz need some
explanation...

Could be
   1) the antenna involved,
   2) or the transmit power is not the same.
   3) the system's reporting of signal strength is defective (but my
empirical observations of what works best has seemed to be correlated with
that).

I'm not likely to be able to do much about 1) (until we have different
routers to play with, anyway...)

How do we get to the bottom on 2) or 3)?
                             - Jim


>
>
>
>
> On Tuesday, December 17, 2013 1:51pm, "Jim Gettys" <jg@freedesktop.org>
> said:
>
>
>
> On Tue, Dec 17, 2013 at 12:54 PM, Michael Richardson <mcr@sandelman.ca>wrote:
>
>>
>> Fred Stratton <fredstratton@imap.cc> wrote:
>> > For best 5GHz results, get rid of your walls and doors...
>>
>> >
>> http://www.theregister.co.uk/2011/09/14/virgin_media_superhub_update_modem_mode/
>>
>> Yeah, in my house, my experience with 5Ghz is that it means the network
>> doesn't work.
>>
> I sometimes have a similar situation in my house.  And I live in a radio
> quiet area, so I don't face the usual tradeoff of polluted 2.4ghz.
> But it does make it very hard to simply recommend 5 over 2.4ghz; there is
> no single "right answer"; the answer is "it depends" for the simple one
> router case.
>  And the right solution is more routers, and using 5ghz once you have
> them.
>  Sigh...
> - Jim
>
>>
>>
>>
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>
>

[-- Attachment #2: Type: text/html, Size: 5787 bytes --]

Re: [Cerowrt-devel] treating 2.4ghz as -legacy?

[Stephen Hemminger]

I concur with Jim.

My observation is that in our house, upstairs the 5Ghz AP has low signal strength
reported by the devices, and poor bandwidth.

Could it be that the radiation pattern of the antenna in WDR3800 laying horizontally
is different for each band. Maybe the 5Ghz band is more of a squashed donut?

Re: [Cerowrt-devel] treating 2.4ghz as -legacy?

[Theodore Ts'o]

On Tue, Dec 17, 2013 at 03:43:45PM -0800, Stephen Hemminger wrote:
> I concur with Jim.
> 
> My observation is that in our house, upstairs the 5Ghz AP has low
> signal strength reported by the devices, and poor bandwidth.
> 
> Could it be that the radiation pattern of the antenna in WDR3800
> laying horizontally is different for each band. Maybe the 5Ghz band
> is more of a squashed donut?

I haven't done a careful study with the WNDR3800 running CeroWRT, but
with my previous dual-band AP's, where my AP is located in the attic
of my house, 5GHz works great on the 2nd floor, but on the first
floor, it's very spotty; it tends to depend on the quality of the
antenna (or WiFI chipset; that's not entirely clear) of the laptop or
mobile handset involved.  Some models show low signal strength on the
5GHz band; other models simply don't work at all on 5GHz.

So it may be an "urban legend" that 5GHz penetrates residential
housing materials more poorly than 2.4GHz radio waves, but all I can
tell you is that 5GHz is definitely much works much more poorly in my
house.  I don't know if it has to do with the antenna quality, or the
radio quality, at either the AP or the client, but it's definitely an
observable phenomena.  I'll have to program in the 5GHz SSID into some
of my devices that historically have completely failed to function on
5GHz when on the first floor of my house (but which work just fine on
the 2nd floor) to see if things are any better with CeroWRT running on
the WNDR3800.

I don't mind using multiple routers, if at some point CeroWRT were to
gain the advanced feature of talking to other routers and forcing a
disassociation when the signal strength talking to a particular client
gets significantly weaker than compared to the signal strength from
another AP.  Is there any special hardware support needed to do this
kind of AP-to-AP handoff, or is it just really complicated and no one
has bothered to do it in an open source implementation?

Cheers,

					- Ted

Re: [Cerowrt-devel] treating 2.4ghz as -legacy?

[David Lang]

On Tue, 17 Dec 2013, Theodore Ts'o wrote:

> On Tue, Dec 17, 2013 at 03:43:45PM -0800, Stephen Hemminger wrote:
>> I concur with Jim.
>>
>> My observation is that in our house, upstairs the 5Ghz AP has low
>> signal strength reported by the devices, and poor bandwidth.
>>
>> Could it be that the radiation pattern of the antenna in WDR3800
>> laying horizontally is different for each band. Maybe the 5Ghz band
>> is more of a squashed donut?
>
> I haven't done a careful study with the WNDR3800 running CeroWRT, but
> with my previous dual-band AP's, where my AP is located in the attic
> of my house, 5GHz works great on the 2nd floor, but on the first
> floor, it's very spotty; it tends to depend on the quality of the
> antenna (or WiFI chipset; that's not entirely clear) of the laptop or
> mobile handset involved.  Some models show low signal strength on the
> 5GHz band; other models simply don't work at all on 5GHz.
>
> So it may be an "urban legend" that 5GHz penetrates residential
> housing materials more poorly than 2.4GHz radio waves, but all I can
> tell you is that 5GHz is definitely much works much more poorly in my
> house.  I don't know if it has to do with the antenna quality, or the
> radio quality, at either the AP or the client, but it's definitely an
> observable phenomena.  I'll have to program in the 5GHz SSID into some
> of my devices that historically have completely failed to function on
> 5GHz when on the first floor of my house (but which work just fine on
> the 2nd floor) to see if things are any better with CeroWRT running on
> the WNDR3800.

the power tends to be a little lower on 5GHz and the antennas are tuned for 
2.4GHz so they aren't quite as efficient. Both of these tend to result in worse 
5G performance

> I don't mind using multiple routers, if at some point CeroWRT were to
> gain the advanced feature of talking to other routers and forcing a
> disassociation when the signal strength talking to a particular client
> gets significantly weaker than compared to the signal strength from
> another AP.  Is there any special hardware support needed to do this
> kind of AP-to-AP handoff, or is it just really complicated and no one
> has bothered to do it in an open source implementation?

As far as I have been able to tell this is purely a software thing. I'm not sure 
that it's even that it's so complicated as it is that there are no standards for 
APs to talk to each other to do this sort of thing so nobody has tackled it as 
an opensource project.

The commercial versions all seem to have a central server that makes these 
decisions rather than the peer-to-peer model I would expect for an open 
implemnetation.

David Lang

Re: [Cerowrt-devel] treating 2.4ghz as -legacy?

[Theodore Ts'o]

On Tue, Dec 17, 2013 at 07:04:54PM -0800, David Lang wrote:
> As far as I have been able to tell this is purely a software thing.
> I'm not sure that it's even that it's so complicated as it is that
> there are no standards for APs to talk to each other to do this sort
> of thing so nobody has tackled it as an opensource project.

The question is whether you can get the signal strength for a client
from an AP which isn't associated with the client.  It may not require
special hardwar, but it would seem to me that it would require special
firmware in the WiFi device on the AP, right?

						- Ted

Re: [Cerowrt-devel] treating 2.4ghz as -legacy?

[David Lang]

On Wed, 18 Dec 2013, Theodore Ts'o wrote:

> On Tue, Dec 17, 2013 at 07:04:54PM -0800, David Lang wrote:
>> As far as I have been able to tell this is purely a software thing.
>> I'm not sure that it's even that it's so complicated as it is that
>> there are no standards for APs to talk to each other to do this sort
>> of thing so nobody has tackled it as an opensource project.
>
> The question is whether you can get the signal strength for a client
> from an AP which isn't associated with the client.  It may not require
> special hardwar, but it would seem to me that it would require special
> firmware in the WiFi device on the AP, right?

I don't believe so. kismit will show all devices without associating with them. 
You can't use it on an active AP, but that's because it wants to scan through 
the different channels. I don't see any reason why you couldn't report the 
signal strength that you do hear.

Now, the fact that you are not scanning will mean that you will probably not see 
the client from all APs, so the smarts in the system will have to know where the 
various APs are, on what channels, and make decisions like 'nobody respond to 
this client on channel 1, AP 53 is on channel 6 and is closer than any AP on 
channel 1.

David Lang

Re: [Cerowrt-devel] treating 2.4ghz as -legacy?

[Michael Richardson]

dpreed@reed.com wrote:
    > I know it will just trigger raging arguments, but it turns out that 5 GHz
    > propagates far better in normal housing than does 2.4 GHz.

I believe you, and the physics.
The question is perhaps, do the 5Ghz access point and stations implement
everything correctly to get this benefit.

    > Please don't repeat this urban legend.   Don't believe *anything* you read in
    > The Register about EM waves, and don't believe computer scientists about
    > electrical and electronic engineering.

/me BSc. Physics (high-energy).
I even took the 4th year EM course from EE.

My 2.4Ghz spectrum has a periodic (120s or so) blast from something which
makes ssh often unuseable... then it goes away for a few months... I have
some screen captures somewhere from wavemon.

More radios, I agree.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

Re: [Cerowrt-devel] treating 2.4ghz as -legacy?

[Chuck Anderson]

On Tue, Dec 17, 2013 at 08:33:03PM -0500, Theodore Ts'o wrote:
> I don't mind using multiple routers, if at some point CeroWRT were to
> gain the advanced feature of talking to other routers and forcing a
> disassociation when the signal strength talking to a particular client
> gets significantly weaker than compared to the signal strength from
> another AP.  Is there any special hardware support needed to do this
> kind of AP-to-AP handoff, or is it just really complicated and no one
> has bothered to do it in an open source implementation?

It is always the Wi-Fi client that decides when/where to roam to in a
multi-AP environment based on whatever criteria it chooses--usually
the signal strength.  The APs don't generally influence the clients'
roaming decisions, except for some advanced enterprise systems which
can sometimes use "tricks" like playing with transmitted
signal-strength or Beacon timing or forced disassociation to "steer"
clients to a certain band or AP, usually for capacity or policy
reasons.  These are imperfect solutions because the AP can't know what
the client's signal strength actually is--it can only infer it from
the AP's received signal strength of a particular client which is
imprecise due to the different antenna and radio characteristics of
each end.  This gets more complicated with MIMO on 802.11n, since
different paths could be used in each direction of transmission.

Simply setting the same ESSIDs on all APs and making sure they are all
connected to the same wired layer 2 network (so IP connectivity wont't
be broken after roaming) is all you should need to do to have a basic,
working multi-AP environment.  Clients usually have a configurable
"roaming aggressiveness" setting that determines how sensitive they
are to changes in the signal srength and how "sticky" they are to one
AP before deciding to roam to another one.

In the context of CeroWRT specifically, a multi-AP environment
presents problems because CeroWRT explicity does NOT come configured
to do layer 2 switching between networks.  In order to support proper
Wi-Fi roaming, though, it would have to provide some solution for the
client to keep working with the same IP address after roaming to
another AP.  This could be as simple as configuring the same layer 2
network between APs, or using a tunneling technology such as Mobile IP
or GRE as some advanced enterprise systems do.

Here is a good paper on how Wi-Fi roaming works;

http://www.revolutionwifi.net/2011/12/wi-fi-roaming-analysis-part-1.html

Here is a relavent quote:

"Wi-Fi network connection establishment and roaming is decentralized,
being controlled almost entirely by the client. The 802.11 standard
explicitly places control of wireless connection establishment in the
hands of clients by defining various logical services and breaking
implementation out between clients and access points."

Re: [Cerowrt-devel] treating 2.4ghz as -legacy?

[dpreed]

[-- Attachment #1: Type: text/plain, Size: 6731 bytes --]


Yes - there are significant differences in the physical design of access points that may affect 5 GHz and 2.4 GHz differently.  There are also modulation differences, and there may actually be scheduling/protocol differences.
 
All of these affect connectivity far more than center-frequency will.
 
1) Antennas.  One of the most obvious problems is antenna "aperture".  That is a measure of the effective 2-D area of the antenna on the receiving side.  A dipole antenna (the cheapest kind, but not the only kind used in access points) is "tuned" by making its length a specific fraction of the wavelength.  Thus a 5 GHz antenna of the dipole type has 1/4 the aperture of a dipole antenna for 2.4 GHz.   This means that the 5 GHz antenna of the same design can access only 1/4 of the radiated energy at 5 GHz.  But that's entirely due to antenna size.   If you hold the antenna size constant (which means using a design that is inherently twice as big as a dipole), you will find that range dramatically increases.   You can demonstrate this with parabolic reflecting *receive* antennas at the two frequencies. (the aperture can be kept constant by using the same dish diameter).   If you look at the antenna elements for 5 and 2.4 in an access pony, you will probably see, if you understand the circuitry, that the 5 GHz antenna has a smaller aperture.
 
The other problem is antenna directionality for the transmit and receive antennas.  Indeed almost all AP antennas have flattened doughnut radiation patterns in free-space.   Worse, however, is that indoors, the antenna patterns are shaped by reflectors and absorbers so that the energy is highly variable, and highly dependent on wavelength in the pattern.  So 5 GHz and 2.4 GHz signals received at any particular point have highly variable relative energies.   In one place the 5 GHz signal might be 10x the energy of a 2.4 GHz signal from the same AP, and in another, 1/10th. The point here is that a "controlled experiment" that starts at a point where 2.4 GHz works OK might find weak 5 GHz, but moving 1 foot to the side will cause 2.4 to be unworkable, whereas 5 works fine.   Distances of 1 foot completely change the situation in a diffusive propagation environment.
 
Fix: get the AP designers to hire smarter antenna designers.  Even big companies don't understand the antenna issue - remember the Apple iPhone design with the antenna that did not work if you held the phone at the bottom, but worked fine if you held it at the top?  Commercial APs are generally made of the cheapest parts, using the cheapest designs, in the antenna area.  And you buy them and use them with no understanding of how antennas actually work.  Caveat emptor.  And get your antennas evaluated by folks who understand microwave antennas in densely complex propagation environments, not outdoor free-space.
 
(and don't put your AP in the attic and expect a good signal near the ground.... or in the basement.  Physics will make sure that the signal is zero at any ground, so being closer to the ground than the antenna weakens the signal a lot!)
 
2) Modulation and digitization.   Indoor environments are multipath-rich.   OFDM, because it reduces the symbol rate, doesn't mind multipath as much as does DSSS.   But it does require a wider band and equalization across the band, in order to work well.  The problem with 802.11 as a protocol is that the receiver has only a  microsecond or so to determine how to equalize the signal from a transmitter, and to apply that equalization.   Since the AP is constantly receiving packets from multiple sources, with a high dynamic range, the radios may or may not succeed in equalizing enough.   The more bits/sample received, and the more variable the analog gain in the front-end can be adapted, the better the signal can be digitized.  Receiver designs are highly variable, and there is no particularly good standard for adjusting the power of transmitters to minimize the dynamic range of signals at the receiver end of a packet transmission.  This can be quite different in 5 GHz and 2.4 GHz due to the type of modulation used in the beacon packets sent by APs.   Since the endpoints are made by a different designers the PHY layer standards are required to do the job of making the whole system work.  Advanced modulation and digitization systems at 5 GHz are potentially better, but may in fact be far more incompatible with each other.  I've seen some terrible design choices.
 
3) Software/Protocol.   The most problematic software issue I know of is the idea of using RSSI as if it were meaningful for adaptation of rates, etc.  The rate achieved is the best measure of channel capacity, not signal strength!   You can get remarkably good performance at lower signal strengths, and poor performance at higher signal strengths - because performance is only weakly affected by signal strength.   Even in the Shannon capacity law, inside the log term, the key constraint is the ratio between S+N and N.   But that is then reduced by the "log" you take.  Far more important is the bandwidth/rate.   The larger the bandwidth used to transmit the same rate, the better the performance.   This has nothing to do with RSSI.  At 5 GHz one could use larger bandwidths and lower the signal rate when there is local noise.
 
One of the biggest issues at 5 GHz is that due to multipath the "hidden terminal" issue gets worse - and this is a specific issue related to "listen-before-talk" protocols.   There are much better ways to deal with hidden terminals than using RSSI to adapt signal strengths or rates on any pairwise link.
 
Fix: if we could, we should redesign large parts of the 802.11 PHY and packet modulation protocol based on physical properties of the indoor environments where it is use.
 
Summary:
 
There *are* differences between 5 GHz and 2.4 GHz.  But they are not due to how far the signals propagate indoors.  First order: make sure aperture and antenna patterns are proper, since they are different on the two bands - that is the main reason that the urban legend continues to survive.
 
Encourage vendors to fix 5 GHz aspects of their products.  They should have no excuse, but they scapegoat propagation of the physical energy.  That's a lie.
 
 


On Tuesday, December 17, 2013 6:43pm, "Stephen Hemminger" <stephen@networkplumber.org> said:



> I concur with Jim.
> 
> My observation is that in our house, upstairs the 5Ghz AP has low signal strength
> reported by the devices, and poor bandwidth.
> 
> Could it be that the radiation pattern of the antenna in WDR3800 laying
> horizontally
> is different for each band. Maybe the 5Ghz band is more of a squashed donut?
> 
>

[-- Attachment #2: Type: text/html, Size: 8277 bytes --]

Re: [Cerowrt-devel] treating 2.4ghz as -legacy?

[Michael Richardson]

dpreed@reed.com wrote:
    > The other problem is antenna directionality for the transmit and receive
    > antennas.  Indeed almost all AP antennas have flattened doughnut radiation
    > patterns in free-space.   Worse, however, is that indoors, the antenna patterns
    > are shaped by reflectors and absorbers so that the energy is highly
    > variable,

Is the donut aligned with the flat direction of the 3800, or another
direction?

My 3800 is mounted on a (concrete) wall, just below ground level in my
basement.  I have good 2.4Ghz coverage in my bedroom, two stories up.

(This is constrast to the 54gl I used to use, which was above my TV in the
den, but it was just an AP-router.  My 3800 is next to the 24-port switch,
and the DSL modem, since it does everything.  Another 3800 is going into the
attic, as soon as I dig through the insulation to run cables)

As for having identical ESSID on the same layer-2... I think that perhaps
cerowrt/openwrt/homenet should consider a wireless AP discovery attribute in
the routing protocol, and given that, run GRE over IPv6 ULA between APs.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

Re: [Cerowrt-devel] treating 2.4ghz as -legacy?

[Toke Høiland-Jørgensen]

[-- Attachment #1: Type: text/plain, Size: 1131 bytes --]

Michael Richardson <mcr@sandelman.ca> writes:

> As for having identical ESSID on the same layer-2... I think that
> perhaps cerowrt/openwrt/homenet should consider a wireless AP
> discovery attribute in the routing protocol, and given that, run GRE
> over IPv6 ULA between APs.

I was thinking something like that would be neat. I seem to recall that
the homenet effort at IETF is in the process of specifying standard(s)
for how multiple routes that get plugged into each other in random
fashions should auto-configure themselves. In the meantime, perhaps a
poor-mans version could be to have cero check, when the wan interface
comes up, whether the upstream router is also running cero, and if so
setup the appropriate GRE tunnels and, basically, turn off all other
functionality.

Some sort of negotiation would be needed, but a lua script running in
the (upstream) web configuration (or even an inetd-powered pipe to a
shell script) could work I guess. This could be authenticated by a
shared secret (which the cero firmware would ship with), to prevent the
most obvious abuse.

Any reason why the above wouldn't work?

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [Cerowrt-devel] treating 2.4ghz as -legacy?

[David Lang]

 On Wed, 18 Dec 2013 18:18:59 +0000, Toke Høiland-Jørgensen wrote:
> Michael Richardson <mcr@sandelman.ca> writes:
>
>> As for having identical ESSID on the same layer-2... I think that
>> perhaps cerowrt/openwrt/homenet should consider a wireless AP
>> discovery attribute in the routing protocol, and given that, run GRE
>> over IPv6 ULA between APs.
>
> I was thinking something like that would be neat. I seem to recall 
> that
> the homenet effort at IETF is in the process of specifying 
> standard(s)
> for how multiple routes that get plugged into each other in random
> fashions should auto-configure themselves. In the meantime, perhaps a
> poor-mans version could be to have cero check, when the wan interface
> comes up, whether the upstream router is also running cero, and if so
> setup the appropriate GRE tunnels and, basically, turn off all other
> functionality.
>
> Some sort of negotiation would be needed, but a lua script running in
> the (upstream) web configuration (or even an inetd-powered pipe to a
> shell script) could work I guess. This could be authenticated by a
> shared secret (which the cero firmware would ship with), to prevent 
> the
> most obvious abuse.
>
> Any reason why the above wouldn't work?

 doing a lot of GRE tunnels could be a lot of overhead.

 What I would like is something that would be easier to scale (I run the 
 wireless network for the Southern California Linux Expo and so I am a 
 bit biased towards figuring out the large scale problem)

 What I do there is to have all the APs on the same ESSID, but them have 
 them all bridge the wireless to the wired network (a different VLAN for 
 2.4 and 5) and then the wireless VLANs get run through a router to 
 connect them to the wired networks.

 I don't do IP management (DHCP in my case) on the individual APs, I do 
 it on the box that is the router/firewall to the rest of the networks.

 in this sort of system, what we would need is a system that would do 
 something along the lines of:

 APs report signal strength of stations they hear to a central location 
 (probably via UDP so that the messages can't queue and be stale when 
 they arrive, but also allowing use of multicast MAC to turn this into a 
 multicast)

 some process decides what the 'best' AP to respond would be and records 
 it in some sort of database (not SQL, possibly memcache)

 when an AP gets a connection request, it checks the client against the 
 database, if it doesn't respond, doesn't have any info on the client, or 
 says that this AP is the best AP, allow the connection


 now, there is a race condition here that APs could be checking as the 
 data is changing, but since the client will retry a couple of times, 
 this should give time for the data to stabilize.



 If there is no central system, this gets a little uglier. By using 
 multicast (either explicitly or by turning the UDP unicast address into 
 a MAC multicast address) the data can be sent to all the APs and they 
 can do their own calculations. The problem would be that this would 
 increase the risk of running into race conditions.

 David Lang

Re: [Cerowrt-devel] treating 2.4ghz as -legacy?

[Michael Richardson]

David Lang <david@lang.hm> wrote:
    >> Michael Richardson <mcr@sandelman.ca> writes:
    >>
    >>> As for having identical ESSID on the same layer-2... I think that
    >>> perhaps cerowrt/openwrt/homenet should consider a wireless AP
    >>> discovery attribute in the routing protocol, and given that, run GRE
    >>> over IPv6 ULA between APs.
    >>
    >> I was thinking something like that would be neat. I seem to recall that
    >> the homenet effort at IETF is in the process of specifying standard(s)
    >> for how multiple routes that get plugged into each other in random
    >> fashions should auto-configure themselves. In the meantime, perhaps a
    >> poor-mans version could be to have cero check, when the wan interface
    >> comes up, whether the upstream router is also running cero, and if so
    >> setup the appropriate GRE tunnels and, basically, turn off all other
    >> functionality.
    >>
    >> Some sort of negotiation would be needed, but a lua script running in
    >> the (upstream) web configuration (or even an inetd-powered pipe to a
    >> shell script) could work I guess. This could be authenticated by a
    >> shared secret (which the cero firmware would ship with), to prevent the
    >> most obvious abuse.
    >>
    >> Any reason why the above wouldn't work?

    > doing a lot of GRE tunnels could be a lot of overhead.

True.  For the average home, there might be two APs (one tunnel). For three
APs, we have either two or three tunnels (three if we support STP).

    > What I would like is something that would be easier to scale (I run the
    > wireless network for the Southern California Linux Expo and so I am a bit
    > biased towards figuring out the large scale problem)

    > What I do there is to have all the APs on the same ESSID, but them have them
    > all bridge the wireless to the wired network (a different VLAN for 2.4 and 5)
    > and then the wireless VLANs get run through a router to connect them to the
    > wired networks.

Yes, all that's great in a managed network, particularly one where one has a
proper router that can filter out the unwanted multicast from the wired
network.  The IETF does that.

    > If there is no central system, this gets a little uglier. By using multicast
    > (either explicitly or by turning the UDP unicast address into a MAC
    > multicast

There is no central system, except that homenet will provide a routing
protocl which will allow a system to elect itself master.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

Re: [Cerowrt-devel] treating 2.4ghz as -legacy?

[David Lang]

On Wed, 18 Dec 2013, Michael Richardson wrote:

> Date: Wed, 18 Dec 2013 15:07:15 -0500
> From: Michael Richardson <mcr@sandelman.ca>
> To: David Lang <david@lang.hm>
> Cc: cerowrt-devel@lists.bufferbloat.net
> Subject: Re: [Cerowrt-devel] treating 2.4ghz as -legacy?
> 
>
> David Lang <david@lang.hm> wrote:
>    >> Michael Richardson <mcr@sandelman.ca> writes:
>    >>
>    >>> As for having identical ESSID on the same layer-2... I think that
>    >>> perhaps cerowrt/openwrt/homenet should consider a wireless AP
>    >>> discovery attribute in the routing protocol, and given that, run GRE
>    >>> over IPv6 ULA between APs.
>    >>
>    >> I was thinking something like that would be neat. I seem to recall that
>    >> the homenet effort at IETF is in the process of specifying standard(s)
>    >> for how multiple routes that get plugged into each other in random
>    >> fashions should auto-configure themselves. In the meantime, perhaps a
>    >> poor-mans version could be to have cero check, when the wan interface
>    >> comes up, whether the upstream router is also running cero, and if so
>    >> setup the appropriate GRE tunnels and, basically, turn off all other
>    >> functionality.
>    >>
>    >> Some sort of negotiation would be needed, but a lua script running in
>    >> the (upstream) web configuration (or even an inetd-powered pipe to a
>    >> shell script) could work I guess. This could be authenticated by a
>    >> shared secret (which the cero firmware would ship with), to prevent the
>    >> most obvious abuse.
>    >>
>    >> Any reason why the above wouldn't work?
>
>    > doing a lot of GRE tunnels could be a lot of overhead.
>
> True.  For the average home, there might be two APs (one tunnel). For three
> APs, we have either two or three tunnels (three if we support STP).

actually, the _average_ home system probably only has a single AP :-)

But if we are going to do something like this, it needs to be able to scale to 
something much larger than just a small home system.

>    > What I would like is something that would be easier to scale (I run the
>    > wireless network for the Southern California Linux Expo and so I am a bit
>    > biased towards figuring out the large scale problem)
>
>    > What I do there is to have all the APs on the same ESSID, but them have them
>    > all bridge the wireless to the wired network (a different VLAN for 2.4 and 5)
>    > and then the wireless VLANs get run through a router to connect them to the
>    > wired networks.
>
> Yes, all that's great in a managed network, particularly one where one has a
> proper router that can filter out the unwanted multicast from the wired
> network.  The IETF does that.

Well, in our case the cerowrt devices should be able to do this.

I believe that Linux allows having both tagged and untagged packets on the samy 
physical interface, so the APs could communicate on a VLAN and one could be the 
gateway to the rest of the network (similar type of overhead in this case to GRE 
tunnels in that all traffic would get routed through one system, but I think it 
would still be less)

Also, if you use multicast MAC, it only is multicast on the local subnet, to 
something the other side of a router it looks like unicast traffic.

>    > If there is no central system, this gets a little uglier. By using multicast
>    > (either explicitly or by turning the UDP unicast address into a MAC
>    > multicast
>
> There is no central system, except that homenet will provide a routing
> protocl which will allow a system to elect itself master.

once a system has elected itself master, we now have a central system :-)

David Lang

Re: [Cerowrt-devel] treating 2.4ghz as -legacy?

[Toke Høiland-Jørgensen]

[-- Attachment #1: Type: text/plain, Size: 594 bytes --]

David Lang <david@lang.hm> writes:

> I believe that Linux allows having both tagged and untagged packets on
> the samy physical interface, so the APs could communicate on a VLAN
> and one could be the gateway to the rest of the network (similar type
> of overhead in this case to GRE tunnels in that all traffic would get
> routed through one system, but I think it would still be less)

What happens to the VLAN tags if the traffic goes through a
non-VLAN-aware switch?

Also, presumably you would need one VLAN/tunnel for each wireless
network (so four in the default cerowrt setup)?

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [Cerowrt-devel] treating 2.4ghz as -legacy?

[Michael Richardson]

Toke Høiland-Jørgensen <toke@toke.dk> wrote:
    >> I believe that Linux allows having both tagged and untagged packets on
    >> the samy physical interface, so the APs could communicate on a VLAN
    >> and one could be the gateway to the rest of the network (similar type
    >> of overhead in this case to GRE tunnels in that all traffic would get
    >> routed through one system, but I think it would still be less)

    > What happens to the VLAN tags if the traffic goes through a
    > non-VLAN-aware switch?

A switch which is totally ignorant of VLAN will simply pass all traffic to
all ports (modulo mac learning).  This is distinguished from a VLAN aware
switch that has it turned off (common for netgear equipment), which might
intolerant.

For many homes, the 3800 may be the only physical switch... a homenet router
discovery protocol would also notice if 3800s were directly attached...
The layer-2 VLAN idea fails if we have a routed homenet and there are a
variety of devices invoved.  That's why, I think that GRE over IP would win
for most homes, and yet keep the wired multicast and wireless multicast
separate.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

Re: [Cerowrt-devel] treating 2.4ghz as -legacy?

[David Lang]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 743 bytes --]

On Thu, 19 Dec 2013, Toke Høiland-Jørgensen wrote:

> David Lang <david@lang.hm> writes:
>
>> I believe that Linux allows having both tagged and untagged packets on
>> the samy physical interface, so the APs could communicate on a VLAN
>> and one could be the gateway to the rest of the network (similar type
>> of overhead in this case to GRE tunnels in that all traffic would get
>> routed through one system, but I think it would still be less)
>
> What happens to the VLAN tags if the traffic goes through a
> non-VLAN-aware switch?

non-aware switches will just pass the packets, reatining the tagging

> Also, presumably you would need one VLAN/tunnel for each wireless
> network (so four in the default cerowrt setup)?

Yes.

David Lang

Re: [Cerowrt-devel] treating 2.4ghz as -legacy?

[Chuck Anderson]

On Thu, Dec 19, 2013 at 12:05:21PM -0800, David Lang wrote:
> On Thu, 19 Dec 2013, Toke Høiland-Jørgensen wrote:
> 
> >David Lang <david@lang.hm> writes:
> >
> >>I believe that Linux allows having both tagged and untagged packets on
> >>the samy physical interface, so the APs could communicate on a VLAN
> >>and one could be the gateway to the rest of the network (similar type
> >>of overhead in this case to GRE tunnels in that all traffic would get
> >>routed through one system, but I think it would still be less)
> >
> >What happens to the VLAN tags if the traffic goes through a
> >non-VLAN-aware switch?
> 
> non-aware switches will just pass the packets, reatining the tagging

Mostly.  Some non-VLAN-aware switches will drop frames larger than
1518 bytes (including FCS).  The switch needs to support up to 1522
byte frames to support the normal IP MTU of 1500 bytes plus a 4-byte
VLAN tag.

Re: [Cerowrt-devel] treating 2.4ghz as -legacy?

[Theodore Ts'o]

Thanks for the detailed explanation about antenna issues.  One
question, if I might:

> (and don't put your AP in the attic and expect a good signal near
> the ground.... or in the basement.  Physics will make sure that the
> signal is zero at any ground, so being closer to the ground than the
> antenna weakens the signal a lot!)

I thought the opposite was true?  That is, ground loses go up when the
antenna is closer to the ground, so it was good to have bigger, taller
atenna towers?  If what you say is correct, how do antennas on cell
towers mitigate this particular issue?

						- Ted

Re: [Cerowrt-devel] treating 2.4ghz as -legacy?

[dpreed]

[-- Attachment #1: Type: text/plain, Size: 2645 bytes --]


The tower is a slightly different situation.  There you are not between the antenna and ground - the ground is between the antenna and you....
|/
|                                 0
|                                -+-
|                                 /\
==================================================
 
If the element is at the top of the mast at left, the path from it to your phone (e.g.) is not close to the ground,
so the losses along the path from you to the element are small.  But as the path gets closer to the ground, the electric field tends to be dragged toward zero.  So the higher the antenna the better, because if it were close to the ground, the energy along the path would tend to be absorbed by the ground because it is closer to the antenna than you.
 
But if the situation looks like this:
 
__  [antenna]
 
\
\
\
0
-+-
/\
=====================================================
 
There is no ground between you and the antenna, but the field is forced to zero at the earth-ground, and also reflected away from you back towards the sky as the slanted "ray" between you and the antenna will reflect off the ground to the right.  So you will find that since you are close to the ground, the field is zero near your head at the spot there, too.  There is no absorption of energy by the air/wood between you and the antenna, but the zero boundary condition at the ground makes the field weaker around you by attenuating the field and reflecting it away from you.
 
The differential equation solutions that describe the time varying EM fields in both situations are, of course, far more complicated (Maxwell's equation with fixed boundary conditions).  But what I'm saying is a rough characterization of the fields' energy structure, given the earth-ground being a roughly flat surface that is conductive enough to hold a near constant zero voltage.
 
Hope this helps.
 
 
On Thursday, December 19, 2013 7:50pm, "Theodore Ts'o" <tytso@mit.edu> said:



> Thanks for the detailed explanation about antenna issues.  One
> question, if I might:
> 
> > (and don't put your AP in the attic and expect a good signal near
> > the ground.... or in the basement.  Physics will make sure that the
> > signal is zero at any ground, so being closer to the ground than the
> > antenna weakens the signal a lot!)
> 
> I thought the opposite was true?  That is, ground loses go up when the
> antenna is closer to the ground, so it was good to have bigger, taller
> atenna towers?  If what you say is correct, how do antennas on cell
> towers mitigate this particular issue?
> 
> 						- Ted
>

[-- Attachment #2: Type: text/html, Size: 4284 bytes --]

Re: [Cerowrt-devel] treating 2.4ghz as -legacy?

[Maciej Soltysiak]

I'm not too keen on the -legacy thing, because it's not language agnostic.
However it seems to be a trend. At 30c3 they do exactly that:

https://twitter.com/arambartholl/statuses/416612652539191296/photo/1/large

Best regards,
Maciej


On Mon, Dec 16, 2013 at 8:46 PM, Dave Taht <dave.taht@gmail.com> wrote:
> I have long used "5" as an indicator that the 5ghz channel was better.
> This goes back to a long thread on nanog, like 4? 5? years ago, where
> the hope was to train users that "5" was better.
>
> Well, it's turned out that 5 is frequently better, but not always, AND
> that clients tend to go for the shortest of the SSIDs available. So a
> thought would be to create another ad-hoc standard for deprecating 2.4
> ghz, and have the shorter SSID be the 5ghz one.
>
> Ideas for the 2ghz channel:
>
> CEROwrt-legacy
> CEROwrt2
>
> I'm not huge on "legacy" because it's rather long but am stuck for
> standards, I'd like a default 2.4 ghz SSID that clearly indicates the
> real use to which 2.4ghz is suitable, like:
> CEROwrt-GET-OFF-MY-BABY-MONITOR-YOU-FREAK
>
> ideas for another ssid naming standard slightly longer than a single
> digit that would make sense to mom?
>
> --
> Dave Täht
>
> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel