Since sockets are buffered `QIODevices` we can use `canReadLine()` to check
if we have a full line, instead of using a custom `SocketLineReader` class
(and the copy-pasted `DeviceLineReader` in the Bluetooth backend).
We can also loop through all the lines instead of queuing calls to `dataReceived`.
And we don't need transactions.
argument
Previously the BluetoothDeviceLink::certificate() method was returning a
value initialized object which I believe default initializes the object.
However, Clang throws a build error at this because QSslCertificate has
explicit constructors. This change uses one of those constructors and
uses value intialization to default construct/initialize the argument
for it. It fixes the build and hopefully doesn't break anything since
this is a TODO anyways!
BUG: 469428
Signed-off-by: Ali Abdel-Qader <abdelqaderali@protonmail.com>
This whole code was no-op: it enumerates network interfaces, enumerates
its IP addresses, but does not change the address of broadcast UDP
packet, sending it only via default route/interface.
Bind the socket to IP addresses of the interfaces to fix the issue.
BUG: 459171
This is the proper way to communicate progress.
It has Plasma show the file name in case of single files
and "n of m files" as before for multiple files.
On FreeBSD 12 or later, a new routing strategy is introduced, which
prevents broadcast using 255.255.255.255.
Thus, we need to explicitly send the broadcast to each network
interfaces.
Here the commit can simply reuse the code for Windows.
Ref: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252596
Detect the MTU on macOS and FreeBSD (which share the network parts of FreeBSD) and adaptively remove the outgoing and incoming capabilities.
The incoming capabilities are usually shorter, fit the size and help initialize the plugin list on the peer. This should fix an empty plugin list when the identity packet is sent by the macOS app.
If the MTU is still too short, both the capabilities need to be removed, which is not likely to happen.
Consider the following scenario:
1. We send a UDP broadcast
2. We receive a reply from 192.168.0.1 with device ID "foo"
3. We connect to 192.168.0.1, and find that the device's certificate
is actually for a different ID "bar". This could be because the
packet did not actually originate from 192.168.0.1, or this host is
malicious / malfunctioning.
4. We remember that device ID "foo" has certificate with common name "bar".
5. When we finally attempt to connect to the real device ID "foo", we
reject their certificate (common name "foo"). We can now never
successfully connect to "foo".
On some network (mis-)configurations, this completely prevents
kdeconnectd from connecting to any peers, because a reply which is
seen as originating from the local interface address will cause
kdeconnectd to immediately connect to itself and remember its own
certificate.
Address this by using the certificate display name of the peer, which
will match the real device ID.
The key is a sha256 of both devices' certificates. Both should generate the
same key, so hey user can check they are pairing against the right device.
Thanks Matthias Gerstner <mgerstner@suse.de> for reporting this.
The package will arrive eventually, and dataReceived will be emitted.
Otherwise we just end up calling dataReceived to no end.
Thanks Matthias Gerstner <mgerstner@suse.de> for reporting this.
Healthy identity packages shouldn't be that big and we don't want to
allow systems around us to send us ever humongous packages that will
just leave us without any memory.
Thanks Matthias Gerstner <mgerstner@suse.de> for reporting this.
## Summary
LanLinkProviderTest fails on Windows. This patch fixes that.
I believe the root cause is that we are using a shared UDP socket to listen for identity broadcasts both in the LanLinkProvider and in the test. Apparently this works on Linux, but on Windows the LanLinkProvider picks up its own identity packet and pairs with itself.
This patch gives a parameter to LanLinkProvider to allow it to listen and broadcast on different ports, then uses that ability in the test to make the test pass on Windows.
## Test Plan
### Before:
lanlinkprovider test fails, first because it can't bind its UDP listener socket, and then because Windows seems to handle shared sockets differently than Linux, so the UDP broadcasts were not reaching the test's listener.
### After:
lanlinkprovider test seems to pass reliably both in my Windows VM and in the CI
Summary:
As mentioned on telegram, there are some fundamental issues with bluetooth. The only approach I could get working was multiplexing: manually sending multiple streams of data over a single connection.
This is the description of that multiplexing protocol. I have an implementation of this protocol, but I'd first like some feedback to see if this is what we're going to use before finishing up those patches.
See the document itself for more details. I make the protocol forward-compatible, although I don't expect we will need ever that.
Test Plan: None, this is just a description.
Reviewers: #kde_connect, andyholmes, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: albertvaka, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D17987
Summary:
When android closes the payload socket (cancel share) calling m_socket.close() results
in a recursive call to onError eventually leading to a segmentation violation
Test Plan:
Install D16491, share a large file from desktop to android and cancel the share on Android through
the notification. kdeconnectd crashes almost 100% of the time. (It doesn't crash when it detects
a disconnect in sendNextPacket)
Reviewers: #kde_connect, nicolasfella
Reviewed By: #kde_connect, nicolasfella
Subscribers: kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D17628
Summary: If the identity packet is split across two packets, then save it until we get a notification that more data is available for reading over the bluetooth link.
Test Plan: Connect a phone and laptop over Bluetooth, and verify that both the phone and laptop are able to see each other, and that either side can start and successfully go through the pairing process.
Reviewers: #kde_connect, mtijink
Reviewed By: #kde_connect, mtijink
Subscribers: mtijink, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D17789
Summary:
Combine multiple upload jobs for files into a single KCompositeJob so only 1 notification will be shown
Includes changes introduced in D16279
Test Plan:
1. Share of multiple files is performed using 1 composite job
Setup:
- Select multiple (big) files in dolphin and share with an Android device
Result:
- The files will be transferred using 1 CompositeUploadJob and showing only 1 notification
2. Share of file while another share is already running adds job to existing composite job
Setup:
- Select multiple (big) files in dolphin and share with an Android device
- Share an additional file with the same Android device
Result:
- The files are all transferred using 1 CompositeUploadJob and showing only 1 notification
- The notification is updated after adding the last file
3. Other packets are transmitted as usual
Setup:
- Setup sharing desktop notification with device
- Share a big file with an Android device
- Generate a desktop notification (eg. sending or receiving an email)
Result:
- Notification packet is send immediately
Reviewers: #kde_connect, nicolasfella, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: albertvaka, apol, nicolasfella, broulik, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D17081
Summary:
Show progress when sending a file from the desktop
BUG: 355044
Test Plan:
Complete transfer:
-Right click on a big file in dolphin
-Select Send to xx via KDE Connect
-Open the Notifications widget and verify progress is shown correctly
Stop transfer:
-Right click on a big file in dolphin
-Select Send to xx via KDE Connect
-Open The Notifications widget and press the stop/kill button
-Observe that the file upload is stopped
Reviewers: #kde_connect, nicolasfella
Reviewed By: #kde_connect, nicolasfella
Subscribers: apol, broulik, nicolasfella, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D16279
Summary:
No need to emit newConnection in Server::incomingConnection because QTcpServer will emit it after incomingConnection returns
QTcpServer also already has a list of pending connections so use that
Test Plan: Send a file from desktop to android and observe that newConnection is only called once
Reviewers: #kde_connect, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D17009
Summary: Why cast sender() to server when we have m_server
Reviewers: #kde_connect, apol
Reviewed By: #kde_connect, apol
Subscribers: kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D16760
Summary: This is not a hugely important change. I noticed it while I was working on something else, and it seems like it ought to be this way
Test Plan: Nothing should be noticeably different
Reviewers: #kde_connect, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: apol, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D16468
Summary:
Main change is to use libkeepalive to wake up the system to ensure connections stay alive
Other minor changes are:
-Log daemon messages for debugging purposes
-Add way to forece refresh of device list
-Minor spec improvements
The keepalive changes certainly seem to help, not sure if it completely solves the problems
The logging changes are temporary, and I could use them locally, but they only affect sailfish users
Im not sure if the refresh method is correct, but seems to force the daemon to check for devices
Reviewers: #kde_connect, nicolasfella, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D15414
Summary:
This fixes receiving payloads using the bluetooth backend.
This looks like some bug in Qt, but I couldn't figure out what happens exactly (will report a bug though).
Test Plan: Receiving files now works!
Reviewers: #kde_connect, apol
Reviewed By: #kde_connect, apol
Subscribers: kdeconnect, nicolasfella, apol, #kde_connect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D12153
