SENAO (Engenius) support for dual band products
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
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, 21:15, 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
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 BlueMailhttp://www.bluemail.me/r?b=12874 On 8 May 2018, at 21:15, Serge Caron <scaron@pcevolution.commailto: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.orgmailto:observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Port speeds are often incorrect on small vendor’s implementations. I’m not sure why. These are reported by the device in ifSpeed and ifHighSpeed, and there’s not much we can do if the device is reporting the wrong speeds. You can ask the vendor about this, they should probably fix the ethernet ports. The wireless interfaces are more troublesome, since there’s the “theoretical” maximum of the technology, and the current negotiated speed, which changes frequently. I don’t have much of an opinion on what should be reported here, but you’ll find that many vendors will just report some placeholder.
It seems the data you’re referring to is being polled by some super old and sort of weird legacy code :
includes/polling/wifi.inc.php: $wificlients1 = count(explode("\n",snmp_walk($device, "entCLInfoIndex", "-OUqnv", "SENAO-ENTERPRISE-INDOOR-AP-CB-MIB")));
It seems to be counting the number of entries returned in that table. This is really old contributed stuff, so I’m not sure who added it. I’m not familiar with SENAO stuff, so it’s also not immediately obvious what would be a better way to do it.
Adam.
From: observium observium-bounces@observium.org On Behalf Of Serge Caron Sent: 09 May 2018 13:32 To: Observium observium@observium.org Subject: Re: [Observium] SENAO (Engenius) support for dual band products
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 http://www.bluemail.me/r?b=12874
On 8 May 2018, at 21:15, Serge Caron <scaron@pcevolution.com mailto: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 mailto:observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
This is very old me-code, but it's using the old and totally shitty wifi support stuff.
I no longer have senao APs in production...
Tom
On 5/9/2018 7:12 PM, adama@memetic.org wrote:
Port speeds are often incorrect on small vendor’s implementations. I’m not sure why. These are reported by the device in ifSpeed and ifHighSpeed, and there’s not much we can do if the device is reporting the wrong speeds. You can ask the vendor about this, they should probably fix the ethernet ports. The wireless interfaces are more troublesome, since there’s the “theoretical” maximum of the technology, and the current negotiated speed, which changes frequently. I don’t have much of an opinion on what should be reported here, but you’ll find that many vendors will just report some placeholder.
It seems the data you’re referring to is being polled by some super old and sort of weird legacy code :
includes/polling/wifi.inc.php: $wificlients1 = count(explode("\n",snmp_walk($device, "entCLInfoIndex", "-OUqnv", "SENAO-ENTERPRISE-INDOOR-AP-CB-MIB")));
It seems to be counting the number of entries returned in that table. This is really old contributed stuff, so I’m not sure who added it. I’m not familiar with SENAO stuff, so it’s also not immediately obvious what would be a better way to do it.
Adam.
*From:*observium observium-bounces@observium.org *On Behalf Of *Serge Caron *Sent:* 09 May 2018 13:32 *To:* Observium observium@observium.org *Subject:* Re: [Observium] SENAO (Engenius) support for dual band products
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 http://www.bluemail.me/r?b=12874
On 8 May 2018, at 21:15, Serge Caron <scaron@pcevolution.com mailto: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 mailto:observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
The status of MIBs for Senao/Engenius stuff is very messy. They seem to have per-device modifications to MIBs, and it’s very hard to actually find their MIBs.
I just spent a couple of hours looking into it, and now I don’t ever want to deal with them again.
The pattern of WiFi vendors producing near useless SNMP implementations seemingly never ends.
Adam.
From: observium observium-bounces@observium.org On Behalf Of Tom Laermans Sent: 09 May 2018 20:04 To: observium@observium.org Subject: Re: [Observium] SENAO (Engenius) support for dual band products
This is very old me-code, but it's using the old and totally shitty wifi support stuff.
I no longer have senao APs in production...
Tom
On 5/9/2018 7:12 PM, adama@memetic.org mailto:adama@memetic.org wrote:
Port speeds are often incorrect on small vendor’s implementations. I’m not sure why. These are reported by the device in ifSpeed and ifHighSpeed, and there’s not much we can do if the device is reporting the wrong speeds. You can ask the vendor about this, they should probably fix the ethernet ports. The wireless interfaces are more troublesome, since there’s the “theoretical” maximum of the technology, and the current negotiated speed, which changes frequently. I don’t have much of an opinion on what should be reported here, but you’ll find that many vendors will just report some placeholder.
It seems the data you’re referring to is being polled by some super old and sort of weird legacy code :
includes/polling/wifi.inc.php: $wificlients1 = count(explode("\n",snmp_walk($device, "entCLInfoIndex", "-OUqnv", "SENAO-ENTERPRISE-INDOOR-AP-CB-MIB")));
It seems to be counting the number of entries returned in that table. This is really old contributed stuff, so I’m not sure who added it. I’m not familiar with SENAO stuff, so it’s also not immediately obvious what would be a better way to do it.
Adam.
From: observium mailto:observium-bounces@observium.org observium-bounces@observium.org On Behalf Of Serge Caron Sent: 09 May 2018 13:32 To: Observium mailto:observium@observium.org observium@observium.org Subject: Re: [Observium] SENAO (Engenius) support for dual band products
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 http://www.bluemail.me/r?b=12874
On 8 May 2018, at 21:15, Serge Caron <scaron@pcevolution.com mailto: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 mailto:observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
_______________________________________________ observium mailing list observium@observium.org mailto:observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Cool! Let’s all move to something else ;-)
De : observium [mailto:observium-bounces@observium.org] De la part de adama@memetic.org Envoyé : 9 mai 2018 15:06 À : 'Observium' Objet : Re: [Observium] SENAO (Engenius) support for dual band products
The status of MIBs for Senao/Engenius stuff is very messy. They seem to have per-device modifications to MIBs, and it’s very hard to actually find their MIBs.
I just spent a couple of hours looking into it, and now I don’t ever want to deal with them again.
The pattern of WiFi vendors producing near useless SNMP implementations seemingly never ends.
Adam.
From: observium <observium-bounces@observium.orgmailto:observium-bounces@observium.org> On Behalf Of Tom Laermans Sent: 09 May 2018 20:04 To: observium@observium.orgmailto:observium@observium.org Subject: Re: [Observium] SENAO (Engenius) support for dual band products
This is very old me-code, but it's using the old and totally shitty wifi support stuff.
I no longer have senao APs in production...
Tom
On 5/9/2018 7:12 PM, adama@memetic.orgmailto:adama@memetic.org wrote: Port speeds are often incorrect on small vendor’s implementations. I’m not sure why. These are reported by the device in ifSpeed and ifHighSpeed, and there’s not much we can do if the device is reporting the wrong speeds. You can ask the vendor about this, they should probably fix the ethernet ports. The wireless interfaces are more troublesome, since there’s the “theoretical” maximum of the technology, and the current negotiated speed, which changes frequently. I don’t have much of an opinion on what should be reported here, but you’ll find that many vendors will just report some placeholder.
It seems the data you’re referring to is being polled by some super old and sort of weird legacy code :
includes/polling/wifi.inc.php: $wificlients1 = count(explode("\n",snmp_walk($device, "entCLInfoIndex", "-OUqnv", "SENAO-ENTERPRISE-INDOOR-AP-CB-MIB")));
It seems to be counting the number of entries returned in that table. This is really old contributed stuff, so I’m not sure who added it. I’m not familiar with SENAO stuff, so it’s also not immediately obvious what would be a better way to do it.
Adam.
From: observium observium-bounces@observium.orgmailto:observium-bounces@observium.org On Behalf Of Serge Caron Sent: 09 May 2018 13:32 To: Observium observium@observium.orgmailto:observium@observium.org Subject: Re: [Observium] SENAO (Engenius) support for dual band products
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 BlueMailhttp://www.bluemail.me/r?b=12874 On 8 May 2018, at 21:15, Serge Caron <scaron@pcevolution.commailto: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.orgmailto:observium@observium.org
http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
_______________________________________________
observium mailing list
observium@observium.orgmailto:observium@observium.org
http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
participants (4)
-
Adam Armstrong -
adama＠memetic.org
-
Serge Caron -
Tom Laermans