Having had some time now to think about what’s going on, given the Wireshark data, I’m starting to believe that there’s a difference between textbook application (where everything works, perfectly) and real-world engineering (where things break). Rumor has it that there is a difference.
So, why, in this case, would using separate ports per query make sense?
Two things to keep in mind: its UDP traffic, and its SNMP, which is used to monitor presumably simple devices.
UDP is an “unreliable” protocol, in that it doesn’t have error detection and retry methods. There’s no guarantee the packet gets to the destination, or if it gets there, that any kind of answer will come back.
SNMP is a common data structure used as an overlay on all sorts of hardware with all sorts of capabilities. In its original incarnation, the device hardware was little more than some decoder logic, a hardwired UDP capability, and a register that could be queried and set by a UDP packet.
SNMP can make a very complicated and physically distributed “device” appear as a single entity. In reality, there may be a single controller device, and very distinct and physically distant subdevices. Consider a cable TV distrubution, with a neighborhood controller node, and the individual household interfaces at each home. One SNMP “device”, but physically distributed.
To query that device, the SNMP manager software will go thru and walk its data structure list. Simple to do. Textbook stuff.
Enter the real world. Things break, wires get unplugged, response times can differ from physical device to physical device.
If the query goes out by TCP, then the controller device has to have more smarts than simple decoder logic. That costs, so that won’t do at all. So UDP it is.
Query packet goes out to the controller device, to report the value of register foo. Okay, so where’s the answer. UDP doesn’t guarantee an answer, or even a timely answer. One device that’s damaged, destroyed, or frozen can’t hold up the queries to everything else. The port the query got sent from can’t be reused until you get an answer back. Answers don’t have tags saying what the answer is about. Query “show me register A”, wait wait wait wait, back comes “15”. If you’re lucky and everything is working.
So, real world requires one unique port per query. The time lag from query-out till answer-back is part of the diagnostics. No answer is a fail, slow answer is a problem. Atypical value, like “2” instead of “15”, may or not be a problem. That depends on the device. Look the number up in the specifications, as translated into the SNMP Management Information Base (MIB), and see what it says.
If the device MIB has a lot of registers to be queried, then it’s a lot of ports and a lot of timeout checking to make sure everything is working properly.
In the case here, the HP printer MIB seems to be large as in several hundred entries. Being directly attached on the LAN, probably with an on-board CPU doing its own diagnostics, the printer can respond almost instantly to any SNMP query that comes in. SNMP answers come back as a flood.
With this kind of SNMP description, it would seem that any SNMP capable device produced these days, especially that has its on on-board CPU, is going to reply similarly. That would seem to imply that CFP is going to complain about any SNMP capable device that has a MIB over a certain size, that has device management software installed on the PC where CFP is installed.
I won’t characterize this as a CFP bug, but a change in the flood and scan checking to ignore LAN traffic on UDP 161 would seem to an obvious solution.
And, my apologies to the HP code writers. They got it right. Real world engineering beats textbook code, if things are going to work reliably.
