Re: [pfSense-discussion] Captive Portal on pfsense
Chris Buechler schrieb: On Tue, Jul 15, 2008 at 8:38 AM, muhammad panji [EMAIL PROTECTED] wrote: Dear All, Hi I start searching for option to implement captive portal on my campus hotspot and I think pfsense captive portal will make it easier. I'm not really familiar with wireless technology. If i'm not false my campus bought some Linksys WRT54G Wireless Router. I want to ask : - What is the difference between Linksys WRT54G and Linksys WAP54G in case of how the basically operate. Up to now what I know is WAP do bridging to wired network and WRT do routing. You would likely deploy WRTs in bridged anyway since you're using them as just APs, so for your purposes the two should be functionally equivalent. - If I have four Access Point is that mean That I have to have four different network which routed to pfsense LAN network? No, you can bridge all four to the same network. If you have more than one AP, don't you need ones that can do mesh-networking, so you can hand-over a connection to another AP, in case the user moves? I'm not very familiar with building large-scale WLANs, but AFAIK, it's a little more than just buying enough APs and placing them in the right spots... cheers, Rainer
Re: [pfSense-discussion] Captive Portal on pfsense
On Wed, Jul 16, 2008 at 11:22 PM, Bill Marquette [EMAIL PROTECTED] wrote: Considering that you are talking about the Linux variant of the WRT54G, I think it's safe to say that Chris probably assumed you were not running the stock Linksys firmware on it. Actually that is what I meant - you can do as David Rees mentioned in this thread and run the WRTs with stock firmware as just a bridged AP. I run one at home that way. The stock firmware bridges the AP to the switch ports. Just don't use the WAN port and disable DHCP server and you have a bridged AP.
Re: [pfSense-discussion] Captive Portal on pfsense
RB wrote: I'm not very familiar with building large-scale WLANs, but AFAIK, it's a little more than just buying enough APs and placing them in the right spots... I am, and it actually is just that. If you already have UTP ports within 300' the AP locations, it's by far the most effective route - then you only have to worry about channelization and overlap. That's what I was thinking: isn't it a problem to have to APs with same SSID (and maybe the same channel) in reach of each other? Don't the clients get confused? Or are the drivers usually smart enough not to flap between the two? Sorry, I'm just curious... Regards, Rainer
Re: [pfSense-discussion] Captive Portal on pfsense
That's what I was thinking: isn't it a problem to have to APs with same SSID (and maybe the same channel) in reach of each other? Don't the clients get confused? Or are the drivers usually smart enough not to flap between the two? Many righteous WLAN cards have the election process hard-wired, and some can even be tweaked by driver. Others that are the radio equivalent of a WinModem do it completely in software, but the net result is that [nearly] all of them are wise enough to roam only when necessary. Adjacent BSSIDs (APs for this discussion) on the same channel can make it hard for some devices to elect and they will waffle, but that can usually be solved by moving two feet and channelization, which itself is a lecture for another day/place. Sorry, I'm just curious... Not a problem - we all are in some form or another. Glad to help.
Re: [pfSense-discussion] Captive Portal on pfsense
Assuming you want continiois coverage, same channel is actually best, unless you can go cross-band, which impacts roaming. The number of people who don't understand this, and instead want to talk about 3 non-overlapping channels and other cr*p is amazing. Same ESSID is what you want, too. Jim On Jul 17, 2008, at 4:58 AM, Rainer Duffner [EMAIL PROTECTED] wrote: RB wrote: I'm not very familiar with building large-scale WLANs, but AFAIK, it's a little more than just buying enough APs and placing them in the right spots... I am, and it actually is just that. If you already have UTP ports within 300' the AP locations, it's by far the most effective route - then you only have to worry about channelization and overlap. That's what I was thinking: isn't it a problem to have to APs with same SSID (and maybe the same channel) in reach of each other? Don't the clients get confused? Or are the drivers usually smart enough not to flap between the two? Sorry, I'm just curious... Regards, Rainer
Re: [pfSense-discussion] Captive Portal on pfsense
I'm happy to respond more fully to this: A) off-list, and B) when I'm back at my desk The short answer is, I don't know because I don't have your data, but what assumptions did your modeling make about adjacent channel rejection figures and CCA thresholds on the clients? By staying co-channel, you increase the likelyhood of coherent recovery of the preamble, which greatly aids CCA. Most 11g/11a chipsets aren't selective enough for three (or even two) channel operation. While you could obtain the requisite selectivity, via (say) filtering or a better receiver front end, you are unlikely to change the client receivers. Even weak adjacent channel transmitters will cause enough in-band signal to de-sense a receiver, which the receiver sees as noise, directly decreasing SNR, and in-turn impacting both range and recovery of higher order modulations. APs, by definion, are strong emitters. Jim On Jul 17, 2008, at 12:28 PM, RB [EMAIL PROTECTED] wrote: On Thu, Jul 17, 2008 at 4:01 PM, Jim Thompson [EMAIL PROTECTED] wrote: Assuming you want continiois coverage, same channel is actually best, unless you can go cross-band, which impacts roaming. The number of people who don't understand this, and instead want to talk about 3 non-overlapping channels and other cr*p is amazing. Jim, I respect the fact that you've been in the industry considerably longer than me and have likely forgotten more than I know, but what technical knowledge can you share with us to back a statement like that? I'm by no means an expert, but the knowledge I'm going on is pulled from having managed ~500k devices and their networks across ~8k sites. Are you saying that the extensive RF propagation calculus we did and compared with hundreds of hours of real-world testing were completely wrong? I'm open to that, but I'd really be interested in the why. RB
Re: [pfSense-discussion] Captive Portal on pfsense
On Thu, Jul 17, 2008 at 7:02 PM, Jim Thompson [EMAIL PROTECTED] wrote: I'm happy to respond more fully to this: A) off-list, Jim, I'd encourage you to keep it on-list, a number of us have learned quite a bit from sharing of your expertise over the years. It may not be precisely on-topic for this list, but it's completely appropriate.
Re: [pfSense-discussion] Captive Portal on pfsense
They most likely are getting it from Cisco of all places. Cisco talks about using 3 non-overlapping channels when establishing a multi-AP roaming wireless network with their APs, and they explain the reasoning behind it in their documentation. Bottom line, if there is too much overlap on the same channel the device may have issues with hearing the AP it is trying to connect to. I'm not going to get into the right or wrong here as what works with one may not with another AP/device, but their method does work at least with their own APs. I've implemented a multi-AP wireless network in a large sub-zero freezer warehouse of all places using their APs and every AP is on a different channel than an adjacent AP. The hand-offs are clean and quick as the signal strength drops from one AP and they see the next one on a different channel. The users run around on forklifts with wireless scanners so their movements are fairly quick also. Ron On Thursday 17 July 2008 15:01, Jim Thompson wrote: Assuming you want continiois coverage, same channel is actually best, unless you can go cross-band, which impacts roaming. The number of people who don't understand this, and instead want to talk about 3 non-overlapping channels and other cr*p is amazing. Same ESSID is what you want, too. Jim On Jul 17, 2008, at 4:58 AM, Rainer Duffner [EMAIL PROTECTED] wrote: RB wrote: I'm not very familiar with building large-scale WLANs, but AFAIK, it's a little more than just buying enough APs and placing them in the right spots... I am, and it actually is just that. If you already have UTP ports within 300' the AP locations, it's by far the most effective route - then you only have to worry about channelization and overlap. That's what I was thinking: isn't it a problem to have to APs with same SSID (and maybe the same channel) in reach of each other? Don't the clients get confused? Or are the drivers usually smart enough not to flap between the two? Sorry, I'm just curious... Regards, Rainer
Re: [pfSense-discussion] Captive Portal on pfsense
at the risk of talking about cisco gear on a freebsd list, they're full of it. In 802.11 the client gets to 'pick' the AP it associates to. Scanning (which is a client activity) off channel takes more time than scanning on-channel. Thus, a client could pick an AP 'on-channel' more easily than an off-channel one. too much overlap is laughable. Perhaps you refer to this: http://www.cisco.com/en/US/docs/wireless/technology/channel/deployment/guide/Channel.html Note how they *ONLY* speak to transmit masks? Note how they *never mention* adjacent channel rejection or adjacent channel interference? This paper from TI touches on the topic. http://focus.ti.com/pdfs/bcg/80211_acr_wp.pdf Its true that the transmit masks of the non-overlapping channels (1, 6, 11) don't overlap. But none of the 802.11b radios on the market have enough selectivity to eliminate in-band signals from an adjacent (25Mhz away) or alternate (50MHz away) channel. Minimum IEEE specs for a 11b receiver is 35dB of adjacent (25MHz away) channel rejection. IEEE doesn't publish specs for alternate channel rejection on 802.11b, but I can tell you that the best designs (in terms of ACR) are the old super-het receivers. Intersil (now Connextant)'s Prism2/2.5 is good for about 41dB of ACR. Alternate channel rejection is perhaps 20dB more with this chipset. That means that if you're operating (your Prism 2/2.5 chipset radio) on channel 11, a signal on channel 1 will be 60dB down from where it would be if your radio was on channel 1. We run into a lot of (sales) situations where the competition likes to claim that they can co-locate APs. You can't. Here's why: Free Space path loss in the first meter @ 2.4GHz is 41dB. Lets say you've got a garden-variety radio that puts up 32mW (15dBm) of tx power, and ignore antenna gain for now (so 0 dBi antennas on both radios). 15dBm - 41dB - 60dB = -86dBm This is the in-channel 'noise power' of the alternate channel radio. Notice that it is at least 15dB above the thermal noise floor. Translated: you've lowered your SINR. Moreover, this signal level is 10dB higher than the CCA threshold, so you'll quiesce the entire cell (no matter which radio was trying to operate) whenever one transmits. (Its worse than this, if one radio was receiving, you've destroyed the incoming packet(s).) Thus, in 802.11b, even if you pick 1 and 11, you're going to end up with significant in-channel power from any operate on the alternate channel by a close-by transmitter. For this reason, the minimum AP separation with 2dBi antennas on channels 1 and 11 is around 10m. Any closer and you're raising the noise floor in any AP or client that is receiving a packet. Now, if you add any antenna gain to the equation, then, unless you manage to find really special antennas, (or use channel filters, etc) then the gain of both antennas affects the above in a negative way. The situation is (much) worse with 11g/11a. Due to their (quite common, but non universal) direct conversion archectures, and some interesting properties of OFDM, most 802.11g receivers can't muster even the 35dB of ACR that the IEEE specifies when operating in the 802.11g/a modes. It varies by modulation rate, but the minimum ACR for 802.11g/a at 6Mbps is 16dB (alternate is 16dB more, for 32dB). This goes down to -1dB (yes, -1dB) ACR @ 54Mbps (with alternate channel rejection at 54Mbps down to 15dB.) If you try the obvious experiment, be sure to make sure that you've got the same range from both cards operating as from one card operating. 1) establish range for first card with no second card operations 2) enable 2nd card 3) re-check range of 1st card while 2nd card is under full operation (passing a lot of traffic) You'll find it appears to work if the clients are at close range. But the thing you really have to understand is this: In wireless, it is a sin to throw a received packet on the floor. You really can't afford to have a near-by AP think the air is clear (because its off- channel) and then stomp on the reception of some near-by AP or client. In co-channel operations, there is a function called Clear Channel Assessment (CCA) that holds any given radio from transmitting if either a) there is a strong signal using the wireless medium, or b) there is a somewhat weaker signal, which is clearly an 802.11 signal (that is, this radio has decoded the pre-amble). We did a bit of work at Vivato to make N radios (13 in the 11b product, 6 in the 11g product) synchronize via the CCA signal, such that if any of them was receiving a packet, none of the others would transmit. The issue at Vivato was that the 'antennas' for these radios were pointed in different directions, so the actual signal level might not be high enough to set CCA, but any of them transmitting would ruin the reception at any other. Jim On Jul 17, 2008, at 1:51 PM, Ron Lockard wrote: They most
Re: [pfSense-discussion] Captive Portal on pfsense
On Jul 17, 2008, at 5:36 AM, RB wrote: That's what I was thinking: isn't it a problem to have to APs with same SSID (and maybe the same channel) in reach of each other? Don't the clients get confused? Or are the drivers usually smart enough not to flap between the two? Many righteous WLAN cards have the election process hard-wired, well, in firmware, but even these can be over-ridden for the most part. and some can even be tweaked by driver. Others are under complete control of the driver (anything that uses athX in FreeBSD, for example) Others that are the radio equivalent of a WinModem do it completely in software, Uh, no. Sorry. You're not going to run the receiver section of an 802.11 PHY in software on your laptop. Now, some of them (anything that uses athX in FreeBSD, for example), implement a very large part of the 802.11 MAC in software. Take a look at the net80211 layer in FreeBSD. but the net result is that [nearly] all of them are wise enough to roam only when necessary. Software gets to decide 'when' in nearly all ases. Adjacent BSSIDs (APs for this discussion) on the same channel can make it hard for some devices to elect and they will waffle, but that can usually be solved by moving two feet and channelization, which itself is a lecture for another day/place. Er... adjacent BSSIDs in the same ESSID make roaming easy. Putting them co- channel makes roaming even easier (see previous message.) Note that there is some frequency-specific fading even in a static environment. Start moving things around (even if the radios don't move) and the fading gets worse. This is why you (and the radios) see SNR values bounce up and down. One issue is that some (stupid) clients will re-run DHCP on every association event, but otherwise, the 802.11 standards are mostly in place for all but seamless walking-speed roaming. See 802.11f/ IAPP, or here: http://www.cs.umd.edu/~mhshin/iapp/ See also: http://www.freebsd.org/projects/ideas/#p-wpa2preauth, and http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/hostapd/iapp.c?rev=1.1.1.3 (getting this work (or similar) into freebsd would be a win, especially if it got adopted into pfSense) Jim
Re: [pfSense-discussion] Captive Portal on pfsense
The short answer is, I don't know because I don't have your data, but what assumptions did your modeling make about adjacent channel rejection figures and CCA thresholds on the clients? I wish I had those particular numbers myself - I've looked but didn't come out of that employment with them. As Ron noted, the adjacent-channel philosophy started with Cisco recommendations. As switch jockeys are wont to do, the APs were typically configured at 50 and 100mW with 3-12dBi antennas, and channels were not always selected to be non-adjacent (the less-wireless networking guys set up the first pass at coverage). Coverage was horrible and the nine of us spent an inordinate amount of our time troubleshooting what ended up being coverage issues. After what seemed to be careful modeling (lots of highly-mobile clients steel like Ron noted as well) and analysis, we settled on 30mW + 3dBi on 120' centers. This gave us largely -67 to -72dBm client coverage on 802.11b - that was with mostly Orinoco-based (later Atheros) cards. Now that I look back at it, I don't think anyone really even questioned whether channelization was right. Roaming between cells was rapid and throughput for clients remained high without much jitter (VoIP toward the end) - we didn't seem to have reason to test any other configuration. Regardless, I really do appreciate your taking the time to explain further - as is normal, I get to thinking I understand a technology, then someone shows me how little I really do know. First glance tells me I likely have nothing to add or respond to on your other two emails. RB
Re: [pfSense-discussion] Captive Portal on pfsense
On Thu, Jul 17, 2008 at 8:11 AM, Chris Buechler [EMAIL PROTECTED] wrote: On Tue, Jul 15, 2008 at 8:38 AM, muhammad panji [EMAIL PROTECTED] wrote: Dear All, Hi I start searching for option to implement captive portal on my campus hotspot and I think pfsense captive portal will make it easier. I'm not really familiar with wireless technology. If i'm not false my campus bought some Linksys WRT54G Wireless Router. I want to ask : - What is the difference between Linksys WRT54G and Linksys WAP54G in case of how the basically operate. Up to now what I know is WAP do bridging to wired network and WRT do routing. You would likely deploy WRTs in bridged anyway since you're using them as just APs, so for your purposes the two should be functionally equivalent. Thanks for the answer Chris. Several months ago I help my friend setup his WRT54GL but as I remember this AP have no option on set it up as a bridge. Must I do a firmware upgrade? will it void the warranty? - If I have four Access Point is that mean That I have to have four different network which routed to pfsense LAN network? No, you can bridge all four to the same network. so the network diagram will look like this? AP(s) -- switch pfsensebox -- (proxy, etc) and DHCP come from pfsensebox - I will use a proxy server too, which one is better to place that proxy, before captive portal or after captive portal? You'll have to put that after the CP, otherwise you won't be able to successfully authenticate users. Ok thanks. best regards, -- Panji http://sumodirjo.blogspot.com
Re: [pfSense-discussion] Captive Portal on pfsense
On Wed, Jul 16, 2008 at 9:38 PM, muhammad panji [EMAIL PROTECTED] wrote: Thanks for the answer Chris. Several months ago I help my friend setup his WRT54GL but as I remember this AP have no option on set it up as a bridge. Must I do a firmware upgrade? will it void the warranty? Considering that you are talking about the Linux variant of the WRT54G, I think it's safe to say that Chris probably assumed you were not running the stock Linksys firmware on it. --Bill
