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>
(cherry picked from commit bbac0aa085)
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
