You might want to check the DHCP lease time in your router. If there is traffic during the last half of the lease, the lease will be renewed. If your lease time is quite low, and you left the scope on and connected but did no network activity for half the lease time, your DHCP lease might expire, and would have to be re-negotiated. If the scope does not handle the re-negotiation properly, this might be enough, like the other network disturbances that have been tested, to fubar the scope. If you increase you lease time to more than twice the longest time you expect to leave the scope on and connected to the net with no network activity, it MIGHT reduce the lockups.
I recently got an MSO2072A scope from TEquipment a few days ago and began experiencing the same screen freezing bug. However, my scope is not connected to a LAN. We're discussing it in another thread here: https://www.eevblog.com/forum/testgear/rigol-mso2072a-problem-display-stops-updating/
I've also contacted Rigol tech support about this and have been talking to Jason (out of Ohio, I believe). I've been posting about my experience in the above thread. Have you tried resetting the FRAM during boot? The theory in the other thread is that there may be a software bug that corrupts a section of the FRAM, resulting in the screen freeze, and bumping a control knob makes the screen update again.
Hey motocoder - you never responded to my question in the other thread, so I'll just ask it again here:
Based on the behavior of my RUU utility, there were some major changes to the LAN code in the DS2000 FW, beginning with, I believe, v.3 (although maybe it was v.2). Have you downgraded to FW 02.01.00.03 or FW 01.01.00.02 to see if the lock-ups persist?
Not that it solves the problem, but if the bug was introduced with the changes to the LAN in that specific FW#, it might help Rigol locate it more quickly.
I'm probably missed something - but if you want to use a DHCP server then just tell it that the scope's MAC address always is given the same IP - i.e. reserved. There are other solutions but on a network this usually a good solution.
causing any issues, because I also see these when the scope is stable with no lock-ups for 12+ hours. Also note that when the scope locks up, it always right after it sends 3 ARP queries to the desktop, each of which asking what MAC address owns its IP address.
So, looking at this capture, and the others, I decided the only thing that looked unique was these strange scanner software packets. In WireShark they are labelled as protocol "BJNP", but they are actually UDP packets to some particular port. The UDP point-to-point packets are sent to port 8612, and the UDP broadcast packets are sent to port 8612. The BJNP broadcast packets seem to be some mechanism for the Canon printer/scanner drivers to identify Canon printers and scanners on the network. I have no idea why the driver also sends such packets directly to specific IP addresses. But in any case, I no longer own any Canon printers, so I uninstalled this driver software. And then after rebooting everything, including the scope, wonder of wonders, the lock-ups stopped.
This is a plausible explanation, as this computer is the only computer on the network that still had the Canon software installed on it, and would explain why the scope only locks up when this computer is on the same LAN with it.
However, that's not the end of story. I decided to write a small "UdpPing" program to allow Rigol to recreate this scenario without having to install old Canon printer drivers. I did that, but so far I have not been able to recreate the lock-up. It's possible that there is some network traffic that I didn't capture (multicast packets maybe?), or perhaps my program isn't faithfully recreating the exact packets that I did capture. I'm going to poke around with it a little bit later today, and will post back here if I find out more.
causing any issues, because I also see these when the scope is stable with no lock-ups for 12+ hours. Also note that when the scope locks up, it always right after it sends 3 ARP queries to the desktop, each of which asking what MAC address owns its IP address.
So, looking at this capture, and the others, I decided the only thing that looked unique was these strange scanner software packets. In WireShark they are labelled as protocol "BJNP", but they are actually UDP packets to some particular port. The UDP point-to-point packets are sent to port 8612, and the UDP broadcast packets are sent to port 8612. The BJNP broadcast packets seem to be some mechanism for the Canon printer/scanner drivers to identify Canon printers and scanners on the network. I have no idea why the driver also sends such packets directly to specific IP addresses. But in any case, I no longer own any Canon printers, so I uninstalled this driver software. And then after rebooting everything, including the scope, wonder of wonders, the lock-ups stopped.
This is a plausible explanation, as this computer is the only computer on the network that still had the Canon software installed on it, and would explain why the scope only locks up when this computer is on the same LAN with it.
However, that's not the end of story. I decided to write a small "UdpPing" program to allow Rigol to recreate this scenario without having to install old Canon printer drivers. I did that, but so far I have not been able to recreate the lock-up. It's possible that there is some network traffic that I didn't capture (multicast packets maybe?), or perhaps my program isn't faithfully recreating the exact packets that I did capture. I'm going to poke around with it a little bit later today, and will post back here if I find out more.
This is why I pinpointed arp broadcast in the first place:
https://news.ycombinator.com/item?id=8565161
look at your captures again and you will find this shitty Canon software spamming mDNS crap all over your network
its not only type of packet, but also amount per second.
I read similar story on one of the bofh forums some time ago where one computer was able to start arp flood in 30 computer office, it started with one, but 100ms later every computer in the office (with mdns support) was spamming that shit 100Mbit flood on every port in the building.
edit: btw to not give Rigol stupid ideas (like charging you for shipping) - this is TOTALLY their fault, they have shit in low level network stack.
Probably just me, but looking on the wireshark capture, I don't get it.
AFAICT the Rigol scope is on an IPv6 ...........:01:8a address and your computer on an IPv6 .........:30:8f address.
So who or what is on the 192.168.1.120 and 192.168.1.9 IPv4 addresses, one of them is probably still your computer, but what is the other
address they all want to discover?
Those are MAC addresses, not IPv6 addresses.
Those are MAC addresses, not IPv6 addresses.ok so the scope asks who has 192.168.1.9 but wants a reply to 0.0.0.0 never seen that how do you explain that?
The client SHOULD perform a check on the suggested address to ensure that the address is not already in use. For example, if the client is on a network that supports ARP, the client may issue an ARP request for the suggested request. When broadcasting an ARP request for the suggested address, the client must fill in its own hardware address as the sender's hardware address, and 0 as the sender's IP address, to avoid confusing ARP caches in other hosts on the same subnet. If the network address appears to be in use, the client MUST send a DHCPDECLINE message to the server.
Ok well not to rock the boat for nothing just interested, he're is an ARP wireshark cap from me.
You can see that here that the Hewlett device that asks for the IP address from the Cisco already has a valid IP address on its own.
It might well be that 0.0.0.0 is used if the device has no IP address yet.
Those are MAC addresses, not IPv6 addresses.ok so the scope asks who has 192.168.1.9 but wants a reply to 0.0.0.0 never seen that how do you explain that?
I think "arp flood" may be what happened here. I looked at the packet capture again,and actually it is my desktop computer that was sending those last 3 arp packets to the scope, not the scope sending the last 3 arp packets, right before or after the lock-up. Last night I used some software (bit-twist) to simulate that, but it didn't trigger a lock-up even if I sent hundreds of them.
Can you elaborate on any theories you might have as to how the Canon software might be triggering the issue? Now that I know how to use bit-twist to send arbitrary packets, it would be great if I could exactly reproduce the lock-up so that Rigol can start working on a fix.
it probably only works if you spam with same IP scope just requested
from your brief screenshot it looks like scope replies like it already owns that particular IP _while it still waits for DHCP request reply_