• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 39 subscribers
  • Views 1191 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Accept returns 0xFEFEFEFE and stops responding to connections after a while.

per.during
Prodigy 130 points

As the subjects states, my accept is returning 0xFEFEFEFE. What does that mean?

The listen socket is in a non blocking state.

As I under stand it, accept should only return >=0 or -1,-2.


After a few connections, 2-100, accept never accept new connections and always returns 0xFEFEFEFE. If I look in tAcceptReturnArguments I can see my ip-number and port there as well as iStatus witch is 0xFEFEFEFE.

I am using driver version 1.32.

Send is non blocking.

My code basically does this:

  1. Create listen socket 
  2. set non blocking
  3. bind
  4. listen
  5. accept
  6. send ~20bytes of data to client
  7. close socket returned by accept
  8. GOTO 5

I have also tried:

  1. Create listen socket 
  2. set non blocking
  3. bind
  4. listen
  5. accept
  6. send ~20bytes of data to client
  7. close socket returned by accept
  8. close listen socket
  9. GOTO 1

The results are the same. The socket I get from accept is always 1 when it is working, so I guess that confirms that I am closing the socket correctly.


Can some one tell me what is happening? If you need more information, just let me know.


Thanks,

Per

  • 0
    TI__Mastermind 27095 points
    Hi Per,

    Can you please confirm that the host driver that you are using is from SDK 1.14 (along with the Service pack 1.32).
    Do you see a similar behavior in the blocking mode?

    I would also suggest running this test without closing the sockets in between, if your test case permits it.

    Regards,
    Raghavendra
  • 0 in reply to Raghavendra Shenoy
    Prodigy 130 points

    I have figured out why accept was returning 0xFEFEFEFE. The module was sending the correct data eg. 0xFFFFFFFE but the function 'UINT32 STREAM_TO_UINT32_f(CHAR* p, UINT16 offset)' gave to much freedom to the compiler, resulting in corrupted data for me. The solution was to rewrite it, and the other converter-function.

    UINT32 STREAM_TO_UINT32_f(CHAR* p, UINT16 offset)
{
	UINT32 old, new;
	
	old = 	(UINT32)((UINT32)((UINT32)(*(p + offset + 3)) << 24) +
			(UINT32)((UINT32)(*(p + offset + 2)) << 16) + 
			(UINT32)((UINT32)(*(p + offset + 1)) << 8) + 
			(UINT32)(*(p + offset)));
		
	new = 	((UINT32)(*(p + offset + 3)) << 24)	& 0xFF000000ul;
	new |=	((UINT32)(*(p + offset + 2)) << 16)  & 0x00FF0000ul;
	new |=	((UINT32)(*(p + offset + 1)) << 8)	& 0x0000FF00ul;
	new |=	((UINT32)(*(p + offset + 0)) << 0)	& 0x000000FFul;
	
	return new; 
}

    The problem with accept never returning a connection still remains.

    Raghavendra Shenoy said:

    Can you please confirm that the host driver that you are using is from SDK 1.14 (along with the Service pack 1.32).

    As you can see above I am using the host driver 1.14, since it contains UINT32, UINT16. And yes, I am reading out FW 1.32 form the module.

    Raghavendra Shenoy said:

    Do you see a similar behavior in the blocking mode?

    I have not tried that. I will see if I can test that too.

    Raghavendra Shenoy said:

    I would also suggest running this test without closing the sockets in between, if your test case permits it.

    So I should test to neither close the listen-socket nor the socket given by accepts? Isn't that going to result in me hitting the limit of 4 socket pretty fast?

    The accept-problem is much more noticeable when the module is connected to a network with many devices. If I connect the module and my computer to a private router, I have not yet been able to replicate it.

    Regards,

    Per

  • 0 in reply to per.during
    TI__Mastermind 27095 points
    Hi Per,

    I missed out the contents of the second test iteration you mentioned. I was referring to not closing the listen socket.
    Please let me know if the blocking accept yields a different result.

    Regards,
    Raghavendra
  • 0 in reply to Raghavendra Shenoy
    Prodigy 130 points
    Blocking or non-blocking does not matter.
    On a network with few devices and low traffic it preforms good. On a network with many devices and probably hight traffic, it is really bad.

    However, UDP is preforming good in the high-traffic-network.
  • 0 in reply to per.during
    Prodigy 130 points

    I have tried to log the HCI_EVENT_ACCEPT coming from the module. See the picture below.

    All the rows in the picture looks good to me, accept is returning -2 as expected, except the last one. This is what happens when accepts stops responding. As you can see in the last row accept is returning -2 but my IP (and port) is there too! Is this a expected behaviour, returning -2 and an IP address?

    Do you know if any one "out there" have been using the CC3000-module in non blocking as a TCP-server successfully?

    Regards,

    Per