static arp and wireless

[Inigo Montoya]

I have 3 wireless desktops running Windows XP Pro SP2 connected to my WRT54GS Linksys router. They all have static IPs so that I can use the port forwarding feature. Each computer runs a batch file at login which sets static arp entries to protect against arp spoofing.

Once or twice a day though, the desktops will lose their wireless connection for a few seconds but reconnect right away. The problem is that at each connection loss, the arp table gets flushed and the static entries are gone. Is there a way to:

A) disable the flushing of the arp table when the connection is dropped? OR

B) have Windows XP add the static entries back to the arp table automatically on reconnect?

I already know how to manually add the arp entries back to the table with arp -s. What I need is a way for Windows to continue to use the arp entries that I trust without manual intervention.

.

[M/Q]

Interesting problem. I have a few questions. I was very curious as to where in the network topology these workstations are located and why you are so concerned about ARP spoofing. Is the environment that hostile?

I guess the first obvious direction would be to determine why the workstations were getting dropped as that has to be annoying regardless of the ARP table being flushed. Is there a signal strength problem that creates the right conditions for drops. I am sure you have checked all these out already, but it in reality is the only way to simply resolve the problem.

The ARP protocol is setup that way and is used by all OS's I know of to work as you have determined. It would IMO more problematic if you disabled that feature.

I am not fluent enough in scripting to determine the trigger that could be used to run a batch file when the connection was reset.

I also have one other thought and that is kind of a workaround and not a solution. I have used ARPwatch as a indicator to if and when any changes where made to an ARP table. Until a better solution is found using this in conjunction might allow you to react to any ARP spoofing attempt in a timely fashion.

http://www.securityfocus.com/tools/142

[Inigo Montoya]

I was very curious as to where in the network topology these workstations are located and why you are so concerned about ARP spoofing. Is the environment that hostile?
The three desktops are on the same subnet (192.168.8.50, 192.168.8.51, 192.168.8.52) and connected directly to the WLAN of a WRT54GS router (192.168.8.1). I've enabled WPA-PSK AES and Wireless MAC Filter. I've also disabled Wireless Access to the router's interface.

Using Network Stumbler I detected 28 other WLANs that have strong enough signals for the three desktops to connect to. If I can detect them, then lots of people in my neighbourhood can detect my WLAN. Maybe I'm being paranoid but I figured that hardening my WLAN against arp spoofing was a prudent thing to do.

I guess the first obvious direction would be to determine why the workstations were getting dropped as that has to be annoying regardless of the ARP table being flushed. Is there a signal strength problem that creates the right conditions for drops.
Actually except for this ARP issue no one has complained about the connection drops since they happen so infrequently. It also helps that they only last a few seconds and the desktops always reestablish the connection without user intervention. I did look into it for awhile but could not find any pattern or reason for the connection loss. The signal is definitely strong enough.

I also have one other thought and that is kind of a workaround and not a solution. I have used ARPwatch as a indicator to if and when any changes where made to an ARP table.
ARPwatch is definitely helpful. I'm still hoping to find a solution to this problem since no one else in the office has any technical knowledge and would not have any idea what to do with ARPwatch if I'm not present.