Hi Kumar
The project can be configured as to how it reacts to TCP connection attempts to a non-listening TCP port.
RST_ON_NO_TCP_PORT defines that a TCP RST is sent back when a SYN to a non-listening port is received. Without this define the SYN will be silently discarded (as if the device had not received the frame). Therefore there always needs to be a listening TCP port to be able to communicate - this define only defines if the device actively informs of non-existing port or not.
Correspondingly for UDP ports there is the define ICMP_DEST_UNREACHABLE which controls whether a "destination unreachable" is sent when a UDP frame is received to an non-listening UDP port. If this is not desired, removing ICMP_DEST_UNREACHABLE will cause the UDP frame to be silently discarded instead.
If you compare this reaction to a Windows PC you will see that these reactions are also configurable. Many people prefer that no response is sent when their PC receives a frame for non-listening ports because hackers (software) often send such frames to strange port numbers to detect whether there is a PC on the IP address or not, based on the way the PC reacts. If the PC silently discards such frames there is no indication that the PC is on the IP address. Therefore it tends to be disabled by default in newer Windows configurations. I always keep it on in the uTasker project because it helps debugging and who wants to hack an embedded device??
Regards
The project can be configured as to how it reacts to TCP connection attempts to a non-listening TCP port.
RST_ON_NO_TCP_PORT defines that a TCP RST is sent back when a SYN to a non-listening port is received. Without this define the SYN will be silently discarded (as if the device had not received the frame). Therefore there always needs to be a listening TCP port to be able to communicate - this define only defines if the device actively informs of non-existing port or not.
Correspondingly for UDP ports there is the define ICMP_DEST_UNREACHABLE which controls whether a "destination unreachable" is sent when a UDP frame is received to an non-listening UDP port. If this is not desired, removing ICMP_DEST_UNREACHABLE will cause the UDP frame to be silently discarded instead.
If you compare this reaction to a Windows PC you will see that these reactions are also configurable. Many people prefer that no response is sent when their PC receives a frame for non-listening ports because hackers (software) often send such frames to strange port numbers to detect whether there is a PC on the IP address or not, based on the way the PC reacts. If the PC silently discards such frames there is no indication that the PC is on the IP address. Therefore it tends to be disabled by default in newer Windows configurations. I always keep it on in the uTasker project because it helps debugging and who wants to hack an embedded device??
Regards
Hi
When you obtain and bind the TCP socket you can define the timeout period with no activity.
USOCKET fnGetTCP_Socket(unsigned char ucTos, unsigned short usIdleTimeout, int (*listener)(USOCKET, unsigned char, unsigned char *, unsigned short) );
usIdleTimeout is the period in seconds (1s to 18 hours) If you define it as 0xffff it will be interpreted as infinite and so never timeout when there is no activity - it will only be closed actively.
If you used example code as a reference it will probably have a timeout of 2 minutes. This timer is reset whenever there is activity on the socket and there is no known problem with this operation. When you write that you are sending a 'ping packet' do you mean that you are sending a TCP frame or an ICMP "ping"? An ICMP ping will not be detected as activity at the TCP socket (TCP socket activity is only of the connected port pairs).
You can verify the internal operation in the uTasker simulator by setting a break point on the line "ptr_TCP->usLinkTimer = ptr_TCP->usIdleTimeout;" in tcp.c - about line 746.
When a connection is established, the keep alive timer will be triggered by every reception on the connection.
I have added a screen shot from the simulator where ptrTCP is expanded. usIdleTimeout is the timeout set for the socket. usLinkTimer is set to this at the break point and counts down every second without activity. Although not absolutely relevant to this discussion, the memory display on the right shows the Ethernet frame in the receive Buffer Description which was destined to the TCP socket. The M5223X is simulated on the PC in the uTasker simulator environment and this was a real TCP frame from another PC in the network which was connected to the simulated device.
If you have any more problems or questions then please post them here or else you can use the direct support address for the processor type used at http://www.utasker.com/
Regards
When you obtain and bind the TCP socket you can define the timeout period with no activity.
USOCKET fnGetTCP_Socket(unsigned char ucTos, unsigned short usIdleTimeout, int (*listener)(USOCKET, unsigned char, unsigned char *, unsigned short) );
usIdleTimeout is the period in seconds (1s to 18 hours) If you define it as 0xffff it will be interpreted as infinite and so never timeout when there is no activity - it will only be closed actively.
If you used example code as a reference it will probably have a timeout of 2 minutes. This timer is reset whenever there is activity on the socket and there is no known problem with this operation. When you write that you are sending a 'ping packet' do you mean that you are sending a TCP frame or an ICMP "ping"? An ICMP ping will not be detected as activity at the TCP socket (TCP socket activity is only of the connected port pairs).
You can verify the internal operation in the uTasker simulator by setting a break point on the line "ptr_TCP->usLinkTimer = ptr_TCP->usIdleTimeout;" in tcp.c - about line 746.
When a connection is established, the keep alive timer will be triggered by every reception on the connection.
I have added a screen shot from the simulator where ptrTCP is expanded. usIdleTimeout is the timeout set for the socket. usLinkTimer is set to this at the break point and counts down every second without activity. Although not absolutely relevant to this discussion, the memory display on the right shows the Ethernet frame in the receive Buffer Description which was destined to the TCP socket. The M5223X is simulated on the PC in the uTasker simulator environment and this was a real TCP frame from another PC in the network which was connected to the simulated device.
If you have any more problems or questions then please post them here or else you can use the direct support address for the processor type used at http://www.utasker.com/
Regards
