Re: [PATCH v4 2/4] dpp: initial version of PKEX enrollee support

[Denis Kenzior <denkenz@gmail.com>]

Hi James,

>> Since you're sharing the DPP state machine object between the two interfaces, 
>> it seems like starting PKEX on the SharedCode interface side-effects the state 
>> of the regular DeviceProvisioning interface?  I hope that's not intended?
> 
> Your right, it does. Once PKEX finishes it starts DPP on the DeviceProvisioning 
> interface. This was intended, but if we want to keep the two isolated I'll have 
> to change gears and think about how we can do it.

Ugh :)  This is something no-one but the person who wrote the code would expect 
to happen.  The interfaces should be kept separate.

Internal implementation wise, I think you probably can get away with a shared 
dpp state machine object, but you do have to track which 'interface' the state 
machine is actually bound to at the time.

> 
> May have to create a dpp_sm for each DBus interface not per-wdev/netdev, and 
> find some way of communicating which interface the property changed calls 
> correspond to.
> 

Well, there's always dpp_find or dpp_pkex_find.

> Apart from the string/cast comments the rest seem to revolve around the shared 
> state between PKEX/DPP. If separating them is the way we want to go I can do that.
> 

I didn't look super closely at the spec details, but what I saw seemed reasonable.

Regards,
-Denis