Failed to detect network devices.

[rjmalagon]

On AppImage version. It fails to recognize local network devices. The app itself works ok, and clients reach it without problems. But the "Not WiFi and LAN Connection" dialog is stuck and preventing to allow an incoming connection.

This dialog should be easy to skip or override.

TODO

write bug report template

[pavlobu]

Hi, thank you for submitting this issue. It may be because the third party JS library such as 'internal-ip' fails to get your specific network card configuration basic info, such as IP adress.

If you know how to fix it, please consider submitting a PR on this repo.

Cheers, Paul

[rjmalagon]

Maybe this hint can help you. My local network is IPV6 only.

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Sunday, January 24, 2021 6:20 PM, Pavlo Buidenkov notifications@github.com wrote:

Hi, thank you for submitting this issue. It may be because the third party JS library such as 'internal-ip' fails to get your specific network card configuration basic info, such as IP adress.

If you know how to fix it, please consider submitting a PR on this repo.

Cheers, Paul

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[pavlobu]

Ok, this is not supported at the moment, developed and tested on ipv4 for now, but you can submit a pr. Cheers

[ant0git]

Hello, I have the same problem but i don't use ipv6. I think it's because i have lots of network interfaces for work. (VPN, virtual machines, etc.) Maybe if we could chose the interface the issue would disappear ?

[pavlobu]

Hello, I have the same problem but i don't use ipv6. I think it's because i have lots of network interfaces for work. (VPN, virtual machines, etc.) Maybe if we could chose the interface the issue would disappear ?

Yes good Idea. We can add in UI for users to choose which interface they use for wifi or lan connection, or even type local IP address manually? This option should appear in 'sorry no internet' alert box in UI

[DeveloperMos]

The network device is not detected on vps. ~ eth0: public ip. Wanted to test on a dedicated server. if you can enter the address yourself or choose a network interface it will be cool. Can be used with nginx or wireguard for general networking. Through nginx, login by password or token. Forwarding to an internal address

[pavlobu]

Maybe this hint can help you. My local network is IPV6 only. Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ … On Sunday, January 24, 2021 6:20 PM, Pavlo Buidenkov @.***> wrote: Hi, thank you for submitting this issue. It may be because the third party JS library such as 'internal-ip' fails to get your specific network card configuration basic info, such as IP adress. If you know how to fix it, please consider submitting a PR on this repo. Cheers, Paul — You are receiving this because you authored the thread. Reply to this email directly, [view it on GitHub](#38 (comment)), or unsubscribe.

@rjmalagon Hey I have a fix for your issue, but you will need to rebuild a Deskreen package after code change

https://github.com/pavlobu/deskreen/blob/217499ddbc4bb2eb89c3dfb2bc24e7538cbf0e14/app/main.dev.ts#L29 Change to: const v4IPGetter = require('internal-ip').v6;

.v6 at the end

Firs install deps, like described in readme.md, Then recompile ot with: yarn package

It will generate a new deskreen app file, try to start it and see what happens. Should work. If is works please tell us here, ill be making a workaround in upcoming release

Cheers, Paul

[iam-TJ]

Confirming this is a failure when operating on IPv6-only networks. Additionally, a fix needs to take account of interfaces typically having two or more scopes for IPv6 addresses (link-local fe80::/16%, ULA fc::/7) as well a globally route-able.

[pavlobu]

guys, if you have a solution for this problem, your pr is welcome. I'm super busy recently, you will have to wait for that fix to come

[iam-TJ]

I develop, deploy, and run IPv6 only networks. I'm currently getting up to speed on this codebase with the aim of adding the required functionality.

[iam-TJ]

@pavlobu Initial review suggests that the package dependency on internal-ip may need to be replaced. The reason being it has a broken method of determining the correct IPv6 address to use.

It incorrectly uses the IPv4 methodology. Specifically, it uses the default gateway to determine which local IPv6 address to choose. However, a correctly configured IPv6 network uses a link-local scope (fe80::/16) address. internal-ip searches for the interface containing the default gateway (using package default-gateway) and will return an address with the same scope.

if (net[0] && net[0].kind() === gatewayIp.kind() && gatewayIp.match(net)) 

Secondly, every interface can potentially have its own default gateway so the choice needs to be intelligent. The obvious way is to attempt an outbound connection and discover which IPv6 source IP address is used.

Thirdly, on Linux internal-ip relies on the presence of the iproute2 package which, especially for the increasing use of containerised applications for desktop deployments, may not be available. See https://github.com/silverwind/default-gateway/issues/21

I'll first see if the publisher of internal-ip is still active and amenable to accepting patches. In parallel I'll add code locally to solve this automatic discovery issue.

Due to increasing use of dual-stack networks I'd suggest considering offering the operator a choice of IP address in the dialog when the application cannot determine with certainty the correct address to use.

Testing via a hostname connection would be a good way to determine the globally routeable address and family without needing to do any complicated determinations - and would work in DNS64/NAT64 networks (where the network is IPv6-only but internally the DNS server rewrites DNS records for IPv4-only destinations with IPv6 addresses which the gateway then does NAT6-to-4 on.

[pavlobu]

@iam-TJ great! you are on the right track

[juju4]

I have same problem but not IPv6 On Fedora-33 in Qubes (direct network access to router)

$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:16:3e:5e:6c:00 brd ff:ff:ff:ff:ff:ff
    inet 10.138.17.235/32 brd 10.255.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3eff:fe5e:6c00/64 scope link 
       valid_lft forever preferred_lft forever
$ rpm -qa |grep iproute
iproute-5.9.0-1.fc33.x86_64
iproute-tc-5.9.0-1.fc33.x86_64

Deskreen returns "No WiFi and LAN connection." install from current rpm deskreen-1.0.11.x86_64.rpm

[gw0]

I also stumbled upon this limitation in Qubes OS and got stuck at the "No WiFi and LAN connection" alert. The situation there is that qube VMs do not have direct network access to hardware (they use virtual eth0) which is probably causing the issue.

I just confirmed that the alert is just that an overlay window that can be disabled by commenting out app/containers/DeskreenStepper.tsx#L98-L111. The QR code will not work in this case and you will need to construct the correct URL for the browser manually.

Having an option to manually provide the IP could provide a workaround to all sorts of issues.

[ryuuzaki42]

Works great in Slackware

PATH=/usr/sbin:$PATH ./Deskreen-2.0.4.AppImage

https://github.com/pavlobu/deskreen/issues/185#issuecomment-1384903157

[HerryLeo]

@pavlobu Initial review suggests that the package dependency on may need to be replaced. The reason being it has a broken method of determining the correct IPv6 address to use.internal-ip

It incorrectly uses the IPv4 methodology. Specifically, it uses the default gateway to determine which local IPv6 address to choose. However, a correctly configured IPv6 network uses a link-local scope (fe80::/16) address. searches for the interface containing the default gateway (using package ) and will return an address with the same scope.internal-ip``default-gateway

if (net[0] && net[0].kind() === gatewayIp.kind() && gatewayIp.match(net)) 

Secondly, every interface can potentially have its own default gateway so the choice needs to be intelligent. The obvious way is to attempt an outbound connection and discover which IPv6 source IP address is used.

Thirdly, on Linux relies on the presence of the package which, especially for the increasing use of containerised applications for desktop deployments, may not be available. See silverwind/default-gateway#21internal-ip``iproute2

I'll first see if the publisher of is still active and amenable to accepting patches. In parallel I'll add code locally to solve this automatic discovery issue.internal-ip

Due to increasing use of dual-stack networks I'd suggest considering offering the operator a choice of IP address in the dialog when the application cannot determine with certainty the correct address to use.

Testing via a hostname connection would be a good way to determine the globally routeable address and family without needing to do any complicated determinations - and would work in DNS64/NAT64 networks (where the network is IPv6-only but internally the DNS server rewrites DNS records for IPv4-only destinations with IPv6 addresses which the gateway then does NAT6-to-4 on.

Hi, I only use deskreen in a wired LAN, the operating system is WIN10. I manually set IPV4, and then the problem still occurs. Finally, according to your description, I found that the gateway address must be set in the network adapter, I just manually set the IPV4 address and subnet mask before. After setting up the gateway, the application can be used normally.