SNMP

While setting up printing from my Linux box and Linux notebook to JDServer, I discovered that, by default, the printing systems request information about the server via SNMP GetRequests. If there was no SNMP response, printing might not start.

The work-round is to add a suffix to the URI string to tell Linux not to use SNMP GetRequests.

Inevitably, though, this got me wondering whether it would be possible to get proper SNMP responses.

This immediately looks difficult because it’s possible to ask lots of different questions via SNMP, only some of which are about printing, but all of which go through port 161/UDP. This means that there would have to be a handler for the port, and some means of passing messages back and forth between it and the parties that would be able and willing to respond. I can imagine the use of Wimp broadcast messages, but this isn’t the only way.

SNMP traps all have to go to port 162/UDP of the SNMP manager (which RISC OS would never reasonably be), but can come from any port, so there isn’t a similar headache if RISC OS were to generate traps.

So: does anyone have any thoughts about whether SNMP is a desirable addition to RISC OS? Also, has anyone actually written any SNMP code? (I have, but only adding more traps to a system with a well developed existing framework, so my knowledge of SNMP is very little.)

Are you looking at SNMPv2c or SNMPv3?
Knowing typical printers, probably SNMPv2c

Out of interest what happens when you disable SNMP on the printer? Typically the Ricoh printer range have it off by default (we turn it on for the reporting system to scan for low toner and other issues)

Are you looking at SNMPv2c or SNMPv3?

I’m looking at SNMPv1. I know you’ll throw your hands up in horror because of the lack of security, but, in the land we’re living in, SNMP is something I’d expect to be used only in networks that are already secure from intrusion.

Out of interest what happens when you disable SNMP on the printer?

In my case, the Linux boxes are dealing with my print server (JDServer). The printer is not visible to them because it’s connected via USB to the BBxM where JDServer is running.

I should add that Wireshark’s SNMP dissector tells me that the GetRequest from Ubuntu is SNMPv1.

(It seems a very rudimentary dissector. I need to see if there’s a more comprehensive one available separately.)

Some progress, which always seems to be accompanied by its share of bad news.

I’ve written a little app in BASIC to accept and textify SNMP requests coming in to port 161/UDP. Each print job sends 2 requests. I’m more interested in the second, which is a GetRequest for an OID of 1.3.6.1.2.1.43.5.1.1.2.1

Now when I look that OID up, I have two problems. First is that the OID appears to be one field longer than is possible (i.e. AFAICS it should only be 1.3.6.1.2.1.43.5.1.1.2). Second is that, although I can understand all the words of the explanation of prtGeneralCurrentLocalization index, I utterly fail to comprehend what it means.

Here’s the content of the SNMP message, in case anyone wants to analyse it.

30 29 02 01 00 04 06 70 75 62 6C 69 63 A0 1C 02
01 01 02 01 00 02 01 00 30 11 30 0F 06 0B 2B 06 
01 02 01 2B 05 01 01 02 01 05 00

Firstly, my earlier question about version was to establish that you were avoiding the security aspects of SNMPv3 as v1 and 2c are virtually identical and both push things around using cleartext community strings while SNMPv3 encrypts

With regard to the actual problem, I presume you’ve checked the network conversation occurring when you run SNMPWALK and that you’re modelling the query util you’ve made on the code in the sourceforge net-SNMP

Looking at the message the first thing I notice is that simply typing the codes into dump mode in StrongED spells out 0)BA@Dpublic where “public” would be the default community string sent in cleartext (as normal in SNMPv1 or v2c). Now if that’s the return message from the SNMP server I don’t think it returns the community string unless there is a mismatch in the community string setting on the client query tool and the SNMP server.
Try the same query using SNMPWALK or SNMPGET from a Windows PC using the tools above with the correct community string and Wireshark that conversation.

Steve, I appreciate your help, but I think you have misunderstood where the messages are coming from: all from Ubuntu, addressed to the print server (my app on a BBxM), which is not responding, so there is no conversation.

Ah, in that case, my understanding is
1.3.6.1.2.1.43.5.1.1.2.1 = 1.3.6.1.2.1.43.5.1.1.2. + index 1 i.e. first instance of the parameter you’re querying which in this instance covers language,country,characterset

Reading the OID information/documentation is often like figuring out a chinese crossword clue but my interpretation is that your app should respond with a language code for 5.1.1.2.1 and country code for 5.1.1.2.2 and characterset code for 5.1.1.2.3

Modifying my suggestion: wireshark the conversation of SNMPWALK using the UBUNTU box and a (commercial) network printer / print server and I think you will see a query of index .1 .2 and .3

Ah, thank you, Steve – I would never have interpreted their description as an index into those three things.

Next challenge is to find out what would be acceptable responses from me to those requests. If I’ve understood the RFC correctly, the responses should be in textual form, but, if so, I have no idea what text strings it would understand.

(As an aside, I don’t understand why Ubuntu asks about the printer localisation, because it’s going to send all text as a graphics image anyway. There is no way to print text to, or to get text from, the printer. I’m not aware of any text responses from a complete implementation of a JetDirect server either, but, as always, if anyone knows different, I will be happy to learn!)

Sadly I don’t have access to any other print server. I used to have a little Netgear one, but it died.

I’ve been duckduckgoing on the Internet, and I’ve seen a posting in a Wireshark forum that suggests that a legitimate response to 1.3.6.1.2.1.43.5.1.1.2.1 is an integer with the value 1.

Well, OK; but what does 1 represent in this context? Let me guess: US English? (The Wireshark correspondence was about Wireshark not dissecting SNMP. So there were numeric values, but no conversions to text.)

I presume there must be a list of localisation values somewhere, but, if so, I haven’t found it yet.

Sadly I don’t have access to any other print server. I used to have a little Netgear one, but it died.

Local freecycle trawl for a network printer?

PS. With this stuff there’s often more info in the MIB than in the (not very) explanatory documentation.

A little more progress. I have responded to the GetRequest I showed above. This has caused Ubuntu to issue another GetRequest, this time for 1.3.6.1.2.1.43.7.1.1.4.1.1

Which I suppose means it could at least understand my response, which was with an integer value 1 (= “other”).

So I’d better look this one up and see if I could respond sensibly.

I can aso play responding to the first that it sends, 1.3.6.1.2.1.25.3.2.1.3.1, with an error.

Technology is such fun, isn’t it? :-) At least it’s better than watching TV…

My first attempt last night to reply to 1.3.6.1.2.1.43.7.1.1.4.1.1 was short by one byte. Ubuntu did not send any more printmib GetRequests.

Maybe it’s a bit fragile. I can’t imagine that it gets much testing from incompetents like me.

Technology is such fun, isn’t it? :-) At least it’s better than watching TV…

Tour round some Birmingham pubs before sitting down in the Symphony Hall.
Steve Hackett, using Marshall amp technology.

Maybe it’s a bit fragile. I can’t imagine that it gets much testing from incompetents like me.

Oh, I don’t know so much, various devices have had to put up with me tinkering.
Simple Network Management Protocol? Can we have a look at the OID schema and delete the Simple?

I saw Steve Hackett in Drammen last month. Brilliant concert! :)
(sorry, offtopic…)

Simple Network Management Protocol is a protocol for managing simple networks. Not a statement on the complexity of the protocol!

That having been said, there doesn’t appear to be much to the protocol itself. The difficulty lies in understanding MIBs.