[ previous ] [ next ] [ threads ]
 From:  Jim Thompson <jim at netgate dot com>
 To:  Jim Wang <jim dot wang at troposnetworks dot com>
 Cc:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] Max number of reported users on a m0n0.
 Date:  Mon, 16 May 2005 22:21:36 -1000
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 
talking about
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 
offer advice.


> Thanks in advance,
> Jim.
> 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  
>>>>> m0n0wall?
>>>>  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)
>> http://lists.freebsd.org/pipermail/freebsd-questions/2004-November/ 
>> 064401.html
>> (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.
>> Jim
>> (*) 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  
>>> metropolitan area networks and venuesó from hotel chains to airports 
>>>  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.
>> Feh.
>> 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  
>> non-starter.
>> You want roaming?  Get a big 802.1x cloud with RADIUS servers that 
>> can  locate "provider X" going.
>> jim