I've experienced a few times, a strange issue, when at an installation upon, setting up a Force 200 and logging in, I am redirected to a totally different Force 200 connected to the same AP. I was wondering if anyone knew what would cause this? The only way I've found to resolve this problem is to get logged in and reboot the SM I'm forwarded to so that I can set up the one I'm working on.
Example: I arrive at customer premises, mount, and connect to SM via PowerLink. Type 169.254.1.1 into my web browser on my phone and I get the usual login prompt. As I log in, say I'm at John Doe's house using his Force 200, The name changes to Larry Person's name and all the info on the Force 200 is his.
Any help would be awesome lol.
I am guessing you are using dhcp for the SM's once they connect to the tower, since you are not accessing it via a static address you have pre-assigned to the unit?
If so, this is going to happen since ALL units have the back door address of 169.254.1.1.
You will need to look at the wireless tab of the AP it connected to or router table (depending on how things are set up) and use the dhcp address assigned to that SM. Then you can access it.
1 Like
Hi,
As CWB said, 169.254.1.1 is a backdoor adress that is always available via the Ethernet port of the radio, whether the radio is set to DHCP or Static IP. However, that IP addres does not traverse the wireless interface and you should not be hitting a second SM connected to the same AP. Worst case, you could be hitting the Ethernet interface of another ePMP radio connected to the same switch as the orginal AP. That said, in some older releases there was a bug that allowed access of this IP over the wireless interface. But this is not an issue in newer releases. What release are the radios running?
Two possible solutions here:
- Disable or change 169.254.1.1 if this issue is causing you inconvenience. Instructions are here.
- Enable SM isolation so traffic from one SM is isolated from another SM connected to the same AP. Generally this is good practice. Information about SM isolation is here.
Sriram
2 Likes
Just use static ARP to avoid this. It's a great universal tool.
If you're not 100% sure what the MAC is, reboot it and watch a constant ping of 169.254.1.1. When it responds, look at your arp cache (arp -a) and then static it (arp -s 169.254.1.1 00-04-56-aa-bb-cc)
2 Likes
We use to see this back in the day on our setup bench. If the radio we were configuring was able to connect to the tower right here by our NOC using 169.254.1.1 to access it would land you at an AP on a tower 4 hops away... I was alway curious why it was always that same AP. Ran into it remotely a few times also. Also wondered why the radios even passed the 169.254.1 in/out the other interface.
Had forgot all about that happening until I seen your post because it had not happened for... well, I can't remember the last time it happened. Cambium_Sri pointing out it was a bug in some older versions of the software solves a mystery for me that I had forgotten about. Except for the part were it was always ended up in that same AP, that part is still a mystery.
1 Like
Thanks everyone!
One thing to check, Crtl+F5 when you log in. I see this a lot here, HOWEVER it is just because the SNMP was cached in the browser for 169.254.1.1. Crtl+F5 is a hard refresh and reloads from the current connection