I recently received my RS+ survey kit, and have gone through the update process, and I have tested them each briefly and they seem to function from my home WIFI.
The issue is with my work WIFI, which is where I will be using it. Our internet requires a username/password and a 3rd party authentication software, in order to even login to the wireless network. My IT guy said he can probably open it up for me if I can provide him with MAC addresses for my two devices.
However, upon checking each RS+ network’s settings, I find out that both units have the same MAC address. I have always thought that MAC address were unique. What can I do, any suggestions, is this normal? Thank you.
I have never seen two Reach devices with the same MAC. That seems odd.
When they are both “ON” and in hotspot mode, and you use your mobile device to scan for networks, what do you see?
It should be a list like this:
Reach:4f:a2
Reach:ba:7e
Reach:2c:cd
That isn’t the actual mac (it is just the hotspot name), but it is usually set to match the last characters of the device’s MAC address.
I thought it was odd too that both have the same MAC…I am hoping that I am just simply doing something wrong.
When connected to my iPhone/iPad is see…
reach:65:A0
reach:13:89
I use Fing to get system info, but the MAC address line says “unavailable”.
When I use my laptop, I see both networks and can log onto them. In the Wireless Settings, the MAC addresses are the same for both. And ipconfig/all, both adresses are the same.
When I try turning one on a time, its still the same MAC.
For wlan0 on reach:13:89 i get…
wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_code1 qlen 1000 link/ether 28:ed:e0:d6:53:6f brd ff:ff:ff:ff:ff:ff
For reach:65:A0 i get…
@@@@@@@@@@@@@@@@
WARNING REMOTE HOST IDENTIFICATION HAS CHANGED!
@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOME IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle-attack)!
It is also possible that a host hey has just been changed.The fingerprint for the ECDSA key sent by the remote host is SHA256…a bunch of numbers etc…
Please contact your system administrator…
Hi Josh. This warning is real and important, but in this case you should expect the error and work around it.
How do I explain it in as few words as possible? Obviously I can’t:
When you connect to a remote ssh server for the first time, usually you have to accept the fingerprint of the ssh server as good without any means to check that it is actually correct. When that ssh server fingerprint is accepted by you as as good, then it is stored along on your system and paired with the IP address of the server. The next time you connect by ssh to that IP address, your system checks the fingerprint and IP against its own copy, decides to trust it, and lets you connect without hassle.
If you are connecting to a server on the Internet and you get that warning it means that the fingerprint is different and something has changed (new server software, MITM attack, etc.) and it is a cause for concern.
However, we are doing this one-to-one directly between your computer and the Reach hotspot so there shouldn’t be a MITM attack happening.
Now, when you connect to any Reach hotspot, Reach always has the same IP address (192.168.42.1), but every Reach generates itself a different ssh server fingerprint. So if you have previously connected to one Reach through its hotspot at IP address 192.168.42.1, and then you switch over and connect to a different Reach though its hotspot at IP address 192.168.42.1, well you are going to get 2 different fingerprints which appear to come from the same IP address, and that will trigger the warning that you see above.
I hope that makes at least a bit of sense why the warning is good and also why the warning should be expected in this case, and then why you should be able to confidently decide to disable the warning for this one time.
One way to disable the warning is to remove the previously stored fingerprint for that IP address using ssh-keygen like this: ssh-keygen -f ~/.ssh/known_hosts -R 192.168.10.1
Another way is do delete the offending line from the ~/.ssh/known_hosts file.
Say that you managed 2 routers via ssh that were in different offices and they had the same default IP address as each other because they were the same model and same brand. You would experience the same warning and workaround when working with one and then the other. It is not a normal thing to have to do this procedure, but it is what must be done. Of course there will be other ways to avoid the error, but I believe this to be the most simple way. And we don’t want to diverge to far from the task at hand or get into a big discussion about best practices and security in general.
