If I understand your plan correctly, I have a feeling you'll run into problems getting past one AP. I think you'll find that running two APs on the same SSID and the same channel, each able to hear the other, and on the same IP address, won't work. If you changed the SSID and/or channel per AP it would. But then you'd have to set your clients SSID and channel for the AP you want to connect to. Maybe I'm overlooking something, but I can't think of a way to let clients connect to any random router without them all being set to the same channel, and the same SSID, and thus the same network. After all, if you could do that, then the network return path would be unpredictable. Say what you're suggesting were possible, and you have routers A and B covering an area. A public client connects and happens to get a connection to router A. It requests a webpage. Half way through, the client moves to B. The remaining packets from the web page are still going to A, but A no longer has a connection to the client. Packets are dropped all over the floor. This problem is aggravated horribly if you want your network connection to remain intact for moving clients (you mentioned firefighers/police cars/EMT ambulances?). As far as I know, the only ways to do this are either some kind of mesh network like OLSR, or a single conventional network. But maybe I'm missing something obvious. If so, I'm sure someone who's played with multiple APs in managed mode will correct me.

On the other hand, pptp should handle the public/private thing fine. It's not quite as elegant as doing it through WPA, as you're running an extra layer of software networking, which will cut into your performance even if you don't use encryption. Also if I remember correctly pptp is an old Microsoft protocol, from the Win9x days. We all know how well Microsoft's security products tend to work. It may well be solid, I'd just suggest doing some research before you rely on it for anything important. Of course, it will work without porting a WPA authenticator to OpenWRT, which is a pretty big advantage.

thanks for the input jaka

going back to something you said before, considering that each router will have at least one private machine, that machine can be used as a RADIUS/WPA implementation.

This is getting confusing - tomorrow I'm going to have to take one side and stick with it. If I use PPTP I'll have a quick and easy solution, but if I use WPA it all could be much more work for a much greater, more powerful, and more secure final product.

As for SSIDs, thats not a problem. Each router can simply have some sort of abbreviation of like a home address, building name and apt #, or something of the sorts.

Rather than creating a mesh, it should be possible to create packet switching mechanisms that allow roaming, dont you think? Or would that just be the same as a mesh? If worst comes to worst, I can use mesh routing, and to alleviate authentication stress on the WRT i'd have a seperate private computer handle that.

Yep, having a RADIUS server per router would work fine. Though it would mean each account is tied to a particular router and its associated RADIUS server.

I'm pretty sure the WPA authenticator will have to be running on the router though.

Different SSIDs per router solves your scaling problem, but means that client machines will have to reconfigure their connection to move between routers.

I'm not sure what you mean by 'packet switching mechanisms', as any IP network is packet switched. Running it as a mesh network brings you back to the 802.11 MAC scaling problem. It will also require some client software, as you need mesh routing software running on each and every wireless node in the mesh, or at least every node that wants to roam. You can set up OLSR in such a way that normal wireless clients can connect, and will work fine as long as they stay in range of that router.

I think your summary of PPTP vs WPA is pretty much spot on. Of course, just to make life that little bit more difficult; WPA doesn't have support for ad-hoc mode networks, and OLSR only works in ad-hoc mode. Ad-hoc support is included in the full 802.11i spec though, which was ratified a month or two ago, so you'd need to make sure the authenticator you use has full 802.11i aka WPA2 support if you want to use mesh networking.

alright, so for now I'm going to use pptp over RADIUS. My project is really to show one way how this can be done, and taking time constraints into consideration, ive gotta do it with pptp.

Meshing isn't necessary, and neither is roaming, for the time being. Ultimately, I would like to add them in once i get things moving. WPA/RADIUS authentication would also come in at that step. The only problems for the time being is that I'm trying to get everything onto one router and not need networked machines to need clients.

In any case, I'm going to need to set up pptp now. Can this be done specifically on the wireless eth interface? What I'm thinking is setting it up so that the wired and wireless will no longer be bridged, and so that pptp only has to manage the wireless interface. (After all, I highly doubt wired nodes would be public.)

Let me know what you guys think.

To break the bridge I use the following command in a startup-script, but I saw other solutions for this in the forum:

brctl delif br0 eth1
ifconfig eth1 address 192.168.254.2
route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.254.1

-> means "delete interface eth1 (wireless) from the bridge); give the wireless interface an ip-address and set the new route, so everything which is not on the wired interfaces with network address 192.168.1.0 is routed over the wireless interface.

Network 192.168.1.0 means there are hosts in the range 192.168.1.1 - 192.168.1.254

If the ppptp daemon should only listen on the wireless interface for pptp clients you could easily use the argument -l when starting up the pptpd ->

pptpd -l 192.168.254.2

Once again:
Be sure to have Nicos special OpenWRT Firmware:
http://nthill.free.fr/nicowrt/firmware/
Get the pptpd and all related stuff from:
http://nthill.free.fr/nicowrt/ipkg/
Don't forget the libradius package!
Nico also described it at this forum thread (don't know if this up-to-date because there's an entry on his site  01 Jun 2004
  - new layout
    stock openwrt firmwares can be found in /openwrt/firmware/
): http://openwrt.org/forum/viewtopic.php?t=114

Get the config files from: http://nthill.free.fr/nicowrt/src/packages/pptp-server/

Wrong.

networking script:
read *_ifname
if *_ifname is br* then create bridge using *_ifnames

translation:
change lan_ifname and no more bridge.

Thank you for your correction!

hey mbm/schorsch -- how do i do what mbm just posted? where am i supposed to execute that from?

in addition to my previous post:

schorsch01/nico, does pptp only work with NicoWRT firmware? I'm just curious, as I'm sorta hesitant to reflash my router, as i just reflashed to the lastest openwrt. im going to try them on reg openwrt first.

It worked for me with Nicos firmware as I described. I don't know if Nicos patches are included in the cvs but I'm sure that you can find some docu about that.

in order to get pptp to work, do i only need ppp and then pptp-server?

correct

for PPTP to use encryption, you need a firmware with MPPE compiled in. This is now done in CVS as of 20040818.
and ppp must be patched too...

--
Nico

thanks nico - is there a guide or anything to help me get it working?

not yet, but you can find useful information on the Poptop documentation site.

basically, you need the ppp and pptp-server packages.
check settings in /etc/pptpd.conf and /etc/ppp/pptp-server-options and add users to /etc/chap-secrets (ip address allocation is done by ppp, so you must fill the 4th field)

nico  pptp-server  gazougazou  172.16.9.99

please report success/failure/problems here and remember to post your steps in the wiki

--
Nico