All of lore.kernel.org
 help / color / mirror / Atom feed
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 16:03:05 -0500	[thread overview]
Message-ID: <82799cec-7d2a-a1fb-cbbb-f58a1a509b2c@gmail.com> (raw)
In-Reply-To: <CAOq732KJpw9Vz9t-4PFUSHiupdXPK56yjgBrVf_+ZFAfDrpXDA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2561 bytes --]

Hi Andrew,

>> 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.
> 
> Maybe we can re-use [General].EnableNetworkConfiguration for the basic
> on/off switch and possibly allow individual access point config files
> to override this?
> 
> In the case of Network Manager users, if they're interfacing with IWD
> through NM they will currently not want DHCP as either client or
> server, and if they use iwctl they might want DHCP everywhere.
> 
> Also for the record, NM only sets the local IP after the AP is started.
> 

Good points.  I'm fine re-using EnableNetworkConfiguration for this.

>>
>>>>
>>>> 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.
> 
> It does seem logical to put those settings in struct ap_config.  P2P
> wouldn't normally need to use them, it should be fine with the
> defaults although I'm thinking in the future there may be exceptions
> where we need to work around client's bugs (hopefully not).
> 
> Note that the P2P Group Owner will need to decide on an IP for itself
> and the client before the 4-Way Handshake starts to implement the
> optional IP assignment during the handshake.

Hmm, wouldn't it make sense for AP to figure out the setup and for P2P to just 
use that?  Especially if we start supporting persistent groups eventually.

You do bring up a good point that we'd need a 'reserve' API of sorts on the DHCP 
server side.  That way IP details for the handshaking client can be 
pre-populated if IP configuration through the handshake is supported.

Regards,
-Denis

  reply	other threads:[~2020-10-20 21:03 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
2020-10-20 20:48         ` Andrew Zaborowski
2020-10-20 21:03           ` Denis Kenzior [this message]
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=82799cec-7d2a-a1fb-cbbb-f58a1a509b2c@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.