On the MAC Auth.. one thing I forgot to mention for a long time now... Listing the MAC's that are allowed to connect is great... but how about a "grant all except" list?
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Lars Gaarden Sent: Sunday, July 13, 2003 19:23 To: [EMAIL PROTECTED] Subject: [smartBridges] Nexus wish-list (Was: Here I come from ETSI land) 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 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
