Receive new posts as email.
RSS 0.91 | RSS 2.0
RDF | Atom
Podcast only feed (RSS 2.0 format)
Get an RSS reader
Get a Podcast receiver
| Sun | Mon | Tues | Wed | Thurs | Fri | Sat |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 | 31 |
This site operates as an independent editorial operation. Advertising, sponsorships, and other non-editorial materials represent the opinions and messages of their respective origins, and not of the site operator or JiWire, Inc.
Entire site and all contents except otherwise noted © Copyright 2001-2006 by Glenn Fleishman. Some images ©2006 Jupiterimages Corporation. All rights reserved. Please contact us for reprint rights. Linking is, of course, free and encouraged.
Powered by
Movable Type
« More Manhattan Wireless Maps | Main | Unstrung Analyzes Access Point "Weight" »
I sat in on the Bay Area Wireless User’s Group (BAWUG) meeting tonight in Santa Clara.
Atheros drivers for FreeBSD, Linux: Sam Leffler has a special relationship with Atheros that has allowed him to code the missing piece needed to create Linux and FreeBSD drivers for their a, a/b, a/g cards.
Sam had to agree to handle the hardware abstraction layer (HAL) and not release the code he wrote for that component because Atheros uses a software defined radio (SDR). The company (and any individuals involved) could face huge headaches if they released code that allowed direct and simple manipulation of the SDR to work outside of a, b, or g ranges. He’ll have precompiled binaries for many processors.
So Sam is the gatekeeper for the hardware layer, but he’s exposed most of the hardware features through this layer to the open-source part of the drivers. He’s has a tacit commitment to get his driver incorporated into the FreeBSD code tree, which means that FreeBSD in the future will include his driver; he’s also revised the code to work in a native form within Linux.
Will it support Mac OS X, asks Cliff Skolnick? Apple’s latest iteration of the operating system has the right pieces in the right places to make it.
Dave Sifry of Sputnik: Sputnik makes managed access points that use a central management system to identify new devices and configure them, and then manage configuration across a network. The approach allows users to be tracked across Sputnik APs; the authentication and associated policies walk with them as they roam.
Their reference access point they’re selling at cost because their goal is to get their code preinstalled in access points by manufacturers; Actiontec has done this already. They sell per-AP licenses for their controller software.
Dave is also showing an unreleased box that will allow you to put non-Sputnik APs behind it, on one Ethernet port, to offer the same authentication controls. More to come.
Question on fat/thin access points: roaming? Layer 3. When you roam, you reassociate, but you keep the same IP. What about Vernier, ReefEdge, Bluesocket, etc.: how it differentiates? Dave says, all these solutions are dumb radios with a smart switch. Can’t obtain same management/policy information. Not scalable: switch limitations (your 21st AP on a Vernier requires a whole ‘nother switch). Cost averaged per AP could be $600 for switch-based solutions, and $200 for Sputnik solution. Question: who’s the market? A: Small to medium-sized businesses as well as community networks.
Dave demoes Central Control management interface, showing granularity of network restriction, user account creation and management, statistic generation. Relies on open-source software with open interfaces: MySQDL, Open LDAP, Jabber — that’s right, a chat program is used (via secured transport) to communicate between APs and the Central Control. The management interface even has a SQL query box if you want to run your own queries.
Q: RADIUS support? A: In the pipeline, LDAP only today, but RADIUS is top of list.
Q: VLAN support? A: Not in the current version, but Layer 3 policy control offers enough of same benefits on the front end (not the backhaul) as to make VLAN support unnecessary at least in this context.
Q: Policy options? A: More options available through backend, but UI is the complex factor. Need to thrash out UI.
Comment from audience: SSL “dead man” switch doesn’t avoid man-in-the-middle attack that allows redirection of packets that don’t include SSL.
Posted by Glennf at April 24, 2003 8:52 PM
Categories: Community Networking
TrackBack URL for this entry:
https://db.isbn.nu/mt3/mt-tb.pl/200
Interesting take on the WLAN switch (aren't they supposed to make things cheaper amd more scalable?). We just posted an article on a proposed AP to Switch protocol: http://www.unstrung.com/document.asp?doc_id=31835
Any thoughts on this?
Posted by: Gabriel at April 25, 2003 2:52 AM