Luci-app-wireguard + QR generation

You assume that there's a DNS server running in the /24 subnet configured on the OpenWrt-side of the connection:

  1. That's a bad assumption
  2. That's not always the case
  3. How does the software determine which of the 254 IPs to use?

e.g.

  • Cloudflare WARP is configured to use 1.1.1.1 as DNS
  • Other companies use a 10.x.x.x IP for their DNS - not in the same subnet configured for the peer
1 Like

What do you define by that line with that IP and /24 suffix? I just want to make sure that we both understand WG background?

Sure, it is not. But it is possible to reduce one's headache and check if DHCP is up and running. One line of code is enough.

I don't understand your question.

It seems like you assume a DNS server must exist within a subnet - that's not the case.

What code, on the Android?

  • Are you now assuming that the peer is allowed to scan the /24 on port 53/udp or something?
  • This still assumes that a DNS server happens to exist on the same subnet as the Wireguard's interface is configured

How would this work in the intended use case quoted here (i.e. moving existing Wireguard configs)?

I believe default DHCP can be determined easily inside LAN? This is the one should be used in QR code by default. Wanna something else? Add checkbox like it was already done with IPs. Same approach just extend it a bit to make user's life easier.

I believe one uci request can clear it up.

We're going in circles:

Wireguard doesn't have DHCP, we've discussed that already.

  • I thought we were discussing the DNS setting on the Android, not the OpenWrt?
  • I don't understand how this helps with a QR Code, unless you incorrectly assume the peer can reach some DNS server configured on an OpenWrt interface - that's a bad assumption too

I haven't changed my opinion at any point. I've always agreed you can make a good guess at what the IP address of the 'client' will be where the allowed IP on the 'server' is a single address. But I've never stated it would be a certainty for that to be correct.

Also, none of that changes the simple fact that it only works for one specific use case. It doesn't a provide a solution for any other use case and could lead to incorrect information being provided in those cases.

As much fun as this back and forth is, the only way you can reliably determine what the correct IP address and DNS server on the 'client' should be is for that information to be manually entered at some point. Now you could either do that before the QR code is generated or after the code has been used on the client, but in both cases the user has to add the information. So does it really matter in any real sense as to which way round it is? (or to put it another way, why should a developer invest time into developing a solution for something that really isn't a problem?)

2 Likes

Ah-h... forget it. Why would anyone expect from QR just to work in Linux world? We are talking about code running with root privileges on a router and we just CAN'T check if DHCP server is configured or /32 (/128) is used in that IPs line... Way to hard to integrate OpenWRT server with native Wireguard app.

The QR Code generation works for me I use it all the time to migrate the config from OpernWrt to the Wireguard mobile app. Perhaps you're using it for a use case it wan't intended for. :wink:

You just described a use case the QR Code wasn't intended for:

Again to be clear, the use case is not intended as an OpenWrt WG Server.

I guess we're talking about Android again and not OpenWrt (which is also native software).

Not only it would be correct, more, it would be the only way it works with that configuration. And in that scenario we can generate QR code that just works.

Well done, we all agree it would probably work in that one specific use case. No-one has been disputing that, so I don't know why you keep banging on about it... Now what about all the other use cases? You can't (or shouldn't) introduce a solution that not only doesn't work for anything other than specific scenarios, but has a good possibility of actively introducing problems into other use cases.

1 Like

Let's be more detailed from this moment. What WG client is satisfied by QR generated by luci-app-wireguard?

What the hell? This is the case Wireguard app expects for. It expects IP address in QR code.

Yet it doesn't throw up an error when it's missing from the QR code... Maybe it's not that much of an expectation...

Because this is the case why I started this thread... This is why, man. I don't know why you started trying to convice me that other cases exist.

Imagine me guessing that address with 0.0.0.0/0 as the only iformation I've from that useless QR code. Thanks god it provided keys.

I don't understand the question - unless I also consider your incorrect assumption that a Layer 3 connection needs a DNS server specified.

Without that assumption - the answer is all of them.

An IP address is provided in the QR config.

Are you I think you're purposely confusing "DNS address" and "peer IP" to introduce confusion?

I'm totally lost at this statement unless it refers to the cryptokey routing.

Because those use cases exist and any solution in OpenWRT has to cater for those. Believe it or not, but it's not all about you.

Some might argue that's the most important bit to transfer accurately.

2 Likes

Words of a man who didn't even care to read configuration lines carefully enough.