I have tried to run the mtapi.py script from wiki. I’m trying now to run the command to print OIDs
...
>>>
/interface/wireless/print
=oid=
...
This works fine on pre 3.22 firmwares and does not work in fw 3.22. In 3.22 this prints only the same output like when the command is only “/interface/wireless/print”. Why? What has changed in new firmware? Searching in ChangeLog did not help and here also. The ChangeLog indicates something might changed in API.
Thanks
this will be fixed in future releases, stay tuned.
According to ChangeLog, something should be changed, but nothing has changed according to me. Now I have also differences between 3.10 and 3.22-3.23:
fw 3.23:
[admin@myname] > interface wireless print
Flags: X - disabled, R - running
0 R name="myname" mtu=1500 mac-address=xx:xx:xx:xx:xx:xx arp=enabled
interface-type=Atheros AR5413 mode=ap-bridge ssid="essid" frequency=2412 band=2.4ghz-b/g
scan-list=default antenna-mode=ant-a wds-mode=disabled wds-default-bridge=none
wds-ignore-ssid=no default-authentication=yes default-forwarding=yes default-ap-tx-limit=0
default-client-tx-limit=0 hide-ssid=yes security-profile=default compression=no
1 R name="wlan1-vsesmerovka" mtu=1500 mac-address=xx:xx:xx:xx:xx:xx arp=enabled
interface-type=Atheros AR5413 mode=ap-bridge ssid="essid" frequency=2447 band=2.4ghz-b/g
scan-list=default antenna-mode=ant-a wds-mode=disabled wds-default-bridge=none
wds-ignore-ssid=no default-authentication=yes default-forwarding=yes default-ap-tx-limit=0
default-client-tx-limit=0 hide-ssid=yes security-profile=default compression=no
[admin@myname] > interface wireless print oid
0 tx-rate=.1.3.6.1.4.1.14988.1.1.1.1.1.2.7 rx-rate=.1.3.6.1.4.1.14988.1.1.1.1.1.3.7
strength=.1.3.6.1.4.1.14988.1.1.1.1.1.4.7 ssid=.1.3.6.1.4.1.14988.1.1.1.1.1.5.7
bssid=.1.3.6.1.4.1.14988.1.1.1.1.1.6.7 frequency=.1.3.6.1.4.1.14988.1.1.1.1.1.7.7
band=.1.3.6.1.4.1.14988.1.1.1.1.1.8.7
1 tx-rate=.1.3.6.1.4.1.14988.1.1.1.1.1.2.9 rx-rate=.1.3.6.1.4.1.14988.1.1.1.1.1.3.9
strength=.1.3.6.1.4.1.14988.1.1.1.1.1.4.9 ssid=.1.3.6.1.4.1.14988.1.1.1.1.1.5.9
bssid=.1.3.6.1.4.1.14988.1.1.1.1.1.6.9 frequency=.1.3.6.1.4.1.14988.1.1.1.1.1.7.9
band=.1.3.6.1.4.1.14988.1.1.1.1.1.8.9
and here is output from mtapi.py from the API example at the web (the radio has 3.23 fw):
...
<<< /interface/wireless/print
<<< =oid=
<<<
>>> !re
>>> =.id=*7
>>> =comment=
>>> =name=myname
>>> =mtu=1500
>>> =mac-address=xx:xx:xx:xx:xx:xx
>>> =arp=enabled
>>> =disable-running-check=false
>>> =interface-type=Atheros AR5413
>>> =radio-name=myname
>>> =mode=ap-bridge
...
Why is there “=.id=*7”??? There should be IMHO “=.id=*0” or “=.id=*1”, but no “7”!! Or this is a feature?
On fw 3.10 commands “interface wireless print” and “interface wireless print oid” work normally as expected. And see the different output from API of 3.10:
...
<<< /interface/wireless/print
<<< =oid=
<<<
>>> !re
>>> =.id=*4
>>> =comment=
>>> =tx-rate=.1.3.6.1.4.1.14988.1.1.1.1.1.2.4
>>> =rx-rate=.1.3.6.1.4.1.14988.1.1.1.1.1.3.4
>>> =strength=.1.3.6.1.4.1.14988.1.1.1.1.1.4.4
>>> =ssid=.1.3.6.1.4.1.14988.1.1.1.1.1.5.4
>>> =bssid=.1.3.6.1.4.1.14988.1.1.1.1.1.6.4
>>> =frequency=.1.3.6.1.4.1.14988.1.1.1.1.1.7.4
>>>
>>> !done
>>>
In my script I really need this output to know, that interface on index “=.id=*0” has frequency OID = .x.x.x.x.x.5 for example.
Or give me please a hint how can I get OID interface index for certain Mikrotik’s interface ID in other way, than SNMP.
Thank you
use snmp tool like snmp-walk to get oids of items. we are still looking into the problem
Can you please give me an example of the MIB using Mikrotik’s iface ID?
snmpget -v1 -c public 192.168.3.50 x.x.x.x.x
I am using version 3.22, so this might have been covered previously. When I do “/interface/wireless/print oid” I get the following:
0 tx-rate=.1.3.6.1.4.1.14988.1.1.1.1.1.2.4 rx-rate=.1.3.6.1.4.1.14988.1.1.1.1.1.3.4
strength=.1.3.6.1.4.1.14988.1.1.1.1.1.4.4 ssid=.1.3.6.1.4.1.14988.1.1.1.1.1.5.4
bssid=.1.3.6.1.4.1.14988.1.1.1.1.1.6.4 frequency=.1.3.6.1.4.1.14988.1.1.1.1.1.7.4
However when I do the command “snmpwalk -v 1 -c public 1.3.6.1.4.1.14988” I get the following:
SNMPv2-SMI::enterprises.14988.1.1.1.2.2.0 = Gauge32: 0
SNMPv2-SMI::enterprises.14988.1.1.1.3.1.2.4 = Gauge32: 0
SNMPv2-SMI::enterprises.14988.1.1.1.3.1.3.4 = Gauge32: 0
SNMPv2-SMI::enterprises.14988.1.1.1.3.1.4.4 = STRING: “LCWNetLamyTest”
SNMPv2-SMI::enterprises.14988.1.1.1.3.1.5.4 = “”
SNMPv2-SMI::enterprises.14988.1.1.1.3.1.6.4 = Counter32: 0
SNMPv2-SMI::enterprises.14988.1.1.3.8.0 = INTEGER: 236
SNMPv2-SMI::enterprises.14988.1.1.4.1.0 = STRING: “02LQ-3TT”
SNMPv2-SMI::enterprises.14988.1.1.4.2.0 = Hex-STRING: 07 B2 01 01 00 01 07 00
SNMPv2-SMI::enterprises.14988.1.1.4.3.0 = INTEGER: 5
SNMPv2-SMI::enterprises.14988.1.1.4.4.0 = STRING: “3.22”
SNMPv2-SMI::enterprises.14988.1.1.4.5.0 = INTEGER: 4
SNMPv2-SMI::enterprises.14988.1.1.6.1.0 = Gauge32: 0
SNMPv2-SMI::enterprises.14988.1.1.7.1.0 = INTEGER: 0
The OIDs that RouterOS says should be there for the wireless interface don’t seem to be there.
Does that makes sense? Is this a bug or feature? Is it changed in 3.23 or later?
I just upgraded to 3.24 and it does exactly the same thing…
do “/interface/wireless/print” and “/interface/wireless/print oid” and post here
“interface wireless print” and “interface wireless print oid” print the results as expected in 3.21, 3.22, 3.23 and 3.24.
The problem is when you type these commands as API commands - they both print the same output in 3.22+, that bad. In 3.21 this works - the output is quite different.
Here is what you requested:
/interface wireless print
Flags: X - disabled, R - running
0 R name=“wlan1” mtu=1500 mac-address=00:0C:42:26:3A:4D arp=enabled interface-type=Atheros AR5413 mode=ap-bridge
ssid=“LCWNetLamyTest” frequency=2422 band=2.4ghz-b scan-list=default antenna-mode=ant-b wds-mode=disabled
wds-default-bridge=none wds-ignore-ssid=no default-authentication=no default-forwarding=yes
default-ap-tx-limit=0 default-client-tx-limit=0 hide-ssid=no security-profile=default compression=no
/interface wireless print oid
0 tx-rate=.1.3.6.1.4.1.14988.1.1.1.1.1.2.4 rx-rate=.1.3.6.1.4.1.14988.1.1.1.1.1.3.4
strength=.1.3.6.1.4.1.14988.1.1.1.1.1.4.4 ssid=.1.3.6.1.4.1.14988.1.1.1.1.1.5.4
bssid=.1.3.6.1.4.1.14988.1.1.1.1.1.6.4 frequency=.1.3.6.1.4.1.14988.1.1.1.1.1.7.4
band=.1.3.6.1.4.1.14988.1.1.1.1.1.8.4
However when I do an snmpwalk I get this:
snmpwalk -v 1 -c public 10.181.1.10 1.3.6.1.4.1.14988
SNMPv2-SMI::enterprises.14988.1.1.1.2.2.0 = Gauge32: 0
SNMPv2-SMI::enterprises.14988.1.1.1.3.1.2.4 = Gauge32: 0
SNMPv2-SMI::enterprises.14988.1.1.1.3.1.3.4 = Gauge32: 0
SNMPv2-SMI::enterprises.14988.1.1.1.3.1.4.4 = STRING: “LCWNetLamyTest”
SNMPv2-SMI::enterprises.14988.1.1.1.3.1.5.4 = “”
SNMPv2-SMI::enterprises.14988.1.1.1.3.1.6.4 = Counter32: 0
SNMPv2-SMI::enterprises.14988.1.1.1.3.1.8.4 = Counter32: 0
SNMPv2-SMI::enterprises.14988.1.1.3.8.0 = INTEGER: 237
SNMPv2-SMI::enterprises.14988.1.1.3.9.0 = STRING: “none”
SNMPv2-SMI::enterprises.14988.1.1.4.1.0 = STRING: “02LQ-3TT”
SNMPv2-SMI::enterprises.14988.1.1.4.2.0 = Hex-STRING: 07 B2 01 01 00 01 07 00
SNMPv2-SMI::enterprises.14988.1.1.4.3.0 = INTEGER: 5
SNMPv2-SMI::enterprises.14988.1.1.4.4.0 = STRING: “3.24”
SNMPv2-SMI::enterprises.14988.1.1.4.5.0 = INTEGER: 4
SNMPv2-SMI::enterprises.14988.1.1.6.1.0 = Gauge32: 0
SNMPv2-SMI::enterprises.14988.1.1.7.1.0 = INTEGER: 0
End of MIB
What I was expecting were the OIDs I saw when I did the /interface wireless print oid
Is that enough information to figure out what is going on?
hmmm… it seems like interface oids are absent in snmpwalk. just use the values you get during ‘/print oid’ directly
I seem to have fixed the problem, but I don’t understand why what I did had the effect it did.
We are evaluating a couple of MikroTik routers for use as replacements in our community WISP. All we need is a box that will connect 20 to 30 802.11b clients and pass the traffic into our back haul which is entirely made up of 5Ghz Tranzeo radios. The APs have static IP addresses and use MAC filtering to determine who gets into the system. We have some of our own software which monitors the system using SNMP.
The anomaly I saw went away when I reassigned the default IP address of the first ethernet port to the static address which it would have if we put the box into our system. Prior to that I had just added the static IP address to the interface leaving the default 192.168.x.x address.
Anyway, our software is now properly monitoring the box and I’m ready to put it into service on a test basis.
BTW, one odd thing that I’ve found is that the frequency assigned to the wireless interface seems to change from time to time. I guess that it could be that the radio is being queried at some point when it’s in the process of scanning other frequencies, but it seems odd. Once the radio is in service I will be watching that more closely.