Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose netif DNS setting functions #495

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Conversation

jothan
Copy link
Contributor

@jothan jothan commented Sep 29, 2024

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
Copy link
Collaborator

ivmarkov commented Oct 1, 2024

@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
Copy link
Contributor Author

jothan commented Oct 1, 2024

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
Copy link
Contributor Author

jothan commented Oct 1, 2024

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
Copy link
Collaborator

ivmarkov commented Oct 1, 2024

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
Copy link
Collaborator

ivmarkov commented Oct 1, 2024

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
Copy link
Contributor Author

jothan commented Oct 1, 2024

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
Copy link
Contributor Author

jothan commented Oct 1, 2024

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

@ivmarkov
Copy link
Collaborator

ivmarkov commented Oct 1, 2024

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
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
Copy link
Contributor Author

jothan commented Oct 1, 2024

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
Copy link
Contributor Author

jothan commented Oct 1, 2024

Unless that IP is subnet.gateway ????

@jothan
Copy link
Contributor Author

jothan commented Oct 1, 2024

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
Copy link
Collaborator

ivmarkov commented Oct 1, 2024

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