Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nanocoap: added function for finding options #18

Closed

Conversation

haukepetersen
Copy link
Contributor

After receiving a packet, I needed to be able to read out certain options (COAP_OPT_LOCATION_PATH in my case), and to copy their content into some user defined buffers. This was not able with the current interface, so I added a function that allows for finding certain options.

The usage is quite easy (I hope):

coap_opt_t *opt;

// for finding the first occurrence of a certain option:
uint8_t *bufpos = coap_find_opt(pdu, pdu->options, &opt, COAP_OPT_LOCATION_PATH);

// for finding the next occurrence of the same option:
while (bufpos) {
    bufpos = coap_find_opt(pdu, bufpos, &opt, 0);
    ...
}

With this function one can read ANY option and do with its values whatever they like...

@haukepetersen
Copy link
Contributor Author

@kaspar030: ping

Copy link
Owner

@kaspar030 kaspar030 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minor comments...

@@ -369,3 +377,65 @@ ssize_t coap_well_known_core_default_handler(coap_pkt_t* pkt, uint8_t *buf, \

return coap_build_reply(pkt, COAP_CODE_205, buf, len, payload_len);
}

size_t get_lenval(uint8_t *buf, uint16_t *val)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

make static, add underscore, maybe rename to "_decode_optlen" to be in line with the other coap decode functions?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, forgot the static. Will do both.

return len;
}

int parse_opt(uint8_t *optpos, coap_opt_t *opt)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

static, too?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes.


uint16_t delta = 0;

do {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we add packet length checks here? Seems like a bogus header leads to crashes here.

@@ -172,6 +180,8 @@ size_t coap_put_option(uint8_t *buf, uint16_t lastonum, uint16_t onum, uint8_t *
size_t coap_put_option_ct(uint8_t *buf, uint16_t lastonum, uint16_t content_type);
size_t coap_put_option_url(uint8_t *buf, uint16_t lastonum, const char *url);

uint8_t *coap_find_opt(coap_pkt_t *pkt, uint8_t *bufpos, coap_opt_t *opt, uint16_t optnum);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the other public functions carry "option" written out, so maybe rename?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will do.

@bergzand
Copy link

I'm trying to use your coap_find_opt function for #21 and I'm running into some issues with the arguments where I want to find a previously inserted option to readjust the value of the option, but a coap_pkt_t variable is not yet created for the packet.

For the context, I'm implementing block2 support (rfc7959). Before constructing the packet payload I insert a block2 header. This header consists of a block number (known), a size exponent (known) and a "more" bit flag. This more bit flag is set if there are more blocks following the current block. I currently set this flag if the payload of the reply exceeds the current block. This flag thus have to be adjusted after the payload is added and I would like to use the coap_find_opt function to retrieve the header from the headers.

So at that moment a coap_pkt_t struct of the reply is not yet available (it is created in the coap_build_reply. Would this not be more flexible if the coap_pkt_t argument would be an uint8_t* to the payload, seeing that it is only used for the payload position. This way the function can also be used to retrieve previously set options in the construction of a packet.

@haukepetersen
Copy link
Contributor Author

@kaspar030 fixed your remarks, better now?

@haukepetersen
Copy link
Contributor Author

@bergzand yes, that makes sense ineed: see last commit

@kaspar030
Copy link
Owner

@kaspar030 fixed your remarks, better now?

yes! (I guess we leave the size validity check for later?)

@haukepetersen
Copy link
Contributor Author

I guess we leave the size validity check for later?

why? It should be fixed now, is it not?

@haukepetersen
Copy link
Contributor Author

I thought the check in line 428

        if (bufpos >= payload_pos) {
            return NULL;
        }

is doing that?!

len = 1;
}
else if (*val == 14) {
memcpy(val, buf, 2);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this might read past packet length

return -1;
}

opt->val += _decode_optlen(opt->val, &opt->delta);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

through _decode_optlen(), this might read past the packet

@kaspar030
Copy link
Owner

For _decode_value() I added the packet end as parameter in order to be able to check if the decoding would read past end.

@haukepetersen
Copy link
Contributor Author

Ah, I see...

@emmanuelsearch
Copy link

@haukepetersen @kaspar030 would love to see this in ;)
(and it would bring us closer to blockwise support, if I understand correctly ?)

@haukepetersen
Copy link
Contributor Author

closing in favor of #8920 and #8772

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants