[ath9k-devel] What mode to use for wireless backhaul?

[ath9k-devel] What mode to use for wireless backhaul?

[John Nielsen]

I have a scenario where it would be nice to use multiple wireless  
nodes to connect point A to points B, C and D instead of running  
cable/fiber. Actually providing a wireless network for people to  
connect to at either end is immaterial. I've been playing with a  
couple Alix boards with AR9220 cards and have enjoyed the setup, but  
recently I've been wondering what the best topology / mode might be to  
use?

The ideal solution will support HT speeds and recover gracefully if  
one node goes down but others are in range.

So what do you guys think? OLSR + ad-hoc? Mesh? Multiple AP's and  
Stations? WDS? P2P?

While we're at it, any specific distro's to try or avoid?

Thanks,

JN

[ath9k-devel] What mode to use for wireless backhaul?

[Peter Stuge]

John Nielsen wrote:
> So what do you guys think? OLSR + ad-hoc? Mesh? Multiple AP's and  
> Stations? WDS? P2P?

Afraid neither code nor community is really quite mature for that
discussion.


> While we're at it, any specific distro's to try or avoid?

Basically you need to track wireless-testing and ideally with all
linux-wireless patches, because more or less serious errors and
problems are fixed on an ongoing basis.

I guess most do that until they have something that works, and then
freeze that.


//Peter

[ath9k-devel] What mode to use for wireless backhaul?

[Larry Vaden]

On Mon, Apr 25, 2011 at 11:45 AM, Peter Stuge <peter@stuge.se> wrote:
> John Nielsen wrote:
>> So what do you guys think? OLSR + ad-hoc? Mesh? Multiple AP's and
>> Stations? WDS? P2P?
>
> Afraid neither code nor community is really quite mature for that
> discussion.

Just as I was thinking OpenWrt is showing more vitality than 11 out of
10 other projects with which I am familiar :(

Perhaps the 65 year old neurons are due for recalibration, but ...

[ath9k-devel] What mode to use for wireless backhaul?

[Peter Stuge]

Larry Vaden wrote:
> >> So what do you guys think? OLSR + ad-hoc? Mesh? Multiple AP's and
> >> Stations? WDS? P2P?
> >
> > Afraid neither code nor community is really quite mature for that
> > discussion.
> 
> Just as I was thinking OpenWrt is showing more vitality than 11 out of
> 10 other projects with which I am familiar :(

I haven't followed OpenWRT at all - the people I know who work there
are not only talented but also very active. I was refering
exclusively to the ath9k code and community.


//Peter

[ath9k-devel] What mode to use for wireless backhaul?

[Joel Wiramu Pauling]

Run node A in AP mode,

have nodes B,C and D connect to it.

Do lots of site scans use chans 1,6,11 as needed.

Don't use any encryption.

Use openvpn or similar in UDP mode with multi cons up from each of B,C
and D to A.



This will give you IMHO the best hassle free results, with ath9k .
802.11s code does not support N modes, ad-hoc also does not.

You could run OLSR or even BATMAN if you like - removing WPA crypt
makes things work better, and openvpn is more secure anyway.



On 25 April 2011 07:48, John Nielsen <lists@jnielsen.net> wrote:
> I have a scenario where it would be nice to use multiple wireless
> nodes to connect point A to points B, C and D instead of running
> cable/fiber. Actually providing a wireless network for people to
> connect to at either end is immaterial. I've been playing with a
> couple Alix boards with AR9220 cards and have enjoyed the setup, but
> recently I've been wondering what the best topology / mode might be to
> use?
>
> The ideal solution will support HT speeds and recover gracefully if
> one node goes down but others are in range.
>
> So what do you guys think? OLSR + ad-hoc? Mesh? Multiple AP's and
> Stations? WDS? P2P?
>
> While we're at it, any specific distro's to try or avoid?
>
> Thanks,
>
> JN
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

[ath9k-devel] What mode to use for wireless backhaul?

[Larry Vaden]

On Tue, Apr 26, 2011 at 6:17 PM, Peter Stuge <peter@stuge.se> wrote:
> Larry Vaden wrote:
>> >> So what do you guys think? OLSR + ad-hoc? Mesh? Multiple AP's and
>> >> Stations? WDS? P2P?
>> >
>> > Afraid neither code nor community is really quite mature for that
>> > discussion.
>>
>> Just as I was thinking OpenWrt is showing more vitality than 11 out of
>> 10 other projects with which I am familiar :(
>
> I haven't followed OpenWRT at all - the people I know who work there
> are not only talented but also very active. I was refering
> exclusively to the ath9k code and community.

my mistake (I mix the the openwrt-*/ath9k-devel lists in one GMail label), but

insert caricature of jaw dropping further ...

perhaps I should explain that I look at the Atheros closed source SDK
as a Basic (yes, a capital B) interpreter for which one writes a
system.cfg file and I look at ath9k, Felix, Adrian et al as real sw
folks who have forgotten more than I'll ever know wrt the specifics of
the matter at hand.

[ath9k-devel] What mode to use for wireless backhaul?

[Peter Stuge]

Larry Vaden wrote:
> > I was refering exclusively to the ath9k code and community.
..
> I look at ath9k, Felix, Adrian et al as real sw folks who have
> forgotten more than I'll ever know wrt the specifics of the matter
> at hand.

Yes Felix in particular does an amazing job on the Linux driver, but
the code seems to need *many* more years of work before it can be
said to actually be finished, I think likely it will not happen at
all before hardware is obsolete. I was quite excited because I had
the impression that Atheros was eager with Linux, but I expected
something completely different from what I found to be the reality
for ath9k code and Atheros' operation. I guess they do what they can,
I just expected something vastly different.

I'm eager to test ath9k hardware with fbsd because Adrian indeed has
much more than a clue.

The fact remains that ath9k on Linux is not mature rock solid in all
different modes and bands, and that hasn't really changed over the
last year and a half I've been around, despite the endless hours that
have been spent on the driver. With regressions happening daily I
have absolutely no expectation for Linux ath9k excellence in the
future.

I believe the code was simply too bad to begin with for it to ever
work properly. Too many cases that someone never thought of when
writing. I'd love to be proven wrong of course! I think the effort
will total monumental however, which is such a waste of life. :(


//Peter

[ath9k-devel] What mode to use for wireless backhaul?

[Xianghua Xiao]

Almost all Atheros-based commercial products on the market are still
based on Atheros's SDK, its driver is still madwifi-based but worked
_reliably_. The IBSS/adhoc driver in that SDK is not fully
done(especially 11N), as 99% customers are doing AP/STA and nobody
needs to care on that 1%.

On Tue, Apr 26, 2011 at 7:18 PM, Peter Stuge <peter@stuge.se> wrote:
> Larry Vaden wrote:
>> > I was refering exclusively to the ath9k code and community.
> ..
>> I look at ath9k, Felix, Adrian et al as real sw folks who have
>> forgotten more than I'll ever know wrt the specifics of the matter
>> at hand.
>
> Yes Felix in particular does an amazing job on the Linux driver, but
> the code seems to need *many* more years of work before it can be
> said to actually be finished, I think likely it will not happen at
> all before hardware is obsolete. I was quite excited because I had
> the impression that Atheros was eager with Linux, but I expected
> something completely different from what I found to be the reality
> for ath9k code and Atheros' operation. I guess they do what they can,
> I just expected something vastly different.
>
> I'm eager to test ath9k hardware with fbsd because Adrian indeed has
> much more than a clue.
>
> The fact remains that ath9k on Linux is not mature rock solid in all
> different modes and bands, and that hasn't really changed over the
> last year and a half I've been around, despite the endless hours that
> have been spent on the driver. With regressions happening daily I
> have absolutely no expectation for Linux ath9k excellence in the
> future.
>
> I believe the code was simply too bad to begin with for it to ever
> work properly. Too many cases that someone never thought of when
> writing. I'd love to be proven wrong of course! I think the effort
> will total monumental however, which is such a waste of life. :(
>
>
> //Peter
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

[ath9k-devel] What mode to use for wireless backhaul?

[Larry Vaden]

On Tue, Apr 26, 2011 at 7:18 PM, Peter Stuge <peter@stuge.se> wrote:
>
> The fact remains that ath9k on Linux is not mature rock solid in all
> different modes and bands, and that hasn't really changed over the
> last year and a half I've been around, despite the endless hours that
> have been spent on the driver.

Take a look at <http://www.nasdaq.com/aspx/chartingbasics.aspx?symbol=ATHR&selected=ATHR>;
 the bulls and the bears may have fought to a draw in a rather unique
display of no one knows where ATHR is headed.

[ath9k-devel] What mode to use for wireless backhaul?

[Larry Vaden]

On Tue, Apr 26, 2011 at 10:47 PM, Xianghua Xiao <xiaoxianghua@gmail.com> wrote:
> Almost all Atheros-based commercial products on the market are still
> based on Atheros's SDK, its driver is still madwifi-based but worked
> _reliably_. The IBSS/adhoc driver in that SDK is not fully
> done(especially 11N), as 99% customers are doing AP/STA and nobody
> needs to care on that 1%.

The stuck beacon/recal problem in the Atheros SDK sticks out like a
sore thumb in even rural installations;  I can't imagine running it in
a metropolitan environment.  We've seen several hw resets per minute
occur in rural environments.

[ath9k-devel] What mode to use for wireless backhaul?

[Felix Fietkau]

On 2011-04-27 2:18 AM, Peter Stuge wrote:
> Larry Vaden wrote:
>>  >  I was refering exclusively to the ath9k code and community.
> ..
>>  I look at ath9k, Felix, Adrian et al as real sw folks who have
>>  forgotten more than I'll ever know wrt the specifics of the matter
>>  at hand.
>
> Yes Felix in particular does an amazing job on the Linux driver, but
> the code seems to need *many* more years of work before it can be
> said to actually be finished,
Depends on what you mean by 'finished'. For many people it's quite 
usable and stable. The number of people that are still able to reproduce 
problems with ath9k on OpenWrt has been consistently decreasing over 
time, whereas more and more people are starting to use it, sometimes 
even in very big setups with thousands of users.

> I think likely it will not happen at
> all before hardware is obsolete. I was quite excited because I had
> the impression that Atheros was eager with Linux, but I expected
> something completely different from what I found to be the reality
> for ath9k code and Atheros' operation. I guess they do what they can,
> I just expected something vastly different.
>
> I'm eager to test ath9k hardware with fbsd because Adrian indeed has
> much more than a clue.
Sure, Adrian is good at what he does, but Atheros support in FreeBSD is 
still quite a bit behind, because for a long time very little work has 
been put into it - so don't expect too much, and if it doesn't work for 
you, please don't start whining on the FreeBSD lists as well :)

> The fact remains that ath9k on Linux is not mature rock solid in all
> different modes and bands, and that hasn't really changed over the
> last year and a half I've been around, despite the endless hours that
> have been spent on the driver. With regressions happening daily I
> have absolutely no expectation for Linux ath9k excellence in the
> future.
I get the impression that you're extrapolating from a very, *very* 
limited set of data, looking only at your own issues and the limited 
traffic on this mailing list, which only represents few actual users.

I'm looking at lots of feedback from a very diverse set of users, using 
ath9k in access point, ad-hoc mesh, point to point link setups, and some 
also using it in client mode.
Sure, not all problems have been resolved yet, but there's a large 
number of users for which the current code is completely solid and 
functional.

> I believe the code was simply too bad to begin with for it to ever
> work properly. Too many cases that someone never thought of when
> writing. I'd love to be proven wrong of course! I think the effort
> will total monumental however, which is such a waste of life. :(
Actually, a lot of the code quality issues have been resolved already 
and aside from a few things here and there (and of course the tx 
aggregation nastiness), the code is in pretty good shape.

- Felix

[ath9k-devel] What mode to use for wireless backhaul?

[Adrian Chadd]

On 27 April 2011 15:52, Felix Fietkau <nbd@openwrt.org> wrote:

>> I'm eager to test ath9k hardware with fbsd because Adrian indeed has
>> much more than a clue.

> Sure, Adrian is good at what he does, but Atheros support in FreeBSD is
> still quite a bit behind, because for a long time very little work has
> been put into it - so don't expect too much, and if it doesn't work for
> you, please don't start whining on the FreeBSD lists as well :)

Aw, I'm blushing. :-)

But Felix is right. FreeBSD is still quite a bit behind but I'm taking
a more conservative approach whilst I try to debug the issues people
are seeing on some of the older chipsets and in some noisy
environments. I'm still a few months out from finishing my degree, a
few months out after that for public 802.11n STA/AP support and then a
good 12 months away for fixing bugs. All of which likely will occur in
my spare time regardless of what/who is employing me.

What we (FreeBSD and ath9k) need is more people who are able and
willing to jump in knee-deep into the code and ask the difficult
questions. That's how I started 18 months ago now - I had no idea what
was going on, I simply started looking at the ath/HAL code and started
asking questions about how things should work. I read patent
documents, I pestered Felix and Luis and generally was a nuisance. But
I was a nuisance who was digging around the source tree and available
documentation to figure out what was going on and I do occasionally
uncover some nugget of strange behaviour that's been lurking about.

If you can't, then please consider finding someone who you can
hire/contract out support to in order to find/fix up the bugs in the
ath9k (or FreeBSD! It doesn't matter :-) stack. That's how progress is
made.

So in summary, ath9k is doing bleeding edge stuff on the newer
chipsets; FreeBSD/myself is currently concentrating more on getting
the older stuff right (before moving onto the shiny newer stuff) and
making that as bullet-proof as can be done given the available
resources. If you want to pitch in, I welcome new developers to help
me out.



Adrian

[ath9k-devel] What mode to use for wireless backhaul?

[John Nielsen]

Thanks! This is the kind of feedback I was looking for. Comments below.

On Apr 26, 2011, at 7:30 PM, Joel Wiramu Pauling wrote:

> Run node A in AP mode,
> 
> have nodes B,C and D connect to it.
> 
> Do lots of site scans use chans 1,6,11 as needed.
> 
> Don't use any encryption.
> 
> Use openvpn or similar in UDP mode with multi cons up from each of B,C
> and D to A.
> 
> This will give you IMHO the best hassle free results, with ath9k .
> 802.11s code does not support N modes, ad-hoc also does not.

I suspected as much; thank you for confirming. Does WDS support N modes?

For redundancy and load balancing I think I would want 2-3 AP nodes in different locations but still on the "A" network segment.

> You could run OLSR or even BATMAN if you like - removing WPA crypt
> makes things work better, and openvpn is more secure anyway.

I may still look at OLSR as a poor man's WDS--if point "C" is acting as a wireless repeater for a more-distant point "E" for instance. I also like the idea of running encryption at a different layer to get it out of the wireless equation.

Regarding the other direction this thread has taken, I also thought that the doom and gloom re: the status and future of ath9k was a bit overstated. It is disappointing to not have more direct support from Atheros but at least the code is out there, which is more than can be said about most (any?) other wireless vendors. The work of the volunteers on this list and elsewhere is immensely valuable and the code today is very useful in many cases (including Access Point, which again most drivers and platforms don't support at all) to many people. I realize that other use cases are less common and will therefore get less attention, but I still think the fact that I can run software of my choosing on a device of my choosing is incredibly valuable. Thank you one and all.

> On 25 April 2011 07:48, John Nielsen <lists@jnielsen.net> wrote:
>> I have a scenario where it would be nice to use multiple wireless
>> nodes to connect point A to points B, C and D instead of running
>> cable/fiber. Actually providing a wireless network for people to
>> connect to at either end is immaterial. I've been playing with a
>> couple Alix boards with AR9220 cards and have enjoyed the setup, but
>> recently I've been wondering what the best topology / mode might be to
>> use?
>> 
>> The ideal solution will support HT speeds and recover gracefully if
>> one node goes down but others are in range.
>> 
>> So what do you guys think? OLSR + ad-hoc? Mesh? Multiple AP's and
>> Stations? WDS? P2P?
>> 
>> While we're at it, any specific distro's to try or avoid?
>> 
>> Thanks,
>> 
>> JN
>> 
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at lists.ath9k.org
>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>> 
> 

[ath9k-devel] What mode to use for wireless backhaul?

[Adrian Chadd]

On 28 April 2011 01:03, John Nielsen <lists@jnielsen.net> wrote:

> Regarding the other direction this thread has taken, I also thought that the doom and gloom re: the status and future of ath9k was a bit overstated. It is disappointing to not have more direct support from Atheros but at least the code is out there, which is more than can be said about most (any?) other wireless vendors. The work of the volunteers on this list and elsewhere is immensely valuable and the code today is very useful in many cases (including Access Point, which again most drivers and platforms don't support at all) to many people. I realize that other use cases are less common and will therefore get less attention, but I still think the fact that I can run software of my choosing on a device of my choosing is incredibly valuable. Thank you one and all.

As a developer, I've been extremely impressed with the direction that
Atheros has taken and with the support that I've received, both from
Atheros employees in an official role and others such as Felix Fietkau
in an open source role. I've also been impressed with the help I've
received from the openwrt community.

If I can make a suggestion, and you should take this as a "hint" about
the direction you (being "people on this list") should take - get into
ath9k development. Show initiative and interest, get some work done,
and ask for help. Even if it's doing what someone did earlier and
bisecting patches to figure out what broke (eg the AR9285/Kite
regression introduced earlier by some RX path tidyups). You'll
suddenly discover you have more direct support. :-)



Adrian

[ath9k-devel] What mode to use for wireless backhaul?

[Joel Wiramu Pauling]

WDS is crap, don't use it. You effectively half the available
bandwidth per node in a WDS network, it's a hack and is only useful if
you want coverage at the sacrifice of bandwidth of the link.

On 28 April 2011 05:03, John Nielsen <lists@jnielsen.net> wrote:
> Thanks! This is the kind of feedback I was looking for. Comments below.
>
> On Apr 26, 2011, at 7:30 PM, Joel Wiramu Pauling wrote:
>
>> Run node A in AP mode,
>>
>> have nodes B,C and D connect to it.
>>
>> Do lots of site scans use chans 1,6,11 as needed.
>>
>> Don't use any encryption.
>>
>> Use openvpn or similar in UDP mode with multi cons up from each of B,C
>> and D to A.
>>
>> This will give you IMHO the best hassle free results, with ath9k .
>> 802.11s code does not support N modes, ad-hoc also does not.
>
> I suspected as much; thank you for confirming. Does WDS support N modes?
>
> For redundancy and load balancing I think I would want 2-3 AP nodes in different locations but still on the "A" network segment.
>
>> You could run OLSR or even BATMAN if you like - removing WPA crypt
>> makes things work better, and openvpn is more secure anyway.
>
> I may still look at OLSR as a poor man's WDS--if point "C" is acting as a wireless repeater for a more-distant point "E" for instance. I also like the idea of running encryption at a different layer to get it out of the wireless equation.
>
> Regarding the other direction this thread has taken, I also thought that the doom and gloom re: the status and future of ath9k was a bit overstated. It is disappointing to not have more direct support from Atheros but at least the code is out there, which is more than can be said about most (any?) other wireless vendors. The work of the volunteers on this list and elsewhere is immensely valuable and the code today is very useful in many cases (including Access Point, which again most drivers and platforms don't support at all) to many people. I realize that other use cases are less common and will therefore get less attention, but I still think the fact that I can run software of my choosing on a device of my choosing is incredibly valuable. Thank you one and all.
>
>> On 25 April 2011 07:48, John Nielsen <lists@jnielsen.net> wrote:
>>> I have a scenario where it would be nice to use multiple wireless
>>> nodes to connect point A to points B, C and D instead of running
>>> cable/fiber. Actually providing a wireless network for people to
>>> connect to at either end is immaterial. I've been playing with a
>>> couple Alix boards with AR9220 cards and have enjoyed the setup, but
>>> recently I've been wondering what the best topology / mode might be to
>>> use?
>>>
>>> The ideal solution will support HT speeds and recover gracefully if
>>> one node goes down but others are in range.
>>>
>>> So what do you guys think? OLSR + ad-hoc? Mesh? Multiple AP's and
>>> Stations? WDS? P2P?
>>>
>>> While we're at it, any specific distro's to try or avoid?
>>>
>>> Thanks,
>>>
>>> JN
>>>
>>> _______________________________________________
>>> ath9k-devel mailing list
>>> ath9k-devel at lists.ath9k.org
>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>>
>>
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

[ath9k-devel] What mode to use for wireless backhaul?

[Larry Vaden]

On Wed, Apr 27, 2011 at 7:55 PM, Adrian Chadd <adrian@freebsd.org> wrote:
>
> If I can make a suggestion, and you should take this as a "hint" about
> the direction you (being "people on this list") should take - get into
> ath9k development. Show initiative and interest, get some work done,
> and ask for help. Even if it's doing what someone did earlier and
> bisecting patches to figure out what broke (eg the AR9285/Kite
> regression introduced earlier by some RX path tidyups). You'll
> suddenly discover you have more direct support. :-)

Is <http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html>
more or less the best reference for learning about bisecting patches?

Or?

[ath9k-devel] What mode to use for wireless backhaul?

[Larry Vaden]

On Wed, Apr 27, 2011 at 7:58 PM, Joel Wiramu Pauling <joel@aenertia.net> wrote:
> WDS is crap, don't use it. You effectively half the available
> bandwidth per node in a WDS network, it's a hack and is only useful if
> you want coverage at the sacrifice of bandwidth of the link.

There is one vendor in the marketplace where if you want layer 2
transparency on a p-t-p link, you VILL use WDS :(

[ath9k-devel] What mode to use for wireless backhaul?

[Adrian Chadd]

On 28 April 2011 09:27, Larry Vaden <vaden@texoma.net> wrote:

> There is one vendor in the marketplace where if you want layer 2
> transparency on a p-t-p link, you VILL use WDS :(

What's broken about WDS? Just that you halve bandwidth?


Adrian

[ath9k-devel] What mode to use for wireless backhaul?

[Adrian Chadd]

On 28 April 2011 09:25, Larry Vaden <vaden@texoma.net> wrote:

> Is <http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html>
> more or less the best reference for learning about bisecting patches?

I think so. I'm not really up to date for doing Linux bisecting. :-)


Adrian

[ath9k-devel] What mode to use for wireless backhaul?

[Larry Vaden]

On Wed, Apr 27, 2011 at 8:44 PM, Adrian Chadd <adrian@freebsd.org> wrote:
> On 28 April 2011 09:27, Larry Vaden <vaden@texoma.net> wrote:
>
>> There is one vendor in the marketplace where if you want layer 2
>> transparency on a p-t-p link, you VILL use WDS :(
>
> What's broken about WDS? Just that you halve bandwidth?

WDS is like a 3 pound sledgehammer or just about anything else, good
for some things, not for other things.

I'm not sure WDS halves the bandwidth in all cases and I'm not sure it
would do that if the links were full duplex?

[ath9k-devel] What mode to use for wireless backhaul?

[Felix Fietkau]

On 2011-04-28 2:58 AM, Joel Wiramu Pauling wrote:
> WDS is crap, don't use it. You effectively half the available
> bandwidth per node in a WDS network, it's a hack and is only useful if
> you want coverage at the sacrifice of bandwidth of the link.
WDS doesn't cut your bandwidth in half, repeating packets on the same 
channel does. If you use WDS just as a backhaul without repeating on the 
same radio/channel, you get the full bandwidth.

- Felix

[ath9k-devel] What mode to use for wireless backhaul?

[Larry Vaden]

On Wed, Apr 27, 2011 at 9:47 PM, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2011-04-28 2:58 AM, Joel Wiramu Pauling wrote:
>> WDS is crap, don't use it. You effectively half the available
>> bandwidth per node in a WDS network, it's a hack and is only useful if
>> you want coverage at the sacrifice of bandwidth of the link.
> WDS doesn't cut your bandwidth in half, repeating packets on the same
> channel does. If you use WDS just as a backhaul without repeating on the
> same radio/channel, you get the full bandwidth.

The manufacturer I referred to uses WDS to achieve layer 2
transparency on point-to-point and point-to-multipoint and the full
bandwidth is available, so I agree with you.

e.g., one can't do dhcp transactions on this manufacturer's equipment
unless WDS is configured because their AP doesn't do dhcp-relay.

Another example is a chain of say 3 p-t-p links linking A, B, C and D;
 the bandwidth doesn't suffer, just the latency suffers, correct?