ucd-snmp is very old (3.6.2) and there is no space in flash for newer version.

At this moment there were much important problems, so we unable to find time to
prepare backports from ucd-snmp mainstream.

Anyway, if someone prepare patch against ucd-snmp 3.6.2, we will apply it.

btw., which SNMP client you are use?

I know it's a low priority one, maybe some time when there's nothing left to do 
:p

I tried the good old look@lan utility (works for windows xp only)
and this one here: http://www.nsauditor.com/network_tools/snmp_mib_browser.html

in the second one the values are like this:
Variable = interfaces.ifTable.ifEntry.ifSpeed.3
Value  = 10000000
Variable = interfaces.ifTable.ifEntry.ifSpeed.4
Value  = 10000000
Variable = interfaces.ifTable.ifEntry.ifSpeed.5
Value  = 10000000

all 10Mbits/s

Try to use net-snmp_5.4.2.1 from optware
(http://ipkg.nslu2-linux.org/feeds/optware/oleg/cross/stable/), it should parse
interface speed correctly.

Seems to be it is a bug in ucd-snmp up to 4.2.3 -
http://sourceforge.net/tracker/index.php?func=detail&aid=657808&group_id=12694&a
tid=312694

Can you build firmware yourself?

P.S. You didn't report your router model

Yes, I'm WPtE from the wl500g forums
and I can still build firmware ;-)

oh router model is wl-500w (I looked over that part)

The rest is question - speed of which port on ethernet bridge should ucd-snmp 
return?
WAN? LANx?

P.S. As I can understand - ucd-snmp(net-snmp) don't support managing of 
ethernet bridges

I guess the WAN speed? probably the most obvious

Or the slowest speed, but that's extra work I guess :)

To do something like in Comment 10, ucd-snmp must recognize our ethernet 
bridge, but
it doesn't. Moreover, for detection of remapped (or second) WAN port it should 
access
nvram.

Realization of such logic are too big for built-in ucd-snmp, so I can hardcode 
only
one port (phy_id). Is this solution are acceptable at all, or better to leave
situation "as is"?

AH! I get it
In that case: when you hardcode it, will it have real statistics like how many 
bytes 
are send or received? otherwise it would be nonsense to hardcode it I think.

RX/TX bytes it is a per interface (ethX, vlanX) metric, it hasn't direct 
relation to
parameters of dedicated physical port.

May be I misunderstand you, since I'm not familiar with SNMPv2 RFC's. To get phy
speed, daemon should issue MII query to the interface (ETHTOOL available in 2.6
kernels) and provide physical port number. For standalone ethernet NIC, it 
always
zero, but our switch has several ports.

I think you understand me, but I'm a bit lost in what you're trying to tell.
Because ETHTOOL is not available on the 2.4 kernel you can't see every port on 
the 
switch (the bridge you're talking about?) the question is which port to take 
for the 
maximum link speed (10/100/100).
As far as I know the WAN is reported back as eth1 usually, and the entire 
switch 
(lan) is also one device.
So you can only query the first port of the LAN for speed in kernel 2.4... 
isn't it 
then the easiest to take port 0?
Or am I completely confused now? :)

I'll try to simplify explanation. ;-)

snmp daemon don't know anything about ethernet switches at all. So, when you 
ask to
show speed of interface eth0, it assumes that we have return media speed of 
portX.
Because snmp also don't know WAN/LAN mappings, flexible & fast solution is 
absent.

Thus, my question is - is solution which returns speed of port 0 (WAN, by 
default)
are acceptable or not?

Complete solution (i.e. full support of bridges) can be done by authors of 
net-snmp only.

No, eth1 is WLAN. WAN/LAN is vlanX but it don't accept media speed queries.

We're on one line now :p
Yes that would be very acceptable!
The complete solution is not something oleg firmware should worry about, as 
you're 
saying it's up to the authors of net-snmp to implement that.

eth1 has the ip of my wan interface actually :p
in fact I don't have any vlan ports according to ifconfig.
Perhaps because I use auto dhcp as internet connection instead of PPPoE

Ok, I apologize that it is possible to backport patch from Comment 5

Task was easier than I expected, check r1042

NB! gigabit logic is incomplete

good job lly :)
I'll test it soon

Just tested it and here are the results :)
Lo = 100mbit
sit0 = 0mbit
eth0 = 0mbit
eth1 = 100mbit
eth2 = 10mbit
br0 = 0mbit
sixtun = 0mbit
tun0 = 0mbit

the WAN on my router (eth1) shows the correct speed now :)
dunno if other devices should have shown their speed or different speeds?

> dunno if other devices should have shown their speed or different speeds?
It is too complex task, so I leave it to net-snmp maintainers ;-)

I'm glad eth1 is showing it's real speed so thanks lly :D
Now I mrtg works properly ;-)