"Add Second Device" doesn't work on Windows because of firewall sometimes

[WofWca]

• Operating System (Linux/Mac/Windows/iOS/Android): Windows 10
• Delta Chat Version: 1.36.1
• Expected behavior: The second device manages to connect to the sending instance of DC
• Actual behavior: Connection times out on the second device
• Steps to reproduce the problem:
  1. Install Delta Chat desktop (if you already have one, you may download the portable version)
  2. Install Delta Chat on another device (say, Android) (if you already have one, you can install an extra nightly one)
  3. On desktop, make sure you're logged in.
  4. On desktop, click "Settings" -> "Add Second Device" -> "Continue"
  5. On the second device, on the log in screen tap "Add as second device" and scan the QR code from the first device.
• Screenshots:
• Logs:

Debugging

The connection fails, unless you have added DC desktop in "Allow an app through Windows Firewall", or unless it was added there in another way, say through the Windows Firewall alert that can pop up when an app tries to listen on a non-localhost network interface.

The "Add Second Device" feature was added here deltachat/deltachat-core-rust#4007, and it uses iroh. The binding address is specified here, down to here, but it doesn't trigger the Windows Firewall alert popup, like it usually does with, say, a simple HTTP server app.

I have a suspicion that it may be related to the fact that DC listens for UDP packets, not TCP. iroh uses the QUIC protocol, which is UDP-based. I just tried

std::net::UdpSocket::bind(("0.0.0.0", 0))?;

And it did not trigger the alert, but with a concrete port ("0.0.0.0", 59999) the alert is triggered. And, again, yes, if you set up an TCP listener, say, with

std::net::TcpListener::bind(("0.0.0.0", 0))?

The alert does get triggered.

Possible solutions

• A simple hack would be to create another dummy (TCP) interface binding at the same time we create the real (QUIC) one, in order to trigger the Windows Firewall alert and let the user decide whether to allow DC through firewall (see fix: "Add Second Device" not working on Windows deltachat-core-rust#4351)
• @Simon-Laux and @flub pointed me to the windows-rs library that DC already depends on, namely these two functions 1, 2. But I myself am not sure how they work. I heard they may require elevation ("Run as administrator"). But not only it is a proper solution, I also suspect that it might actually be better because it might (based on my intuition) cause the Firewall alert to pop up a second time if network access was previously denied for the application.

[WofWca]

Edited the issue with the info about UdpSocket::bind().

[WofWca]

About the windows-rs solution.
With the help of microsoft/windows-rs#2466, I have created the following prototype app that adds a firewall rule. It doesn't cause any user prompts, just silently does its thing.

But the problem is that it fails unless you run it as admin.

• Maybe there is a way to make the firewall rule user-specific, so that it doesn't require elevation?
• Or, maybe it can be run when DC is being installed? Though IIRC elevation is only required when you install an app for all Windows users.
• Or maybe there is a way to invoke a user prompt that can allow DC to add the rule.

Code

use windows::{
    core::BSTR,
    Win32::{
        Foundation::VARIANT_BOOL,
        NetworkManagement::WindowsFirewall::{
            INetFwPolicy2, INetFwRule, NetFwPolicy2, NetFwRule, NET_FW_ACTION_ALLOW,
        },
        System::Com::{
            CoCreateInstance, CoInitializeEx, CLSCTX_INPROC_SERVER, COINIT_MULTITHREADED,
        },
    },
};

fn main() -> std::io::Result<()> {
    unsafe {
        CoInitializeEx(None, COINIT_MULTITHREADED)?;

        let fw_policy: INetFwPolicy2 = CoCreateInstance(&NetFwPolicy2, None, CLSCTX_INPROC_SERVER)?;

        let rule: INetFwRule = CoCreateInstance(&NetFwRule, None, CLSCTX_INPROC_SERVER)?;
        rule.SetApplicationName(&BSTR::from(
            "C:\\firewall-test\\target\\debug\\firewall-test.exe",
        ))?;
        rule.SetAction(NET_FW_ACTION_ALLOW)?;
        rule.SetEnabled(VARIANT_BOOL::from(true))?;
        rule.SetName(&BSTR::from("firewall-test.exe"))?;

        fw_policy.Rules()?.Add(&rule)?;
    }

    println!("Success!");
    Ok(())
}

[Simon-Laux]

can we check if the transfer would be blocked by the firewall? so that we can hint the user at what they need to do to fix it?

[link2xt]

There is a PR deltachat/deltachat-core-rust#4351, but I think this should be solved with a firewall rule without any user action if possible, so the user cannot accidentally block DC.

[WofWca]

A thing that wasn't mentioned: the alert pops up when you launch a webxdc app for the first time.
And apparently after each DC update of a Windows Store installation the state gets cleared (cause it's a new app every time I guess) the alert pops up again.

[Simon-Laux]

he alert pops up when you launch a webxdc app for the first time.

maybe because of fill500?

[WofWca]

That's right.
I couldn't disclose this back when I created this issue haha

[Simon-Laux]

A manual solution was shared in the forum: https://support.delta.chat/t/add-hint-select-on-windows-desktop-private-network-to-add-a-second-device/2921

maybe we should incorporate it into the local help / FAQ and add a trouble shoot button that links into the inApp Help? this could solve this issue without the need for us to understand those apis.

[r10s]

added a maybe sufficient hint at deltachat/deltachat-pages#799