Access to TCP/IP Stack?

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
1

Is the soucre code to the TCP/IP stack(s) available or is it
possible to extract/inject packets at different layers within the
stack to facilitate custom processing? There are a handful of
protocols we are considering for implementation that I think
would be difficult to do without access to the source code. Here
are a couple of examples. I don’t have full details, but you’ll
get the idea…

  1. One of these protocols uses UDP for transport. The packet
    breaks down kind of like you’d expect with a 20 byte IP
    header, 20 byte UDP header, 20 byte protocol specific header
    and then the payload. The catch here is the payload is only a
    few bytes so most of the packet just consists of packet
    headers. Not all that efficient. To help with this, after a
    transaction is established the header portion is replaced with
    (I think) a 4 byte transaction ID in all future packets
    associated with the transaction. When a packet is received,
    the stack recognizes it is one of these “compressed” affairs,
    uses the transaction ID to retrieve a locally-stored copy of
    the header which is used to build an “uncompressed” version of
    the packet. The uncompressed version is then propagated up
    the stack as usual.

I’m not sure if the entire header (IP/UDP/other) is
represented by the transaction ID or if just the (UDP/other)
portion is. In the first case I guess it would be the
ethernet driver that would have to expand the header then pass
it up to the IP layer. In the second case, the IP layer would
have to expand it and pass it to the UDP layer.

Anyway, like I said, I’m sketchy on the details of this
protocol. I haven’t seen a spec, I’ve only had it described
to me and I’ve probably described it to you incorrectly. The
key point is, its unlikely the off-the-shelf stacks will know
when or how to do this compression trick so we’d have to add
it. Assuming the source code is not available, is it possible
to extract packets at the IP layer say, modify them and stick
them back in?


2) Another protocol we are potentially interested in is the
Stream Control Transmission Protocol described in
RFC-2960. This protocol is at the same level as UDP and TCP in
that it sits between IP and the application. Is it possible to
extract incoming packets at the IP layer based on protocol
number and insert outbound SCTP packets back into the stack at
the IP layer?

2

Charlie Hubbard <chubbard@owt.com> wrote in
news:kuhc8u4pug2folu91l1iqt1gva2dp40lco@4ax.com:

Is the soucre code to the TCP/IP stack(s) available or is it
possible to extract/inject packets at different layers within the
stack to facilitate custom processing? There are a handful of
protocols we are considering for implementation that I think
would be difficult to do without access to the source code. Here
are a couple of examples. I don’t have full details, but you’ll
get the idea…

Do you mean available for public consumption? If so - no. You can contact
your sales rep. to get information on the availability of source code.

  1. One of these protocols uses UDP for transport. The packet
    breaks down kind of like you’d expect with a 20 byte IP
    header, 20 byte UDP header, 20 byte protocol specific header
    and then the payload. The catch here is the payload is only a
    few bytes so most of the packet just consists of packet
    headers. Not all that efficient. To help with this, after a
    transaction is established the header portion is replaced with
    (I think) a 4 byte transaction ID in all future packets
    associated with the transaction. When a packet is received,
    the stack recognizes it is one of these “compressed” affairs,
    uses the transaction ID to retrieve a locally-stored copy of
    the header which is used to build an “uncompressed” version of
    the packet. The uncompressed version is then propagated up
    the stack as usual.

I’m not sure if the entire header (IP/UDP/other) is
represented by the transaction ID or if just the (UDP/other)
portion is. In the first case I guess it would be the
ethernet driver that would have to expand the header then pass
it up to the IP layer. In the second case, the IP layer would
have to expand it and pass it to the UDP layer.

Anyway, like I said, I’m sketchy on the details of this
protocol. I haven’t seen a spec, I’ve only had it described
to me and I’ve probably described it to you incorrectly. The
key point is, its unlikely the off-the-shelf stacks will know
when or how to do this compression trick so we’d have to add
it. Assuming the source code is not available, is it possible
to extract packets at the IP layer say, modify them and stick
them back in?

Your idea would then be limited to a link layer of ethernet (if the entire
header is to be “compressed”). If you leave the IP header alone, you might
be able to do the “expansion” in an IP to IP converter. You should look
into the costs and the implications for the upper transport layer if the
lower layer has to fail/retry (transaction id not recognized, perhaps it
was expunged due to lack of traffic etc).

I’m not entirely convinced you need to do this, since if you use Nagles
algorithm and a tcp connection, you accomplish about the same thing (ie.
transport overhead overwhelming payload size). Not to mention that a UDP
transfer isn’t guaranteed to arrive at the destination, you’d have to
implement your own transport protocol.

  1. Another protocol we are potentially interested in is the
    Stream Control Transmission Protocol described in
    RFC-2960. This protocol is at the same level as UDP and TCP in
    that it sits between IP and the application. Is it possible to
    extract incoming packets at the IP layer based on protocol
    number and insert outbound SCTP packets back into the stack at
    the IP layer?

I think you could write an IP to IP filter to intercept IP packets with
your protocol, do some work, then shove them back down. You could also do
a userland implementation using raw sockets, but it could be expensive due
to memory copies into and out of your process space.



\

Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>

3

On 6 Mar 2002 19:27:54 GMT, Adam Mallory <amallory@qnx.com> wrote:

Charlie Hubbard <> chubbard@owt.com> > wrote in
news:> kuhc8u4pug2folu91l1iqt1gva2dp40lco@4ax.com> :

Is the soucre code to the TCP/IP stack(s) available or is it
possible to extract/inject packets at different layers within the
stack to facilitate custom processing? There are a handful of
protocols we are considering for implementation that I think
would be difficult to do without access to the source code. Here
are a couple of examples. I don’t have full details, but you’ll
get the idea…

Do you mean available for public consumption? If so - no. You can contact
your sales rep. to get information on the availability of source code.

Nah, I don’t necessarily mean for general public consumption. If
an NDA or something is necessary, ok. I’m just interested to
know if it is possible to get the source code at all.

Your idea would then be limited to a link layer of ethernet (if the entire
header is to be “compressed”). If you leave the IP header alone, you might
be able to do the “expansion” in an IP to IP converter. You should look
into the costs and the implications for the upper transport layer if the
lower layer has to fail/retry (transaction id not recognized, perhaps it
was expunged due to lack of traffic etc).

You’re right, if the IP portion is included in the “compression”
then changes need to made to whatever link layer protocol is in
use to recognize and support the compressed packets. Support for
this protocol in particular would probably go into the link layer
driver and not in the IP stack itself although it would need to
get the uncompressed IP packets into the IP layer eventually.
None of this sounds like much fun. Unfortunately, this scheme
for header compression isn’t my idea so I don’t get a say in
whether or not the IP header is left uncompressed. This is a
protocol developed at Cisco and described in RFC-2508. I gather
this is actually implemented in certain Cisco products (they call
it cRTP – compressed Realtime Transport Protocol).

But I’m getting bogged down in details again. In truth, we may
never have to implement the Cisco header compression
protocol. Unfortunately, the protocol in my second example (SCTP,
RFC-2960) we probably will have to implement. I guess the intent
of my original post was not so much to see if those two protocols
in particular could be implemented within the existing QNX
network stack but to see if new protocols in general could be
added.

Our current product runs software that we developed completely
in-house including the TCP/IP stack. This has one big advantage
in that it lets us make it do whatever we need it to. I’m sure
everyone reading this is well aware of the associated
disadvantages. I’ll be happy not to have to write another file
system or network stack and for our next product we’ll probably
go with a commercial RTOS. That RTOS will almost certainly be
QNX. However, I am pretty nervous about the ways in which
switching to QNX may reduce our flexibility. The networking
stack in particular scares me because we work in an industry
(telecommunications) that seems to be collecting a rather lot of
unusual but necessary protocols. I think eventually we’ll have to
implement at least some of them. Without the source code I’m not
sure we even could. Writing our own, replacement stack, besides
just being a stupid thing to think about given that QNX already
provides two great ones, also defeats some of the reason for
switching to a commerial OS in the first place!

I know, contact my sales rep! I’ll do that in the morning.



Charlie Hubbard

4

Charlie Hubbard <chubbard@owt.com> wrote:

On 6 Mar 2002 19:27:54 GMT, Adam Mallory <> amallory@qnx.com> > wrote:

[snip]

Our current product runs software that we developed completely
in-house including the TCP/IP stack. This has one big advantage
in that it lets us make it do whatever we need it to. I’m sure
everyone reading this is well aware of the associated
disadvantages. I’ll be happy not to have to write another file
system or network stack and for our next product we’ll probably
go with a commercial RTOS. That RTOS will almost certainly be
QNX. However, I am pretty nervous about the ways in which
switching to QNX may reduce our flexibility. The networking
stack in particular scares me because we work in an industry
(telecommunications) that seems to be collecting a rather lot of
unusual but necessary protocols. I think eventually we’ll have to
implement at least some of them. Without the source code I’m not
sure we even could. Writing our own, replacement stack, besides
just being a stupid thing to think about given that QNX already
provides two great ones, also defeats some of the reason for
switching to a commerial OS in the first place!

Well, my view is you should really consider that the protocol
you try to implement, is it mean to be inside of tcpip stack?

For example, “telnet” is a protocol on TCP, but you implement
it as a userland application, right?

Your “Head compress protocol” can be implement in between
tcpip stack and the data link driver. So, you compress it
while it goes out, and decompress it, give tcpip a full ip packet…

So, if you start think of modify tcpip stack, you might want
to think it again. But anyway, if you still want the stack
source, you know where to ask :slight_smile:

-xtang

5

On 7 Mar 2002 15:44:33 GMT, Xiaodan Tang <xtang@qnx.com> wrote:

Well, my view is you should really consider that the protocol
you try to implement, is it mean to be inside of tcpip stack?

For example, “telnet” is a protocol on TCP, but you implement
it as a userland application, right?

Your “Head compress protocol” can be implement in between
tcpip stack and the data link driver. So, you compress it
while it goes out, and decompress it, give tcpip a full ip packet…

So, if you start think of modify tcpip stack, you might want
to think it again. But anyway, if you still want the stack
source, you know where to ask > :slight_smile:

Yes, I agree with you completely! Certainly some telco
protocols (like SIP, RFC-2543) are completely implemented ON
TOP of UDP or TCP and can be implemented with no changes to
the stack at all. Others, like the header compression
scheme, really exist at the link layer and also require no
modification to the TCP/IP stack (although they do require
modification of, say, the ethernet driver) provided there is
a way to get the uncompressed IP packet into the TCP/IP
stack. However, there are some protocols like SCTP
(RFC-2960) that ARE NOT implemented on top of UDP, TCP,
etc. but instead exist side by side with UDP and TCP. That
is to say, they receive packets from the IP layer and pass
packets up to the application layer. That requires routing
IP packets containing the SCTP protocol number to special
SCTP code in the same way that IP packets containing
protocol numbers for UDP or TCP are routed to the existing
UDP or TCP code. Right now that happens inside the stack.
I don’t know what the unmodified stack would do if it
received an IP packet containing an SCTP payload. My guess
is it would throw it away and generate an ICMP “destination
unreachable / protocol unreachable” message back to the
sender. I don’t know how to get around that problem without
extending the stack.

But anyway, like you point out, I need to talk the QNX sales
guys and get more information. I hope to do that today!


Charlie Hubbard

6

Charlie Hubbard <chubbard@owt.com> wrote:

stack. However, there are some protocols like SCTP
(RFC-2960) that ARE NOT implemented on top of UDP, TCP,
etc. but instead exist side by side with UDP and TCP. That
is to say, they receive packets from the IP layer and pass
packets up to the application layer. That requires routing
IP packets containing the SCTP protocol number to special
SCTP code in the same way that IP packets containing
protocol numbers for UDP or TCP are routed to the existing
UDP or TCP code. Right now that happens inside the stack.
I don’t know what the unmodified stack would do if it
received an IP packet containing an SCTP payload. My guess
is it would throw it away and generate an ICMP “destination
unreachable / protocol unreachable” message back to the
sender. I don’t know how to get around that problem without
extending the stack.

I just briefly look at the RFC-2960, I think it is idealy for
a raw socket implemetation.

sd = socket(AF_IENT, SOCK_RAW, PROTO_SCTP);

then all the IP packet with ip_proto == PROTO_SCTP will deliever
to this kind of socket.

-xtang

7

On 7 Mar 2002 19:08:44 GMT, Xiaodan Tang <xtang@qnx.com> wrote:

I just briefly look at the RFC-2960, I think it is idealy for
a raw socket implemetation.

sd = socket(AF_IENT, SOCK_RAW, PROTO_SCTP);

then all the IP packet with ip_proto == PROTO_SCTP will deliever
to this kind of socket.

-xtang

Excellent, thanks! I didn’t know you could strip out protocol
specific packets that way. Looks like that technique would work great
and it requires no modification to the stack.


C.