On May 16, 2005, at 7:59 PM, Jim Wang wrote:
> Hi Jim,
> Thanks for the very detailed response. Your answer is very similar to
> my response when customers asking how many simultaneous clients can
> connect to an individual Tropos AP :-)
In deference to the list, I didn't even start on the whys and wheres of
wireless performance. Aren't the Tropos APs still based on a prism2.5
design running TBRPF(*) on top of FreeBSD? If so, the firmware (or
driver) largely dictates the number of 'simultaneous clients'
(*) it seems that lately both Tropos and Firetide have decided that
TBRPF wasn't all it could have been.
> At any rate, I really love the m0n0wall and like recommending it to my
> customers because it really works. The problem is that our customers
> especially the bigger deployments don't have the expertise to run
> their own RADIUS servers and to support their own authentication and
> billing. They would rather have outfits like Airpath and Pronto
> manage all that for them. So as I'm recommending a m0n0wall I'd like
> to make sure that at a minimum it's able to perform the 802.1x
> authentication with these companies.
1) There is no 802.1x in m0n0wall right now, but I've put it in a
custom CF image based on 6.0 (-CURRENT, with OLSR, but I only mention
this because you'll get a kick out of it), and I'm looking at pfSense.
2) I'm not sure where you want the 802.1x authenticator to run. If
m0n0wall (or pfSense, or ...) is to be the AP, then its fairly
straight-forward, else, its difficult to impossible. Perhaps you were
having m0n0wall act as the RADIUS server in this case. I can't tell.
> Incidently, we will be testing authentication/billing of a wireless
> client on a m0n0wall with Airpath tomorrow for a new upcoming
> customer. I'll keep you informed of our progress.
> Other useful features that we're seeing customers do with their
> service gateways is allocating public IP address to their wireless
> clients when the infrastructure would be on a private network. Here's
> a brief network diagram of such a setup.
> wireless client - - - wireless infrastructure ---- service
> gateway/captive portal ---- internet
> public ip private ip private
> public ip
> Although I haven't tested this on a m0n0wall yet, I think in theory it
> should work. My only concern is the DHCP server on the m0n0wall. I
> don't believe the dhcp server on the m0n0 can assign a network range
> that is differerent than the dhcp servers interface ip address. Any
> thoughts on supporting this dhcp server shared-network concept.
You don't show which piece(s) of the diagram are m0n0wall-based.
Assuming is the piece that looks like:
> - wireless infrastructure --
> private ip private
There is a small problem, the "wireless client" (with a public IP) will
need a default route which
is reachable on the "LAN" (wireless, presumably), and thus, the " -
wireless infrastructure --" device
will need to provide same.
There are a number of ways I can see making this work, but its not
clear from your diagram what you're looking for, so I'm hesitant to
> Thanks in advance,
> Jim Thompson wrote:
>> On May 16, 2005, at 4:48 PM, Jim Wang wrote:
>>> Jim Thompson wrote:
>>> On May 16, 2005, at 4:32 PM, Jim Wang wrote:
>>>>> What's the highest reported number of simultaneous users on a
>>>> This is one of those "how long is a rope" style questions. What
>>>> are your "simultaneous users" doing, which hardware are you running
>>>> on, etc?
>>> JIM: Wireless clients connected to a citywide wireless network.
>>> We're going to be evaluating it on a net4801. If all looks good
>>> it'll be installed on a 1U Dell Rack Mount Server, but what are
>>> your suggestions.
>> You'll need to specify what the clients are doing.
>> Lets assume that you've got two thousand APs all talking back to a
>> single gateway over a wired network, and that these APs all have a
>> single associated client, and that they're all in lead-lined rooms,
>> so none of the clients or APs co-interfere.
>> For reasons I won't got into here, you can get about 446 TCP segments
>> per second through an 802.11b link. Assuming that each TCP segment
>> has 1460 bytes of payload. Thus, 1460 x 8 x 446 yields a throughput
>> of approximately 5.21 Mbit/s for the 802.11b wireless LAN component
>> of the network path.
>> This is a reasonable 802.11b upper bound throughput limit of TCP
>> end-to-end performance with the long 802.11b preamble. Using a short
>> 96-bit preamble we get an even better throughput of approximately
>> 6.28 Mbit/s.
>> Using 802.11a, or 802.11g with no "11b protection", you can get about
>> 2000 TCP segments per second through the link. Thus, 1460 x 8 x 2000
>> yields a throughput of approximately 23.36 Mbit/s for the 802.11a or
>> 802.11g part of the path..
>> So, assuming that you've got users who transfer big files (P2P
>> anyone?) while sitting in small rooms,
>> and your 1U dell (wouldn't you rather have something with no moving
>> parts (disk drives?) if so, see me off list) has a couple Gigabit
>> Ethernet interfaces, and that m0n0wall's performance will be
>> approximated by FreeBSD's performance on the same hardware (its the
>> same kernel, after all)
>> (Wherein we can fill a 100Mbps path with any recent version of
>> FreeBSD using a Celron)
>> On all but very recent mobos, the PCI slots are 32 bit, 33MHz. This
>> means they can in theory transfer at speeds of 133MB/s. Since the bus
>> is shared between many parts of the computer, and due to timing
>> constraints, it's realistically limited to around 80MB/s in the best
>> case (and constant load).
>> Gigabit network cards (*) provide 1000Mb/s, or 125MB/s, in theory.
>> However, if the PCI bus is only capable of 80MB/s this is a limiting
>> factor for gigabit network cards. Assuming the 80MBps, or 640Mb/s,
>> you can do the math above.
>> However, your traffic mix probably isn't steady-state maximum-sized
>> packets. Nor are your 802.11 installations free of interference
>> (even if you do work for Tropos :-). As the packet size goes down,
>> the throughput on the 802.11 links will drop (faster than the
>> throughput on an equivalent Ethernet link would drop). Assuming
>> you've got the CPU and Ethernet cards to deal, you will probably
>> find that the freeBSD router is not the source of your throughput
>> choke point.
>> (*) Note that GigE cards that deal in Jumbo frames aren't going to
>> help you here.
>>>>> Has anybody compared the m0n0wall with a MikroTik router?
>>>> mikrotik is linux. 'nuff said.
>>> JIM: Hmm. OK :-)
>>> JIM: Has anybody used the m0n0 under a WISP application and
>>> authenticated to Airpath. Here's a description from Airpath's
>>> website of what they do.
>>> Airpath is the preferred OSS and Roaming hosted solutions provider
>>> for wireless ISPs, service providers, network providers and systems
>>> integrators focused on wireless broadband services delivery for
>>> to cafes and campgrounds. Airpath-enabled carriers are able to
>>> quickly negotiate, activate and settle roaming agreements with
>>> other carriers. Airpath is making the fragmented nature of wireless
>>> broadband availability a thing of the past.
>> I was the CTO @ Wayport from founding until 2001. Airpath has no
>> carrier relationships, and no relationship with anyone other than ...
>> other companies like them (iPass, FatPort, etc). Complete
>> You want roaming? Get a big 802.1x cloud with RADIUS servers that
>> can locate "provider X" going.