Click on Pictures to View

To view a larger version of an image within a post, just click on the picture you want to view :)

Thursday, March 15, 2018

Cisco 2802i Access Point LED Flashing Green

We had a Cisco 2802i Access Point that wasn't showing up in the wireless controller.  Upon inspection of the AP hanging on the ceiling, the LED status light was flashing green consistently.

According to Cisco documentation, this indicates a boot loader error.

            


After a little research, I discovered I was going to have to get a ladder and plug in to the console port on the AP.

Once I was connected, I went ahead and tried a factory reset of the AP.  When I saw the CLI of the AP come up, I noticed it was stuck in a "u-boot" prompt.
Further research led me to an article (see source links at the end of this post) that helped me see that the AP had a faulty boot command.

I did a printenv command, and it returned the below (I'm pasting only the first part of the actual output):

             u-boot>> printenv
             BOOT=part1
             CASset=max
             ENABLE_BREAK=1
             FACTORY_RESET=0
             MALLOC_len=5
             MANUAL_BOOT=0
             MEMORY_DEBUG=0
             MPmode=SMP
             autoload=yes
             baudrate=9600
             bootcmd=boardinit

             ...(remaining output omitted)...


This "boardinit" is apparently not the proper bootcmd that the AP should be using.

Here was the proposed solution that worked for me.  I ran the following commands in the u-boot prompt:

            > setenv bootcmd nandboot
      > saveenv
      > boot

Or, it would look like this, for example:

            u-boot>> setenv bootcmd nandboot
       u-boot>> saveenv
         Saving Environment to SPI Flash...
         Erasing SPI flash....Writing to SPI flash.....done
       u-boot>> boot



Sources:

Cisco Getting Started Guide Cisco Aironet 2800 Series Access Points - 

How To Restore Factory Settings (Access Point) - 

2802i Flashing Green + Solution - 


Wednesday, March 14, 2018

RADIUS Clients Disappearing from NPS

An issue at hand recently was that newly added RADIUS clients to an NPS server were disappearing for no apparent reason.  This was a Windows 2008 Server running the Network Policy Server.

I had added several RADIUS client entries back on February 8th, 2018, and we noticed them missing from the server on Wednesday the 22nd.  While I recognized this was unusual, I added them all back in due to not enough time to investigate the cause.
However, they were missing again by March 2nd.

I checked event logs on the NPS server, and saw login/authentication errors for networked equipment starting Tuesday the 21st, and again Tuesday the 26th after the re-adds from the 22nd.  I went ahead and enabled auditing for NPS events for successess and failures.

After some research and comparison, and having restored the NPS server to a couple different previous versions to no avail in restoring the entries, I finally found an online thread that described the issue accurately, and proposed a cause as resolution.

"...we basically discovered that when people made changes to the NPS server, they disconnected and never logged out - so...  the changes were held open in a disconnected session.  The next person to log in, makes changes, logs out as they should, then the person with the disconnected session logs back in, makes changes to the file that is already open (but not the latest one), saves the changes, thus over-writing the last changes..."

I tested this theory with a coworker, doing disconnects and logins with edits by one user, versus logoffs, logins and edits by another user.

I happened to notice during this that a teammate was in a disconnected session from Tuesday 2-26-2018 at 10:55 on the main NPS server - the last time the RADIUS ias.xml file (C:\Windows\System32\ias\ias.xml) was updated and the day the RADIUS clients disappeared (or when NPS errors started).  I assumed this person had had a disconnected session from the week before on Tuesday as well, the day the RADIUS clients first disappeared.
There were also two other RADIUS client entries added to the main server, but NOT to the secondary server, suggesting this person made modifications those days at least to the main server.

There was also a disconnected session from this teammate on the secondary server.  The secondary server RADIUS ias.xml file was last edited 2-22-18, ending with a particular entry name edit I personally made that day.  Therefore, it was likely that the next time that user would've logged on, it would've reestablished their disconnected session, and any RADIUS edits made by them would then have been made to the suspended/open file in their account, essentially overriding the actual file made by people who log off...needless to say, I ended their disconnected session to avoid this :)




SOURCES:

Windows Server 2008 R2 NPS RADIUS clients disappearing -
https://social.technet.microsoft.com/Forums/windowsserver/en-US/824b462c-515d-471a-8c46-cc1f23460386/windows-server-2008-r2-nps-radius-clients-disappearing?forum=winserverNIS

NPS Events & Audit Policy -
https://social.technet.microsoft.com/Forums/windowsserver/en-US/064f3e68-42fa-4669-aede-838e7cc7df92/nps-events-and-audit-policy?forum=winserverNAP