[Xenomai] A fix to few generic issues in rttcp stack

[Gilles Chanteperdrix]

On Thu, Mar 31, 2016 at 10:33:09AM +0000, Matti Suominen wrote:
> Hi,
> 
> I have case where we use rtnet's tcp socket in server application to 
> communicate with real time and non-real time tcp clients. To get 
> communication work between client and server I had to do some changes to 
> stack/ipv4/tcp/tcp.c file.
> 
> First. Original tcp flag enumeration didn't work at all in this case. This 
> was verified by using Wireshark to track communication which didn't show 
> me any flags in tcp packets. This was solved by replacing flags assigning 
> TCP_FLAG_ prefixed enums with TCPHDR_ prefixed defines from <net/tcp.h> in 
> stack/ipv4/tcp/tcp.c file. The original code only works in case of little 
> endian machine, as rt_tcp_set_flags function places assumption that flags 
> are located in the least-significant 8bits of the 32bit flag variable. 
> This approach is similar to what regular TCP is using: 
> https://github.com/torvalds/linux/blob/master/net/ipv4/tcp.c
> 
> Second. Server was able to receive messages from client but was unable to 
> reply messages. I was able to trace function calls by adding debug prints 
> to tcp.c functions and noticed that accepted socket wasn't signaled for 
> "ready to send" at all and server was unable to reply messages. This seems 
> to work properly if the send signal is posted in the end of the accept 
> function, which also would seem the logical way to initialize it once 
> connection has been established.
> 
> Third. In our case we have regular Linux tcp sockets and rtnet tcp sockets 
> working parallel, serving different services. Referred to this I noticed 
> that *rt_tcp_dest_socket() may cause problem when real time stack 
> processes a message targeted to a regular Linux socket and does not find a 
> rttcp socket for it. The rttcp stack then  tries to send RST|ACK to client 
> to terminate the connection. This is temporarily disabled by setting 
> "if (!th->rst)" clause into #ifdef YET_UNUSED. This should be corrected 
> for example by implementing layer which is able to loop also non real time 
> sockets. Or is it really a desired rttcp design principle to unsupport the 
> usage of regular Linux tcp sockets in parallel?

I am going to merge your patch for the time being. However, I have a
question about using rttcp in parallel with Linux tcp: are you using
the rtnetproxy module? If yes, then testing for
CONFIG_XENO_DRIVERS_NET_ADDON_PROXY and the rt_ip_fallback_handler
pointer would be the way to go.

-- 
					    Gilles.
https://click-hack.org