enarx-archive / tlssock

A library exposing TLS/DTLS sockets using the POSIX networking APIs
Apache License 2.0
18 stars 7 forks source link

Improve test coverage #9

Open npmccallum opened 5 years ago

npmccallum commented 5 years ago

We currently have 65% test coverage for the core library. It would be good to increase this.

An obvious place to start is the send() and recv() functions.

DK-DARKmatter commented 5 years ago

When replacing write() and read() in main.c, it looks like the test fails when our program work as client.

The test log shows the server could never receive the message.

When adding MSG_DONTWAIT flag, it has the similar behavior as using 0 flag, the program cannot receive anything.

DK-DARKmatter commented 5 years ago

19/100 4TCP: ts-openssl -> socat               FAIL     0.14 s (exit status 1)

--- command ---
/home/kzhao/workspace/tlssock/build/default/run -- tlssock-openssl localhost4 %PORT% -- /usr/bin/socat tcp-listen:%PORT%,pf=ipv4 exec:/usr/bin/cat
--- stderr ---
client: tlssock-openssl localhost4 52474
server: /usr/bin/socat tcp-listen:52474,pf=ipv4 exec:/usr/bin/cat
wrote: 9: abcdefgh

fd is 3
con is -1
in is 0
out is 1
opts->listen is 0
ret is -1!
pfds[0].fd is 0!
Errno is 88
read: 0: 

This is one example of the failure case. The test output is placed at https://github.com/enarx/tlssock/blob/master/bin/main.c#L254 before the on_conn() is called. We can see that the bug happens even when opts->exec is not enabled. I think the problem is, in this situation, recv() will do read from pfds[0].fd, which is 0. We indeed create a socket for the client, the fd is 3, but then the recv() function seems have no relationship with the socket, it reads from 0, which is STDIN_FILENO. I think in this case STDIN is not closed. I have the same reuslt when I run the command manually.