[Xenomai] A fix to few generic issues in rttcp stack
Gilles Chanteperdrix
gilles.chanteperdrix at xenomai.org
Sat Apr 30 08:49:39 CEST 2016
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
More information about the Xenomai
mailing list