Continual ARP Requests

asked 2019-07-21 03:10:04 +0000

New2Shark
1 ●1 ●1 ●1

updated 2019-07-21 07:51:54 +0000

flag of United Kingdom of Great Britain and Northern Ireland

23835 ●4 ●976 ●227 https://www.wireshark.org

Hello, everyone. I'm new to Wireshark, so this may be a stupid question. I'm seeing my router continually ARP-ing an IP address that appears to be the same as my public address except for the last octet (after the last period). The message is the following:

46.853880 Tp-LinkT_24:23:b4 Cadant_6f:68:46 ARP 60 Who has 73.207.128.1? Tell 192.168.0.1

I read an answer to a similar question, but it didn't make sense to me. My set up is very simple: a router with Wi-Fi capabilities with two Ethernet connections + whoever is connected to Wi-Fi at the time (my phone, my wife's phone, my daughter's laptop and phone). I have strict access controls, so there are no unauthorized devices. I can account for everything when I access the router and check everything that is connected - nothing but the whitelisted devices that I configured myself. Such behavior of the router is obviously not normal. Is the router ARP-ing the modem itself for some reason and the model does not respond? I may be just talking gibberish right now... as I said, I'm new to WireShark and don't have a deep understanding of networking yet (but trying to learn).

edit retag flag offensive close merge delete

add a comment

answered 2019-07-21 13:37:13 +0000

SYN-bit

18528 ●9 ●343 ●255 https://SYN-b.it

An ARP request packet is used to map an IP address (Layer 3) to Mac address (Layer 2). When the mapping is unknown, you will see an ARP packet sent to the broadcast mac-address ff:ff:ff:ff:ff:ff. When the requester does already know the mapping, it will send a unicast ARP packet to the already known mac-adress to verify if that mac-address is still using the requested IP address.

In your case it's a unicast destination mac-address, meaning the router still knows the mac-address that uses the IP address 73.207.128.1. But it is verifying that it can continue to use the mac-adress "Cadant_6f:68:46" to send traffic to this IP address. As you said that this IP address is the same as your public-IP apart from the last octet, I assume this address is the gateway address your router received from your ISP to use when sending packetss to the Internet.

What is not normal bout this packet is that it uses the IP adress of the LAN/WiFi interface of your router. But I guess you see these ARP requests on the LAN/WiFi side of the router. In that case it would be correct to use this IP address, but then it is strange that it tries to find the gateway of your provider on the LAN/WiFi side of your network. It should be looked for on the WAN side of your router.

My guess is that your router sends out the ARP request for 73.207.128.1 on all of it's network segments (both the WAN side as the LAN/WiFi side). It will (and should) only receive an ARP response on the WAN side and will update the idle-timer of the ARP entry in its ARP cache.

edit flag offensive delete link

Comments

That makes most sense out of it than I can hope to get, I believe :) You are right, I was running WireShark on the LAN side just to see what it would capture. As I said, I'm new to WS, so I'm starting to learn from the basics. So, where I'm scanning I will only see the exchanges between the router and my machine plus the multicasts and broadcasts that the router may be sending. Another thing to add to this, which I forgot, is that "Cadant_6f:68:46" used to have one of the subnet addresses, let's say 192.168.0.186. So, the router would just be ARP-ing this subnet address all the time. But even then I did not see it among the devices on the subnet. But then I went ahead and shrunk the range of available subnet addresses to just be ...(more)

New2Shark ( 2019-07-21 14:23:10 +0000 )edit

So, where I'm scanning I will only see the exchanges between the router and my machine plus the multicasts and broadcasts that the router may be sending.

Plus packets that were "flooded" by the switch. Whenever a switch needs to forward a packet to a destination that is not in its forwarding table, it just floods that packet to all ports (in the same VLAN) as a last resort to reach it. So in this case, if you saw this packet on a LAN port, it means the router did not have that mac-address in its forwarding table for the LAN side.

Does the mac-address "Cadant_6f:68:46" belong to a system on your LAN or is it the mac-address of the gateway at your ISP (as I assumed).

SYN-bit ( 2019-07-21 14:46:29 +0000 )edit

Thank you for explaining the flooding as well, I was only marginally knowledgeable about it :) As far as the "Cadant_6f:68:46," none of the connected devices have that MAC address per what the router reports in its GUI. So, that would be the gateway at the ISP, then? And the reason I'm not seeing the response from the ISP is that I'm not scanning at the router so I don't see the WAN side, correct?... The only strange thing is that somehow that ISP gateway had a subnet IP provided by my router until I changed the available subnet IP pool... or am I missing something?

New2Shark ( 2019-07-21 17:49:18 +0000 )edit

Thank you for explaining the flooding as well, I was only marginally knowledgeable about it :)

No problem, we are all (me included) here to learn and pass on the gained knowledge...

As far as the "Cadant_6f:68:46," none of the connected devices have that MAC address per what the router reports in its GUI. So, that would be the gateway at the ISP, then?

That would be most likely.

And the reason I'm not seeing the response from the ISP is that I'm not scanning at the router so I don't see the WAN side, correct?...

Yes, that is correct.

The only strange thing is that somehow that ISP gateway had a subnet IP provided by my router until I changed the available subnet IP pool... or am I missing something?

I would not assume that based on the ARP traffic. Please beware that the ARP ...(more)

SYN-bit ( 2019-07-21 20:32:44 +0000 )edit

Good point :) It's just that the router was directing that traffic to a subnet IP until I shrunk the subnet IP pool and effectively "kicked" that IP out of the range... then the router started directing ARP traffic to the same device but using its actual IP. Pretty weird indeed. I wonder how I would test it :) Thanks again :)

New2Shark ( 2019-07-21 21:27:20 +0000 )edit

add a comment

Continual ARP Requests

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

Continual ARP Requests edit

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

Continual ARP Requests