Wireshark doesn't seem to work with SOME systems ...

this is all just about student lab work in a classroom environment - so this isn't really a "problem" for me – but I'm more than a little bit curious ...

when I use Wireshark to "discover" an unknown address on something like a 1756-ENBT it works flawlessly ... and on a 1769-L35E – also perfect results ...

specifically, when I first connect either one of these two devices to a simple network with my laptop, the expected magic happens – and the Wireshark window displays something like this:

Gratuitous ARP for 192.168.1.3 (Request)

Click to expand...

that part is great – and now I know the IP address of the "unknown" network device – even if it's on a completely different subnet from my laptop ... so Wireshark works ...

but ...

I can't get the same response from a 1756-ENET ... nothing "Gratuitous" pops up on the Wireshark screen when I connect to one of these things ... (I've tried it with two separate ENETs with the same lousy results) ...

so ...

I'm thinking that the newer ENBT and the also newer L35E devices will make the "Gratuitous" requests as advertised ... but ... it looks like the somewhat older ENET devices don't want to cooperate ... and yes, I can ping these things with ZERO problems ... and they work perfectly with RSLinx and so on ...

is there something simple that I'm missing – or is this just the way the world works? ... I've tried powering-down and powering-up ... and plugging-out and plugging-in ... and the super-secret high-tech rain dance (yes, going counter-clockwise and making sure to lead off with my right foot) ...

as I said earlier, this isn't something that I'm worried about ... if it works OK – and if it doesn't work that's OK too ... but if it's just a matter of some simple little setting that I'm missing, I'd appreciate a kind nudge in the right direction ...

thank you for reading this far ...

Perhaps it's as simple as the ENET does not support ARP Announcements or Gratuitous ARP Messaging. Can anyone confirm?

It's probably just something the 1756-ENET doesn't do.

Another thing the 1756-ENET doesn't do is (as far as I've seen) respond to the List_Identity broadcast used by the EtherNet/IP driver in RSLinx Classic. You have to use the Ethernet Devices driver with the 1756-ENBT, no matter if it's running Series A or Series B firmware.

I consider this method 80%. It works often, but no where near 100%. I don't have this product, but as you mention it is old, I am not surprised it does not work.

Address conflict detection, if supported, will usually make this method of finding an unknown IP work. Ken had my next guess with the EIP broadcast discovery methods, but since that doesn't work, we can dig deeper into the bag of tricks.

Can you try a broadcast ping? From Linux, it's ping -b 255.255.255.255 and SOME hosts respond. My Micrologix 1100 responds, but that's the only Rockwell device I have access to right now. Isolating the devices, with a broadcast ping, a response matching the mac would give you an IP in the ICMP echo response. Not exactly sure of the Windows syntax. Verify in Wireshark when you try this that the ICMP echo request has a layer-2 broadcast address, i.e. destination MAC of ff:ff:ff:ff:ff:ff. This ensures that the unknown device gets the request, but whether it responds or not is a different story.

I have less luck with the all-hosts multicast address: ping 224.0.0.1
I usually get some responses, but I usually get more, and different, responses with the broadcast method.