lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-users] Re: Incorrect RequestID field in SNMP response message


From: Lubomir Toshev
Subject: [lwip-users] Re: Incorrect RequestID field in SNMP response message
Date: Mon, 10 Sep 2007 13:34:52 +0300

Hello,

I applied patch #5896 and it solved the problem with the RequestID
field. Actually this problem would affect any s32_t value.

Thank you for the reply.

I would like to discuss a few more things related to SNMP and private
MIB usage. I applied for enterprise PEN which is to be released soon.
I used private_mib.c (from the contrib/unix project) as a reference
to build my private MIB. I use it to keep read-only measurement result
values and read-write configuration values. I successfully GET values
from the private MIB and I also successfully send enterprise-specific
TRAP messages. I have a slight problem with the SET requests.

I tried to analyze the code in private_mib.c and mib2.c and I made the
following assumptions about SET requests:

1. sensorentry_get_object_def_a(...) will set the fields of the
obj_def struct according to the specific referenced item.
2. sensorentry_set_test_a(...) will return true or false if the
specific item can be changed and if the value is within the expected
limits. No actual value change is done here.
3. sensorentry_set_value_a(...) will execute the actual value change of
the referenced item.

Are the above assumptions correct?
Do I miss anything important?
What is the purpose of the functions which names end with _pc?

What actually happens in my system is that when the
sensorentry_set_test_a(...) function is called the viod* value
argument is valid and points to the number passed by the SET message,
but when the sensorentry_set_value_a(...) function is called the void*
value argument is NULL and no longer points to the number passed by
the SET message.

Please, comment the possible reasons.

-- 
Best regards,
 Lubo




 
Sunday, September 9, 2007, 7:00:08 PM, you wrote:

lurno> Send lwip-users mailing list submissions to
lurno>  address@hidden

lurno> To subscribe or unsubscribe via the World Wide Web, visit
lurno>  http://lists.nongnu.org/mailman/listinfo/lwip-users
lurno> or, via email, send a message with subject or body 'help' to
lurno>  address@hidden

lurno> You can reach the person managing the list at
lurno>  address@hidden

lurno> When replying, please edit your Subject line so it is more specific
lurno> than "Re: Contents of lwip-users digest..."


lurno> Today's Topics:

lurno>    1. Incorrect RequestID field in SNMP response message
lurno>       (Lubomir Toshev)
lurno>    2. Re: Incorrect RequestID field in SNMP response message
lurno>       (Fr?d?ric BERNON)


lurno> ----------------------------------------------------------------------

lurno> Message: 1
lurno> Date: Sun, 9 Sep 2007 10:01:27 +0300
lurno> From: Lubomir Toshev <address@hidden>
lurno> Subject: [lwip-users] Incorrect RequestID field in SNMP response
lurno>  message
lurno> To: address@hidden
lurno> Message-ID: <address@hidden>
lurno> Content-Type: text/plain; charset=us-ascii

lurno> Hello,

lurno> I have ported lwIP 1.2.0 to a proprietary Coldfire system. I do not
lurno> use RTOS and I work with a single thread. I use UDP communication as
lurno> well as the SNMP agent. UDP communication works fine, but I have some
lurno> problems with the SNMP agent.

lurno> I noticed a mismatch between the RequestID fields of the request and
lurno> response messages in an SNMP communication sequence. Some SNMP
lurno> managers (like HostMonitor) succeed to GET values despite this
lurno> mismatch. Others however (like Net-SNMP) will reject the response.

lurno> It seems the RequetID field generated by my system has reversed byte
lurno> order. Other fields of the message are encoded correctly, for example
lurno> the specific variable values (sysUpTime, etc.).

lurno> I am not sure if this is an issue of lwIP or it is related to my port.
lurno> Please, make some comments on the possible reasons. What shall I be
lurno> more carefull about?

lurno> Two examples of SNMP GET request/response are given below. The first
lurno> one is between HostMomitor (manager) and lwIP (agent). The second one
lurno> is between Net-SNMP (manager) and lwIP (agent). Network traffic is
lurno> captured by WireShark.

lurno> 1. HostMonitor <-> lwIP (HostMonitor accepts the response)

lurno> SNMP GET requet:
lurno> RequestID is encoded 02 01 01 which is interpreted as "1"

lurno> SNMP GET response:
lurno> RequestID is encoded 02 04 01 00 00 00 which is interpreted as "16777216"

lurno> SysUpTime value is encoded 43 03 00 9d c7 which is correct

lurno> These are the two messages:
lurno> +---------+---------------+----------+
lurno> 04:39:39,029,776   ETHER
lurno> |0  
lurno> 
|00|06|70|00|00|01|00|c0|9f|16|ba|a3|08|00|45|00|00|44|00|a9|00|00|80|11|b8|
lurno> 
aa|c0|a8|00|02|c0|a8|00|03|0b|e5|00|a1|00|30|3b|79|30|26|02|01|00|04|06|70|75|62|
lurno> 
6c|69|63|a0|19|02|01|01|02|01|00|02|01|00|30|0e|30|0c|06|08|2b|06|01|02|01|01|03|
lurno> 00|05|00|

lurno> +---------+---------------+----------+
lurno> 04:39:39,030,235   ETHER
lurno> |0  
lurno> 
|00|c0|9f|16|ba|a3|00|06|70|00|00|01|08|00|45|00|00|4a|00|11|40|00|ff|11|fa|
lurno> 
3b|c0|a8|00|03|c0|a8|00|02|00|a1|0b|e5|00|36|fa|ef|30|2c|02|01|00|04|06|70|75|62|
lurno> 
6c|69|63|a2|1f|02|04|01|00|00|00|02|01|00|02|01|00|30|11|30|0f|06|08|2b|06|01|02|
lurno> 01|01|03|00|43|03|00|9d|c7|

lurno> 2. Net-SNMP <-> lwIP (Net-SNMP rejects the response)

lurno> SNMP GET requet:
lurno> RequestID is encoded 02 02 70 06 which is interpreted as "28678"

lurno> SNMP GET response:
lurno> RequestID is encoded 02 04 06 00 00 00 which is interpreted as 
"100663296"

lurno> SysUpTime value is encoded 43 03 01 0F 57 which is correct

lurno> These are the two messages:
lurno> +---------+---------------+----------+
lurno> 04:44:59,264,042   ETHER
lurno> |0  
lurno> 
|00|06|70|00|00|01|00|c0|9f|16|ba|a3|08|00|45|00|00|45|00|ae|00|00|80|11|b8|
lurno> 
a4|c0|a8|00|02|c0|a8|00|03|0b|e6|00|a1|00|31|a2|96|30|27|02|01|00|04|06|70|75|62|
lurno> 
6c|69|63|a0|1a|02|02|70|06|02|01|00|02|01|00|30|0e|30|0c|06|08|2b|06|01|02|01|01|
lurno> 03|00|05|00|

lurno> +---------+---------------+----------+
lurno> 04:44:59,264,466   ETHER
lurno> |0  
lurno> 
|00|c0|9f|16|ba|a3|00|06|70|00|00|01|08|00|45|00|00|4a|00|12|40|00|ff|11|fa|
lurno> 
3a|c0|a8|00|03|c0|a8|00|02|00|a1|0b|e6|00|36|89|59|30|2c|02|01|00|04|06|70|75|62|
lurno> 
6c|69|63|a2|1f|02|04|06|00|00|00|02|01|00|02|01|00|30|11|30|0f|06|08|2b|06|01|02|
lurno> 01|01|03|00|43|03|01|0f|57|






reply via email to

[Prev in Thread] Current Thread [Next in Thread]