Can't find what you need?


• Ask the Community
• Create a Case
Reset Search
 

 

Article

How to troubleshoot a client (MU) that fails to get an IP address or has an APIPA IP address (169.254.0.0/16)

« Go Back

Information

 
TitleHow to troubleshoot a client (MU) that fails to get an IP address or has an APIPA IP address (169.254.0.0/16)
Objective
How to troubleshoot a client (MU) that fails to get an IP address or has an APIPA IP address (169.254.0.0/16) 

 
Environment
  • identiFi wireless
  • Extremewireless
  • Access Points 36xx 37xx 38xx 39xx
Procedure
Check on the Ethernet port of the AP to see if the DHCP request and offer are seen using realcapture

If the offer arrives at the Ethernet port:
  1. Is the offer broadcast? 
    • Can the DHCP server be switched to force unicast reply?
    • Measure the background broadcast levels, can they be reduced with filtering, ipv6 etc?
    • Remove lower data rates, for example, set g/n instead of b/g/n or increase minimum basic rate by 1 “notch”
    • Lower DTIM to 1 or 2
    • Classify DHCP/DNS/ARP to high priority queue in role.
  2. If the offer is unicast and the above is done for broadcast:
  3. Check DCS file for utilisation - What does the data in the dcs file from an AP trace tarball show
    • In the event there is a lot of utilisation on the radio:
      • See above comment on filtering excess traffic.
      • IPv6, Netbios, MDNS
      • ARP – How big is the IP subnet? 
      • Can the number of SSIDS’s broadcast be reduced?
      • If the WLAN was designed for 5Ghz coverage, can some of the clients be moved to 5Ghz? 
        1. Band steering
        2. Power settings
        3. Min Basic Rate (MBR)
      • Are OneView maps or building map showing AP’s so that you can check channel overlap.
        1. Can DFS channels be utilised to increase capacity?  How to create a 5GHz WiFi Channel Plan
        2. If DFS channels are problematic and 40Mmhz channel width is in use consider using 20Mhz width?
If the offer doesn’t arrive at the Ethernet port look elsewhere on the data-path between the client and the server, start at one end or the other of the data-path until the loss is detected.

If none of the above resolves the issue:
  • Note the MAC address of problem device
  • Note the date/time the issue happened or was noticed
  • Device type and OS version (eg Macbook pro El Capitan) or Windows 10, Lenovo with 7260 AC driver x.y.z – don’t say “All devices” – this may be true but it’s too wide a field to troubleshoot
    • It is highly recommended to test with as many devices as possible. The more data the better but ensure that this data can be presented clearly with carefully named files and document what was done.
  • What changed?  
    • Is this a new install?
    • Was the controller upgraded, is from what to what and when?
    • Was a new DHCP server commissioned?  For example Client connection issues, started with 10.01.06, still continuing with 10.11.04
    • Was everything working last year, and now is not when user numbers have increased, such as when students/staff return after summer holidays?
    • Have user numbers increased, such as a new application being deployed that works over wifi enabled devices?
    • Firewall/Router/Switch config change and/or upgrade?
    • Have more AP’s added, have legacy AP’s been swapped for newer AP’s?
    • Has a site survey been done and can this data be shared?
    • Can critical services be moved to 5Ghz using a unique SSID that is not attached to 2.4Ghz anywhere?
  • Send any wireless traces to GTAC
  • Send relevant AP tarballs - How to Collect IdentiFi Access Point Logging Information (Trace Bundle)
  • Send tech support all - How to Collect a Tech Support File from an IdentiFi Wireless Controller
    • Gather a new tech support for EACH controller and for any new troubleshoot, prefix the filename with the controller hostname, eg EWC1_
  • Note the frequency, or anything specific, such as device was asleep just before, or device was on battery etc.
  • Note the band the issue happens on, always 2.4? Always 5? Can happen on either?
    • Isolate the problem to 1 Building/Room/AP/Radio.  To minimise the chances of the client roaming to an unexpected AP/Radio, can one of the radios be switched off, for example Radio 2 (2.4Ghz)
Additional notes
Notes on naming files:

Try to group files so the date they were gathered and to which device they are involved in troubleshooting is clear, prefix AP traces with MAC of MU we are looking at, for example:
  • yyyymmdd_mu_001122334455_failed_at_1509

Feedback

 

Was this article helpful?


   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255