bug: fails when Windows -> Linux

[hearthewind]

I am running Windows 11, Ubuntu 22.04 and Android 14.

I have multicast enabled, and use RQuickShare 0.10.2.

I can detect my Ubuntu device on my Android device, however, when I try to send anything to Ubuntu from Android, it fails.

I cannot detect my Ubuntu device on my Windows QuickShare app.

I tried to send some file from Ubuntu to WIndows, however, the received file on Windows will have a random file name, with '-' followed by a string of numbers, it will not be the same file name sent. The file extension will be lost as well. However, if we rename the file into the original extension, the file will still work.

Anyways, great work, I really have high hopes for this project, and I hope one day it works flawlessly.

[Martichou]

Hello @hearthewind ,

however, when I try to send anything to Ubuntu from Android, it fails

Any more details? Logs? Error message?

I cannot detect my Ubuntu device on my Windows QuickShare app.

Both on the same network and no firewall in between?

I tried to send some file from Ubuntu to WIndows, however, the received file on Windows will have a random file name, with '-' followed by a string of numbers, it will not be the same file name sent. The file extension will be lost as well. However, if we rename the file into the original extension, the file will still work.

That is bizarre.. maybe the Windows implementation is different... I don't have a Windows PC to analyze the packets unfortunately. Maybe someone with a Windows can check and try to fix this? I can help if needed, but help is welcome for that one.

[sarco3t]

Hello @hearthewind ,

however, when I try to send anything to Ubuntu from Android, it fails

Any more details? Logs? Error message?

I cannot detect my Ubuntu device on my Windows QuickShare app.

Both on the same network and no firewall in between?

I tried to send some file from Ubuntu to WIndows, however, the received file on Windows will have a random file name, with '-' followed by a string of numbers, it will not be the same file name sent. The file extension will be lost as well. However, if we rename the file into the original extension, the file will still work.

That is bizarre.. maybe the Windows implementation is different... I don't have a Windows PC to analyze the packets unfortunately. Maybe someone with a Windows can check and try to fix this? I can help if needed, but help is welcome for that one.

Hello @Martichou , I do have an windows PC and willing to help with the issue, if anyone will guide/help with analyzing packets

[MrCheatak]

I cannot detect my Ubuntu device on my Windows QuickShare app.

Having the same problem. Neither I can detect Windows machine, nor Windows machine can detect Linux. Firewall on Linux is disabled.
Windows 23H2. Linux distro Tuxedo OS, GLIBC 2.35, so i am using the legacy version.

[dephunk]

So I just tried this out.

My setup is Linux - SteamOS, Android (Pixel) and Windows 10 PC.

Sending/Receiving works both ways From Linux to Android & Android to Windows.
Sending from Linux to Windows works but sending from Windows to Linux does not, the Windows PC can see Linux but I never receive the notification on Linux to accept. Not sure what is happening here.

[SalmonSays]

I came here looking to see if there was an open issue for this- I'm experiencing it too: Stock Windows 11 PC install with SteamOS (Arch-ish) on a Steam Deck. Sending from SteamOS works but the file is renamed to a random number string and loses its extension. When sending from Windows to SteamOS, Windows can see the SteamOS recipient and makes an attempt to send but the SteamOS recipient never gets a confirmation to receive the file.

[EXTREMEGABEL]

I'm using the same setup (SteamDeck/Win11) (Using the official app from google on windows)
Sending from Deck to Windows the file arrives but with a seemingly random number as a filename
see files prefixed (deck to win)

(decktowin)desktop.log
(decktowin)steamdeck.log

in the win to deck direction it tries to connect but never really does
see wintodeck logs
(wintodeck)desktop.log
(wintodeck)deck.log

in both cases i sent a text file named test.txt containing text

Let me know if my redactions were to aggressive and or i could help with more files/data

[alexandru-g]

I'm just gonna pitch in here since starting another thread is pointless.

I can send files from Linux (Mint Wilma / Ubuntu Noble), but I can't receive them from the Windows host. And a weird thing is that the Windows and Linux entries appear multiple times in the other's window.

Both RQuickShare (Linux) and the Windows app (the official Google one) cand send and receive fine from Android.

[SalmonSays]

I was able to fix one half of this problem: sending from Linux to Windows.

Looking at rquickshare-master/core_lib/src/hdl/outbound.rs, I noticed that the PayloadHeader struct is missing some fields that Windows looks for when reconstructing the file.

Specifically, the file_name field was not being set when constructing the PayloadHeader during file transfer. This caused the Windows receiver to default to numeric filenames, as it didn't receive the original filename from the sender.

Here's the updated code with the fix:

let payload_header = PayloadHeader {
id: Some(current),
r#type: Some(payload_header::PayloadType::File.into()),
total_size: Some(curr_state.total_size),
is_sensitive: Some(false),
file_name: Some(
curr_state
.file_url
.file_name()
.unwrap()
.to_string_lossy()
.into_owned(),
),
..Default::default()
};

The file_name field extracts the original filename from curr_state.file_url using .file_name()

This uses .unwrap() to assume that a filename is present

Converts the filename to a UTF-8 String with .to_string_lossy().into_owned()

Assigns it to the file_name field wrapped in Some()

After applying this fix and recompiling the application, files sent from Linux to Windows now arrive with their correct filenames instead of random numeric junk. I still haven't looked into the send-stall when going the other direction.

[SalmonSays]

Re: Windows to Linux file transfers- I've set up some more detailed logging and it looks like the encryption key data is missing on the receiving end right after initiating a transfer. I suspect possibly this is an issue with an invalid string from non-utf8 encoded data? Still digging.

[Martichou]

A new release has been made with the changes from @SalmonSays.

Would it be possible for someone to report on what is still needed for this issue? :)

[EXTREMEGABEL]

I've tried 1.11.4 sending from linux causes the windows app to error out and the linux app to report a success
From log (Windows):
E0118 13:52:08.903686 30360 base_pcp_handler.cc:1846] Failed to parse incoming connection request; client=6889725494078666629; device=364b5158with error: 1

Sending to an Android device works though

in the reverse direction Receiving from Android works without problems Receiving from Windows works as long as the QuickShare app was started with Administrative privileges

RQuickShare.log

EDIT:
I've looked at the log output of the Win App again and noticed that the above Error message is consistently followed by a warning concerning the keep-alive frame
E0118 16:57:55.022866 9552 base_pcp_handler.cc:1846] Failed to parse incoming connection request; client=-196694337415509743; device=55553144with error: 1
W0118 16:57:56.520079 9552 base_pcp_handler.cc:1933] Incoming connection has wrong keep-alive frame interval=0, timeout=0 values; correct them as default.

Without any understanding of how the Protocol works: could this be related?

[SalmonSays]

I can confirm that v0.11.4 has broken functionality again between operating systems, I'll have to try adding some custom debugging when I have the free time to troubleshoot. My branch of v0.11.2 does not behave this way, so I'm assuming this is a result of some newly updated dependency/merged code?