Using the Wi-Fi Pmod board and library, I have successfully established a connection to a server through TCP, however this connection will close after an unsuccessful send attempt of a packet i.e. two concurrent packets will not have concurrent identification numbers and the network will throw up an error. In the Wi-Fi Pmod library, where are the identity numbers set and what could cause them to be set to zero (note that the fragment message bit is also set even though the message is less than 16 bytes)? Examining the contents of each packet sent through wire shark shows that these message are not causing the error (although they may be part of the solution).
In an effort to gain more understanding of the device I have printed out the transport header, IP header and payload from the function ''SendNextIpStack(void)''. These printed values show that there is a packet which is attempted to be sent regularly which has no header but the payload is:
In my research I have found that all TCP packets need a header which means that these packets are invalid. I know that these are not acknowledge packets as those packets have empty payloads not empty headers. Is there a valid reason these packets are being created, if so why? Is it a coincidence that around half these 'invalid' packets are the same as packet 1 and the other half the same as packet 2.
It might also be important to know that after the connection fails completely the device continually (periodically) tries to send packet 1.
Question
Ryan_98
Using the Wi-Fi Pmod board and library, I have successfully established a connection to a server through TCP, however this connection will close after an unsuccessful send attempt of a packet i.e. two concurrent packets will not have concurrent identification numbers and the network will throw up an error. In the Wi-Fi Pmod library, where are the identity numbers set and what could cause them to be set to zero (note that the fragment message bit is also set even though the message is less than 16 bytes)? Examining the contents of each packet sent through wire shark shows that these message are not causing the error (although they may be part of the solution).
In an effort to gain more understanding of the device I have printed out the transport header, IP header and payload from the function ''SendNextIpStack(void)''. These printed values show that there is a packet which is attempted to be sent regularly which has no header but the payload is:
00 01 08 00 06 04 00 02 00 1E C0 4B E4 7B C0 A8 56 24 B0 2A 43 C7 CF C5 C0 A8 56 01 (packet 1)
or
00 01 08 00 06 04 00 01 00 00 00 00 00 00 C0 A8 56 24 00 00 00 00 00 00 C0 A8 56 01 (packet 2)
In my research I have found that all TCP packets need a header which means that these packets are invalid. I know that these are not acknowledge packets as those packets have empty payloads not empty headers. Is there a valid reason these packets are being created, if so why? Is it a coincidence that around half these 'invalid' packets are the same as packet 1 and the other half the same as packet 2.
It might also be important to know that after the connection fails completely the device continually (periodically) tries to send packet 1.
Link to comment
Share on other sites
0 answers to this question
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now