Re: [Interest] Strange socket problem. QTcpSocket. Windows/Linux
On 29/01/14 19:48, Guido Seifert wrote: Can you say what is happening at the TCP level? Are the packets being sent? Do they have the PSH flag set? Does the TV send back ACK packets? To tell you the truth, I don't know. This is normally a bit too low-level for me. More or less I moved on, because even if I had seen a problem within the TCP packets, I still would have been unable to fix it. If you are interested, I would start wireshark again and check for the PSH flag and ACK packets. But not before this weekend. I don't think it is a problem in my code or in Qt, else the E series should be affected, too. You might want to post links to some Wireshark/tcpdump captures here so that others can have a look. I'd suggest captures of it working and not working on the D series, and maybe it working on the E series, from whichever OS didn't work with the D. Hamish ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Strange socket problem. QTcpSocket. Windows/Linux
On terça-feira, 28 de janeiro de 2014 10:01:11, Guido Seifert wrote: After 3 - 10 resubscriptions the socket is dead. It takes data, seems to be in perfect working order, but the Samsung does not react. Same when I send play and stop UPnP commands. Works several times, then I get socket error -1. I can hammer the port, e.g. send the stop command a few dozen times. Can you say what is happening at the TCP level? Are the packets being sent? Do they have the PSH flag set? Does the TV send back ACK packets? Is the problem that it should be replying with data over the TCP connection, but isn't? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Strange socket problem. QTcpSocket. Windows/Linux
On quarta-feira, 29 de janeiro de 2014 09:48:44, Guido Seifert wrote: Can you say what is happening at the TCP level? Are the packets being sent? Do they have the PSH flag set? Does the TV send back ACK packets? To tell you the truth, I don't know. This is normally a bit too low-level for me. More or less I moved on, because even if I had seen a problem within the TCP packets, I still would have been unable to fix it. If you are interested, I would start wireshark again and check for the PSH flag and ACK packets. But not before this weekend. I don't think it is a problem in my code or in Qt, else the E series should be affected, too. Well, the point is that we'd be able to rule it as a TCP stack problem or not. If it isn't a stack problem, then it's something that either Qt or you are doing, which might have feasible solutions. Is the problem that it should be replying with data over the TCP connection, but isn't? Yes. When I do a QTcpSocket::write(const QByteArray byteArray) the correct number of bytes written is returned. That number is not relevant. QTcpSocket is fully buffered, so it always accepts as many bytes as you've given it. That number is only telling you that those bytes got buffered properly. Do you get bytesWritten(qint64) emitted with a total count equalling that number of bytes? Alternatively, if you loop as while (socket-bytesToWrite() socket-waitForBytesWritten()) ; Do you eventually get to bytesToWrite() == 0? Or does it time out trying to write? Since the OS TCP stack is *also* buffered, that only means the bytes got copied from userspace to the kernel (though, unlike QTcpSocket, the kernel buffers are not unlimited). If you get to bytesToWrite() == 0, the question is whether the other side is receiving them. You can find that out by running ss or netstat: E.g.: $ netstat -nt Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp0112 10.24.4.51:4774510.7.211.16:1080 ESTABLISHED The above is showing that my machine has 112 bytes in the send-queue yet to send the remote. Does the number go to zero? Or does it remain? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Strange socket problem. QTcpSocket. Windows/Linux
On 27 Jan 2014, at 4:38 PM, Thiago Macieira wrote: That's why companies are moving away from custom or specialised embedded OS to just running Linux on their hardware. Do we know that Samsung didn't do that? (except that if they had, it would probably work well ;-) Anyway, if you are already researching with wireshark, you can find some uPnP software that does work with that TV, and see what is different. If you're lucky it might be a matter of a packet size limit or something like that. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Strange socket problem. QTcpSocket. Windows/Linux
Do we know that Samsung didn't do that? (except that if they had, it would probably work well ;-) Actually it is a Linux that is running in Samsung TVs. Maybe it is not the firmware, but the hardware? Anyway, if you are already researching with wireshark, you can find some uPnP software that does work with that TV, and see what is different. If you're lucky it might be a matter of a packet size limit or something like that. I did. But compared only the human readable part. This is definitely correct. Apart from that, my UPnP code works with Samsung E and F and XBMC and bubbleUPnP on Android. Only the Samsung D series has this problem. Did not test C series, yet. So where ever this problem is located, it is on a lower level to which I don't have access. It is a normal tcp connection via QTcpSocket and QTcpSocket does not have that many parameters, which I can tweak. And the few there are, are already tried in all possible permutations. No effect at all. Even if I knew what the difference between a socket initiated by Linux and one by Windows I probably would not be able to fix anything. It looks like the code seems to work a couple of times, but to receive UPnP events, the eventing must be resubscribed in a regular interval. 5 min fix on Samsung TVs. After 3 - 10 resubscriptions the socket is dead. It takes data, seems to be in perfect working order, but the Samsung does not react. Same when I send play and stop UPnP commands. Works several times, then I get socket error -1. I can hammer the port, e.g. send the stop command a few dozen times. After a while it starts working again for a few commands, then it fails again. While the necessary interval for eventing resubscriptions is fix, I am free to choose the rate in which I send the play or stop commands. The failure trigger definitely does not depend on the time between two commands. It seems to happen randomly. Guido ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Strange socket problem. QTcpSocket. Windows/Linux
On segunda-feira, 27 de janeiro de 2014 07:35:05, Guido Seifert wrote: On Window the D series behaves strangely. I send a UPnP command to it and it responds... or not. Totally unreliable. Very often I get a very unhelpful error message: QAbstractSocket::error = -1. I can hammer the socket with the same data and sometimes I get after a while the correct response. Now I checked with wireshark. Windows and Linux send exactly the same data. At least the ascii part, which is the UPnP command. The data itself is correct. As I said: It always works for the E series and from Linux it also works for the D series. There must be something different how QTcpSocket opens a connection from Windows and from Linux. Any ideas? My guess is that the TCP/IP stack on the D series TV is broken and is somehow failing to deal with the packets from the Windows machine. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Strange socket problem. QTcpSocket. Windows/Linux
My guess is that the TCP/IP stack on the D series TV is broken and is somehow failing to deal with the packets from the Windows machine. Yes, do you know if there is anything I can do? I don't see many options in QTcpSocket. What could be the difference between a Windows and a Linux socket? What I find interesting is that I have no problem with the stream itself. But the streaming socket is initiated by the TV itself. I am also a bit irritated that I have the problem with Windows. If the connection with Linux was broken... heck, which company tests their products for Linux compatibility? But Windows... this should not have gone unnoticed. But this list is probably not the right place to discuss this. :-) Guido ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Strange socket problem. QTcpSocket. Windows/Linux
On segunda-feira, 27 de janeiro de 2014 10:24:22, Guido Seifert wrote: My guess is that the TCP/IP stack on the D series TV is broken and is somehow failing to deal with the packets from the Windows machine. Yes, do you know if there is anything I can do? I don't see many options in QTcpSocket. What could be the difference between a Windows and a Linux socket? What I find interesting is that I have no problem with the stream itself. But the streaming socket is initiated by the TV itself. If I'm right, then the problem has no solution inside Qt. It would imply trying to change something in the Windows socket stack to make it change how it sends the packets. This is just a guess. I haven't seen the network traffic you have. I'm going on what you said (the contents of the stream are identical) and the fact that if you remove the impossible, whatever remains, however improbable, must be the truth. If you remove the data, the only thing remaining is metadata and overhead. I am also a bit irritated that I have the problem with Windows. If the connection with Linux was broken... heck, which company tests their products for Linux compatibility? But Windows... this should not have gone unnoticed. My guess? They didn't test much at all. They got some stripped down TCP/IP stack from somewhere, did some initial tests and shipped the product. That's why companies are moving away from custom or specialised embedded OS to just running Linux on their hardware. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
