This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Cache Problem under eCos on
TQ850
The hardware set up being used is a PowerPC 850. The following packets are SNMP responses to a GET command on an OID .2.16.44.1.4.1.1.4.1.1.3.1.2.0 . The previous two gets also failed with the Text message being send over the network having the same error as shown here the correct value is "Bit0-CByte_str" and for the error the string is shown as "Bit0-Cbyteescr". From other runs the text message returned is combined with the text of previous OID strings. This is the first failure, with the UDP check sum failing as the text has been changed. User Datagram
Protocol, Src Port: snmp (161), Dst Port: 4050
(4050) Source port: snmp
(161) Destination port: 4050
(4050) Length:
78 Checksum: 0x35a9 (incorrect,
should be 0x40a9) Simple Network
Management Protocol Version:
1 Community: public PDU type:
RESPONSE Request Id:
0x6d4dc731 Error Status: NO
ERROR Error Index:
0 Object identifier 1:
2.16.44.1.4.1.1.4.1.1.3.1.2.0 Value: OCTET STRING:
Bit0-CByteescr 0000 00 30 05 19 b8 f9 00 d0 93 00 1f 80 08
00 45 00
.0............E. 0010 00 62 34 eb 00 00 40 11 43 cb 89 df 98
d5 89 df
.b4...@.C....... 0020 55 41 00 a1 0f d2 00 4e 35 a9 30 82 00
42 02 01
UA.....N5.0..B.. 0030 00 04 06 70 75 62 6c 69 63 a2 82 00 33
02 04 6d
...public...3..m 0040 4d c7 31 02 01 00 02 01 00 30 82 00 23
30 82 00
M.1......0..#0.. 0050 1f 06 0d 60 2c 01 04 01 01 04 01 01 03
01 02 00
...`,........... 0060 04 0e 42 69 74 30 2d 43 42 79 74 65 65
73 63 72
..Bit0-CByteescr The second packet is successful the text message not being changed and the checksum is now correct. Both packets have the data and request Id so the error can be seen to have occurred after the checksum calculations. User Datagram
Protocol, Src Port: snmp (161), Dst Port: 4050
(4050) Source port: snmp
(161) Destination port: 4050
(4050) Length:
78 Checksum: 0x35a9
(correct) Simple Network
Management Protocol Version:
1 Community:
public PDU type:
RESPONSE Request Id:
0x6d4dc731 Error Status: NO
ERROR Error Index:
0 Object identifier 1:
2.16.44.1.4.1.1.4.1.1.3.1.2.0 Value: OCTET STRING:
Bit0-CByte_str 0000 00 30 05 19 b8 f9 00 d0 93 00 1f 80 08
00 45 00
.0............E. 0010 00 62 34 ec 00 00 40 11 43 ca 89 df 98
d5 89 df
.b4...@.C....... 0020 55 41 00 a1 0f d2 00 4e 35 a9 30 82 00
42 02 01
UA.....N5.0..B.. 0030 00 04 06 70 75 62 6c 69 63 a2 82 00 33
02 04 6d
...public...3..m 0040 4d c7 31 02 01 00 02 01 00 30 82 00 23
30 82 00
M.1......0..#0.. 0050 1f 06 0d 60 2c 01 04 01 01 04 01 01 03
01 02 00
...`,........... 0060 04 0e 42 69 74 30 2d 43 42 79 74 65 5f 73 74 72 ..Bit0-CByte_str When the cache is turned off this error is
no longer seen, when on about 3% of
all packets were failing. However
with cache enabled the flood test did not generate any
errors. We are using the OpenBSD stack from a CVS snapshot taken a month ago. Does anyone know why enabling the cache would directly effect the upper layers of the protocol stack, and how to solve the problem?
Siemens Plc Registered office: Siemens House, Oldbury, Bracknell, Berkshire, RG12 8FZ. Registered no: 727817, England. This communication contains information which is confidential and may also be privileged. It is for the exclusive use of the addressee. If you are not the addressee please note that any distribution, reproduction, copying, publication or use of this communication or the information in it is prohibited. If you have received this communication in error, please contact us immediately and also delete the communication from your computer. |
-- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |