Regression in TCP

[Jakub Jermář]

Some changes in changeset:mainline,350 introduced a regression in the behavior of the TCP module.

In changeset:mainline,349, the TCP module would even accept some user data (netecho prints them), while in changeset:mainline,350, the connection is not fully setup when the tcp_process_packet() is called on a packet with a wrong src address (sa_family==0).

To reproduce, start HelenOS like this:

$ contrib/conf/net-qe.sh

from HelenOS do:

# netstart
# netcho -v -p 8080 -t SOCK_STREAM

and from outside of qemu, do:

$ telnet localhost 8080

After short time, TCP will report error -10047, which translates into EAFNOSUPPORT (unknown address family).

[Jakub Jermář]

I suspect this is because packet_get_copy() calls the _local packet interfaces instead of _remote (assuming modular build). The reason why I think that it should be remote for a modular build is that the packet server lives in the net task, which is… a different task and as such one needs to use IPC / _remote interfaces to talk to it.

There appears to be a similar issue in the socket_destroy_core() which calls oq_release_local(). socket_destroy_core() is to be called from the TL modules. If these are separate tasks, then this should rather be pq_release_remote().

This problem is not discovered at build time thanks to some really ugly things that we do. For instance, libsocket which links to all these modules contains data structures for the packet server. That means that every networking module has its private copy of the packet server data structures. When we make a mistake and call a _local() interface instead of the _remote() interface, everything looks good at the surface as the request will go to the local, unauthorative, non-actual, private copy of packet server, but the packet consistency is broken by that.

[Jakub Jermář]

Fixed in changeset:mainline,634.1.28 and merged in changeset:mainline,643.