Winsock problem
-
In ARM processor, which BSP r u using? how r u receiving Data? U TCP stack implemented? If u have stack implementation, there should not be problem in sending. If u dont have stack implementation, u have to assemble the packet in the TCP/IP struct and have to send it.
I'm not using any BSP and I implemented the TCP stack myself. I am able to establish communication via the 3-way handshaking process and then I assemble the package and send it. I used Wireshark to trap the packets between the PC and the micro and it recognizes it as a valid TCP/IP packet so I'm assuming it's formated properly.
-
In ARM processor, which BSP r u using? how r u receiving Data? U TCP stack implemented? If u have stack implementation, there should not be problem in sending. If u dont have stack implementation, u have to assemble the packet in the TCP/IP struct and have to send it.
Please, write international English, not stenography. We are not chatting with a phone.
2 bugs found. > recompile ... 65534 bugs found. :doh:
-
Please, write international English, not stenography. We are not chatting with a phone.
2 bugs found. > recompile ... 65534 bugs found. :doh:
-
Yes I can connect to the micro and send data from the PC to the micro but not the other way around. My socket is created as follows:
// Create socket
Socket = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);And then I wait for data:
fd_set sckt;
timeval timeout;// Set two second timeout
timeout.tv_sec = 2;
timeout.tv_usec = 0;FD_ZERO( &sckt );
FD_SET( Socket, &sckt );int nRet = select( 0, &sckt, 0, 0, &timeout );
selectalways returns 0 indicating a timeout no matter how much data I send from the micro.If the TCP handshake is successful, you are actually sending packages from the microcontroller to the PC. This lets me wonder if the error you see is on application level, perhaps your socket code is not working properly, could be both client or server side. In the code snippet you provided there is no
connectorbind/listencall, so I would not expect the socket to change status. 1) Have you tried connecting to your PC socket application from another PC (or via loopback)? 2) What error code do you get when connecting from microcontroller to PC? Timeout or something else? 3) Have you checked with Wireshark that TCP handshake is fine and packages are properly ACKed? 4) Which TCP stack are you using on the micocontroller (ARM SDK)? Could the problem not be Winsock at all?Chat in Europe :java: Now with 24% more Twitter
modified on Wednesday, July 7, 2010 11:05 AM
-
If the TCP handshake is successful, you are actually sending packages from the microcontroller to the PC. This lets me wonder if the error you see is on application level, perhaps your socket code is not working properly, could be both client or server side. In the code snippet you provided there is no
connectorbind/listencall, so I would not expect the socket to change status. 1) Have you tried connecting to your PC socket application from another PC (or via loopback)? 2) What error code do you get when connecting from microcontroller to PC? Timeout or something else? 3) Have you checked with Wireshark that TCP handshake is fine and packages are properly ACKed? 4) Which TCP stack are you using on the micocontroller (ARM SDK)? Could the problem not be Winsock at all?Chat in Europe :java: Now with 24% more Twitter
modified on Wednesday, July 7, 2010 11:05 AM
Sorry Moak, I was cutting and pasting and forgot the most important part. Here's the actual code to open and connect:
int CHPCtrl::Connect()
{struct sockaddr\_in rmtAddr;// Create data socket
m_Socket = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);if ( m\_Socket == INVALID\_SOCKET ) return 1;// Set client properties
rmtAddr.sin_family = AF_INET;
rmtAddr.sin_addr.s_addr = inet_addr( remoteIP );
rmtAddr.sin_port = htons( m_nDevicePort );// Connect to remote
if ( connect( m_Socket, (struct sockaddr *)&rmtAddr, sizeof(rmtAddr) ) == SOCKET_ERROR )
return 1;// Open rx monitor thread
m_hRxMonitor = (HANDLE)_beginthreadex( 0, 0, RxMonitor, this, CREATE_SUSPENDED, 0 );if ( m\_hRxMonitor ) { m\_bConnected = true; ResumeThread( m\_hRxMonitor ); } //\_\_if ( m\_pReadThread )\_\_ return 0;}
And in a separate thread I wait for incoming data:
UINT CHPCtrl::RxMonitor(void *pThis)
{CHPCtrl \*pCtrl = (CHPCtrl\*)pThis; int bytes\_recevied = 0; fd\_set sckt; timeval timeout;// Set two second timeout
timeout.tv_sec = 2;
timeout.tv_usec = 0;// Monitor all rx traffic
while ( pCtrl->m_bConnected )
{FD\_ZERO( &sckt ); FD\_SET( pCtrl->m\_Socket, &sckt ); int ret = select( 0, &sckt, 0, 0, &timeout ); switch ( ret ) { case SOCKET\_ERROR: //Handle error break; case 0: //Timeout //Handle time out break; default: pCtrl->ReadFromSocket( pCtrl->m\_Socket ); } //\_\_switch ( ret )\_\_ } //\_\_while ( m\_bRunRx )\_\_// Shutdown rx comm
shutdown( pCtrl->m_Socket, SD_RECEIVE );return 0;}
m_Socket is a class variable. I did this so I can send and receive on the same socket without blocking. Please let me know if you see anything wrong with this.
-
Sorry Moak, I was cutting and pasting and forgot the most important part. Here's the actual code to open and connect:
int CHPCtrl::Connect()
{struct sockaddr\_in rmtAddr;// Create data socket
m_Socket = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);if ( m\_Socket == INVALID\_SOCKET ) return 1;// Set client properties
rmtAddr.sin_family = AF_INET;
rmtAddr.sin_addr.s_addr = inet_addr( remoteIP );
rmtAddr.sin_port = htons( m_nDevicePort );// Connect to remote
if ( connect( m_Socket, (struct sockaddr *)&rmtAddr, sizeof(rmtAddr) ) == SOCKET_ERROR )
return 1;// Open rx monitor thread
m_hRxMonitor = (HANDLE)_beginthreadex( 0, 0, RxMonitor, this, CREATE_SUSPENDED, 0 );if ( m\_hRxMonitor ) { m\_bConnected = true; ResumeThread( m\_hRxMonitor ); } //\_\_if ( m\_pReadThread )\_\_ return 0;}
And in a separate thread I wait for incoming data:
UINT CHPCtrl::RxMonitor(void *pThis)
{CHPCtrl \*pCtrl = (CHPCtrl\*)pThis; int bytes\_recevied = 0; fd\_set sckt; timeval timeout;// Set two second timeout
timeout.tv_sec = 2;
timeout.tv_usec = 0;// Monitor all rx traffic
while ( pCtrl->m_bConnected )
{FD\_ZERO( &sckt ); FD\_SET( pCtrl->m\_Socket, &sckt ); int ret = select( 0, &sckt, 0, 0, &timeout ); switch ( ret ) { case SOCKET\_ERROR: //Handle error break; case 0: //Timeout //Handle time out break; default: pCtrl->ReadFromSocket( pCtrl->m\_Socket ); } //\_\_switch ( ret )\_\_ } //\_\_while ( m\_bRunRx )\_\_// Shutdown rx comm
shutdown( pCtrl->m_Socket, SD_RECEIVE );return 0;}
m_Socket is a class variable. I did this so I can send and receive on the same socket without blocking. Please let me know if you see anything wrong with this.
Looks good, but I have never used
select()on Windows. Perhaps have a look at the questions I had, they might give you some ideas. :) -
Please elaborate as to which part of the post wasn't in "international" English and I will be happy to clarify.
masnu wrote:
Please elaborate as to which part of the post wasn't in "international" English and I will be happy to clarify.
"r" "u" Mind you, once translated from text messaging, it was a helpful question / answer. Iain,
I am one of "those foreigners coming over here and stealing our jobs". Yay me!
-
Hi, I'm trying to enable my ARM development board to communicate with a PC. I can establish a connection and send data from the PC to the micro without any issues. When I try to send data from the micro to the PC, however, my socket doesn't respond to the data. A network analyzer shows that the packet was sent and formated properly. I have tried both TCP and UDP with the same results. Has anyone come across this before? Thanks.
For those of you who are interested I finally figured out what the problem was. When I implemented the TCP/IP stack on the micro I made a mistake in the routine that calculates the IP header checksum. With an invalid checksum Winsock just disregarded the message. Once the correct checksum was sent everything worked fine. Thanks to all of you for your help. I appreciate it. Paul
-
For those of you who are interested I finally figured out what the problem was. When I implemented the TCP/IP stack on the micro I made a mistake in the routine that calculates the IP header checksum. With an invalid checksum Winsock just disregarded the message. Once the correct checksum was sent everything worked fine. Thanks to all of you for your help. I appreciate it. Paul
So it was not a Winsock problem at all. ;)
-
So it was not a Winsock problem at all. ;)
-
For those of you who are interested I finally figured out what the problem was. When I implemented the TCP/IP stack on the micro I made a mistake in the routine that calculates the IP header checksum. With an invalid checksum Winsock just disregarded the message. Once the correct checksum was sent everything worked fine. Thanks to all of you for your help. I appreciate it. Paul
-
If you don't mind me asking, which network analyser did you use that didn't display an incorrect checksum?
-
I was using Wireshark, but it DID display an incorrect checksum. I just got busy doing other things and completely overlooked it. It wasn't until I focused on the problem that I paid attention to what the analyzer was telling me.
-
Cool, the reason I asked is we have a similar project coming up, and a long time ago I ran into a goofy problem with a fairly early version of Ethereal where it didn't flag some field as having an invalid value, I lost a lot of hair over that one! :)
-
I can see how that would happen. Thankfully this one didn't take me that much time. Try WireShark http://www.wireshark.org/[^] it's a useful tool.
What wonders me now... that you actually have seen the corrupt IP packages in Wireshark. I was assuming you ran Wireshark on Windows PC and your hosts are connected via a switch, shouldn't the switch throw away the IP packages from the embedded board with wrong header checksum instead of forwarding them?
-
What wonders me now... that you actually have seen the corrupt IP packages in Wireshark. I was assuming you ran Wireshark on Windows PC and your hosts are connected via a switch, shouldn't the switch throw away the IP packages from the embedded board with wrong header checksum instead of forwarding them?
Oops I was thinking wrong. IP packages are OSI Layer 3 and network switches operate on Layer 2... so they couldn't care less about IP header checksums. Sorry for the confusion. Happy coding! :)
-
What wonders me now... that you actually have seen the corrupt IP packages in Wireshark. I was assuming you ran Wireshark on Windows PC and your hosts are connected via a switch, shouldn't the switch throw away the IP packages from the embedded board with wrong header checksum instead of forwarding them?