SNMP string with # displayed as %23

Many text-based protocols (not sure that it is the case of SNMP, but I am sure about SIP and I am almost sure about HTTP) use escaping of special characters in address (uri, url) strings because these characters have a special meaning for the text-based protocol itself.

I can imagine that Wireshark would translate (unescape) %23 (three characters) into a single # when displaying the value in dissection pane, as dissectors are written by different people and someone might prefer to be bit-verbatim while someone else might prefer readability, but it would definitely not do the reverse, i.e. to escape a received # into %23.

Luckily, there is the packet bytes pane below the dissection pane, so click at the string value in the dissection pane and see the corresponding bytes highlighted in the packed bytes pane. If you find there, in the ASCII (rightmost) part, the %23, you can be sure it is what the web-fed machine has sent in the SNMP message.

My own guess is that your browser translates the # into %23 before sending the data using http GET, because in case of GET, the data filled in to the form are used as parameters of url so they have to be escaped, and the vendor's machine does not translate %23 back into # when processing the received parameters.

If you can use plain http rather than https to access the web interface, capture also the http communication and look into it, you should see whether your browser sends # or %23 in the request url if you use # inside the form fields, something like

GET /?field1=%23one HTTP/1.1\r\n

if you've filled one of the fields with #one.

If they are using POST instead of GET, the parameters are part of the body rather than the url but the same encoding rules are intentionally applied.

The # has a specific meaning in an url because it is normally used to separate an identifier of a certain position on the web page to which the browser should focus the display of the page, so it is normally not sent from the browser to the server. So I dare to speculate further and say that the application vendor improperly handles url-encoded strings at reception, unescaping only % HEX HEX sequences which it has on some list, and the %23 is missing on that list for the above reason and therefore they forward it transparently. The correct way is to escape only what is necessary (to save place) when sending, but to unescape everything received, as the % character is always a leading one of an escape sequence; if it is to be sent itself, it is escaped as %25.