Skip to content

netdev: at86rf2xx: fix chan. length check#7427

Closed
OlegHahm wants to merge 1 commit intoRIOT-OS:masterfrom
OlegHahm:at86rf2xx_set_chan_assert
Closed

netdev: at86rf2xx: fix chan. length check#7427
OlegHahm wants to merge 1 commit intoRIOT-OS:masterfrom
OlegHahm:at86rf2xx_set_chan_assert

Conversation

@OlegHahm
Copy link
Copy Markdown
Member

Channels can have up to 16 bits, but only 8 bit channels are valid for
802.15.4.

Channels can have up to 16 bits, but only 8 bit channels are valid for
802.15.4.
@OlegHahm OlegHahm added Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors) Area: drivers Area: Device drivers Area: network Area: Networking labels Jul 28, 2017
@OlegHahm OlegHahm added this to the Release 2017.10 milestone Jul 28, 2017
assert(chan <= UINT8_MAX);
* 2.4 GHz band radios have different legal values. Here, we just
* take the first eight bits. */
uint8_t chan = ((uint8_t *)value)[0];
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

The API doc says uint16_t so it should be uint16_t (though I don't know if there are radio standards with channel numbers >255, at this point I'm against changing the API, because I don't see much benefit in it).

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

(casting from uint16_t pointer to uint8_t pointer doesn't seem like a sane idea to me)

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

The same thing is done in the driver anyway.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I don't understand what you mean by that.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Yes, but that is wrong.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

break;
case NETOPT_CHANNEL:
assert(len != sizeof(uint8_t));
assert(len <= sizeof(uint16_t));
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

== for scalar types

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

I don't get it. Why should't I be allowed to pass a 8 bit channel if 802.15.4 channels always fit into 8 bit?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Because if the user provides a 16-bit channel (or the shell_commands module for that matter) the cast in netdev_ieee802154 will cast a uint16_t pointer to a uint8_t pointer, discarding the least-significant byte, which on a big-endian platform would contain the actual value, so the value would always resolve to 0.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Well, that seems to be broken for the last two years anyway, but I see your point. So, an upper layer API that uses 8 bit integers for radio channels need to upcast its parameter or what is the best solution for this?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Yes, I think that is the best solution.


case NETOPT_CHANNEL_PAGE:
assert(len != sizeof(uint8_t));
assert(len <= sizeof(uint16_t));
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

== for scalar types

{
assert(len == sizeof(uint16_t));
uint16_t chan = *((uint16_t *)value);
assert(len <= sizeof(uint16_t));
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

== for scalar types

/* real validity needs to be checked by device, since sub-GHz and
* 2.4 GHz band radios have different legal values. Here we only
* check that it fits in an 8-bit variabl*/
assert(chan <= UINT8_MAX);
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

This check can still be kept

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

If chan is uint8_t this doesn't make sense.

@miri64
Copy link
Copy Markdown
Member

miri64 commented Jul 28, 2017

@thomaseichinger
Copy link
Copy Markdown
Member

@OlegHahm @miri64 So what's the solution?

@miri64
Copy link
Copy Markdown
Member

miri64 commented Aug 11, 2017

Simple: replace the

assert(len != sizeof(uint8_t);

with

assert(len == sizeof(uint16_t);

for NETOPT_CHANNEL. This fixes the bug and for anything else I see too much of a complication to change at this point.

@miri64
Copy link
Copy Markdown
Member

miri64 commented Aug 21, 2017

Provided alternative in #7488.

@miri64
Copy link
Copy Markdown
Member

miri64 commented Nov 15, 2017

I interpret #7488 (comment) in that way, that @OlegHahm agrees with me to close this PR. Re-open if you disagree.

@miri64 miri64 added Discussion: contested The item of discussion was contested quality defect and removed Discussion: contested The item of discussion was contested labels Nov 15, 2017
@miri64 miri64 closed this Nov 15, 2017
@miri64 miri64 added Discussion: contested The item of discussion was contested and removed quality defect labels Oct 1, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Area: drivers Area: Device drivers Area: network Area: Networking Discussion: contested The item of discussion was contested Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants