Bruce123

Its under Configuration, Wired, VLAN. You then have to link this VLAN to an ESS; Configuration, Wireless, ESS, VLAN Name. Assuming you're tunneling between AP and Controller, this VLAN has to exist on the switch the controller is connected to. Thanks, Bruce.

The Netgear

We had the above switch and experienced a similar issue, I am not sure we ever got to the bottom of it. It *may* have been a loop, or some kind of firmware issue. It was many years ago... Thanks, Bruce.

I am sorry, are you asking why DFS events we are experiencing could be an issue for the wireless / connected devices? Or are you asking why we are experiencing this level of DFS events? The data suggests a lot of these DFS events are actually "false positives" (why would weather radar decease at half term week?) It's not just the re-association time, it's the issue of contention on the single channel when APs drop down to the same (non-DFS) channel. That depends very much on how the wireless network is being used, who is using it and what level of service they expect. In our case, it matters. Much of the advise I've read online is to avoid DFS channels (if at all possible) for this reason. Again, are you saying you don't experience any DFS events on the two ends of the links? Or do you not monitor this? Which DFS channel is it setup to use? Or, that you are experiencing DFS events, but that you don't notice it causing any issues on the link? If it's a point-to-point link, does it really need to use any DFS channels at all? Could it not just be setup to use the one 80Mhz non-DFS channel? We use DFS channels in-doors to reduce the contention in the airwaves generated by clients/APs (i.e. more collision domains), but in a directed point-to-point this wouldn't be an issue. Kind Regards, Bruce.

I would agree a good starting point would be to eliminate (or not) Meru, by connecting them to another AP from another vendor for example. I would also try connecting a small number of devices (using the QR card method) to see the problem relates to number of devices trying to connect simultaneously. You mention ping times, where are you pinging? Maybe it's a problem further down the line (not between AP and device). But, off-the-top-of-my head it would seem to be a contention issue, with too many devices trying to send/receive too much data. If this SSO works by simply and crudely sending multiple pictures or even video from the webcam to a server until authenticated, then this could generate an awful lot of data per Chromebook. Multiply it by the number of Chromebooks and you potentially have a problem. If the SSO is an App, then maybe it can't do any local processing (doesn't have permission) and has no option other than to stream the video / photos over wireless to a server? The fact that you don't experience any issues with the other (text-based) authentication method suggests this could be the problem. Go to Monitoring -> Wireless Statistics on the controller and check for high Channel utilization, high Loss % and high Retry % on the particular AP/band they are connected to. These values are updated every 60 seconds. If these look high during this period, then it could indicate an issue with contention. Kind Regards, Bruce.

I logged the number of DFS events over our half-term week (13-17 Feb Mon-Fri) and there is about half the number of events compared to a term-time week Mon-Fri. There was some wireless usage even over half-term by a small number of classes, which might explain the increased compared to the weekend. The first week shown is a term-time week (for comparison) and the second week shown is during half-term week. I think the power reduction strategy only works (up to a point) because typical clients don't typically transmit at the maximum power permissible by the standard (i.e. 200mW ERP for 5Ghz and 100mW ERP for 2.4Ghz, if memory serves). In additional to this, their antennae tend to be smaller with significantly lower gain. So I imagine a typical mobile phone's (or laptop) transmit "coverage" is probably a lot less than an AP's transmit "coverage". We did consider the one layer per floor strategy, but there are disadvantages; 1) If there are a high density of clients on a particular floor, you could still end up with too high channel utilization on the floor. 2) We would probably need to utilize DFS channels, as the two 40Mhz non-DFS channels probably wouldn't be sufficient to avoid contention between 3,4,5 floors. And by putting all APs on one floor into the same DFS channel it could put wireless on the whole floor "at risk" if all APs on the floor drop down simultaneously. Although I guess they may be able to roam to the layer on the floor above or below. However, this strategy is mentioned in one Meru's guidance documents we found on layering. I think you are right about a high number of APs within range of each other causing issues with single cell when there are multiple areas of high density. The DFS detection issue probably relates to an algorithm embedded on the WiFi chip-set of the AP, which for the 832 would appear to be a Broadcom chipset. The DFS event is reported by the Chipset to the OS of the AP, and then onto the controller itself. But I just wonder if this particular chipset has more issues with false positives when used in a virtual cell, compared to micro cell? Kind Regards, Bruce.

I monitored the number of DFS events logged each day for one week and there is a close correlation with the amount of WiFi usage here in the College (high usage Mon-Fri and very low Sat-Sun), suggesting that most of these events are actually "false positives" (see image). Perhaps caused by WiFi frame collisions and the AP seeing the resulting corrupt frame as "potentially a radar signal", or misbehaving WiFi clients? Thanks, Bruce. DFS Radar Events.bmp

We have an eleven story building with 90 832 APs (average of 8 per floor), the AP with the highest neighborhood counter on 5Ghz band is (predictably) located on the middle of the 5th floor (i.e. central to all the other APs), the count is currently 26. The AP with the highest neighborhood counter on the 2.4Ghz band is 45 (also located centrally). We could probably do with reducing the power on the 2.4Ghz band further... We aren't so bothered about the the 2.4Ghz band as we use band steering to 5Ghz, resulting about 20% of clients connecting on 2.4Ghz. We're trying out layering (for both 2.4Ghz and 5Ghz) and it's working well to increase the available bandwidth (/reduce contention) in those areas of high client density, but we are experiencing occasional DFS drop-outs. Re the level of support, sometimes it can be good, but they are too eager keen to close the job quickly, without waiting for feedback on whether the solution has worked. Fortinet didn't provide any help/advise on with reducing the power on APs or nor channel layering, it's something worked out for ourselves. Thanks, Bruce.

We are using Meru/Fortinet's Virtual Cell operating on a single non-DFS 80Mhz channel and it works well for what it was designed for ("zero handoff"). The problem is, it struggles in areas of high client density (there is just too much traffic on the single channel). So we are testing "channel layering" with DFS channels (which are the only other 5Ghz channels available). It resolves the contention issue in the areas of high client density, but we would ideally like to reduce the frequency of "radar" detection events (which causes the affected AP to drop to the main non-DFS channel / merge back into the main virtual cell for 30 minutes, before trying the DFS channel again). Thanks, Bruce.

We have been testing the use of DFS channels (in the 5Ghz band) and are experiencing quite frequent "radar" detection events, which is causing the affected AP to drop to a non-DFS channel for 30 mins, before trying again. Unfortunately, the majority of channels on the 5Ghz are DFS: Number of 80Mhz wide channels: 1 non-DFS and 4 DFS Number of 40Mhz wide channels: 2 non-DFS and 8 DFS Number of 20Mhz wide channels: 4 non-DFS and 16 DFS Which doesn't leave us much to play with (in fact it's not much better than 801.11bg 2.4Ghz, where there are 3x 20Mhz channels available) I just wondered if anyone else were using thee DFS chnanels, and if so how many radar events are being detected? Is there anything that we can do to reduce the number of these events? (I suspect that some are false positives). Perhaps using 40Mhz wide channels could half the probability of a radar signal being detected? Kind Regards, Bruce.

I'd like to try this, but I'd have to get two half decent USB WiFi adapter's (with good aerials), as it will need to extend the range too. The problem is, I could purchase the Pi 3 and two (compatible) adapters and still not get it to work properly (and I have already spent money on two devices that don't quite work...) Thanks, Bruce.

It's an FE College with 4 internet connections to Janet (3x 1Gbit and 1x100Mibt), and each connection has a public IP, which isn't shared with anyone else. Having read the article posted at the end, I think it could be due to particular apps installed on user's own BOYD devices or particular Chrome extensions (on domain joined desktops or Chrome devices). The problem is, I imagine it's quite hard to identify the cause(s), and I can only see this problem getting worse... Thanks, Bruce.

Correct

Just to update people on this issue. We have largely resolved the issue through a combination of methods; 1. Reducing power to APs We ended up turning down the power on each band: 2.4Ghz: 20 to 18dB 5Ghz: 23 to 18dB This reduced the highest neighborhood counter on the 5Ghz band from 50 to 33. 2. Turning off certain APs where APs are densely located. 3. Implementing channel layering in areas of high density (i.e. cabinets of Chromebooks). As we operate a 802.11ac 80Mhz single channel virtual cell (primary channels 36,40,44,48), the only other channels available to use for layering are DFS channels (3x 80Mhz wide channels and 1x 40Mhz wide channel) . But there is a surprising number of "radar detection" events on these channels, causing the affected AP to drop to the non-DFS 80Mhz channel for 30 minutes (merging back into the main virtual cell channel layer), before trying again. 4. Band steering to 5Ghz The AP logs showed the Chromebooks intermittently switching between bands (to switch between bands it has to drop the link and re-establish it unlike switching between channels on the same band which is basically just a roaming operation). I am not sure why this was happening, perhaps an issue with virtual cell or perhaps this happens when the Chromebook detects high utilization on the band/channel and decides to switch. 5. Ensure all APs within same area connect to the same controller. We had a case where the APs in one building connected to one controller and the APs in the adjoining building connected to another (licensing reasons). This was causing issues as the controllers couldn't cooperate to schedule the transmission of frames in the virtual cell. I notice that version 8 of SD introduces a feature that allows cooperation between controllers, so this wouldn't be an issue. 6. Positioned distribution layer switch stack between controller and core layer 3 switch. The addressed an issue with a large ARP table (wireless clients) on the core. 7. Firmware upgrade to Bloxx We use Bloxx as a transparent proxy, it would intermittently seem to stop operating as a transparent proxy (for a few seconds), which seems to have been resolved on the latest firmware 8. Upgrade SD to V8.1 (as pointed out - not available for 320i APs). This seems to have resolved the issue where APs intermittently stop allowing clients to connect, requiring a reboot of the AP. It also introduces Auto Radio Provisioning for "Native Cell" (Micro Cell), which allows the controller to automatically select the best channels/power. We may try also try disabling the very low connection speeds on the APs (as advised here and elsewhere) and enable 802.11k and 80.211r. Moving forward: we are looking at switching from Virtual Cell to Native Cell (40Mhz wide channels). The choice of 40Mhz channel width is the "best" a trade off between number of channels and bandwidth per channel. It would provide us with 2x non-DFS channels and 8 DFS channels, which should be sufficient to minimize overlap (co-channel interference) between nearby APs (lower neighor counter), but also provide each AP/client with sufficient bandwidth (on testing a realistic throughput of 150Mbit for single a .ac client connected to a single 832 AP). Kind Regards, Bruce.

Hi, I am looking for a device that will connect to an existing wireless network and create wireless network with separate SSID/key and NAT route between the two. I already have a device that will do this ( PR2000 | WiFi Routers | Networking | Home | NETGEAR ), but it is limited to 2.4hz and will only operate on one channel at a time (i.e. the new hotspot is always on the same channel as the wireless network it connects to which limits performance somewhat. The other issue with it is that the built-in antenna isn't very good, so the received/transmitted signal is weak. I recently purchased this ( EX6120 | WiFi Range Extenders | Networking | Home | NETGEAR ), it solves the latter two issues; good receive / transmit strength and can create a new network on a different band or channel to the network it connects to. However, as it is designed as a "range extender" it only "bridges" the two networks and doesn't perform routing (NAT) or DHCP on the wireless network it creates. Any ideas? I want to used it to connect to a web authenticated wireless network, so once a device of mine is authenticated on the personal network, all connected devices are authenticated (due to the authentication server seeing all devices coming from the same IP/Mac). Many Thanks, Bruce.

I did notice a clause on the agreement to say that I have checked the signal where I live and it is OK. Whether they could use the clause to refuse cancellation of the contract? I don't know... "I've done a 4G coverage check and understand that if I change my mind about a device I can't return or exchange it." (I am not sure if this implies I won't be able to return it if the coverage is not OK? It looks like they may be trying to link the two parts of the statements in an unclear way). Anyway, this is a point of principle for me, they shouldn't be showing customers ex VAT prices and comparing them to prices that include VAT to give the impression of a bigger discount than there really is, then adding VAT afterwards once the customer has made a decision based on misleading information. Kind Regards, Bruce.

According to https://www.asa.org.uk 3.18 Price statements must not mislead by omission, undue emphasis or distortion. They must relate to the product or service depicted in the advertisement. 3.19 Quoted prices must include non-optional taxes, duties, fees and charges that apply to all or most buyers. However, VAT-exclusive prices may be given if all those to whom the price claim is clearly addressed pay no VAT or can recover VAT. Such VAT-exclusive prices must be accompanied by a prominently statement of the amount or rate of VAT payable. However, I don't know if they are getting around the law by whipping out the pricing page in-store and then hiding it again? They could claim that it's not advertising. I still think that putting two price lists side-by-side ("for comparison" in her words) (one inc VAT and one not) isn't fair selling practice. Many Thanks, Bruce.

We're still within 14 days, but when I asked during the sale they told us that the "cooling off period" doesn't apply as it wasn't sold at a distance (online, mailorder, phone) and any refund would be at the manager's discretion. Thanks, Bruce.

I assisted my sister in upgrading her EE PAYG to 12 month SIM-only. We went into a EE shop and explained with wanted to go from PAYG to 12m SIMO. She explained that as an upgrading customer there are better details and showed two pages: For new customers For existing customers The 12m 500min, 500MB deal was £14.99 for new customers and £9.99 for upgrading customers. The latter seemed like a good deal (as it was £5 less than the normal price), so she signed up. However, it only became apparent after receiving the first bill, that £9.99 price was excluding VAT. I'm fairly sure first page of prices (for upgrading customers) excluded VAT and the 2nd page (for new customers) included VAT. She took these sheets away pretty quickly so I couldn't take them away with me. On checking the agreement she signed, the sales staff hand-wrote "Pre to post £9.99", but printed above it was "Offer details (Excluding VAT)", so I guess we should have checked it before signing. But is it legal to show prices in store that exclude VAT (with no writing to say this) and show another sheet side-by-side that does include VAT, not a fair comparison I would say? To be honest, I was "conned" by EE several years ago (they showed me prices in-store that they said were discounted, but as it turned out they excluded VAT), but I never bothered to chase it up with them. Many Thanks, Bruce.

From what I've read about how band steering works, it shouldn't cause any significant issues with connectivity: With Band steering to 5Ghz enabled: The AP stops sending beacons on the 2.4Ghz Band (or hides them). So devices that employ "passive scanning" will not see the AP on 2.4Ghz, only 5Ghz. Devices that employ "active scanning" will send a probe (on each band that it supports). If the AP receives a probe on both bands (or 5Ghz only), it will only respond on 5Ghz and the device will connect at 5Ghz. If the AP receives a probe on 2.4Ghz, it will respond on 2.4Ghz and connect at 2.4Ghz. Therefore the only clients that might have issues connecting are 2.4Ghz-only (legacy really) devices employing passive scanning (e.g. to save power). I did wonder whether band steering may be having a detrimental affect, but from what I have read and understand, it shouldn't. But whether that is the case in practice, is another matter... Many Thanks, Bruce.

Yes, we have previously raised a ticket for this issue and was advised to update the firmware to the most recent, which we did in June. Initially it seemed to resolve the issue as and the release notes referred to the update fixing a stability/connectivity issue, it looked promising.... However, I am now wondering if the issues only subsided because the client count dropped substantially over the Summer period. I also understand that we were informally advised to reboot the APs periodically. I have raised another ticket for the issue and we will see what comes of it... Thanks, Bruce.

I agree with this entirely, Fortinet should be focused on fixing the stability of the firmware on their APs above anything else (e.g. rebranding/adding features). It is clear from the forums that this issue has been present through a range of firmware versions with no fix yet. It has to be an issue with their firmware because when it occurs it prevents all clients from connecting (not vendor specific). Whatever the interactions the clients are having with the APs, an AP should never end up in the state where the only solution to reboot it. It sounds to me like there is some kind of memory leak or something similar in the processes running on the APs. Also, this is especially disappointing when you consider this is supposed to be "enterprise class" equipment (with a price tag to suite) and even a basic home broadband router can stay online for months/years without needing a reboot. Kind Regards, Bruce.

832e, 832i and 332i. Thanks, Bruce.

Sorry, do you mean Fortinet support were good with modifying some of RF settings, turning down the aggressiveness of roaming and slightly reducing the power on large block APs? Because with the support jobs we have opened, they have never got as far as tinkering with settings, they just confirmed that they looked to be OK, but perhaps they have been too focussed on (what we believed to be) a Chromebook specific issue. Yes we are using them in large groups at the same time (and APs are located quite densely within the buildings). We have classes of up to 30 Chromebooks in use in a classroom at a time. We own several thousand of the HP Chromebooks (G3s and G4s). The network adapter on G4 is Intel 7260NGW . But the Acer Chromebook we've also been testing has been rock solid (no drops in connection). What we've realised is that just adding additional APs doesn't increase/aggregate bandwidth when operating in Virtual Cell mode (unlike standard multi cell networks, where AP can operate on different channels). Looking at Monitoring -> Wireless Statistics on the controller reveals that many APs are experiencing high noise levels (-90db) and many see a high number of neighboring APs (up to 50). Some others have a high tx loss rate of up to 50%, but what any of this means.... As regards to Virtual Cell. I am seriously wondering if we might be better off without it. Out of interest, do you have band steering enabled on the controller? We have band steering to A band (5Ghz). In relation to the inability to modify wireless settings on the Chromebooks, it occurred to me on my drive home yesterday that ChromeOS is based on Linux, so I am going to do some research to see if there is a standard location on Linux where the settings are stored, and could they be in the same location on the Chromebooks. I will try lowering band steering aggressiveness and roaming aggressiveness (and maybe even disable 2.4 altogether). Mine you, whether the change will invalidate their warranty is another matter.. Kind Regards, Bruce.

Good afternoon, We've been experiencing issues with our HP Chromebooks (models G3/G4 and G5) connecting to Meru WiFi and wondered if anyone else had noticed any problems. The issue users are experiencing is intermittent drop in connection (the users sees the wifi icon on the status bar, drop and re-establish intermittently). We ran some logs for the stations affected (from the controller) while they were experiencing the issue and sent them to Meru and they say they indicate the device is switching between 2.4Mhz and 5Ghz, but don't know why. Initially they asked us to reduce roaming aggressiveness on the adapter on the Chromebooks (actually I think lowing Band Steering aggressiveness on the client might be more appropriate). I explained that none of the properties can be changed on Chromebooks (I had to facilitate remote access to prove it), so they are now asking us to setup a separate SSID that only broadcasts on the 5Ghz band, so they never try to change band. Anyway, I was just wondering if anyone knew of any way to adjust the wifi adaptor settings on Chromebooks? Is there a text file containing these values? We can get root access via developer mode, so if it is there we should be able to modify it. In summary, I think there is some kind of incompatibility between Meru's Virtual Cell Technology (where the clients see all APs as a single AP with one MAC address operating on one channel). I have a theory that might be happening is the Chromebook is picking up a poll frame from a distant AP with a weak signal (as well as a string signal from the closest AP), wrongly assume the signal is weak on that band and switch to a stronger signal on the other band. Kind Regards, Bruce.