Hi B.Goode
Thank you for replying.
You are obvoiusly correct, I didn't mention anything about my router but I didn't really mention anything about what other avenues I've tried. I didn't want to fill pages with all my 'dead ends'. I decided instead to let people come up with their ideas and provide them with whatever they required.
My router consists of a pc with multiple network cards running OPNsense. When I started investigating this issue I had a different router with a very similar spec', but running pfsense. That router did have a fault (unrelated) so I swapped the machine out and changed the O/S to OPNsense which I'm still getting to grips with. So I've been trying to debug this with two different machines and two 'different' router O/S's.
In relation to your question; yes I have rebooted the routers and flushed the arp caches and the individual arp entries and assighed different MAc addresses. I've also cycled round different router ports just in case there was issues with particular network cards. All to no avail. I'm in the process of posting this issue on the OPNsense forum just incase someone there has any fruitful ideas.
Here is an image of my Arp Table:
The interface for the subnet we are interesting in is called 'infastructure' and the device we're interested in has the ip 192.168.0.117 and the Mac: 2c:cf:67:19:9d:14. You can see the router interface card just above that. Note there is no entry for an ip of 172.16.1.17 which would violate this subnet.
Next is a packet capture of the Infastructure subnet. Here I set up and captured a number of pings.
Line 1 shows a ping from my PC (ip ending 135) to the pi box targeting the correct IP value set in the interface file. No problem here; line 1 show the request from my pc and line 2 shows the reply from the pi box using the correct IP.
Line 3 on the other hand shows a ping from the pi box to google for which there is no reply. More importantly note the ip address it is using. The one which should not exist given it hasn't been set in the interface file.
Line 4 show a ping from the Pi box to the the local subnet interface and again it's using the 'non existent' IP and there is no reply.
Lines 5,6 and 7 are just repeats.
line 8 shows the ssh connection between my PC and the Pi Box using the correct IP, obviously.
The sharp eyed may notice that the only two mac addresses listed are the Pi box and the infastructure subnet/router interface card. This is because I set the capture to only target the Infastructure subnet and so it only picks up and displays the packets which traverse into the subnet and not their path before they enter the target area. Hence you only see the local subnet interface mac address and not the origin mac address.
Please note this might read as If I'm trying to prove the issue is not with the router. That is not my intension. I am only showing what the router is displaying. Clearly the issue can only be with the router or the pi box and if I knew which one I probably wouldn't be writing this post.
I have done lots of testing and far from shedding light on the matter it just seems to show results that shouldn't be happening. I don't mean as in a bug. I mean as in 'networking doesn't work that way', ' I can't see how this is possible'.
Above I refered to the 'non existing IP'. That's because 172.16.1.17 isn't set in the interface file nor anywhere else as far as I can find. I grep'ed every file in the etc directory and all those related to the main compents I installed and it simply isn't there. But obviously it must be stored, cached or embeded somewhere or the PI simply wouldn't be able to display it because it wouldn't know about it.
I said I didn't find the offending IP address anywhere. That is not exactly true. I did get a hit on the pi-hole binary. Further I can't seem to clear it out with the 'pihole -r reconfigure' command because this performs a release check and update. Which requires a working internet connection, which currently means I have to put the pi box back on a 172.16.1.1 subnet. And hence I can't get 'pihole -r' to reset the IP away from 172.16.1.17.
But how this could affect the network stack as a whole is another question.
Thanks again for your help.
Thank you for replying.
You are obvoiusly correct, I didn't mention anything about my router but I didn't really mention anything about what other avenues I've tried. I didn't want to fill pages with all my 'dead ends'. I decided instead to let people come up with their ideas and provide them with whatever they required.
My router consists of a pc with multiple network cards running OPNsense. When I started investigating this issue I had a different router with a very similar spec', but running pfsense. That router did have a fault (unrelated) so I swapped the machine out and changed the O/S to OPNsense which I'm still getting to grips with. So I've been trying to debug this with two different machines and two 'different' router O/S's.
In relation to your question; yes I have rebooted the routers and flushed the arp caches and the individual arp entries and assighed different MAc addresses. I've also cycled round different router ports just in case there was issues with particular network cards. All to no avail. I'm in the process of posting this issue on the OPNsense forum just incase someone there has any fruitful ideas.
Here is an image of my Arp Table:
- Image may be NSFW.
Clik here to view.
Next is a packet capture of the Infastructure subnet. Here I set up and captured a number of pings.
- Image may be NSFW.
Clik here to view.
Line 3 on the other hand shows a ping from the pi box to google for which there is no reply. More importantly note the ip address it is using. The one which should not exist given it hasn't been set in the interface file.
Line 4 show a ping from the Pi box to the the local subnet interface and again it's using the 'non existent' IP and there is no reply.
Lines 5,6 and 7 are just repeats.
line 8 shows the ssh connection between my PC and the Pi Box using the correct IP, obviously.
The sharp eyed may notice that the only two mac addresses listed are the Pi box and the infastructure subnet/router interface card. This is because I set the capture to only target the Infastructure subnet and so it only picks up and displays the packets which traverse into the subnet and not their path before they enter the target area. Hence you only see the local subnet interface mac address and not the origin mac address.
Please note this might read as If I'm trying to prove the issue is not with the router. That is not my intension. I am only showing what the router is displaying. Clearly the issue can only be with the router or the pi box and if I knew which one I probably wouldn't be writing this post.
I have done lots of testing and far from shedding light on the matter it just seems to show results that shouldn't be happening. I don't mean as in a bug. I mean as in 'networking doesn't work that way', ' I can't see how this is possible'.
Above I refered to the 'non existing IP'. That's because 172.16.1.17 isn't set in the interface file nor anywhere else as far as I can find. I grep'ed every file in the etc directory and all those related to the main compents I installed and it simply isn't there. But obviously it must be stored, cached or embeded somewhere or the PI simply wouldn't be able to display it because it wouldn't know about it.
I said I didn't find the offending IP address anywhere. That is not exactly true. I did get a hit on the pi-hole binary. Further I can't seem to clear it out with the 'pihole -r reconfigure' command because this performs a release check and update. Which requires a working internet connection, which currently means I have to put the pi box back on a 172.16.1.1 subnet. And hence I can't get 'pihole -r' to reset the IP away from 172.16.1.17.
But how this could affect the network stack as a whole is another question.
Thanks again for your help.
Statistics: Posted by 101charlie — Sat May 25, 2024 4:04 am