Not to mention the adding of PROPER layer 3 Filtering for discard/forward along with the bandwidth management that's what I want along with the VLAN's by macaddress and by ESSID (multiessid per ap), plus TELNET MUST BE ADDED as a management interface perhaps even basic web for statistics.
Chris
-----Original Message-----
From: Lars Gaarden [mailto:[EMAIL PROTECTED]]
Sent: Sunday, July 13, 2003 8:23 PM
To: [EMAIL PROTECTED]
Just want to add a few things.
Since sB is tight-lipped at the moment and don't want to commit to
features they are still not certain that the product can support
(quite understandable), I certainly don't expect to get yes/no answers
to this list.
Kevin Summers wrote:
> How about including some of us in the drawing board and
> testing phase? As mentioned, an NDA is not a problem to
> sign.
>
> Just some thoughts off the top of my head,
>
> -On the AP side-
>
> * 2 Modes (Access Point, PtP)
> * Client status for AP mode, showing the name of the CPE,
> the MAC address, and the RSSI and signal quality.
* Information about communcation speed per client. (something like
"80% packages transmitted to CPE1 at 11Mbps, 15% @ 5.5Mbps, 5% @
2Mbps, 75% packages received at 11Mbps,...")
* Total and per client packet/error counters (where possible - at
least ACKFailure, FCSError, UnicastPacketsRX/TX, RTSRX, CTSTX).
* Access to MAC forwarding tables through SNMP, ability to flush
forwarding tables.
* Ability to set static MAC forwarding tables per CPE.
> * LOVE the adjustable power via software. Keep that!
> * Make routing an option. It can either be set up as a router,
> or a transparent bridge.
> * In PtP mode, it should only be able to connect to another
> SB AP in PtP mode. (for Backhauls)
> * Increase the output power to at least 24db (250mW not counting
> antenna) so that we can adjust our power with the right size
> antenna to reach the FCC legal limit of 36db. With only 17.5db
> coming out of the radio, an AMP is required to get us to the right
> level so we can serve customers. We'd like to get rid of the
> AMPs to cut down on the noise they add and still be able to
> get to 36db.
> * Naturally we would be ethically bound to follow the law and turn
> down the power when we are using the unit in PtP mode with a
> larger antenna. With 24db of power, we could use smaller
> antennas to go the same distance on our backhaul links, and some
> backhaul links would be easier to do at greater distances.
>
> * For the AP TOTAL, make sure that those of us in FCC land can
> have a setup that allows the full 36db. Options like 60 degree,
> 90 degree, 120 degree, and Omni would give us excellent
> flexibility.
* Support for 802.1q VLAN tagging - "VLAN-per-ESSID" - set up AP with
several ESSIDs, traffic for each ESSID is tagged on the ethernet side
of the AP.
* Keep the block client<->client communication feature, and add
feature to block broad/multicast forwarding on the wireless side.
> -On the CPE side-
>
> * KEEP IT SIMPLE
> * 1 Mode (Client Bridge) The current design and function
> are good. It's clean and simple. Just need to fix the
> problems with the current firmware.
* Since "address 4" support is still optional with 11a/g/h (I think),
please have two modes - true bridge like the current airPoint
clientbridge mode and MAC translation like the current multimac
airBridge.
* Support for more protocols in multimac mode.
* Ad-Hoc mode? I don't use it myself, but there are probably people
who need it.
> * For the TOTAL, more antenna choices. 9db, 13db, 15db, 19db.
> All flat panels of course. No customer install is the same.
> One guy could need a 13db antenna and the guy next door could
> need the 9db because he has shorter trees in his freznel zone.
- AP and CPE -
* SNMPv3 management.
* More packet filters (PPPoE, IPSec, etc). User defined packet filters
would be great. This is really most important on the CPE - most people
have a router/firewall directly behind the AP anyway, so it doesn't
matter much whether you do the AP side filtering on the AP itself or
on the firewall box right behind it (especially if client-client
communication is disabled on the AP).
* Bandwidth control in both directions. Also most important on the
CPE, since it doesn't matter much whether you do the AP side bwcontrol
on the AP itself or the router/FW directly behind it. If the client
gets infected by a DDoS trojan or similar, you need bwcontrol on the
CPE side to make sure one client doesn't kill the wireless segment.
* A maximum air-time control would be great for those situations where
one clients suddenly gets lower LQ/RSSI and eats all the capacity on
the AP because he only receives/transmits at 1Mbps. "traffic to/from
this CPE can not use more than x% of the total available air time" -
including inter frame gaps, RTS/CTS, packets with errors, etc.
* Lower the minimal TX setting so that us in ETSI land can use more
powerful antennas.
* Support for alternative MAC layer (Karlnet or similar). Normal
802.11 CSMA/CA sucks, imho, for outdoor use.
* WPA (and 802.11i whenever it becomes ready) support. Hopefully
without too much throughput penalty.
* 3 configuration levels - running config (config after power off/
power on), wisp default (config after reset by powershot or similar)
and factory default (config after hard reset with a CMOS jumper or
similar).
* 802.1q VLAN tagging/untagging support on both CPE and AP.
> I completely agree with Eje. Make the equipment capable of routing
> if you want, but don't take away the ability to bridge.
Absolutely. A "wireless broadband router" would be great in some
situations, but regular bridging support is also needed.
A big kudos to sB, they definately seem to be on the right track.
--
LarsG
The PART-15.ORG smartBridges Discussion List
To Join: mailto:[EMAIL PROTECTED] (in the body type subscribe smartBridges <yournickname>
To Remove: mailto:[EMAIL PROTECTED] (in the body type unsubscribe smartBridges)
Archives: http://archives.part-15.org
