udpsocket ready read not fired on arm64

[Alexander Lampret]

Hello,

I faced a problem where readyRead is not fired for QUdpSocket.
I've tested this functionality with a basic udp receiver on different systems.
On armhf it works fine, the same code does not work on arm64 (Pine64).

This seems to be similar to bug https://bugreports.qt.io/browse/QTBUG-48556 mentioned on QT site to be fixed with 5.5.1
Maybe it was not merged to arm64? Or any other idea?
netstat -l shows that bytes are available

With polling implementation it's possible to receive the data.

Ubuntu 16.04.1, all updates
Pine64, arm64
Kernel: 3.10.102-2-pine64-longsleep

Best regards,
Alex

[Timo Jyrinki (timo-jyrinki)]

All code is the same regardless of archs, but the commit mentioned there is Mac specific so those code paths are not used on Linux.

Another idea would be, if you don't mind adding and removing PPAs and possibly needing to start over with your rootfs (if something goes badly wrong), to try stable phone overlay PPA from: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/ - it includes Qt 5.6.1 which obviously has almost a year worth of newer fixes.

sudo add-apt-repository ppa:ci-train-ppa-service/stable-phone-overlay
sudo apt update
sudo apt dist-upgrade

To downgrade:
sudo apt install ppa-purge
sudo ppa-purge ppa:ci-train-ppa-service/stable-phone-overlay

Or you could simply try Ubuntu 16.10 which has the same Qt 5.6 version.

[Alexander Lampret (alamp4kf)]

Unfortunately, upgrading and recompiling did not solve the problem.

netstat -l RECV-Q shows bytes received but readyRead is not fired.
Im listening to port 3512 (for example), but nothing happens inside udp receiver test program.
I've added a possibility to send datagrams on 3512 in the same program. These "writeDatagram()" datagrams fire a readyRead event, as long as there are no other datagram from an external source are queued.

If I use a udp receiver written in python, for testing, it works like a charm

P.S: Sorry, wrong bug attached, there was one bug related to linux and this was a clone related to OSX.

[Alexander Lampret (alamp4kf)]

Fixed with newest kernel 3.10.104-1-pine64-longsleep