This is a static archive of our old Q&A Site. Please post any new questions and answers at

SNMP string with # displayed as %23


Hi, I am troubleshooting an issue with a vendor of ours. We are using an SNMP tool to scan our network and keep running into failures. I used wireshark to determine that the snmp string sent out over the wire is incorrect.

I am typing my SNMP string into a webserver which then takes that string and attempts to query the device. When I see the community string in wireshark, I notice that the "#" is now missing from my string and replaced with "%23"

The vendor has told us this is just wireshark displaying the # as the hex value. This does not make sense to me as I am asking myself, why wouldn't wireshark convert the rest of that value to hex? Can anyone help me validate or correct what this vendor has told me?

asked 11 Dec '15, 15:11

crknipe123's gravatar image

accept rate: 0%

Do you have a screenshot of the packet bytes pane, or better yet a trace you can share? Share by cloudshark, dropbox, drive, etc...

(11 Dec '15, 17:30) Rooster_50

One Answer:


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.

answered 12 Dec '15, 02:22

sindy's gravatar image

accept rate: 24%

edited 12 Dec '15, 04:13

I had a 2nd look and it seems as if it is also incorrect in the dissection pane as well. So I am now confident it is the web browser/web server. Thanks for the explanation.

Screenshot of pcap

(12 Dec '15, 06:35) crknipe123