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

[Gilles Chanteperdrix]

On Sun, Apr 03, 2016 at 09:09:48PM +0200, Gilles Chanteperdrix wrote:
> 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.

Hi, ping ?

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