TCP/IP stack trapping

Discussion to talk about software related topics only.
User avatar
pbreed
Posts: 1080
Joined: Thu Apr 24, 2008 3:58 pm

Re: TCP/IP stack trapping

Post by pbreed »

Also what tools revision are you using?
(the contents of the file nburn\release_tag)
romanluba
Posts: 12
Joined: Mon Oct 26, 2020 6:03 am

Re: TCP/IP stack trapping

Post by romanluba »

These are the Trap outputs of the s19 files you have provided me, thank you for taking the time to help me debug. The release version I am using is 2.9.2, I will try to re-install the NNDk. Images of the trap are attached.
Attachments
Trap11208.PNG
Trap11208.PNG (24.75 KiB) Viewed 1892 times
info1208.PNG
info1208.PNG (35.58 KiB) Viewed 1892 times
User avatar
pbreed
Posts: 1080
Joined: Thu Apr 24, 2008 3:58 pm

Re: TCP/IP stack trapping

Post by pbreed »

Were looking at this... we will get back to you soon...(IE late today early Wedensday)
User avatar
pbreed
Posts: 1080
Joined: Thu Apr 24, 2008 3:58 pm

Re: TCP/IP stack trapping

Post by pbreed »

Please try the attached...
and send us the full text result of running...
Attachments
IPv6-ShowAddress_APP.zip
(181.59 KiB) Downloaded 136 times
User avatar
dciliske
Posts: 623
Joined: Mon Feb 06, 2012 9:37 am
Location: San Diego, CA
Contact:

Re: TCP/IP stack trapping

Post by dciliske »

Just want to pop in and add a bit here. You've got lots of eyeballs on this one since it's quite bizarre what seems to be happening and you see to be able to reproduce it trivially, whereas we cannot.

The status is as follows: the trap is due to a NULL pointer in a buffer member used for read tracking in streams. This NULL pointer is not possible to exist within the code path being affected (aka, the serial port). Therefore, we believe that there is a buffer use-after-free occurring/double-free. This is where the updated executable comes in. The updated image has a build configuration enabled which will trap the application as soon as a buffer is attempted to be freed that is already marked as free. This should cause the application to trap when the buffer is attempted to be freed the second time, which would give insight into the path that triggered it.

Additionally, it would be very beneficial if you can send us a capture of the network traffic to/from the module in the preceding ~60 seconds or since boot, whichever is shorter. If a full capture is not feasible for privacy/data security concerns, a capture of the payloadless V6 headers would also be beneficial. It is recommended that if you can provide these and they may contain sensitive data, the captures should be sent as part of a support (or sales if you do not have a support account) ticket.
Dan Ciliske
Project Engineer
Netburner, Inc
Post Reply