Wireless Access

I've got an AP205 that I have successfully provisioned but when I take it out to the location its to be mounted it won't find the controller, I've tried multiple switch interfaces and even plugged the AP directly into the switch interface. Bring the AP back to my office and plug it in and it comes up straightaway. I've also tried 2 other network connections on the same switch stack that my office connections on and 1 works fine and the other fails. All the AP does when it fails to connect to the controller is reboot. It successfully gets its DHCP settings and controller but will not connect. What can I do to allow this AP to work wherever I plug it in? Thanks Jon

Were you able to see what was going on during the boot process while connected through the AP Console ?

I've done some further testing and found that DHCP is timing out on the AP.

 

The switches used for testing were a 6 x 2960x stack with a single gig uplink to the core, 4 switches are non POE and 2 are POE.

 

On one POE switch the 3 ports I tested with the AP all return DHCP timeout, the other POE switch the 3 ports I tested worked fine. Just to complicate matters when I plug in an IP Phone and Laptop to these same ports they both pickup their DHCP details correctly on both switches. 

 

I'm at a loss to know what's causing this issue so any help would be much appreciated.

 

Thanks

 

Jon

What are you using for a switch ?
How do you have configured your IAP Port setting and Switch port settings? can you please share your config?

 

Switch model we're using  WS-C2960X-48FPS-L

 

They're not IAP's they're Campus AP's and this one has been provisioned already.

 

Standard interface config on the switch stack I did the testing from 

 

switchport access vlan 106
switchport mode access
switchport voice vlan 2
no logging event link-status
power inline auto max 15400
mls qos trust dscp
energywise role Access Interface
spanning-tree portfast
spanning-tree bpduguard enable
service-policy input QOS

Do the switches that work find use the same access VLAN as the ones that doesn´t work?

 

Have you made sure that the DHCP scope for that VLAN isn´t full and the phone/laptop had a lease before?

 

Which master discovery method are you using?

---

@Christoffer wrote:

Do the switches that work find use the same access VLAN as the ones that doesn´t work?

 

Have you made sure that the DHCP scope for that VLAN isn´t full and the phone/laptop had a lease before?

 

Which master discovery method are you using?

 

Yes all the access interfaces tested use the same VLAN.

 

The DHCP scope isn't full full but that wouldn't make any difference anyway as the AP is connecting on a different switch on the same stack and getting a DHCP so that DHCP address would still be valid for any other interface on any of the 6 switches for that VLAN. See below DHCP entry for the AP.

We're using ADP as the Master discovery process.

ADP would require the controller to either be on the same subnet as the AP or for your network to be able to forward multicast between the AP and controller. Just to be sure. :)

 

You could perhaps try to statically assign the IP from the setenv commands in the AP via console to further narrow down the problem.

 

If it´s on the same switchstack with identical port configuration and two different behaviours in between the stack members I´d start to take a look at the switchstack to see if you have any errors in the logs or firmware mismatches in between the members or something like that.

 

Cheers,

 

 

Our network will forward Multicast traffic.

I've set the AP with a static IP address but it's still looking at DHCP and still fails, see below.

 

apboot> setenv ipaddr 10.170.23.250
apboot> setenv netmask 255.255.255.0
apboot> setenv gateway 10.170.20.1
apboot> saveenv
Saving Environment to Flash...
Erasing flash...Writing to flash..................done
apboot> boot
Checking image @ 0x1e100000
Copying image from 0x1e100000

Image is signed; verifying checksum... passed
Signer Cert OK
Policy Cert OK
RSA signature verified.
Uncompressing... done
[ 0.000000]
[ 0.000000] Aruba Networks
[ 0.000000] ArubaOS Version 6.4.3.4 (build 51619 / label #51619)
[ 0.000000] Built by p4build@formentera.arubanetworks.com on 2015-09-10 at 17:53:00 PDT (gcc version 4.7.2)
[ 0.000000]
[ 0.000000] Flash variant: variant0
[ 0.000000] MPCORE found at 19020000, SCTLR 0x10c53c7f ACTLR 0x00000040 CPSR 0x600001d3 SPSR 0x52000000 PRRR 0x000a81a8 NMRR 0x40e040e0
[ 0.000000] Memory: 128MB = 128MB total
[ 0.000000] Memory: 120668k/120668k available, 10404k reserved, 0K highmem
[ 0.052000] hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7 counters available
[ 3.460000] PMU: registered new PMU device of type 0
[ 3.966000] pci 0001:00:00.0: BAR 8: assigned [mem 0x08000000-0x080fffff]
[ 3.968000] pci 0001:01:00.0: BAR 0: assigned [mem 0x08000000-0x08007fff 64bit]
[ 3.970000] pci 0001:01:00.0: BAR 0: set to [mem 0x08000000-0x08007fff 64bit] (PCI address [0x8000000-0x8007fff]
[ 4.474000] pci 0002:00:00.0: BAR 8: assigned [mem 0x40000000-0x400fffff]
[ 4.476000] pci 0002:02:00.0: BAR 0: assigned [mem 0x40000000-0x40007fff 64bit]
[ 4.478000] pci 0002:02:00.0: BAR 0: set to [mem 0x40000000-0x40007fff 64bit] (PCI address [0x40000000-0x40007fff]
[ 4.824000] i2c-springbank: using remapped base c9e4c060
[ 4.826000] mpcore_wdt mpcore_wdt: enabling watchdog.
[ 4.830000] qspi_iproc qspi_iproc.1: 1-lane output, 3-byte address
[ 4.832000] m25p80 spi1.0: mx25l25635e (32768 Kbytes)
[ 4.834000] Creating 1 MTD partitions on "spi1.0":
[ 4.836000] 0x000000000000-0x000002000000 : "qspi"
[ 4.848000]
[ 4.848000] Starting Kernel SHA1 KAT ...Completed Kernel SHA1 KAT
[ 4.852000] Starting Kernel HMAC-SHA1 KAT ...Completed Kernel HMAC-SHA1 KAT
[ 4.912000] Starting Kernel DES KAT ...Completed Kernel DES KAT
[ 4.916000] Starting Kernel AES KAT ...Completed Kernel AES KAT
[ 4.918000]
AP-type has_ble_support: .
Domain Name: arubanetworks.com
No panic info available
[ 13.624000] AP xml model 81, num_radios 2 (jiffies 6812)
[ 13.626000] init_asap_mod: installation:0
[ 13.628000] radio 0: band 1 ant 0 max_ssid 16
[ 13.630000] radio 1: band 0 ant 0 max_ssid 16
Starting watchdog process...
Getting an IP address...
[ 18.012000] ADDRCONF(NETDEV_UP): bond0: link is not ready
[ 20.016000] bond0: link up (1000FD)
[ 20.018000] ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
DHCP timed out.
killall: nanny: no process killed
killall: sapd: no process killed
Sending SIGKILL to all processes.
Please stand by while rebooting the system.
[ 318.128000] Restarting system.

Enviromental Variables of the AP

 

apboot> printenv
bootdelay=2
baudrate=9600
autoload=n
boardname=Springbank
bootcmd=boot ap
autostart=yes
bootfile=armv7ns.ari
ethaddr=ac:a3:1e:c3:b2:dc
backup_vap_init_master=10.170.38.153
num_ipsec_retry=85
name=PH15_AnteNatal_AP1
group=APG-PILGRIM-2
syslocation=PH15_AnteNatal_AP1
ip6prefix=64
servername=aruba-master
a_antenna=0
g_antenna=0
usb_type=0
uplink_vlan=0
auto_prov_id=0
is_rmp_enable=0
priority_ethernet=0
priority_cellular=0
cellular_nw_preference=1
usb_power_mode=0
ap_power_mode=0
cert_cap=0
mesh_role=0
installation=0
mesh_sae=0
backup_vap_password=6745C62369987340D95AE0229F3EF17D76F32E2441B040896624890AE7972986
start_type=cold_start
backup_vap_opmode=0
backup_vap_band=2
ethact=eth0
ipaddr=10.170.23.250
netmask=255.255.255.0
gateway=10.170.20.1
stdin=serial
stdout=serial
stderr=serial

Just to update this issue, have now tried a brand new 205 and get the same issue. So I took a spare 105 I've got knocking around and reconfigured it and it worked first time so I believe its an AP issue and not a DHCP\switch issue. The 105 was patched to exactly the same port on the switch using exactly the same patch lead.

Is there any difference in IP MTU settings between the two members? I´ve seen a difference from 105 and newer models of APs how they handle MTU discovery. But this should not prevent the AP from getting an IP in the first place :/

 

You do have a case with TAC open?

 

Cheers,

I haven't opened a TAC case yet that was my next step, thanks for the input.

I just took a look at your setenv parameters, it looks like you´ve misconfigured either the IP or the default gateway, they arn´t on the same subnet.

 

When the access point has booted, can you from its prompt ping the controller?

Hi, did you manage to resolve this in the end? I have the same issues so just wondered. Thanks