tcp_close and tcp_abort doesn't work properly

I think you are looking at a "TIME-WAIT" state.

Don't use "tcp_abort" unless you _really_ have to!

I think this might be more related to a TCPnet limitation where you must be VERY careful what you call from within a TCP callback. Especially the part where you say:

"...in initializetcp routine I try to get socket and listen."

from within your TCP_EVT_CLOSE condition.

The details concerning the ability to do is were (and possibly still are still) very sketchy.

When I first encountered it, the support team unfortunately were unable to provide me with further details and simply said that their documentation needed updating!

I would suggest you move all but the most basic code out of the callback into the main TCP processing task.

Yes,

I would strongly second the moving of code out of the call_back routine, generate events here to signal your main tcp_routine.

regards
Darren

Hi all

you said:

I would suggest you move all but the most basic code out of the callback into the main TCP processing task

I tried to move get socket routine to another place (to main task) and connection will close as well

thanks a lot IB Shy

but here is another problem with my board

when the cable be unplugged link indicator of PHY (DP83848) will show me that the cable was unplugged very fast but there is no any act on software till timeout occur.

how can I aware such an event very fast?

although I found somethings about keepalive routine but I can not send zero length packet. (tcp_send give me an error)

is keepalive essential for TCP connection?
if yes how?

thanks in advance

"when the cable be unplugged link indicator of PHY (DP83848) will show me that the cable was unplugged very fast but there is no any act on software till timeout occur."

Most (if not all) PHYs have the ability to check the link state - You can poll the status and determine whether the cable connection is good. Check the PHY documentation for details.

Hi

I don't know why but I tried it and always give me zero as a result and it's nonsense.

but thanks I'll try it more and more... but is there any solution in RL-ARM? or not?

thanks a lot

"...but is there any solution in RL-ARM? or not?"

None of which I'm aware.

You may want to look at keepalives.

You may want to look at sending periodic packets as part of your communication protocols.

Neither of these will tell you of:

1) a cable disconnection very soon after it occurs
2) brief intermittent communication problems

In my opinion, the best way is to interrogate the PHY.

Hi

thanks IB Shy

I tried to read PHY status register ... but it gave me zero as a result ... but something here was dropped out and that was setting PHY to MDI enable... I've forgot it and now with such a routine works properly:

unsigned short int status;
MDI_Enable();
status=Read_PHY(0x10);
if ((status & 1))
        printf("lan is connected\r\n");
else
        printf("lan has been disconnected\r\n");

MDI_Disable();

here, I could recognize LAN link status very fast.

and about keepalive:
Do you agree with keepalive method ,or not?
because I've read RFC for TCP and keepalive in this document was not a good method.

I need to know the connection is still alive or not.

with these methods which you said (reading the PHY status and moving the port closing routine to main process), connection is reliable enough but I want to prevent any unexpected problems.

How can I send a TCP packet with zero lenght of data?

thank thank thank

"Do you agree with keepalive method ,or not?"

It really does depend on the requirements. For a connection that is expected to stay alive for a long time with long gaps in the communication, it can be useful. If data is being sent/received with gaps shorter than the keepalive rate then there is little point in having the keepalives. If you want the connection to tidily close when inactive, then keepalives would need to be disabled anyway.

"How can I send a TCP packet with zero lenght of data?"

As far as I am aware, you cannot send a TCP packet of zero length using TCPnet, but that should not be a requirement ...

Technically, when you send data from an application over TCP it is in a stream and the fact that the data is sent in packets should not be important.

Note that checking the state of the PHY only helps with a cable being disconnected locally. It doesn't tell what happens on the other side of the first switch, and there may be a huge number of network routers between your unit and the other end.

KeepAlive - or regular own messages - will catch even these errors. But since regular transfers represents a form of polling, the polling frequency decides how fast you will notice a problem.

Note also that in many situations, TCP/IP will be able to retransmit and keep the connection alive even if a user shortly disconnects/reconnects a wire or reboots a router. Having too hard requirements - for example by looking for ping times - may be counterproductive.

"Note that checking the state of the PHY only helps with a cable being disconnected locally."

A very valid point.

I'd also add that if you really need to check for broken connections quickly then TCP/IP over Ethernet is not always the most suitable anyway. Like many other communication mediums, Ethernet is, by definition, non-deterministic. Errors can (and quite often do) occur, which cause retransmissions and therefore delays.