Thanks for taking the time and effort to confirm that. Odds are in our favor they will add that back in then 
I hope for a quick fix as I had mentioned the wrong oid months ago on http://forum.mikrotik.com/t/found-capsman-snmp-mac-table/97430/1
Till then still they have wrong output on oid on console that snmp-walk. And now they broke it. Shall we will wait months to get back the previous functionality and get matched oid? Hoping for the best…
Is the RSTP problem (which I reported here http://forum.mikrotik.com/viewtopic.php?f=21&t=116951&start=50#p582781 ) fixed?
noticed that last RC’s of 639 both upgrade and Boot-Up MUCH faster than before.
not big deal, but not bad thing either.
Hello,
If you can fix in an upcoming RC - in the TR-069 data model, the MAC address for Ethernet interfaces seems to be missing. I can still see the MAC addresses for the wireless interfaces, but they are gone for the Ethernet interfaces. I have many other stats, ex. byte counts for all ethernet interfaces, but no MAC addresses. This looks like a strange oversight. It is useful for us to collect the MAC address of our managed devices, particularly the ether1 interface, so I would really like to have this data.
OIDs for CAPsMAN will be fixed in next rc release. MAC-Address parameter is removed since it was already available and this was a duplicate entry,
Hi everyone
I have 10g ports on my router and graphs look like this:
I am using version: 6.38.1
3G everything looks good, after exceeding this value, it begins to fall apart.
What could be the reason?
I will add that any problems with the link no The cacti looks normal.
ps: I apologize in advance for my English 
Looks like a 32 vs 64 bit counter rollover problem. Lots of info if you do a Google search on that. Here is one example:
https://www.google.com/amp/s/gorthx.wordpress.com/2012/04/20/this-is-what-counter-rollover-looks-like/amp/
Where else is it included that we aren’t finding (I say we because others are posting about this being gone too, so it’s not just me missing it)?
Thank you!
Thank you very much for your answer. I understand the question of whether and when the dude will support 64bit?
Where is it available? I do not see the MAC address anywhere in TR-069 data returned from device, except for the MAC addresses for the WiFi interfaces. What I want is the ethernet interface MAC addresses, primarily ether1 so that I can see what MAC address the customer has on their WAN port. I have gone through the entire TR-069 data returned from my device and from what I can see this is not present.
I think that is a reply regarding snmp, not tr-069
Ahh, thanks - I didn’t realize there was another post about MAC addresses with SNMP in the thread that strods was probably replying to.
In the same boat as well. I updated to the latest 6.39rc33 for the virtual static ap for capsmam feature, which works great! But it broke the snmp capsman registration table Mac address oid. Hopefully it can be fixed soon.
So based on some of my own digging, I found that the entries for capsman can be looked up in the bridge mib.
As an example, this client:
1.3.6.1.4.1.14988.1.1.1.5.1.[3-12].0.14.88.171.21.21.14
has a mac address here:
1.3.6.1.2.1.17.4.3.1.1.0.14.88.171.21.21 = Hex-STRING: 00 02 B3 AB C1 DE
Based on the conversation in my ticket so far, it seems as if they expect us to use that. I’m waiting on confirmation.
Thanks for the info. It looks like the mac entries are a lookup table. To see if a client is disconnected or connected, would have to check the client by the snmp id addresses and not the macs. Not super useful for my application as I used the snmp macs in the capsman registration table to determine if people are home or not for some home automation. Ideally they can bring this back. However I did some more digging and found macs (wired and wireless) are also listed in the ‘ipNetToMediaPhysAddress’ with the OID prefix of: 1.3.6.1.2.1.4.22.1.2.9. This so far seems to working for my application.
This is an example about SNMP CAPsMAN registration table.
We run SNMPwalk to device. As a result we get different OIDs. For example:
iso.3.6.1.4.1.14988.1.1.1.5.1.12..587
In this case:
iso.3.6.1.4.1.14988.1.1.1.5.1.12 - CAPsMAN registration table specific entry;
xx.xx.xx.xx.xx.xx - MAC address in decimal system
587 - specific ID to avoid duplicates
I see now, so what you mean is the mac address is part of the OID, just in decimal form instead of hexadecimal.
for example, mac address 00:DB:9A:B0:E4:72 would be converted to 0.219.154.176.228.114 and it’s stats would then be iso.3.6.1.4.1.14988.1.1.1.5.1.12.0.219.154.176.228.114.1
or, mac address DB:DB:DB:DB:DB:DB would become 219.219.219.219.219.219
While I can see this works, it does seem to be easier to have a Hex-String or String conversion automatically done for us in an additional OID. Since the code was there already and it makes things easier on folks, why not just leave it (put it back)?
Thanks for the example and help Strods. I understand it now however I agree with Alex that it’s much easier to have the strings even though it is somewhat redundant. Much appreciated if it can be placed back in!