Skip to content

Expose netif DNS setting functions - #495

Open
jothan wants to merge 3 commits into
esp-rs:masterfrom
jothan:set-dns
Open

Expose netif DNS setting functions#495
jothan wants to merge 3 commits into
esp-rs:masterfrom
jothan:set-dns

Conversation

@jothan

@jothan jothan commented Sep 29, 2024

Copy link
Copy Markdown
Contributor

I'm using this to make a captive portal using the DNS method (edge_captive made it really simple).

I need this for captive portal use.
I already had a homemade wrapper around this, throwing it into this PR.
@ivmarkov

ivmarkov commented Oct 1, 2024

Copy link
Copy Markdown
Collaborator

@jothan Just to make sure I understand the need for this:

In general, the EspNetif API was created with immutability in mind first (though we are slowly drifting away from that).
What I mean by this, is that you choose - upfront - prior to the creation of the netif, what configuration it is going to have, by using a NetifConfiguration struct.

This struct has a variant, Router(RouterConfiguration) that has the DNS fields you are trying to set. While it does not have the hostname field, I'm actually not even sure why you need it, given that hostname is only useful in the presence of DHCP, and only for clients, which want to register themselves in the DHCP server under that hostname, if the DHCP server happens to do local DNS resolution too.

So, would you elaborate why do you need to have these APIs as public in the first place?

@jothan

jothan commented Oct 1, 2024

Copy link
Copy Markdown
Contributor Author

I want the DHCP client hostname to contain the device name and a part of the serial number.

For the DNS, it is my understanding that the primary DNS of the AP interface is sent out by the DHCP server to clients to use as their DNS. I want the clients to use the ESP32 as DNS server to redirect them via captive portal techniques to the configuration page.

Hope that explains my use cases.

@jothan

jothan commented Oct 1, 2024

Copy link
Copy Markdown
Contributor Author

Also, the netif is created by the Wi-Fi calls. Should I create the interface configuration I want and hot-swap the netif in ?

@ivmarkov

ivmarkov commented Oct 1, 2024

Copy link
Copy Markdown
Collaborator

Hope that explains my use cases.

It does. However it does not explain, why you need mutating operations to achieve this. Namely:

I want the DHCP client hostname to contain the device name and a part of the serial number.

Sure. Just use a NetifConfiguration instance where ip_configuration is set to Some(ipv4::Configuration::Client(ClientConfiguration::Dhcp(DhcpClientSettings { hostname: <your-host-name>})))?

Note that the hostname you are setting on the netif anyway only has any use when you use a DHCP configuration, and in no other cases. I.e. using a statically configured IP and hoping that somehow your esp client will be pingable by its hostname is just not possible. For such cases, the only solution is mDNS (but then you don't need the router to serve as a DNS proxy anyway).

For the DNS, it is my understanding that the primary DNS of the AP interface is sent out by the DHCP server to clients to use as their DNS. I want the clients to use the ESP32 as DNS server to redirect them via captive portal techniques to the configuration page.

Assuming your clients use DHCP, they will use whatever DNS the DHCP server sends them. So you need to configure the DNS IPs on the router. Wouldn't a router ip_configuration set to Some(ipv4::Configuration::Router(RouterConfiguration { dns: Some(<your-router-ip>), ...})) work?

@ivmarkov

ivmarkov commented Oct 1, 2024

Copy link
Copy Markdown
Collaborator

Also, the netif is created by the Wi-Fi calls. Should I create the interface configuration I want and hot-swap the netif in ?

Hot-swapping is one option, but we also have EspWifi::wrap_all for that purpose.

@jothan

jothan commented Oct 1, 2024

Copy link
Copy Markdown
Contributor Author

I mostly use the DHCP hostname because it makes my devices easy to spot in the DHCP server log and Wi-Fi access point page. I also consider it a courtesy to customers for network admin reasons.

I did not know wrap_all existed, I'm going to have a look at it and report back on my use cases.

@jothan

jothan commented Oct 1, 2024

Copy link
Copy Markdown
Contributor Author

Is there a way to grab the STA mac address before using the wrap_all call ?

@ivmarkov

ivmarkov commented Oct 1, 2024

Copy link
Copy Markdown
Collaborator

Is there a way to grab the STA mac address before using the wrap_all call ?

Can't recall off the top of my head, but for setting the MAC I think we have a mutating method on EspNetif? (As I said, we are slowly drifting towards mutation.)

@Vollbrecht

Copy link
Copy Markdown
Collaborator

Is there a way to grab the STA mac address before using the wrap_all call ?

If you know the base mac address, its always the same schema. STA is always +0 offset.
You can get it via the esp_read_mac() function

@jothan

jothan commented Oct 1, 2024

Copy link
Copy Markdown
Contributor Author

Ok, so I'm getting the default AP netif config like this:

let mut ap_cfg = NetifConfiguration::wifi_default_router();

Nowhere in that struct do I have a way to get the IP that will be assigned to the ESP32 SoftAp. I would like to fill https://docs.esp-rs.org/esp-idf-svc/esp_idf_svc/ipv4/struct.RouterConfiguration.html with this IP.

@jothan

jothan commented Oct 1, 2024

Copy link
Copy Markdown
Contributor Author

Unless that IP is subnet.gateway ????

@jothan

jothan commented Oct 1, 2024

Copy link
Copy Markdown
Contributor Author

Ok, so I managed to do what I need to do using the mainline esp-idf-svc. I did the manual chain with configuration of going from Driver to AsyncWifi, which is non-obvious but got me what I needed.

I also managed to grab the STA MAC from WifiDriver in that chain.

Should we close this PR then ?

@ivmarkov

ivmarkov commented Oct 1, 2024

Copy link
Copy Markdown
Collaborator

Ok, so I managed to do what I need to do using the mainline esp-idf-svc. I did the manual chain with configuration of going from Driver to AsyncWifi, which is non-obvious but got me what I needed.

I also managed to grab the STA MAC from WifiDriver in that chain.

Should we close this PR then ?

Let me think about this overnight. Not sure - would it work in all cases?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants