From: Denis Kenzior <denkenz@gmail.com>
To: iwd@lists.01.org
Subject: Re: [PATCH 12/13] ap: add support for DHCPv4 server
Date: Tue, 20 Oct 2020 13:51:39 -0500 [thread overview]
Message-ID: <b111caae-01da-a122-0ba0-afb024baa384@gmail.com> (raw)
In-Reply-To: <a936dd184b0054d7b2c295fd92c3af2f022b4c93.camel@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2784 bytes --]
Hi James,
On 10/20/20 1:41 PM, James Prestwood wrote:
> On Tue, 2020-10-20 at 13:28 -0500, Denis Kenzior wrote:
>> Hi James,
>>
>> On 10/20/20 1:02 PM, James Prestwood wrote:
>>> The DHCP server can be enabled by including an [IPv4] group
>>> in the AP provisioning file and including at least a subnet
>>> mask.
>>
>> Any chance we can add this code to the current implementation without
>> changing
>> the API just yet? I think it is safe to assume that if the address
>> is set prior
>> to AP starting on a given interface, then we should not start our own
>> DHCP, and
>> if the address isn't set, then start DHCP server. If the address is
>> provided by
>> provisioning, then start our own DHCP as well, overriding whatever we
>> picked.
>
> Sure, so keep the 'psk' DBus argument and remove [Security].Passphrase?
> It seems weird to have both since we would be ignoring one.
I don't know yet. I don't think removing the simple 'Start' method which just
provides an SSID and PSK is a good idea. It is useful for quick and dirty
setups. Provisioning files might be for more advanced users and might need
their own dedicated Start method. So something like KnownNetwork(s) but for
AccessPointConfiguration(s).
>
> But do we really want to make the decision to use DHCP based on if the
> address is set? It really seems like the user would want to decide that
> explicitly with a config file. OTOH if all no DHCP options are required
> (using defaults) we would need some way of knowing to start DHCP or
> not. I just don't see a correlation between the address being set and
> the user wanting/not wanting a DHCP server.
Well, the user has to first switch the device into AP mode or create the
required interface first somehow. So before they actually hit .Start, they have
a chance to configure the IP or not. If the IP is configured, then we assume
the interface is managed by someone else. If it isn't, we take ownership.
I suppose we can add an explicit setting in main.conf somewhere, or in the
profile itself. But I'd keep things simple for now.
>>
>> I think we may need Andrew's opinion on whether these should be part
>> of
>> ap_config. P2P might not really care about setting up these
>> variables and would
>> prefer for ap.c to just figure things out.
>
> Sure, but they aren't required anyways so p2p doesn't have to include
> them and defaults will be used (once netmask is fixed). The ap_config
> structure was just a convenient storage object for these but we could
> define something else too.
Yes, true. But not much sense in actually storing them long-term if that's the
case. Generate them / load from settings, give them to dhcp-server and forget.
Regards,
-Denis
next prev parent reply other threads:[~2020-10-20 18:51 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-20 18:02 [PATCH 01/13] auto-t: no hostapd instance graceful failure James Prestwood
2020-10-20 18:02 ` [PATCH 02/13] auto-t: add copy_to_ap utility James Prestwood
2020-10-20 18:02 ` [PATCH 03/13] auto-t: simplify copy_to_hotspot James Prestwood
2020-10-20 18:02 ` [PATCH 04/13] storage: allow NULL type on storage_network_ssid_from_path James Prestwood
2020-10-20 18:30 ` Denis Kenzior
2020-10-20 18:02 ` [PATCH 05/13] storage: add storage_get_ap_path James Prestwood
2020-10-20 18:02 ` [PATCH 06/13] ap: refactor AP to use provisioning files James Prestwood
2020-10-20 18:02 ` [PATCH 07/13] doc: update AP docs with new Start() arguments James Prestwood
2020-10-20 18:02 ` [PATCH 08/13] ap: remove 'psk' from Start() James Prestwood
2020-10-20 20:19 ` Andrew Zaborowski
2020-10-20 20:27 ` James Prestwood
2020-10-20 18:02 ` [PATCH 09/13] auto-t: update start_ap() to remove psk argument James Prestwood
2020-10-20 18:02 ` [PATCH 10/13] auto-t: update AP tests with provisioning files James Prestwood
2020-10-20 18:02 ` [PATCH 11/13] build: add ELL dhcp-util.c to build James Prestwood
2020-10-20 18:02 ` [PATCH 12/13] ap: add support for DHCPv4 server James Prestwood
2020-10-20 18:28 ` Denis Kenzior
2020-10-20 18:41 ` James Prestwood
2020-10-20 18:51 ` Denis Kenzior [this message]
2020-10-20 20:48 ` Andrew Zaborowski
2020-10-20 21:03 ` Denis Kenzior
2020-10-20 21:41 ` Andrew Zaborowski
2020-10-20 18:02 ` [PATCH 13/13] auto-t: add AP test with DHCP server James Prestwood
2020-10-20 18:32 ` [PATCH 01/13] auto-t: no hostapd instance graceful failure Denis Kenzior
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b111caae-01da-a122-0ba0-afb024baa384@gmail.com \
--to=denkenz@gmail.com \
--cc=iwd@lists.01.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox