All of the following is in a Windows 10 environment.

I've got a software defined radio here. Its firmware seems to have problems responding to ARP requests correctly. When I start the SDR software on the PC the radio, i.e. the radio firmware, generally fails to respond to the ARP request, and it doesn't work. Once in a while it will respond correctly, the software works, and you can see the correct entry appear in the Windows ARP table. I can also put the entry into the ARP table manually, and then of course everything works perfectly.

All logical and correct, and easily visible on Wireshark. But then there is ping...

When I ping the SDR, Wireshark shows no response to the ARP request, and yet the damn pings work. "arp -a" shows no entry in the ARP table. And yet the damn pings work. I thought ping was a layer 3 protocol and absolutely required ARP, which is a layer 2 protocol?

OK, more information...this has something to do with my Cisco SG200-08 switch. If I get rid of that switch and use a dumb switch, everything works fine.

So what the hell is that switch doing? I'm not blaming the switch, necessarily. Everything else hooked up to it works perfectly.  I'm still blaming the radio for something not quite right with the implementation of either the MAC layer or ARP. But what could it be that it works OK on a dumb switch and not a Layer 2 managed switch?

I had some sg300 switches, and I recall that they had the option for limited L3 functionality. (enabled in web mangement)

Does yours have this option / option turned on?

Hi Bill, thanks for the reply. No L3 features in the SG200.

I was looking carefully at Wireshark, and the only difference I can see between an ARP reply from the SDR and an ARP reply from something else is that the radio pads the ARP reply packet with all zeroes, as opposed to a seemingly random string of junk that other devices pad the ARP reply packet with.

I vaguely remember a big discussion about ARP and SDR a while back, and I think we determined that a lot of SDR boards respond to ARP requests with incorrectly formatted MAC addresses (incomplete) or reply with empty MAC addresses (all zeros) and dumb switches do what dumb switches do and just forwarded it, where managed switches view it as malformed or even ARP poisoning/snooping and drop the packets.

That was also my thread Totally separate problem. It had to do with an aberrant MAC address when the SDR in question was in an backup access mode used when the primary firmware was bricked. This is not related. These ARP replies have a valid and legal MAC address.

Devices do all kinds of peculiar things.  Especially when the makers don't always stay 100% compliant with the protocols they implement.

Did you clear the ARP caches along the path while using WS?  That might be a good sanity check.

It's natural to assume the SDR is not replying to ARP simply because your workstation is broadcasting ARP every time.  

My first thought was that they are on different subnets and that's why you aren't seeing a direct response from the SDR.  However you state that it's a pure L2 switch and didnt mention the existence of any other sort of layer 3 device between them.

I'm curious to hear what it was if you figure it out

Your system may be sending the ping to the layer 2 broadcast address or the switch may be sending the ping to all ports

Good point, Foxxz, I will look at that possibilty

brassburn: all is on the same subnet, and going through a dumb switch or directly wired (using static IPs) works perfect for ARP every time. Put the L2 switch in and not so much. Now I haven't done port mirroring to see if the ARP request is actually making it to the SDR, but I'm pretty sure it is since I have no reason to believe a Windows 10 sourced ARP request is in any way improperly formed. Occam's razor says something is wrong with the ARP reply from the SDR. I can't tell if the FCS field is OK since Wireshark doesn't report that. The only other thing I can think of is the padding as mentioned above.

This is positively IPv4, right?

Unless I'm completely misreading your post, you are describing behavior that is expected.  

If there's no match in the cache and the destination IP is determined to be on the same subnet as the source host, there is a layer 2 ARP broadcast.  The switch would then flood the ARP broadcast to all ports (except the one it was received on) and then it's up to the host with the matching IP to send the ARP reply.

This is the exact circumstance that would ideally show the reply rather than obscuring it.

Yes.

its also possible that the design of whatever client/server comms is w/o ARP.  where you tell a client what IP address the server is, and the client assumes some arbitratry MAC for the server. even so, in this case the flood still happens until the server responds and then the switch knows what port the mac is behind and can then stop flooding.

the behavior you see in wireshark seems impossible.  do this:

power off sdr.  uninstall all sdr client software, reboot pc, start pcap capture.  power on sdr, wait a few secs, ping.  post up the capture on a pastebin somewhere.  id like to see this.  you are not quite right though - ping/ICMP is layer 4.