hmm... I'm not sure I understand your "use case" for snmp giving the mentioned "OID mapping" proposed.
Do you meant to use the snmp functionality to allow snmp managers to access the owfs hierarchy (sensors, properties) - this is what I presumed and as far as I see Paul also. Or you had the idea to "connect to a sensor/device" via snmp and show that in the owfs hiararchy? (this is what I understand from your mapping suggestion) Anyway, I think the snmp v2 is the "right" protocol to use (as you said, it's simpler, no complications with auth etc, and it has support for 64bit values - and it's still "simple" to use - like v1) regarding mapping... as Paul also said, it's necessary to "conform" to the snmp standards to be able to "integrate" owfs in any existing snmp environment - actually, this is true for both "use cases" I asked clarification about - if you want to access some device via snmp or you want something else to access your owfs hierarchy... anyway... some MIBs should be created at the end. Before or during that it will be necessary to map various owfs properties to "numbers" and make this "generic" for all devices - at least for common properties like: Let's assume the OID for owfs is 1.3.6.1.4.868.2.4.1.2.1.1.1.3.3536 then for example .0 - devices .1 - interface .2 - buses .3 - uncached .4 - settings .5 - alarm ... then for example an DS2409 would have .0.0 - let's say it's only one sensor on bus, it gets "dir entry 0" .0.0.0 - address .0.0.1 - crc .0.0.2 - family .0.0.3 - id .0.0.4 - locator .0.0.5 - etc (standard properties) .0.0.231 - branch.byte .0.0.232 - branch.all .0.0.233 - clear event .0.0.234 - event.all .0.0.238 - sensed.byte etc (specific for this sensor/chip) .2.0.0 - devices .2.0.1 - interface .2.0.3 - uncached .2.0.4 - settings so the MIBs could define something similar... to be more "human readable" otherwise the snmp is rather "human un-friendly" hmm.... I think I'm getting "too smart" so it it better to stop spamming the list with this "escaped thoughts"... regards, m.culibrk On 01/20/2011 12:39 AM, Roberto Spadim wrote: > lets use a human(snmp) readable like aliases > (http://owfs.org/index.php?page=aliases) > but using the limitation... > NOT > > 12.0AB668000000/PIO.B = office > > > 12.0AB668000000/PIO.B = 1.3.6.1.4.868.2.4.1.2.1.1.1.3.3536.3 > > > > 2011/1/19 Mauricio Culibrk<[email protected]>: >> Hi! >> >> well... to "conform" with the snmp "standards/philosophy" the entire >> owfs hierarchy should be placed in a "separate" OIB/OID... >> >> http://www.paessler.com/support/kb/questions/49 >> >> Here is a sample structure of an OID: >> >> Iso >> (1).org(3).dod(6).internet(1).private(4).transition(868).products(2).chassis(4).card(1).slotCps(2) >> . >> cpsSlotSummary(1).cpsModuleTable(1).cpsModuleEntry(1).cpsModuleModel(3).3562.3 >> >> or >> >> 1.3.6.1.4.868.2.4.1.2.1.1.1.3.3536.3 >> >> As far as I remember, there are some "reserved for internal use" OIBs >> otherwise it would make more sense to register an OIB for owfs usage - >> as far as I recall it's easy and free - I did that some 5 years ago for >> my company - in this way owfs could get a reserved and unique >> identification... >> >> After that, it's all up to owfs - regarding hierarchy... the only >> "problem" is that all the "keys" should be numeric and max 32 bit (if I >> recall correctly) - at least for snmp v1 - this could cause some issues >> on how to "map" device ids to OIDs... >> >> And.. if adding snmp support I think the right way would be to add a >> snmp agent to existing snmp daemons (like ownet, owphp...) instead of >> making a snmp daemon directly. >> >> regards, >> m.culibrk >> >> >> On 01/19/2011 02:45 AM, Roberto Spadim wrote: >>> i will read more >>> but it shouldn't follow any snmp hierarchy >>> it's owfs hierarchy >>> but using snmp for "get"/"set" and "walk" (list) values >>> >>> 2011/1/18 Paul Alfille<[email protected]>: >>>> Any idea where in the snmp hierarchy 1-wire devices should be placed? >>>> >>>> On Tue, Jan 18, 2011 at 6:10 PM, Roberto Spadim<[email protected]> >>>> wrote: >>>>> hi i read about implement snmp on owfs... >>>>> maybe snmp v1 is very easy to implement >>>>> check >>>>> http://tools.ietf.org/html/rfc3584 >>>>> >>>>> 1.1. SNMPv1 >>>>> >>>>> >>>>> SNMPv1 is defined by these documents: >>>>> >>>>> - STD 15, RFC 1157 [RFC1157] which defines the Simple Network >>>>> Management Protocol (SNMPv1), the protocol used for network access >>>>> to managed objects. >>>>> >>>>> - STD 16, RFC 1155 [RFC1155] which defines the Structure of >>>>> Management Information (SMIv1), the mechanisms used for describing >>>>> and naming objects for the purpose of management. >>>>> >>>>> - STD 16, RFC 1212 [RFC1212] which defines a more concise >>>>> description mechanism, which is wholly consistent with the SMIv1. >>>>> >>>>> - RFC 1215 [RFC1215] which defines a convention for defining Traps >>>>> for use with the SMIv1. >>>>> >>>>> Note that throughout this document, the term 'SMIv1' is used. This >>>>> term generally refers to the information presented in RFC 1155, RFC >>>>> 1212, and RFC 1215. >>>>> >>>>> >>>>> v2, v3 is more complex protocol, v1 is very "easy" to implement >>>>> >>>>> -- >>>>> Roberto Spadim >>>>> Spadim Technology / SPAEmpresarial >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Protect Your Site and Customers from Malware Attacks >>>>> Learn about various malware tactics and how to avoid them. Understand >>>>> malware threats, the impact they can have on your business, and how you >>>>> can protect your company and customers by using code signing. >>>>> http://p.sf.net/sfu/oracle-sfdevnl >>>>> _______________________________________________ >>>>> Owfs-developers mailing list >>>>> [email protected] >>>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers >>>>> >>>> ------------------------------------------------------------------------------ >>>> Protect Your Site and Customers from Malware Attacks >>>> Learn about various malware tactics and how to avoid them. Understand >>>> malware threats, the impact they can have on your business, and how you >>>> can protect your company and customers by using code signing. >>>> http://p.sf.net/sfu/oracle-sfdevnl >>>> _______________________________________________ >>>> Owfs-developers mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers >>>> >>>> >>> >> ------------------------------------------------------------------------------ >> Protect Your Site and Customers from Malware Attacks >> Learn about various malware tactics and how to avoid them. Understand >> malware threats, the impact they can have on your business, and how you >> can protect your company and customers by using code signing. >> http://p.sf.net/sfu/oracle-sfdevnl >> _______________________________________________ >> Owfs-developers mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/owfs-developers >> >> > > ------------------------------------------------------------------------------ Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Owfs-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/owfs-developers
