tcp socket for communication with hardware

asked 2024-01-21 16:11:05 +0000

schoko
1 ●1

updated 2024-01-21 18:24:40 +0000

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!

edit retag flag offensive close merge delete

Comments

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

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

yes of course, thanks @Chuckc

schoko ( 2024-01-21 18:23:14 +0000 )edit

add a comment

answered 2024-01-21 20:23:22 +0000

SYN-bit

18528 ●9 ●339 ●255 https://SYN-b.it

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)

edit flag offensive 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 ( 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 ( 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 ( 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 ( 2024-01-22 16:36:57 +0000 )edit

add a comment

tcp socket for communication with hardware

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

tcp socket for communication with hardware edit

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

tcp socket for communication with hardware