[PW_SID:835030] Initial prep/skeleton for isolating core DPP protocol #329
Conversation
This is taken care of by the individual cache items and if none exist, tar fails.
The AAD pointers for DPP are specific to the frame type. This is currently sorted out by the caller within the respective frame building functions but its quite unreadable. There are some comments but lots of magic numbers. This should be moved within the dpp_append_wrapped_data utility but the first step is to make the frame buffer continuous. This will allow the entire frame to be passed and dpp_append_wrapped_data can calculate the AAD offsets itself.
Leaving it up to the caller to calcluate the AAD resulted in lots of magic values, and any comments associated are spread out within dpp.c. The AAD values can be calculated entirely by the frame contents so move that within dpp_append_wrapped_data. The caller now only needs to pass the frame (after the mpdu header), the length, and the offset to where the wrapped data should start. The new AAD calculation includes all relavent comments so magic offsets are documented. The reason the entire mmpdu_body is not passed to dpp_append_wrapped_attributes (and one byte further) is to future proof for DPP encapsulation using TCP. For this, the category byte is omitted and only the action byte and further is encapsulated. Having dpp_append_wrapped_attributes start at the action byte allows it to work regardless of 8021x or TCP encapsulation.
Any time DPP needs to append a point it has to use a temporary buffer to copy into, then copy that into the message buffer. Instead of this add a special purpose API to add the type/length then copy the data directly into the message buffer.
Use dpp_append_point where possible to avoid temporarily copying data
In order to expand the features for DPP e.g. TCP or a DPP controller the state machine needs to be both transport agnostic and buildable for other apps outside of IWD-core. To do this the core DPP state machine is being moved into a common module. The consumers of the common SM will create a dpp_sm object for each protocol run, and destroy it afterwards. The SM will take a write callback, event callback, the boostrapping keys, and expose a read handler: - The write callback will be called by the SM whenever there is a frame to be sent out. In order to support 802.11 encapsulation dpp_sm_set_write_handler can be used to notify the SM that writes are allowed or disallowed (by passing NULL). This is done to allow the 802.11 encapsulating module to prepare any offchannel requests before sending out frames. - The event callback is called by the SM whenever there are events requiring some handling by the encapsulating protocol, or when DPP has succeeded or failed. - The read handler can be called by the encapsulating protocol in order to RX frames to the SM. Making the SM common will allow both pure-802.11 DPP and DPP-over-TCP to utilize the same state machine. In addition a DPP-controller can now be implemented using the common SM but be entirely standalone from IWD.
|
Fetch PR Make Distcheck Build - Configure Make Check Make Check w/Valgrind Incremental Build with patches |
|
Fetch PR GitLint Make Distcheck Build - Configure Make Check Make Check w/Valgrind Incremental Build with patches Autotest Runner Clang Build |
github-actions
bot
force-pushed
the
workflow
branch
from
4170bb4
to
c067bc7
Compare
github-actions
bot
force-pushed
the
workflow
branch
4 times, most recently
from
f10f2fc
to
c2be9ec
Compare
github-actions
bot
force-pushed
the
workflow
branch
2 times, most recently
from
ebbbc93
to
089fa9a
Compare
github-actions
bot
force-pushed
the
workflow
branch
4 times, most recently
from
2192e98
to
43a07cc
Compare
github-actions
bot
force-pushed
the
workflow
branch
3 times, most recently
from
2c7b52e
to
58d64d4
Compare
github-actions
bot
force-pushed
the
workflow
branch
3 times, most recently
from
38fe7c3
to
68d5156
Compare
github-actions
bot
force-pushed
the
workflow
branch
from
68d5156
to
953fb5e
Compare
The AAD pointers for DPP are specific to the frame type. This is
currently sorted out by the caller within the respective frame
building functions but its quite unreadable. There are some comments
but lots of magic numbers. This should be moved within the
dpp_append_wrapped_data utility but the first step is to make the
frame buffer continuous. This will allow the entire frame to be
passed and dpp_append_wrapped_data can calculate the AAD offsets
itself.
src/dpp.c | 239 +++++++++++++++++++++++++-----------------------------
1 file changed, 112 insertions(+), 127 deletions(-)