[PATCH v2 2/4] HS20: Add support for configuring frame filters

[Peer, Ilan]

> -----Original Message-----
> From: Jouni Malinen [mailto:j at w1.fi]
> Sent: Monday, March 21, 2016 20:36
> To: Peer, Ilan
> Cc: hostap at lists.infradead.org; Gottlieb, Matti
> Subject: Re: [PATCH v2 2/4] HS20: Add support for configuring frame filters
> 
> On Mon, Mar 21, 2016 at 08:21:45AM +0000, Peer, Ilan wrote:
> > That's coming from the HS20 rel. 2 specification, section 6.5 that
> > states "Once the mobile device has associated to an HS2.0 network and
> > obtained an IP address, the mobile device ..."
> 
> Yes, I know where it comes from, but I cannot figure out why there would be
> such a constraint there..
> 
> > The motivation was to adhere to the "IP assignment" requirement. I do
> > not think that this would be a real issue as the port is not yet
> > authorized, so lower driver should not pass any IP packets anyway.
> 
> If we need to adhere to that requirement, wpa_supplicant would need to
> register for IP address change events and do this based on those. If we want
> to do this, we can, but I'm not sure we want.. I would either select to do this
> when starting the connection (which makes sense to me) or do this in a
> manner that is compliant with the specification (which someone would need
> to explain to me). I don't see much point in doing something in the middle that
> is neither compliant nor technically justifiable (i.e., it looks like it was just
> convenient to do this after 4-way handshake is completed for the first time in
> the association).
> 

Maybe it was stated so as there was some assumption that unicast IP packets cannot/won't
be received before an IP address has been assigned. If this is the case it makes sense to ignore
this and start the filtering when starting the connection.

> > I'll move the clearing of the flags as you suggested, and also clear
> > these settings on interface de-init. Do you still want the setting of
> > the flags to be earlier although it does not adhere to the "IP assignment"
> requirement?
> 
> I'd want to decide this based on someone figuring out why the spec says what
> it says today.. I'll ask the task group if someone were to remember the reason
> for that or if there is any views on how this should really be done in devices.
> 

Will wait with the changes until this is clarified.

Regards,

Ilan.