Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve handling "Error in packet Reason: (noSuchName)" situation #4

Open
lazna opened this issue Dec 23, 2017 · 5 comments
Open

Improve handling "Error in packet Reason: (noSuchName)" situation #4

lazna opened this issue Dec 23, 2017 · 5 comments

Comments

@lazna
Copy link

lazna commented Dec 23, 2017

Rare case: Two network devices have (accidentaly) same IP addres and SNMP community, one support 64bit counters but second one dont.

Reading packets from 64bit conuter aware device, but (probably) ARP table record expires and device supported only 32bit counters is queried with -x parameter and get error. SNMPGET display "Error in packet
Reason: (noSuchName) There is no such variable name in this MIB. Failed object: .1.3.6.1.2.1.31.1.1.1.10.2" in such situation, but TTG computate with 0 in this case which usually give non-sence results.

Shouldnt be better to terminate TTG with corresponding error message and exitcode?

@tenox7
Copy link
Owner

tenox7 commented Dec 25, 2017

Good question. Its probably a good idea to terminate. But what about other errors, should ttg terminate on timeout for instance?

@lazna
Copy link
Author

lazna commented Dec 25, 2017

What about this: Default behaviour is to terminate on any error, but offer another option "e.g. -t Dont terminate on error" with accorging behaviour. Print error text into output line is an option too, but what if people (sometimes me) expect strictly formated output for parsing? Or print error message into STDERR only?? I do not know what solution is better, but I am pretty sure ttg should not count with 0 if get error by SNMP, this is very confusing. Yesterday I sit on it few hours to discovery from where 0 value came from :-/

@tenox7
Copy link
Owner

tenox7 commented Dec 27, 2017

Thanks for finding it out! A flag like -t sounds sounds like a simple thing to do. Let me look at it.

@tenox7
Copy link
Owner

tenox7 commented Dec 29, 2017

I looked at the code and the default behavior is to terminate on any SNMP error.

stat=snmp_synch_response(ses, pdu, &resp); if (stat != STAT_SUCCESS || resp->errstat != SNMP_ERR_NOERROR) perr(resp);

perr() is terminating with exit(1) unconditionally

Are you saying that ttg is printing Error in packet but then it continues and doesn't exit?

@lazna
Copy link
Author

lazna commented Feb 7, 2018

Yes, but I am not a C programmer so I cant comment your code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants