First time here? Check out the FAQ!
THIS IS A TEST INSTANCE. Feel free to ask and answer questions, but take care to avoid triggering too many notifications.
0

tcp socket for communication with hardware

Hi,

i have also posted my question on stack overflow and my questions might also be better placed here then on stack overflow... https://stackoverflow.com/questions/7...

I use nodejs net module to create a tcp socket connection for mimic data transfer from and to the hardware (kemper amp).

File node_capture is the file when trying to send data when the first packet from the hardware was sent: https://github.com/schoko11/wireshark...

File wireshark_sample1 is the captured traffic from android (with pcapdroid).I don't have a capture from the hardware side(would need a switch i think, connected with a dlink router to my local wlan)... https://github.com/schoko11/wireshark...

Both files contains just the first small part of the whole communiction, because there is also a serial number etc. in the files i don't want to post ( it should not be necessary IMHO )

Do you have any idea why this does not work / getting tcp retransmission errors ?

Thank you!

schoko's avatar
1
schoko
asked 2024-01-21 16:11:05 +0000, updated 2024-01-21 18:24:40 +0000
edit flag offensive 0 remove flag close merge delete

Comments

Place the files on a public file share then update the question with a link to them.

Chuckc's avatar Chuckc (2024-01-21 17:30:28 +0000) edit

yes of course, thanks @Chuckc

schoko's avatar schoko (2024-01-21 18:23:14 +0000) edit
add a comment see more comments

1 Answer

0

In your provided captures there is not a real problem. One TCP segment did not get an ACK in time, so the 200ms RTO timer fires and triggers a retransmission which is properly ACKed. So this problably means there is a certain amount of packet loss between the endpoints.

BTW, the captures were not made at the same time, so it is not possible to see wheter the packet loss was on the way to the device or on the way back from the device. Please provide traces of the app and the device at the same when the problem is happening.

I skimmed youtr stackoverflow question, so it seems the problem might lie more at the message content level than at the TCP level (even though there might be the occasional retransmission due to packet loss)

SYN-bit's avatar
18.5k
SYN-bit
answered 2024-01-21 20:23:22 +0000
edit flag offensive 0 remove flag delete link

Comments

Thanks for taking a look into this.

I assumed after sending, that the device responds with the next message... (the difference is the prepended header and a tailor x'00' -> any idea why?)

What do you mean with "the captures were not made at the same time ..." -> i only have one device..???

maybe the connection would be better if i wire the hardware directly to the router...

schoko's avatar schoko (2024-01-21 20:49:09 +0000) edit

Often when people analyze TCP traffic, a capture is made near/on the client and another one near/on the server. So I assumed that was the case, my bad.

The prepended header is the ethernet header[1], containing the dst mac address, the source mac address and the ethertype (0x0800 for IP). Then what follows are the IP header, TCP header and TCP payload data.

I have no idea what the extra 0x00 at the end is. That is listed as an ethernet trailer, ie not part of the ip datagram and thus also not part of the TCP payload data. I assume it is an artefact of the capture mechanism. On which system was the capture made and which systems have which IP addresses in your traces?

From my current point of view, there is nothing wrong going on, except some packet loss and therefor some retransmissions at ... (more)

SYN-bit's avatar SYN-bit (2024-01-22 12:59:22 +0000) edit

The pcap file was made with an android app called pcapdroid. 1.) start pcapdroid 2.) select the app you want to listen at 3.) start the capture 4.) open the app and wait a few seconds 5.) open pcapdroid again and wait until no more traffic is captured.

I added another capture doing this in the exact way like described above. https://github.com/schoko11/wireshark...

in this capture the android handy(samsung galaxy s21 android 13) has the ip: 10.215.173.1

so my assumption is when doing e.g. a "follow tcp stream"

  • package nr. 4 the hardware is sending the first message with identifiers (and here also a trailer)
  • package nr. 6 android is sending the corresponding identification back
  • package nr. 8 android is sending additionally x'0d 0a'
  • package nr.10 the hardware is sending x'2b' + idenfication + x'0d 0a'

and so on, but ... (more)

schoko's avatar schoko (2024-01-22 15:54:10 +0000) edit

oh i found it, had a wrong hex in my message, after comparing everything i found it now :-) Thank you for your kind support!

schoko's avatar schoko (2024-01-22 16:36:57 +0000) edit
add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer