Followup from
https://www.eevblog.com/forum/testgear/keysight-dmm-yay-or-nay/msg4048270/#msg4048270Just tried wake-on-lan with the latest firmware (3.03), both when not actively accessing the webserver and when accessing the HTML5 'remote control' page - no crash, works fine.
I've found the web server in the 3446x machines to be somewhat flaky. For example: Leave it showing the front panel using the HTML5 remote access and the browser end will say it can't contact the DMM after about 1/2 hour or so and a refresh, or reactivating via the control instrument tab sometimes gets it back sometimes doesn't - close the browser window and start again and it contacts it with no problem.
However, I've never had problems with basic initial access to the web server, neither have I seen the cash message that mawyatt mentions above.
So, my suspicions are that this is something to do with the local network - either some peculiarity of how it is set up, or some traffic that's happening on mawyatt's network that isn't seen on mine and that causes the Keysight firmware to barf. So, the question is: How good is the OP at using tools like tcpdump or wireshark? The ideal thing to get to here would be to see a packet (or sequence of packets) hitting the port on the DMM and the DMM repeatably crashing when that packet/sequence hits it.
The DMM
ought to be insensitive to local network settings (unless they are grossly wrong), other protocols, etc., etc., and behave nicely in the presence of any oddities,
but we know that the software/networking world often doesn't reach the standards of quality that perhaps it should. If we can find out why this is happening then perhaps we can find a workaround.
The problem here is that there are 1001 network related things that could be happening, so basics first. What's the topology of the local network, how is the DMM attached (e.g. direct to a switch and so on), how does it get its IP address, how do you browse to it (e.g. by ip address, using bonjour/mdns/zero-conf, name in DNS...)?