Hi,
I have a problem. I'm unable to do any SNMP request on my AS400 at the office.
I have tested several software that are able to check my AS400 and get SNMP information from it from my Dude server but The Dude server itself is unable to do so.
I have tested public as an SNMP community as well as my network's usual SNMP community but none of them works.
I don't understand how TheDude was able to get the MAC address of my AS400 and is unable to get its interfaces... That's weird.
Can someone tell me what I can test please ?
Thanks for your help

No one can help me on this problem ?
That's really weird.

bump... Am I the only one with my AS/400 issue ?

Just to illustrate my problem :

SNMP Walk with the Dude : Smae SNMP Walk with MIB Browser :

Unfortunately we don't have AS400 on our lab, we are unable to test it with this device.
Make sure you don't have any firewall on AS400, you may try to run sniffer on computer where Dude is installed and check what happens with packets.

Unfortunately we don't have AS400 on our lab, we are unable to test it with this device.
Make sure you don't have any firewall on AS400, you may try to run sniffer on computer where Dude is installed and check what happens with packets.

Thanks for your answer.
Both SNMP Walk are taken from the same computer (my Dude server) and the AS/400 doesn't have any firewall integrated in it's OS.
I'll try packet capture and let you know the result if it can help you
Thanks

Hi,
I have finally done a Wireshark capture of what's going on with my SNMP Walk on the AS400....
Who can I send it to in order to check what's going on ?
I don't really know how to read this but it seems that there's an incorrect checksum in the UDP packet.... but well, I don't know how to read it.
I wouldn't like to make it available to anyone on the forum as there's my internal network IP address.
Is one of the gurus available to help me ?
Thanks

Do you have incorrect checksum for both SNMPwalks from Dude and from your program ?

Do you have incorrect checksum for both SNMPwalks from Dude and from your program ?

Yes, I get the same errors using my other software but it doesn't prevent it from getting the answers and continuing to send requests....
Here's what I get from SNMPWalk in TheDude :
1 0.000000 frgucxxxx03.xxxxxx.xxxx asxxx.xxxxxxx.xxx SNMP get-next-request SNMPv2-SMI::zeroDotZero
2 0.000338 asxxx.xxxxxxx.xxx frgucxxxx03.xxxxxx.xxxx SNMP get-response SNMPv2-MIB::sysDescr.0
3 2.999400 frgucxxxx03.xxxxxx.xxxx asxxx.xxxxxxx.xxx SNMP get-next-request SNMPv2-SMI::zeroDotZero
4 3.000253 asxxx.xxxxxxx.xxx frgucxxxx03.xxxxxx.xxxx SNMP get-response SNMPv2-MIB::sysDescr.0
5 6.016304 frgucxxxx03.xxxxxx.xxxx asxxx.xxxxxxx.xxx SNMP get-next-request SNMPv2-SMI::zeroDotZero
6 6.017132 asxxx.xxxxxxx.xxx frgucxxxx03.xxxxxx.xxxx SNMP get-response SNMPv2-MIB::sysDescr.0

Here's what I get from iReasonning :
221 0.690021 frgucxxxx03.xxxxxx.xxxx asxxx.xxxxxxx.xxx SNMP get-next-request TCP-MIB::tcpConnLocalAddress.10.33.xx.xx.23.10.1.10.7.4396
222 0.690353 asxxx.xxxxxxx.xxx frgucxxxx03.xxxxxx.xxxx SNMP get-response TCP-MIB::tcpConnLocalAddress.10.33.xx.xx.23.10.1.10.7.4412
223 0.690504 frgucxxxx03.xxxxxx.xxxx asxxx.xxxxxxx.xxx SNMP get-next-request TCP-MIB::tcpConnLocalAddress.10.33.xx.xx.23.10.1.10.7.4412
224 0.690839 asxxx.xxxxxxx.xxx frgucxxxx03.xxxxxx.xxxx SNMP get-response TCP-MIB::tcpConnLocalAddress.10.33.xx.xx.23.10.1.10.16.4834
225 0.690991 frgucxxxx03.xxxxxx.xxxx asxxx.xxxxxxx.xxx SNMP get-next-request TCP-MIB::tcpConnLocalAddress.10.33.xx.xx.23.10.1.10.16.4834
226 0.691534 asxxx.xxxxxxx.xxx frgucxxxx03.xxxxxx.xxxx SNMP get-response TCP-MIB::tcpConnLocalAddress.10.33.xx.xx.23.10.1.10.16.4839

If I understand what I read, they do not request using the same protocol ?
I have selected version 1 in The Dude, why do I read SNMPv2 ?

Does it help you ?

Bump... Nobody ?

No answer ??
Bump

The problem is still present in v3.0 final...
Well, I finally think it's not gonna be solved by anyone....
I'm a bit disappointed

you should email MT support, because this is just a user forum

you should email MT support, because this is just a user forum

Thanks for the suggestion
I thought there wasn't any support and that all the developers and else were coming here...
I'll follow your recommendation.
Thanks

I have seen your thread and I am curious if you tried putting a specific OID in the dude and tried to just retrieve that one OID?

I don't really have any other suggestions hope the devs come along with some help for ya.

and try change where from is sends snmp-query - server/local/agents

Sorry I didn't answer before
I have tried all your suggestion and none work
Using a specific OID doesn't do anything as well as changing server or local
I'm really stuck with this and don't understand why it doesn't work.
Obviously, it doesn't want to use the same protocol as seen in my Wireshark capture....
Well, this looks like a dead end

I would love to have this solved in a way or another... Can anyone at The Dude help me ?

Please... help me in anyway

Bump again

http://www.tcpipguide.com/free/t_SNMPPr ... ndGe-2.htm

I think you are seeing snmp v1 in the working capture and snmpv2 in the non working capture... Now to figure out why when you select v1 it still uses v2.

After looking at this more closely I don't think it is a v1 or v2 issue.

Have you seen this thread?
http://forums13.itrc.hp.com/service/for ... adId=79029

Do you have any as400 mib? Maybe it will work if you add the mib?

Just fyi if you have checksum offloading in wireshark it complains about incorrect checksums. I just disable checksum testing in wireshark... False positives on that all the time.

So open wireshark, snmp walk your as400.

Open any packet in wireshark you should see the snmp version if you open the packet... You can see the circled versions. Both these captures were done from the dude in snmp walk and changing the version that it used. So you can see that the dude used snmp version 2 and version 1 in the above graphic...

Next I hovered over the object with snmp set to version 1. Then I hovered over the object with snmp set to version 2. The captured traffic looks identical. I don't know snmp well enough. I though you could browse the entire object with out having the mib. Maybe you have to have the mib? Maybe you could just place host resources mib into the mibs folder on the dude?

Nope I just looked host resources.mib and rfc1213 mib are in my Dude server...

Here's what I can give you
Using iReasonning MIB Browser

SNMP is supposed to "get next" if it is going to get a whole chain of snmp oids. The issue here could be the as400 will not start an snmp conversation from a get next, it may not support SNMP Walk.

What happens when you put [oid("1.3.6.1.2.1.1.5.0")] on the device label.
Right click the as400, select appearance, paste "[oid("1.3.6.1.2.1.1.5.0")]"

You should see the system name on the device label.
Here is the packet capture a a label refresh from my test. Notice it is just a get request and get response. I am learning here with you so please bear with me. What I don't know is why my response is a simple string value and it is populated while yours is a scalar value that is not populated. Although when you use the other mib browser you it uses "get request" and the scalar value is populated. Hopefully we can figure this out!

I am thinking that the other mib browser you are using doesn't ever use "get next" and it walks the MIB manually so to speak.

Hi sweetdude,
I'm gonna be off for a few days with a slow Internet connection...
I'll do it at the end of the week.
Thanks for helping

Yeah hopefully it is just a matter of snmp walk won't work but snmp get will work and then you will just have to build probes for specific oids since probes use get. Then you can just use your other program to get the entire oid space and find the oids you want to watch... If that is not the case then were back to debugging protocol.

Once you put the [oid("1.3.6.1.2.1.1.5.0")] on the device label. If the name shows up we are golden.

Hi and sorry for this long absence
Here's the result of what you've asked me to try : Not very conclusive....

Yeah hopefully it is just a matter of snmp walk won't work but snmp get will work and then you will just have to build probes for specific oids since probes use get. Then you can just use your other program to get the entire oid space and find the oids you want to watch... If that is not the case then were back to debugging protocol.

Once you put the [oid("1.3.6.1.2.1.1.5.0")] on the device label. If the name shows up we are golden.

Hey CGirardy,
Can you place this oid on the label instead...
[oid("1.0.8802.1.1.2.1.3.2.0")]

Thanks,
SD

Never mind that is a 802.11 wifi mib object.

The only thing I can think of now is mabye there is a specific mib for you as400 that doesn't already exist in the dude.

I placed the 802.11 mib in my file list thinking it might come in handy and it caused the dude to search for a ton of oids in that range. I don't watch wireless yet... I am certain that the OID for system name is "1.3.6.1.2.1.1.5.0" and that is part of ISO mib so there is no way it shouldn't work bleh.

Since it doesn't appear in the label when you place it directly on the device can you get a wireshark capture of what is returned when it tries to read the label value.

You will probably have to remove and re-add the label a few times to find the request and then try to get a nice capture of it...

unfortunatly I think you are going to have to send support another email... might want to refer them to this thread.

CGirardy did you give up on this?

CGirardy did you give up on this?

I'm kind of desperate because, beside you, no one seems to be interested in this problem.
As, at the moment, my schedule is pretty booked, I'm not finding any time to search....
So yes, I'm, at the moment, giving up on this.
Thanks for asking

Yeah, If someone at Mikrotik had an AS400 they would fix it now

I am stumped, Placing the oid directly on the label is the super simple way to find out if SNMP works,

Placing the sysName on the device label should work.
[oid("1.3.6.1.2.1.1.5.0")]
Although I have seen
[oid(".1.3.6.1.2.1.1.5")]
work for different types of OIDs.

The only thing I think will work is to get Mikrotik to examine a protocol exchange. support at mikrotik.com
Place the OID on the device label fire up Wireshark put "host (as400ip)10.10.10.1" in the filter, and send the capture to them.
The label should be attempted to be read every 30 seconds (default).

SD

This is probably not worth mentioning but

http://www.elifulkerson.com/articles/ne ... ficial.php

You could use the net-snmp tools to grab the values you want to graph. I know it is completely ridiculous but the thought did occur to me

I actually have an AS/400 I'm trying to get to work as well. I'd be happy to share notes on this problem.

So, as far as we know now...

http://thwack.com/forums/50/ipmonitor/2 ... onitoring/
The reason the AS/400 replies to SNMP requests using ephemeral ports rather than 161/UDP is that when IBM wrote the SNMP server, they split it into two threads or jobs: one for receiving and one for sending, presumably for performance/efficiency reasons. Since the receiver thread is already listening on 161/UDP, the sender thread is forced to use ephemeral ports. IBM say this can't be fixed without a complete rewrite and I'm guessing that task isn't high on their priority list.

==============================================

http://forums.cacti.net/about4523.html
I realize this is a very old message, but we're revisiting getting some decent metrics off our iSeries/AS400 machines. And immediately we ran into the same problem: SNMP running, but no response from an snmpwalk.

Turns out, the OS/400 implementation of SNMP, as with many things in its TCP stack, is slightly off. Our firewalls were blocking the snmp-replies. Basically, with most devices you send an SNMP-read to port 161 with a source of some random high port, and it will reply with source port 161. The iSeries, however, chooses a random source port to reply with. Fortunately, our firewall had an option for snmp for "Accept replies from any port." This solved the problem.

==============================================

“An Introduction to AS400 SNMP Support.pdf”, 255. page
Make sure OS/400 SNMP is using port 161 to receive requests. The OS/400 SNMP agent uses UDP port 161 to receive requests from managers. It doesn′ t use UDP port 161 to send response PDUs to those requests, due to technical reasons. The SNMP management application should not check the response PDU port number. The SNMP manager should not compare the source UDP port number in the response PDU with the destination UDP port number in the request PDU it sent to the OS/400 SNMP agent.

==============================================

Last one is from IBM official documentation! Is there something that developers of dude can do about this type of OS behavior?
Until that you can query AS/400 machines from Windows box like this

1. Put the SNMPUTIL.exe (Microsoft) and SNMPGET.exe (Net-SNMP - v5.4 - SNMP tools for Windows) in one folder and the MIBs in another
2. Add 2 Functions in Dude

3. Add 2 devices in Dude, with the IP of the AS/400 and in the Device – Appearance – Label put the name of the function
This is just an example on how to quickly retrieve values from AS/400. Of course you need to do some formatting on the result of the basic execute function, create probe, service, ... but that stuff is all well documented.

But, watch for 2 things, I had problems with!
First, the names of the functions must not begin with the number ("123exSNMPUTIL_Test01") because in that case the result of the function will not show correctly on the Map! (put this in the manual, please)
Second, when you type the parameters of the execute function, the location of the .exe files must not be in the folder whose name have space character (" "). This is a known issue. For example, if the folder is named "C:\Program Files\Dude\external\tools", that space character between "Program" and "Files" will make you use basic concatenate function in Dude. Also it doesn't matter if you put "\" sign on the end of the line, so "...external\tools" and "...external\tools\" is the same.
In this .zip are MIBs extracted from one AS/400 machine. Take into account that not all OIDs are explained in those files!

THE DUDE is GREAT!

I'm trying to query an AS/400 device. The SNMPWalk is able to retrieve a good deal of information, but none of the AS400 specific stuff defined in the AS/400 MIB is returned (rws related items). I read somewhere that this section had to be enabled on the AS/400. Is that true? If so, how does it get enabled. I've tried requesting the specific OID (rwsSerial; .1.3.6.1.4.1.2.6.11.1.1.1.9) and didn't receive information. I get information under sys or if or hr, but nothing under rws (sorry for the abbreviations).