Tech Blog

Did you know that Windows 10 supports fast roaming standards such as 802.11r/k/v?

Well it does but there’s a few caveats.

If you’re unsure what these standards are and how they operate then keep reading:

Remember, the CLIENT decides when to roam, not the Access Point!!!!

802.11k (Neighbor Reports)

Access points that have it will send out special reports of their Neighbours to the windows 10 device.  Neighbour Reports contain information about neighbouring access points so would allow a Windows 10 device to know if it can roam if it needs too. Windows 10 takes advantage of this capability by shortening the list of channels that the device needs to scan before finding a neighbouring AP to roam to.

802.11v (BSS Transition Management Frames)

Access points that support 802.11v can suggest that Windows 10 devices to roam to another AP that it believes will provide a better wireless experience.  Windows 10 devices can now accept and respond to these Basic Service Set (BSS) Transition Management frames, leading to improved wireless quality i.e. potentially better SNR or RSSI.

802.11r (Fast BSS Transition)

Fast BSS Transition reduces the time needed for a Windows 10 device to move/roam to another AP that supports 802.11r. This time reduction results from fewer frames being exchanged with the AP prior to data transfer. By moving quickly to a new AP the tranistion time will be less interupotive to the client, for example a slow move would disrupt a video call. You must be using Radius authentication (802.1X), Pre-Shared Key (PSK) and Open Networks are currently not supported.

Unfortunately there only these intel chipsets are supported with Windows 10:

https://www.intel.com/content/www/us/en/support/articles/000021562/wireless/intel-wireless-products.html

What about other clients such as MACs and RF scanners???

MACs

Yes but it depends, have a look at this:

https://support.apple.com/en-gb/HT202628

RF Scanners

Yes but it depends, for example 802.11r is support on mc9200 if the radio is updated to 2.03 so please ensure these devices are updated to the latest version.

https://www.zebra.com/us/en/support-downloads/software/release-notes/operating-system/mc9200-operating-system-standard-bsp-15-57-16-release-notes.html

If you’d like to know more on client roaming and supporting it then this video is interesting:

https://www.youtube.com/watch?v=8upYZYKXRc4

Any questions please let me know.

Had a very frustraiting issue recently where our Zebra RF Scanners werent getting DHCP addresses on certain Cisco Access Points.

Only the scanners were not working, everything else seemed fine!

So I checked a heap of things:

Data Rates

Some of RF scanners are OLD, so its important to find out what data rates they require and then match your RF profile.

I suggest you profile the scanner using sometime like a WLANPi first just so you dont have to enable any older data rates.

Or use:

Show client detail <MAC Address>

Read more about old data rates here.

Port Config

We run FlexConennect so was every port in a Trunk and did every port have have the correct vlans tags?

Trunk

Where all the vlans trunked up to the core switch?

DHCP Server

Rebooted it and everything seems fine, lots of DHCP requests from other devices etc.

To be sure I did run wireshark and there were no requests from the scanners while on the “broken” APs.

Debug, Debug, Debug

I then started these debugs and waited forced the client to join again:

From AP:
config ap client-trace address add 5c:87:9c:93:da:4b
config ap client-trace filter all enable 
config ap client-trace output console-log enable 
config ap client-trace start 
term mon

#when 
config ap client-trace stop


From WLC:
Debug client 11:22:33:44:55:66
Show client detail 11:22:33:44:55:66

So the results showthis:

When it works it looks like this:

DHCP request,

DOT11 Auth

DOT11 Association

ARP

DHCP Request

DHCP ACK

Dec 1 09:02:39 kernel: [*12/01/2020 09:02:39.6821] [1606813359:682125] [AP16] [11:22:33:44:55:66] < wifi1> [U:W] DHCP_DISCOVER : TransId 0xefec6e9f
Dec 1 09:02:39 kernel: [*12/01/2020 09:02:39.6821] [1606813359:682163] [AP16] [11:22:33:44:55:66] <apr1v0> [U:C] DHCP_DISCOVER : TransId 0xefec6e9f
Dec 1 09:02:43 kernel: [*12/01/2020 09:02:43.2458] [1606813363:245845] [AP16] [11:22:33:44:55:66] <apr1v0> [D:W] DOT11_DISASSOC : (.)
Dec 1 09:02:43 kernel: [*12/01/2020 09:02:43.2465] [1606813363:246587] [AP16] [11:22:33:44:55:66] <apr1v0> [D:W] DOT11_DEAUTHENTICATION : (.)
Dec 1 09:02:43 kernel: [*12/01/2020 09:02:43.9712] [1606813363:971275] [AP16] [11:22:33:44:55:66] <apr1v0> [U:W] DOT11_AUTHENTICATION : (.)
Dec 1 09:02:43 kernel: [*12/01/2020 09:02:43.9721] [1606813363:972101] [AP16] [11:22:33:44:55:66] <apr1v0> [D:W] DOT11_AUTHENTICATION : (.)
Dec 1 09:02:43 kernel: [*12/01/2020 09:02:43.9829] [1606813363:982985] [AP16] [11:22:33:44:55:66] <apr1v0> [U:W] DOT11_REASSOC_REQUEST : (.)
Dec 1 09:02:43 kernel: [*12/01/2020 09:02:43.9839] [1606813363:983901] [AP16] [11:22:33:44:55:66] <apr1v0> [D:W] DOT11_REASSOC_RESPONSE : (.)
Dec 1 09:02:44 kernel: [*12/01/2020 09:02:44.0783] [1606813364: 78316] [AP16] [11:22:33:44:55:66] <wired0> [D:E] EAP_PACKET.Request : Id 0x01 type 1 Identity
Dec 1 09:02:44 kernel: [*12/01/2020 09:02:44.0784] [1606813364: 78397] [AP16] [11:22:33:44:55:66] <apr1v0> [D:W] EAP_PACKET.Request : Id 0x01 type 1 Identity
Dec 1 09:02:44 kernel: [*12/01/2020 09:02:44.1278] [1606813364:127862] [AP16] [11:22:33:44:55:66] < wifi1> [U:W] EAP_PACKET.Response : Id 0x01 type 1 Identity
Dec 1 09:02:44 kernel: [*12/01/2020 09:02:44.1279] [1606813364:127968] [AP16] [11:22:33:44:55:66] <wired0> [U:E] EAP_PACKET.Response : Id 0x01 type 1 Identity
Dec 1 09:02:44 kernel: [*12/01/2020 09:02:44.1745] [1606813364:174565] [AP16] [11:22:33:44:55:66] <apr1v0> [D:W] EAP_PACKET.Request : Id 0xa7 type 25 Other
Dec 1 09:02:44 kernel: [*12/01/2020 09:02:44.1773] [1606813364:177337] [AP16] [11:22:33:44:55:66] < wifi1> [U:W] EAP_PACKET.Response : Id 0xa7 type 25 Other
Dec 1 09:02:45 kernel: [*12/01/2020 09:02:45.8440] [1606813365:843995] [AP16] [11:22:33:44:55:66] <apr1v0> [D:W] EAPOL_KEY.M1 : DescType 0x02 KeyInfo 0x008a
Dec 1 09:02:45 kernel: [*12/01/2020 09:02:45.8906] [1606813365:890656] [AP16] [11:22:33:44:55:66] < wifi1> [U:W] EAPOL_KEY.M2 : DescType 0x02 KeyInfo 0x010a
Dec 1 09:02:46 kernel: [*12/01/2020 09:02:46.0282] [1606813366: 28207] [AP16] [11:22:33:44:55:66] < wifi1> [U:W] ARP_QUERY : Sender 10.10.10.1 TargIp 10.20.20.1
Dec 1 09:02:46 kernel: [*12/01/2020 09:02:46.0282] [1606813366: 28252] [AP16] [11:22:33:44:55:66] <apr1v0> [U:C] ARP_QUERY : Sender 10.10.10.1 TargIp 10.20.20.1
Dec 1 09:02:46 kernel: [*12/01/2020 09:02:46.0291] [1606813366: 29096] [AP16] [11:22:33:44:55:66] <wired0> [D:E] ARP_REPLY : Sender 10.10.10.1 HwAddr 66:55:44:33:22:11
Dec 1 09:02:46 kernel: [*12/01/2020 09:02:46.0291] [1606813366: 29138] [AP16] [11:22:33:44:55:66] <wired0> [D:C] ARP_REPLY : Sender 10.10.10.1 HwAddr 66:55:44:33:22:11
Dec 1 09:02:46 kernel: [*12/01/2020 09:02:46.0291] [1606813366: 29187] [AP16] [11:22:33:44:55:66] <wired0> [D:C] ARP_REPLY : Sender 10.10.10.1 HwAddr 66:55:44:33:22:11
Dec 1 09:02:47 kernel: [*12/01/2020 09:02:47.0520] [1606813367: 52031] [AP16] [11:22:33:44:55:66] < wifi1> [U:W] DHCP_REQUEST : TransId 0xa68db1f1
Dec 1 09:02:47 kernel: [*12/01/2020 09:02:47.0520] [1606813367: 52070] [AP16] [11:22:33:44:55:66] <apr1v0> [U:C] DHCP_REQUEST : TransId 0xa68db1f1
Dec 1 09:02:47 kernel: [*12/01/2020 09:02:47.0555] [1606813367: 55585] [AP16] [11:22:33:44:55:66] <wired0> [D:C] DHCP_ACK : TransId 0xa68db1f1
Dec 1 09:02:47 kernel: [*12/01/2020 09:02:47.0556] [1606813367: 55636] [AP16] [11:22:33:44:55:66] <apr1v0> [D:W] DHCP_ACK : TransId 0xa68db1f1

When it doesnt, everything looks good until the end, no ACK from DHCP:

Dec  1 09:02:39 kernel: [*12/01/2020 09:02:39.6821] [1606813359:682125] [AP16] [11:22:33:44:55:66] < wifi1> [U:W] DHCP_DISCOVER : TransId 0xefec6e9f
Dec  1 09:02:39 kernel: [*12/01/2020 09:02:39.6821] [1606813359:682163] [AP16] [11:22:33:44:55:66] <apr1v0> [U:C] DHCP_DISCOVER : TransId 0xefec6e9f
Dec  1 09:02:43 kernel: [*12/01/2020 09:02:43.2458] [1606813363:245845] [AP16] [11:22:33:44:55:66] <apr1v0> [D:W] DOT11_DISASSOC : (.)
Dec  1 09:02:43 kernel: [*12/01/2020 09:02:43.2465] [1606813363:246587] [AP16] [11:22:33:44:55:66] <apr1v0> [D:W] DOT11_DEAUTHENTICATION : (.)
Dec  1 09:02:43 kernel: [*12/01/2020 09:02:43.9712] [1606813363:971275] [AP16] [11:22:33:44:55:66] <apr1v0> [U:W] DOT11_AUTHENTICATION : (.)
Dec  1 09:02:43 kernel: [*12/01/2020 09:02:43.9721] [1606813363:972101] [AP16] [11:22:33:44:55:66] <apr1v0> [D:W] DOT11_AUTHENTICATION : (.)
Dec  1 09:02:43 kernel: [*12/01/2020 09:02:43.9829] [1606813363:982985] [AP16] [11:22:33:44:55:66] <apr1v0> [U:W] DOT11_REASSOC_REQUEST : (.)
Dec  1 09:02:43 kernel: [*12/01/2020 09:02:43.9839] [1606813363:983901] [AP16] [11:22:33:44:55:66] <apr1v0> [D:W] DOT11_REASSOC_RESPONSE : (.)
Dec  1 09:02:44 kernel: [*12/01/2020 09:02:44.0783] [1606813364: 78316] [AP16] [11:22:33:44:55:66] <wired0> [D:E] EAP_PACKET.Request : Id 0x01 type 1 Identity
Dec  1 09:02:44 kernel: [*12/01/2020 09:02:44.0784] [1606813364: 78397] [AP16] [11:22:33:44:55:66] <apr1v0> [D:W] EAP_PACKET.Request : Id 0x01 type 1 Identity
Dec  1 09:02:44 kernel: [*12/01/2020 09:02:44.1278] [1606813364:127862] [AP16] [11:22:33:44:55:66] < wifi1> [U:W] EAP_PACKET.Response : Id 0x01 type 1 Identity
Dec  1 09:02:44 kernel: [*12/01/2020 09:02:44.1279] [1606813364:127968] [AP16] [11:22:33:44:55:66] <wired0> [U:E] EAP_PACKET.Response : Id 0x01 type 1 Identity
Dec  1 09:02:44 kernel: [*12/01/2020 09:02:44.1745] [1606813364:174565] [AP16] [11:22:33:44:55:66] <apr1v0> [D:W] EAP_PACKET.Request : Id 0xa7 type 25 Other
Dec  1 09:02:44 kernel: [*12/01/2020 09:02:44.1773] [1606813364:177337] [AP16] [11:22:33:44:55:66] < wifi1> [U:W] EAP_PACKET.Response : Id 0xa7 type 25 Other
Dec  1 09:02:45 kernel: [*12/01/2020 09:02:45.8440] [1606813365:843995] [AP16] [11:22:33:44:55:66] <apr1v0> [D:W] EAPOL_KEY.M1 : DescType 0x02 KeyInfo 0x008a
Dec  1 09:02:45 kernel: [*12/01/2020 09:02:45.8906] [1606813365:890656] [AP16] [11:22:33:44:55:66] < wifi1> [U:W] EAPOL_KEY.M2 : DescType 0x02 KeyInfo 0x010a
Dec  1 09:02:46 kernel: [*12/01/2020 09:02:46.0282] [1606813366: 28207] [AP16] [11:22:33:44:55:66] < wifi1> [U:W] ARP_QUERY : Sender 10.10.10.1 TargIp 10.20.20.1
Dec  1 09:02:46 kernel: [*12/01/2020 09:02:46.0282] [1606813366: 28252] [AP16] [11:22:33:44:55:66] <apr1v0> [U:C] ARP_QUERY : Sender 10.10.10.1 TargIp 10.20.20.1
Dec  1 09:02:46 kernel: [*12/01/2020 09:02:46.0291] [1606813366: 29096] [AP16] [11:22:33:44:55:66] <wired0> [D:E] ARP_REPLY : Sender 10.10.10.1 HwAddr 66:55:44:33:22:11
Dec  1 09:02:46 kernel: [*12/01/2020 09:02:46.0291] [1606813366: 29138] [AP16] [11:22:33:44:55:66] <wired0> [D:C] ARP_REPLY : Sender 10.10.10.1 HwAddr 66:55:44:33:22:11
Dec  1 09:02:46 kernel: [*12/01/2020 09:02:46.0291] [1606813366: 29187] [AP16] [11:22:33:44:55:66] <wired0> [D:C] ARP_REPLY : Sender 10.10.10.1 HwAddr 66:55:44:33:22:11
Dec  1 09:02:47 kernel: [*12/01/2020 09:02:47.0520] [1606813367: 52031] [AP16] [11:22:33:44:55:66] < wifi1> [U:W] DHCP_REQUEST : TransId 0xa68db1f1
Dec  1 09:02:47 kernel: [*12/01/2020 09:02:47.0520] [1606813367: 52070] [AP16] [11:22:33:44:55:66] <apr1v0> [U:C] DHCP_REQUEST : TransId 0xa68db1f1
Dec  1 09:02:47 kernel: [*12/01/2020 09:02:47.0520] [1606813367: 52031] [AP16] [11:22:33:44:55:66] < wifi1> [U:W] DHCP_REQUEST : TransId 0xa68db1f1
Dec  1 09:02:47 kernel: [*12/01/2020 09:02:47.0520] [1606813367: 52070] [AP16] [11:22:33:44:55:66] <apr1v0> [U:C] DHCP_REQUEST : TransId 0xa68db1f1
Dec  1 09:02:47 kernel: [*12/01/2020 09:02:47.0520] [1606813367: 52031] [AP16] [11:22:33:44:55:66] < wifi1> [U:W] DHCP_REQUEST : TransId 0xa68db1f1
Dec  1 09:02:47 kernel: [*12/01/2020 09:02:47.0520] [1606813367: 52070] [AP16] [11:22:33:44:55:66] <apr1v0> [U:C] DHCP_REQUEST : TransId 0xa68db1f1
Dec  1 09:02:47 kernel: [*12/01/2020 09:02:47.0520] [1606813367: 52031] [AP16] [11:22:33:44:55:66] < wifi1> [U:W] DHCP_REQUEST : TransId 0xa68db1f1
Dec  1 09:02:47 kernel: [*12/01/2020 09:02:47.0520] [1606813367: 52070] [AP16] [11:22:33:44:55:66] <apr1v0> [U:C] DHCP_REQUEST : TransId 0xa68db1f1

So what does this tell us? The DHCP requests are not getting to the DHCP server.

The Fix

So based on the above, I doubled checked the switches.

Trunks and ports were fine BUT I had missed something!!

Show VLAN Brief

Showed me I hadnt actually added the sodding vlan on the switch…… 🙁

Why did other devices work?

Well we use one SSID and Cisco ISE moves RF scanners to a different vlan when they’ve authed. Other devices dont use our special RF scanners VLAN.

The Lesson

Its never Wireless, its always something else!

Hello,

I recently setup dynamic vlan assignment using Cisco ISE and a Cisco vWLC but had an issue where on some APs on some sites wouldnt move the devices to the correct DHCP scope.

So just make it clear what dynamic vlan assignment is, its when you have one SSID to rule them all and in the dark bind them.

So I have laptop and hand held scanners and only one SSID, I want my hand held scanner to go onto a different vlan and DHCP scope my laptops. So I use this option in profiles in ISE:

Then setup the scope option and bobs your uncle.

So back to the issue, some sites just wouldnt move scopes i.e. they’d stay on default scope.  So first thing I did was debug the client via the CLI on the vWLC:

debug client 94:fb:29:43:74:b9
*apfMsConnTask_1: Jan 30 13:09:53.561: 94:fb:29:43:74:b9 Encryption policy is set to 0x80000004
*apfMsConnTask_1: Jan 30 13:09:53.561: 94:fb:29:43:74:b9 10.51.140.17 8021X_REQD (3) Client already has IP 10.10.1.17, DHCP Not required on AP 70:79:b3:9f:4c:c0 vapId 1 apVapId 1
*apfMsConnTask_1: Jan 30 13:09:53.561: 94:fb:29:43:74:b9 Not Using WMM Compliance code qosCap 00
*apfMsConnTask_1: Jan 30 13:09:53.561: 94:fb:29:43:74:b9 Vlan while overriding the policy = 153
*apfMsConnTask_1: Jan 30 13:09:53.561: 94:fb:29:43:74:b9 sending to spamAddMobile vlanId 153 flex aclName = , flexAclId 65535

So the client knows it should be on vlan 153 but isnt moving…….So after much googling I found that my flex connect groups hadnt been setup properly.

I was missing the vlans from the vlans from AAA VLAN-ACL Mapping.  Added them in and everything started working on every site!!!

Very weird how it ever worked but there you go.

Hello,

Had an issue joining a Cisco 2800 AP to a Cisco Wireless Controller

So the first thing to check is country code of the AP and controller and the time.

The AP is a -E and the country is on the controller:

https://www.cisco.com/c/dam/assets/prod/wireless/wireless-compliance-tool/index.html

Time looks ok:

To the console!!!

debug capwap errors enable

Looks like this controller version 8.0.133.0 isnt compatible with 2800s:

https://www.cisco.com/c/en/us/td/docs/wireless/compatibility/matrix/compatibility-matrix.html

Time to upgrade.

First check the APs are compatible with the version you are going too:

Looks ok.  Next download it (oh also download the code you currently have installed in case you need it!) and while you’re waiting backup the controller config:

Before you reboot, go to the CLI:

Check the version:

Show boot

Show ap image all

Pre-image the APs:

config ap image predownload primary all

Check the progress:

Reboot the controller via the GUI.

Done:

Hi All,

Had a issue with users connecting to a WLAN on the virtual controller i.e. my mobile phone (94:65:2d:29:00:00) wouldn’t connect to standard PSK SSID.

So I ran the following on the console:

debug client 94:65:2d:29:00:00

Then tried to connect and had the following results:

(Cisco Controller) >*apfOpenDtlSocket: Jan 22 08:52:43.645: 94:65:2d:29:00:00 Recevied management frame ASSOCIATION REQUEST on BSSID f8:0b:cb:43:15:bb destination addr f8:0b:cb:43:15:bb
*apfOpenDtlSocket: Jan 22 08:52:46.278: 94:65:2d:29:00:00 Recevied management frame ASSOCIATION REQUEST on BSSID f8:0b:cb:43:15:bb destination addr f8:0b:cb:43:15:bb
*apfMsConnTask_6: Jan 22 08:52:46.278: 94:65:2d:29:00:00 Processing assoc-req station:94:65:2d:29:00:00 AP:f8:0b:cb:43:15:b0-01 ssid : GUEST thread:a513f80
*apfMsConnTask_6: Jan 22 08:52:46.278: 94:65:2d:29:00:00 Station: 94:65:2d:29:00:00 trying to join WLAN with RSSI -50. Checking for XOR roam conditions on AP: F8:0B:CB:43:15:B0 Slot: 1
*apfMsConnTask_6: Jan 22 08:52:46.278: 94:65:2d:29:00:00 Station: 94:65:2d:29:00:00 is associating to AP F8:0B:CB:43:15:B0 which is not XOR roam capable
*apfMsConnTask_6: Jan 22 08:52:46.278: 94:65:2d:29:00:00 Association received from mobile on BSSID f8:0b:cb:43:15:ba AP ISE-TEST-AP
*apfMsConnTask_6: Jan 22 08:52:46.278: 94:65:2d:29:00:00 Station: 94:65:2d:29:00:00 trying to join WLAN with RSSI -50. Checking for XOR roam conditions on AP: F8:0B:CB:43:15:B0 Slot: 1
*apfMsConnTask_6: Jan 22 08:52:46.278: 94:65:2d:29:00:00 Station: 94:65:2d:29:00:00 is associating to AP F8:0B:CB:43:15:B0 which is not XOR roam capable
*apfMsConnTask_6: Jan 22 08:52:46.278: 94:65:2d:29:00:00 Global 200 Clients are allowed to AP radio
*apfMsConnTask_6: Jan 22 08:52:46.278: 94:65:2d:29:00:00 Max Client Trap Threshold: 0 cur: 19
*apfMsConnTask_6: Jan 22 08:52:46.278: 94:65:2d:29:00:00 Rf profile 600 Clients are allowed to AP wlan
*apfMsConnTask_6: Jan 22 08:52:46.278: 94:65:2d:29:00:00 Max client(60) reached on WLAN. Sending assoc resp failure with reason code 17(max_sta)

The bottom line looked like the issue was a client connection limit per WLAN so I had a look on the console and found:

Changed it to 0 and BOOM.

Had a roaming issues with Symbol MC9090 RF scanners on a Cisco virtual WLC (AIR-CTVM-K9) but weirdly only at one site, even though the same setting were applied across all sites.

The issue was the scanners would drop their SSH connection when moving between APs.

Here’s all my findings:

• Update the scanner firmware, do this, it’s a pain but the newer firmware has so many features that are beneficial.
• Some Scanner firmware would not allow them to connect using the security method WPA2, so enable WPA /TKIP or a better option, update the scanner firmware.
• Secondly change the Scanners to CAM Mode = constant awake mode.
• Thirdly, Cisco TAC recommended using these settings:

Ensure the fast transition is set to adaptive (if you don’t see this then update the code on your WLC):

The Symbol RF scanners support CCKM according to the manual so enable this:

Weird one this one, Cisco told us to disable “Enable Session Timeout” (also disable Aironet IE)

First thing to do is install Filezilla installed and setup a user called meru with a password meru to a shared folder where the update file is stored.

Backing up your saved configuration to offbox (remote location)

First copy the running config as some backup file by using the below command

copy running-config backupconfig

Then copy the backupconfig file out off the box

copy backupconfig <a href="ftp://meru:meru@offbox-ipaddress/backupconfig">ftp://meru:meru@offbox-ipaddress/backupconfig</a> .

Next copy the update to the Meru controller, change the file name to match your firmware.

copy ftp://meru:meru@offbox-ipaddress/meru-5.1-93-MC3200-rpm.tar .

Once the file uploaded you can check its uploaded correctly, you may see more updates than just the running and the version you are on.

Show Flash

To start the firmware you need to disable the AP auto upgrade feature temporally

configure terminal
auto-ap-upgrade disable
exit

Now to start the upgrade

upgrade system xxxx

where xxxx is the name of the new firmware code to which the controller has to be upgraded you can get this from the Show Flash command

It will update the AP’s first and then once they are rebooting it will update the controller and restart. Normally allow 1 hour to perform this work.  You sometimes have to upload the firmware in steps to get to the latest version.

Now turn AP auto upgrade back on

configure terminal
auto-ap-upgrade enable
exit

Hi all,

As well as our main site we have a remote site, lets call it Remote1. Remote1 is on a basic ADSL line, the site connects to the main site via a site to site VPN between two SonicWall’s.  Remote1 has two Meru Access Points (AP332e) which are configured to communicate with the Meru controller at the main site which is where our issue was.

Here’s a pretty picture to help see what I’m on about:

With the help of Meru support who were brilliant I carried out the follow analysis:

So normally Meru AP’s talk to the controller via UDP broadcast packets i.e. UDP port 9292, 9393.  If that doesnt work it uses layer 3 IP routing.

From the remote site I can ping (IP address, server name and broadcast address), telnet and http access the Meru Controller via the VPN. Great Layer 3 is good to go.

From the Controller I can ping the Access Points. Again great.

We have two AP’s on the remote site, to test one is set to L3 and one to L2 but neither work…hmmmm

From connecting to the AP’s via a cable we can see the packets are broadcasting and the AP’s have a valid IP address,

A packet trace on the firewalls show the UDP broadcast packets arrive and leave the remote firewall, are ingested and forwarded at the main site,

A port mirror on the controller shows no traffic from the remote site subnet.

A port mirror of the Main Sites firewall show the packets entering the network but when you connect to the next switch and port mirror I cant see any traffic (see wireshark results below):

So what the hell is going on???  Well it turned out I hadnt drawn the network diagram properly (above), here’s the proper topography:

Between the firewall and the first switch we have a Lightspeed Rocket that does a great job of email protection and website filtering.  Well after looking on the main web filtering page I noticed a tick box under “Block all unidentified UDP connections, Skype, UltraSurf type traffic, and file-sharing networks such as BitTorrent.”….well bugger!!

So I un-ticked this section and Boom the AP’s came one line!!

Now this isnt great as users could start using P2P so I re-ticked the box and added a exception for AP’s and we have a winner!!!

Big thanks to Meru Support, Lightspeed Support, SonicWall Support, HP Support and Commercial LTD (who in the end helped find my missing piece in the diagram).

Had the weirdest issue with my Draytek Vigor 2920n router the other day,  so a mate came over the other day and enabled the wireless on his HTC One X mobile phone, two seconds later my Draytek  started continuously rebooting.

It would come up for a few seconds then reboot again, over and over.

So turned the wireless off and bam it was stable again!!

Had a flick about the internet and few other people are having the same issue, so contacted draytek.co.uk who have issued me a beta firmware for my router (beta_0414), so I’ll have my mate back over and let you know what happens!!