Hello Adam,
Thank you for your answer.
I don’t think things are as bleak as it looks. Below is an “inventory” of an ECB1750 access point serving 6 VLANS over two bands (2.4/5 GHz): observium is picking up all ports even if this device
does way more than the old Engenius “hockey puck”.
As you point out, data needs to be interpreted correctly. In the case of dual band units, there will be two fields for wireless clients (one for each band) and all observium outputs/graphs needs
to be adjusted accordingly. I overlooked this reality before asking my question.
In the case of this ECB1750 device, all ports are reported as “Ethernet 10 Mbps” even though the wired port is connected at 1 Gbps in the switch and each radio is “capable” (the quotes are from me
as emphasis on shameless marketing) of 450 Mbps on the 2.4 GHz band and (OMG!) 1.2 Gbps on the 5 GHz band. It is these things that look “broken” in observium.
In essence, I am getting most of the stats I need as things are.
Regards,
Serge Caron
Inventory of sample ECB1750 device:
|
# |
Description |
Type |
Status |
Errors |
Load |
|
768 |
Processor |
hrDeviceProcessor |
running |
0 |
12 |
|
1025 |
lo |
hrDeviceNetwork |
running |
0 |
|
|
1026 |
ifb0 |
hrDeviceNetwork |
down |
0 |
|
|
1027 |
ifb1 |
hrDeviceNetwork |
down |
0 |
|
|
1028 |
eth0 |
hrDeviceNetwork |
running |
0 |
|
|
1031 |
br-1 |
hrDeviceNetwork |
running |
0 |
|
|
1032 |
eth0.401 |
hrDeviceNetwork |
running |
0 |
|
|
1033 |
br-2 |
hrDeviceNetwork |
running |
0 |
|
|
1034 |
eth0.402 |
hrDeviceNetwork |
running |
0 |
|
|
1035 |
br-3 |
hrDeviceNetwork |
running |
0 |
|
|
1036 |
eth0.403 |
hrDeviceNetwork |
running |
0 |
|
|
1037 |
br-4 |
hrDeviceNetwork |
running |
0 |
|
|
1038 |
eth0.404 |
hrDeviceNetwork |
running |
0 |
|
|
1039 |
br-5 |
hrDeviceNetwork |
running |
0 |
|
|
1040 |
eth0.600 |
hrDeviceNetwork |
running |
0 |
|
|
1041 |
br-99 |
hrDeviceNetwork |
running |
0 |
|
|
1042 |
br-lan |
hrDeviceNetwork |
running |
0 |
|
|
1043 |
eth0.172 |
hrDeviceNetwork |
running |
0 |
|
|
1044 |
wifi0 |
hrDeviceNetwork |
running |
85513 |
|
|
1045 |
wifi1 |
hrDeviceNetwork |
running |
0 |
|
|
1046 |
ath1 |
hrDeviceNetwork |
running |
0 |
|
|
1047 |
ath11 |
hrDeviceNetwork |
running |
0 |
|
|
1048 |
ath12 |
hrDeviceNetwork |
running |
0 |
|
|
1049 |
ath13 |
hrDeviceNetwork |
running |
0 |
|
|
1050 |
ath14 |
hrDeviceNetwork |
running |
0 |
|
|
1051 |
ath15 |
hrDeviceNetwork |
running |
0 |
|
|
1052 |
ath0 |
hrDeviceNetwork |
running |
1956 |
|
|
1053 |
ath01 |
hrDeviceNetwork |
running |
0 |
|
|
1054 |
ath02 |
hrDeviceNetwork |
running |
0 |
|
|
1055 |
ath03 |
hrDeviceNetwork |
running |
0 |
|
|
1056 |
ath04 |
hrDeviceNetwork |
running |
0 |
|
|
1057 |
ath05 |
hrDeviceNetwork |
running |
1684 |
|
De : observium [mailto:observium-bounces@observium.org]
De la part de Adam Armstrong
Envoyé : 8 mai 2018 17:25
À : 'Observium'
Cc : 'Observium'
Objet : Re: [Observium] SENAO (Engenius) support for dual band products
MIBs do not affect the data the device reports, they just make it easier to identify and work with the data.
MIBs are like DNS, all they really do is provide a hierarchy, a name<>number translation and sometimes some hints about the format of the
data returned. They're not really useful by themselves in enabling support for new things, like a driver would be. They're rather more like the technical specification used to write the driver.
It's possible they have moved this data to a new location on newer MIBs, or added new OIDs with more useful data. It's strange they'd be returning
erroneous data in old tables though, but tis difficult to say without examples.
Adding support for new things requires writing code and/or definitions for the new data. This isn't a zero-effort thing, and usually occurs
based on greatest demand (or commercial sponsorship).
Mike/Tom: I think we should come up with a generic "new stuff" template form or something, and include the "mibs don't do shit" boilerplate
in the mailing list sign-up process somewhere. I think this would go some way to mitigating these open ended things.
Adam.
Sent from
BlueMail
On 8 May 2018, at 21:15, Serge Caron <scaron@pcevolution.com> wrote:
Greetings!
Quote from Adam : “The archives died during a server move, and the mailing list software is voodoo, so they never came back”.
Apologies for asking something that is probably old news.
The Community Edition ships with Senao (Engenius) MIBs dated 2013.11.25.
This is fine for older devices such as the EAP9550 and we get proper data (such as number of wireless clients).
However, it seems all modern dual band devices such as the (older) EAP600 and the (newer) ECB1750 always report 1 as the number of wireless clients (as well as other broken stats).
Are there updated MIBs compatible to observium for these products?
Regards,
Serge Caron
observium mailing list
observium@observium.org
http://postman.memetic.org/cgi-bin/mailman/listinfo/observium