lee <lee <at> yagibdah.de> writes:
> >> They are wrong because there is no way for network traffic from the > >> devices on the LAN to make it to the interface enp2s0. Or, if they do > >> make it there, then there is something else seriously wrong. Absolutely. ARP has been around a very long time (rfc 826). There are thousands of code snippets out there that contain 'arp chatter'; many are benign, some are still useful, other are parts of sploits. *usually* after an extensive search, the source of the chatter is very sporadic and found in a product from a vendor. In the early days, many vendors used codes from a variety of sources to get their products to work with a variety of other devices that supported 'ethernet'. Unfortunately many companies put these codes into mal-form 'ip stacks' in products with embedded controllers. The turn over of corporate coding staff has resulted in many of the these code snippets remaining because 'the new guy' with full stack responsibility did not want to mess with parts of other folks codes. This situation varies widely and is a mild problem from big name gear (starts with a C) to the little vendors. As a consultant, it's a source of billable hours for those that can find the source (very common with industrial ethernet based control systems). It is an unmanaged irritant that mostly goes ignored from overworked coders at various vendor corps running their 'own ip stack'. And again your source(s) of nefarious arp issues many have no relationship at all to these 'arp quirks' I have characterised. > > tcpdump -i enp2s0 arp > > will tell you if the arps are being generated from something on the wire > > side. If there's not much traffic then clear the arp entry and ping > > the IP address to generate traffic. > Yes, I already tried that and didn't get any traffic listed. For me, it usually takes a while to find these 'buggers' as most are vendor vestibules in my experience. good hunting, James
