Fedora 31 server running trunk (v4).
Instead of detecting the http traffic, peek returns no data and we fail with:
io_in_cb(<socket.socket fd=4, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('0.0.0.0', 10000)>, <flags G_IO_IN of type GLib.IOCondition>) (..) socket tcp socket: 192.168.0.10:10000 <- 192.168.0.106:47438 peek: got 0 bytes may_wrap_socket: no data, not wrapping (..) New tcp connection received from '192.168.0.106:47438' on '0.0.0.0:10000'
That's despite waiting for 1 second polling the socket...
wireshark shows that the TCP packet does contain the HTTP GET request:
GET / HTTP/1.1 Host: 192.168.0.10:10000 Connection: keep-alive Cache-Control: max-age=0 Upgrade-Insecure-Requests: 1 Save-Data: on User-Agent: Mozilla/5.0 (Linux; Android 10; PH-1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.87 Mobile Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 Accept-Encoding: gzip, deflate Accept-Language: en-GB,en;q=0.9,fr-FR;q=0.8,fr;q=0.7,th-TH;q=0.6,th;q=0.5,en-US;q=0.4
This happens with android clients, but not with desktop browsers!?
recv call immediately after the empty peek shows that the data is there waiting to be read!?
This is a kernel / distro bug. Every other distro works just fine. Tested: Ubuntu 18.04, Ubuntu 19.10, Debian Stretch, Debian Buster, etc..
The problem only occurs on Fedora 30 and 31. (Not tested Fedora 29 or earlier). And also with MS Windows servers!
Things I've tried:
... Why do we reset the connection!? We're actually doing a recv when that happens!?
Also happens with v3.
make all sockets peekable
The patch above uses the same workaround that is used with ssl sockets: emulate peek by actually reading from the socket (without PEEK) but cache the data and return it later. (also uncomment
enable_peek() to use it)
Does not always help. No idea why.
wireshark capture of a failure
r27660 logs more details of connection timeouts.
I really don't understand why this makes any difference, but r27662 fixes things. (at least I haven't been able to reproduce the bug with the Android tablet or mswindows browsers)
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2587