Closed drn05r closed 2 years ago
ssh -v 10.5.0.212 suggests it is a Raspberry Pi:
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4p1 Raspbian-10+deb9u4 debug1: match: OpenSSH_7.4p1 Raspbian-10+deb9u4 pat OpenSSH* compat 0x04000000 Raspbian / Debian 10 is Buster.
According to @cjsoftuk this is a Wireless Quality Monitoring (WQM) box sat on @heliosfa desk. I am going to check the DNS to see if it is registered, otherwise I will add it. Either way I will move login to a new private IP address.
This is rather odd there is staff-wqm looks to be on 10.5.0.250 and student-wqm is on 10.5.0.251. Based on a matching ECDSA key fingerprint it looks like student-wqm is also on 10.5.0.212 for some reason.
I think the WQMs were renumbered a while ago when we changed how our IP space was split up - maybe it retained the old IP as well?
I have done the following:
I don't know how easy it will be for @heliosfa to sort out the errant 10.5.0.212 IP registration on STUDENT-WQM. Therefore better to reassign login. I did not want to use 10.5.0.211 or 10.5.0.210, as arp on auth2 suggested these may be in use.
I'm not sure if I have login to them but happy to give both of the WQMs a reboot when I am in.
There is also the Odroid that we were using for something - is that registered in all the right places?
@heliosfa That may be useful at clearing the rogue IP address on student-wqm. It would be useful to get that cleared. Also trying to work out why arp -a on auth2 is reporting part records for the following:
? (10.5.0.210) at <incomplete> on eth1
? (10.5.0.211) at <incomplete> on eth1
210 rings a bell as being the odroid.
Did the other WQM used to be 11?
@helios Neither is pingable as you expect from that result from arp. It would make sense that are odroid and staff-wqm, as they are still contiguous now they have been moved. I assume they must sometimes respond as I rebooted auth2 earlier today, so I would only expect results from arp -a since the server was rebooted. I guess a reboot on all three of these devices might help.
This is all quite interesting given that I pinged and arped for the IP before assigning it to LOGIN initially.
@heliosfa That may be useful at clearing the rogue IP address on student-wqm. It would be useful to get that cleared. Also trying to work out why arp -a on auth2 is reporting part records for the following:
? (10.5.0.210) at <incomplete> on eth1
? (10.5.0.211) at <incomplete> on eth1
These I reckon might be as a result of me trying to ping IP addresses to test if they were in use. Therefore, the main concern is just 10.5.0.212. As you can see the ARP entry below has a MAC address rather than saying incomplete:
? (10.5.0.212) at b8:27:eb:d3:0c:43 [ether] on eth1
When login.sown.org.uk was offline it was still possible to SSH to 10.5.0.212. This suggests some other device is also on this IP address. We need to investigate what this is.