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)
+1 
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
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
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.
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.
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… 
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
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:
Inter-| Receive | Transmit
face |bytes packets errs 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?
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.
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 
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] 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
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…
There is no need to go inside Mikrotik. I can get 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
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.
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.