Wireless

Cisco Wireless & DHCP

Posted by robd on December 02, 2020
Cisco, Wireless / No Comments

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!

 

Tags: , , ,

Dynamic vlan Assignment on Flexconnect using Cisco Wireless

Posted by robd on February 17, 2020
Wireless / No Comments

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.

 

Tags: , , ,

Cisco Wireless Lan Controller Update with Pre-Download

Posted by robd on June 13, 2019
Wireless / No Comments

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:

 

Tags: , ,

Client Connecting to WLAN on Cisco WLC

Posted by robd on January 22, 2019
Wireless / No Comments

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.

Tags: ,

Symbol RF Scanners and Cisco WLC

Posted by robd on November 13, 2018
Wireless / No Comments

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)

Tags: , , , ,

Wireless – Insulation

Posted by robd on September 06, 2018
Wireless / No Comments

Hello,

I’ve been meaning to post something on wirelss for a while, actually since I gained my CCNA Wireless cert, but I’ve not really been sure what to post…until now.

I install quite a lot of Cisco wireless in factories and although I’m new to Ekahau (any complimentrary Ekahau training would be awesome) recently had the opertunity to test the attenuation of some insulation.

The kit I used to test was:

I tested two types of standard foam insulation that I currently cant name but here are the results:

Here’s the free path loss from the AP to the sidekick

Here’s with some insulation in the way:

So,

free loss  -46dBm

insulation = 2.4m in length and 2m depth and 3m height.

loss = -45dBm

= 1dBm loss!

 

Second piece of insulation:

free loss -58dBm

insulation = 2.4m in length and 2m depth and 3m height.

insulation -52dBm

= 6dBm loss.

 

So all in all I’d say depending on the insulation there can be quite a lot of attenuation.

Meru Controller – Firmware upgrade

Posted by robd on April 10, 2016
Wireless / 2 Comments

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

 

Tags: , ,

The Meru AP to VPN to HP Switches to Controller issue

Posted by robd on April 08, 2014
Networking, Wireless / No Comments

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:

MeruIssue

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,

Wireshark

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):

wireshark2

 

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

MeruIssue2

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!!

LightspeedBlock

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).

Tags: , , , , , , , ,

Copy Protected by Chetan's WP-Copyprotect.