SNMPv3发现 [英] SNMPv3 Discovery

查看:232
本文介绍了SNMPv3发现的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我已经使用SNMP v1和2c通过与社区"public"发送广播消息来进行打印机的网络发现,并且效果很好,但是当我使用协议版本3发送广播消息时,出现超时错误.

I have use SNMP v1 and 2c for network discovery of printers by sending broadcast message with community "public" and it works just fine, but when I send broadcast message with version 3 of the protocol I got timeout error.

有人共享SNMPv3设备发现示例吗?

Do somebody share example of SNMPv3 device discovery?

谢谢.

推荐答案

两件事:

1)实际上,未将广播SNMPv1/v2c定义为在协议中起作用.正如您所发现的那样,廉价的实现将简单地响应它看到内核接受端口而不检查地址的任何数据包.但是,您还会发现一些不响应广播数据包的实现.因此,实际上,这首先不是一种可靠的发现"机制. (更不用说,许多供应商终于变得聪明了,并且没有将public作为默认社区名称)

1) Doing a broadcast SNMPv1/v2c is actually not defined to work in the protocol. Cheap implementations will simply respond, as you've found, to any packet it sees that the kernel accepts to the port and not check the address. However, you'll also find some implementations that will not respond to broadcast packets. So that's actually not a surefire discovery mechanism in the first place. (Let alone, many vendors finally got smart and don't have public be the default community name)

2)另一方面,由于在SNMPv3协议中引擎ID发现是如何发生的,因此SNMPv3的工作可能性甚至更低. SNMPv3仍然不会以普通的响应PDU进行响应,因为它应该以REPORT PDU进行响应,说这是我的engineID",因此您必须以该engineID 和正确的USM凭据进行响应.来访问设备.

2) SNMPv3, on the other hand, is even less likely to work because of how engineID discovery happens within the SNMPv3 protocol. SNMPv3 won't respond with a normal response PDU anyway, as it should respond with a REPORT PDU saying "this is my engineID" and you'd have to respond back with that engineID and the proper USM credentials to access the device.

简而言之,SNMPv3是为安全性而设计的,不再有等效的公共"版本.您需要知道如何访问设备,而不能只是猜测".

In short, SNMPv3 was designed for security and there isn't a "public" equivalent any longer. You'd need to know how to access the device and can't just "guess".

这篇关于SNMPv3发现的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆