proxy forwarder: Forwarding SNMPv3 request to SNMPv2c broken

Hi,
Forwarding an SNMPv3 request to an SNMPv2c proxy is broken. The debug shows the following (last line is the important one):

20250207.06:10:07: 127390219945536: (1)DEBUG  : snmp_engine called with UTarget
20250207.06:10:07: 127390219945536: (4)DEBUG  : SNMPMessage: return value for build message: (0)
20250207.06:10:07: 127390219945536: (1)DEBUG  : ++ SNMP++: sending to 127.0.0.1/10162:   
20250207.06:10:07: 127390219945536: (3)DEBUG  : 30 28 02 01  01 04 07 70  72 69 76 61  74 65 A0 1A  
20250207.06:10:07: 127390219945536: (3)DEBUG  : 02 02 6F 22  02 01 00 02  01 00 30 0E  30 0C 06 08  
20250207.06:10:07: 127390219945536: (3)DEBUG  : 2B 06 01 02  01 01 01 00  05 00       
20250207.06:10:07: 127390219945536: (1)DEBUG  : ++ SNMP++: something received...                    
20250207.06:10:07: 127390219945536: (1)DEBUG  : Length received 76 from socket 4; fromlen 16        
20250207.06:10:07: 127390219945536: (1)DEBUG  : ++ SNMP++: data received from 127.0.0.1/10162.      
20250207.06:10:07: 127390219945536: (3)DEBUG  : 30 4A 02 01  01 04 07 70  72 69 76 61  74 65 A2 3C  
20250207.06:10:07: 127390219945536: (3)DEBUG  : 02 02 6F 22  02 01 00 02  01 00 30 30  30 2E 06 08  
20250207.06:10:07: 127390219945536: (3)DEBUG  : 2B 06 01 02  01 01 01 00  04 22 41 47  45 4E 54 2B  
20250207.06:10:07: 127390219945536: (3)DEBUG  : 2B 76 34 2E  37 2E 31 20  50 72 6F 78  79 20 28 73  
20250207.06:10:07: 127390219945536: (3)DEBUG  : 6C 6F 74 20  31 29 20 61  67 65 6E 74           
20250207.06:10:07: 127390219945536: (1)DEBUG  : receive_snmp_response requestID = 28450, returning SUCCESS.                                                     
20250207.06:10:07: 127390219945536: (1)INFO   : MsgQueue: Ignore response that does not match message id: (id1) (type2) (msgid1) (msgid2: (28450), (28450), (414921791), (0)

It looks like this issue was introduced in snmp++ v3.5.0, which added this bit of code (starting at ‘#ifdef _SNMPv3’):

int CSNMPMessage::SetPdu(const int reason, const Pdu &pdu,
                         const UdpAddress & /* fromaddress */)
{
#ifdef _SNMPv3
  if (m_pdu.get_message_id() != pdu.get_message_id())
  {
    LOG_BEGIN(loggerModuleName, INFO_LOG | 1);
    LOG("MsgQueue: Ignore response that does not match message id: (id1) (type2) (msgid1) (msgid2");
    LOG(m_pdu.get_request_id());
    LOG(pdu.get_request_id());
    LOG(m_pdu.get_message_id());
    LOG(pdu.get_message_id());
    LOG_END;
    return -1;
  }
#endif

I think the issue is that it checks if the msgID matches, but because the SNMPv2c response from the proxy doesn’t contain a msgID, it’s set to 0 and the check fails.
I guess one possible fix would be to compare the requestID’s instead, but not sure if there would be security implication with regards to SNMPv3. Also if I am not mistaken the msgID gets incremented for each retry, whereas the requestID is not, so it wouldn’t be exactly the same behaviour.

This was tested with the latest release:
agent++ v4.7.1
snmp++ v3.6.2

Best Regards,

Holger

Hi,

a check with the request id is not needed, as this check is only needed if the message was sent/received using SNMPv3. So the check should be:

  if ((m_target->get_version() == version3) &&
      (m_pdu.get_message_id() != pdu.get_message_id()))

But as this is caused by application code (agent++), I also think about resetting the message id of the Pdu in Snmp class e.g. in Snmp::get_next().

Thanks for reporting this and best regards,
Jochen

Thank you, I can confirm the patch fixes the issue.

Best regards,

Holger