Feature proposal (also community pls say if it is required)

nuclearcat · Wed Dec 12, 2007 1:43 am

1)We faced recently strange issue with lightening - 3 cards in PC, one of the cards was damaged (it is was not shown anywhere, card was visible). All cards was dead (i can change settings, but cards dont see anything in air), cause by "unexpected replies to driver" from damaged card was blocking atheros driver. It was visible only on screen, looks like Linux kernel messages. So question - is it possible to make option, to send kernel messages with atheros driver errors to log?
2)Ethernet error counters. In case of duplex mismatch, corrupted cable, kernel overload - it will be very useful to see input/output error counters (like in ifconfig)

Equis · Wed Dec 12, 2007 3:40 am

Ethernet error counters. In case of duplex mismatch, corrupted cable, kernel overload - it will be very useful to see input/output error counters (like in ifconfig)

+1

roc-noc.com · Thu Jan 03, 2008 4:02 pm

Yes it is really needed. Add my vote. I am trying to troubleshoot an ethernet problem with a customer right now. It would be nice if I wasn't blind on the Routerboard side.

Come on Mikrotik. ifconfig can't be that difficult to add.

Tom

stephenpatrick · Thu Jan 03, 2008 5:55 pm

It's been asked for before - and yes, it's very much needed, especially for outdoor/rooftop routers.
I bet the feature is already there in the drivers in the Kernel. Most decent NIC drivers Windows (esp. Intel) have this feature.

Make sure you've voted for this on the Wiki.

Generally, I sense the MT people are probably working flat-out to get a stable 3.0.0 out, i.e. debugging, and any new features are going to have to wait till some time after that.

Regards

nuclearcat · Fri Jan 04, 2008 6:37 pm

Imho it is too trivial to include it to wiki. Already Mikrotik taking from /proc or somewhere else information about counters, so it is just few lines more in code. Not complicated like other things in WIKI.

Tue Jan 08, 2008 10:49 am

It's not as easy as you make it seem. this information is different in each driver, and we would have to work on each driver to make this information available.

cmit · Tue Jan 08, 2008 10:55 am

OK, but I think that it would be well worth that work.
I consider this a very valuable information for diagnostics, and actually would consider it a must-have...

stephenpatrick · Tue Jan 08, 2008 11:53 am

It's not as easy as you make it seem. this information is different in each driver, and we would have to work on each driver to make this information available.

Ah thanks Normis - this is the "real" problem here - multiple drivers to support "extract of stats".

Suggestion: I wonder if it possible to extract such data from the driver into some simple common format (strings? flags?) and perhaps just make available in CLI (not winbox) to keep things simple, so that users can at least "print" extended port stats, which might be more or less "complete" depending on which driver. Some (oddball) drivers, that might be "none", common ones would be easier. Supporting just the most common types would be a great start.
Another note, I guess most RB's (and several other makes of board) use similar chips e.g. Via, Realtek, i.e. a specific subset of the total number supported. Many PC and PCI-type boards use Intel chipsets, those would be good too.

I tend to agree with CMIT, that for carrier-grade and certainly rooftop routers (which can be on long POE, with other sources of noise like GSM, radio, microwave transmitters) that it's a "required" not "desired".

Regards

nuclearcat · Tue Jan 08, 2008 12:15 pm

I dont agree about specific drivers. From me it took about 30 minutes to implement interface, and there is various ways to do it (over netlink or plain file /proc/net/dev lookups)

Just look to /proc/net/dev. Majority of drivers have "tp->stats.tx_errors++;" at least and similar things.

Example my "homemade" router on Linux /proc/net/dev:

国米传递脸| | |接收字节数据包犯错s drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed lo:833645974 2248850 0 0 0 0 0 0 833645974 2248850 0 0 0 0 0 0 eth0:689731851 208780975 0 0 0 0 0 241 3318003266 163815713 0 0 0 0 0 0 eth1:2390171464 174492174 0 0 0 0 0 603 2296370884 214921519 0 0 0 0 0 0 teql0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth1.10: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth1.11:3547648499 30456087 0 0 0 0 0 96 2549967840 38667836 0 0 0 0 0 0 eth1.12:3463167444 57065011 0 0 0 0 0 179 2028042674 71285724 0 0 0 0 0 0 eth1.13:502234657 32030859 0 0 0 0 0 103 2752216307 37425224 0 0 0 0 0 0 eth1.14:1862571411 12730849 0 0 0 0 0 81 3409601235 15766866 0 0 0 0 0 0 eth1.15:1826968872 13221641 0 0 0 0 0 75 3438064953 16323743 0 0 0 0 0 0 eth1.16:233191655 28983223 0 0 0 0 0 67 3366357061 35452379 0 0 0 0 0 0

Do you want to tell for Mikrotik developers serious challenge to parse teh file?

butche · Tue Jan 08, 2008 8:22 pm

FWIW, you can gather this information from SNMP. Not a perfect method, but it is certainly a usable method.

[admin@ButchEvans] > /interface print oid Flags: X - disabled, D - dynamic, R - running 0 R name=.1.3.6.1.2.1.2.2.1.2.1 mtu=.1.3.6.1.2.1.2.2.1.4.1 mac-address=.1.3.6.1.2.1.2.2.1.6.1 admin-status=.1.3.6.1.2.1.2.2.1.7.1 oper-status=.1.3.6.1.2.1.2.2.1.8.1 bytes-in=.1.3.6.1.2.1.2.2.1.10.1 packets-in=.1.3.6.1.2.1.2.2.1.11.1 discards-in=.1.3.6.1.2.1.2.2.1.13.1 errors-in=.1.3.6.1.2.1.2.2.1.14.1 bytes-out=.1.3.6.1.2.1.2.2.1.16.1 packets-out=.1.3.6.1.2.1.2.2.1.17.1 discards-out=.1.3.6.1.2.1.2.2.1.19.1 errors-out=.1.3.6.1.2.1.2.2.1.20.1

You can see that errors, discards, and such are available from snmp, so:

butchhomeunix:~$ snmpwalk -v 1 -c public 192.168.5.1 1.3.6.1.2.1.2.2.1.14 IF-MIB::ifInErrors.1 = Counter32: 0 IF-MIB::ifInErrors.2 = Counter32: 0 IF-MIB::ifInErrors.3 = Counter32: 0 IF-MIB::ifInErrors.4 = Counter32: 0

It is, again, not a perfect solution when troubleshooting, but having something like snmpwalk available can be handy. I agree that it should be visible directly in the winbox or cli (preferred by me), but in the meantime, this is a usable method.

nuclearcat · Tue Jan 08, 2008 10:06 pm

FWIW, you can gather this information from SNMP. Not a perfect method, but it is certainly a usable method.

Butche, thanks a lot, for a time being it can help in most difficult situations.
Probably i will write some tool in perl to get only specific values of interface by name (first getting one by one names from indexes and then when i will find required number it will grab stats from it), it is not useful to keep grabbing all data from snmpwalk

butche · Tue Jan 08, 2008 10:15 pm

no problem, nuclearcat. You can find which specific oid is for each interface by doing:

/interface print

The output of that will have something like this:

[admin@ButchEvans] interface> print Flags: X - disabled, D - dynamic, R - running # NAME TYPE RX-RATE TX-RATE MTU 0 R lan ether 0 0 1500 1 R nonused ether 0 0 1500 2 R newcablemodem ether 0 0 1500

Then do:
/interface print oid

That output looks like this:

[admin@ButchEvans]接口>打印oid旗帜:X -disabled, D - dynamic, R - running 0 R name=.1.3.6.1.2.1.2.2.1.2.1 mtu=.1.3.6.1.2.1.2.2.1.4.1 mac-address=.1.3.6.1.2.1.2.2.1.6.1 admin-status=.1.3.6.1.2.1.2.2.1.7.1 oper-status=.1.3.6.1.2.1.2.2.1.8.1 bytes-in=.1.3.6.1.2.1.2.2.1.10.1 packets-in=.1.3.6.1.2.1.2.2.1.11.1 discards-in=.1.3.6.1.2.1.2.2.1.13.1 errors-in=.1.3.6.1.2.1.2.2.1.14.1 bytes-out=.1.3.6.1.2.1.2.2.1.16.1 packets-out=.1.3.6.1.2.1.2.2.1.17.1 discards-out=.1.3.6.1.2.1.2.2.1.19.1 errors-out=.1.3.6.1.2.1.2.2.1.20.1 1 R name=.1.3.6.1.2.1.2.2.1.2.2 mtu=.1.3.6.1.2.1.2.2.1.4.2 mac-address=.1.3.6.1.2.1.2.2.1.6.2 admin-status=.1.3.6.1.2.1.2.2.1.7.2 oper-status=.1.3.6.1.2.1.2.2.1.8.2 bytes-in=.1.3.6.1.2.1.2.2.1.10.2 packets-in=.1.3.6.1.2.1.2.2.1.11.2 discards-in=.1.3.6.1.2.1.2.2.1.13.2 errors-in=.1.3.6.1.2.1.2.2.1.14.2 bytes-out=.1.3.6.1.2.1.2.2.1.16.2 packets-out=.1.3.6.1.2.1.2.2.1.17.2 discards-out=.1.3.6.1.2.1.2.2.1.19.2 errors-out=.1.3.6.1.2.1.2.2.1.20.2

Item 0 in both the commands is the same interface, as is item 1 and so on....

nuclearcat · Wed Jan 09, 2008 8:25 am

没有必要去Mikrotik内部。雷竞技网站我可以得到all names of interfaces by walking (it can be done by perl code or even using libnetsnmp, instead forking snmpwalk binary), it is just standart MIB.

IF-MIB::ifDescr.1 = STRING: ether1
IF-MIB::ifDescr.2 = STRING: ether2
IF-MIB::ifDescr.3 = STRING: ether3
IF-MIB::ifDescr.10 = STRING: wlan2
IF-MIB::ifDescr.17 = STRING: vlan2
IF-MIB::ifDescr.19 = STRING: bridge1
IF-MIB::ifDescr.100 = STRING:

And directly i can see hidden before problem:
IF-MIB::ifInDiscards.1 = Counter32: 7
IF-MIB::ifOutDiscards.1 = Counter32: 31786

butche · Wed Jan 09, 2008 8:33 am

没有必要去Mikrotik内部。雷竞技网站我可以得到all names of interfaces by walking (it can be done by perl code or even using libnetsnmp, instead forking snmpwalk binary), it is just standart MIB.

I know...and now with your statements and mine above, everyone sees both possibilities. Thanks for putting this reply back.

IF-MIB::ifDescr.1 = STRING: ether1

And directly i can see hidden before problem:
IF-MIB::ifInDiscards.1 = Counter32: 7
IF-MIB::ifOutDiscards.1 = Counter32: 31786

For those that are not aware of what this represents, this shows that there is packet loss (discards) on ether1 on this router. It is exactly this kind of information that started this thread asking for MT to show this kind of information directly in the WINBOX or CLI.

I know most of you that read this will understand it, I just thought I'd put this explanation out for those that don't understand.

BrianHiggins · Wed May 07, 2008 8:15 pm

It is exactly this kind of information that started this thread asking for MT to show this kind of information directly in the WINBOX or CLI.

any idea when this will be included in the CLI or winbox?

SNMP is a work-around at best when you're trying to troubleshoot a system in the field... at worst it's not always available.

Feature proposal (also community pls say if it is required)

Feature proposal (also community pls say if it is required)

Re: Feature proposal (also community pls say if it is required)

Re: Feature proposal (also community pls say if it is required)

Re: Feature proposal (also community pls say if it is required)

Re: Feature proposal (also community pls say if it is required)

Re: Feature proposal (also community pls say if it is required)

Re: Feature proposal (also community pls say if it is required)

Re: Feature proposal (also community pls say if it is required)

Re: Feature proposal (also community pls say if it is required)

Re: Feature proposal (also community pls say if it is required)

Re: Feature proposal (also community pls say if it is required)

Re: Feature proposal (also community pls say if it is required)

Re: Feature proposal (also community pls say if it is required)

Re: Feature proposal (also community pls say if it is required)

Re: Feature proposal (also community pls say if it is required)

Who is online