Wireless AP 1142 - Convert to controller based or standalone mode

If you are faced with the task of installing 1100 series APs into a controller environment but somehow "standalone" APs were procured, don't panic! Here is the fix:

1. Note the AP's IP address by "show cdp neigh detail"
2. http:// to the address to manage (Cisco/Cisco... case sensitive ID and pass!)
3. Go to the software tab and update to the correct image

If your controller is a hop or two or more away, don't forget to adjust DHCP option 43 and option 60 values!

Cisco 2600 AP - Convert to Stand-Alone mode

Follow these simple steps:

1. Download the stand-alone image from Cisco.com (.tar)
2. Rename the file to ...tar.default
3. Make sure you have a console connection to the 2600 AP - this will you verify the name of the file the AP expects to boot from using TFTP.
4. Change your IP address to 10.0.0.2 /8
5. Run a TFTP  server on your laptop or PC
6. Plug the AP and your PC into two ports a switch that are in the same VLAN (no layer3 SVI necessary, I recommend creating a temporary VLAN such as 99 for example)
7. Make sure that the AP is connected to a PoE port if you don't have a power brick, BUT before you do that, press the MODE button and hold it down as the AP boots!!
8. Watch the console messages for the correct filename - ...tar.default should match exactly.
9. AP's LED will go blue and then after 15 seconds will go RED - you can let go of the MODE button now!
10. AP LED will blink green and it will intialize in stand-alone mode, and obtain a DHCP address.
11. You can manage it using http://

Cisco ASA: "LAND" attack - track false positves

A LAND attack is characterized by an IP packet whose source and destination IP addresses are the same. HOwever, sometimes on the ASA platform, it is possible to see false postives.


Consider the following example:

Jan 05 2012 16:21:36: %ASA-2-106017: Deny IP due to Land Attack from 192.168.2.71 to 192.168.2.71

Jan 05 2012 16:21:37: %ASA-2-106017: Deny IP due to Land Attack from 192.168.2.71 to 192.168.2.71

What is really happening?

Upon closer examination, you notice that you have static tranlation setup:

static (inside, outside) 192.168.2.71 172.16.2.71

Now let's capture traffic b/w the private address and translated IP, and lo and behold, the mystery is solved! The server inside is trying to access "itself via its public IP address" (perhaps via a script that is running).

3 packets captured

1: 16:20:37.032469 172.16.2.71.58126 > 192.168.2.71.80: S 1304500266:1304500266(0) win 5840

2: 16:21:36.938168 172.16.2.71.58128 > 192.168.2.71.80: S 4035860468:4035860468(0) win 5840

3: 16:21:37.173559 172.16.2.71.58129 > 192.168.2.71.80: S 4123968769:4123968769(0) win 5840

3 packets shown   Notice how the time-stamps match!