Skip to content

Conversation

daniel-k
Copy link
Member

The driver should set the broadcast flag (GNRC_NETIF_HDR_FLAGS_BROADCAST) for incoming packets.

@daniel-k daniel-k added Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation Area: network Area: Networking Area: drivers Area: Device drivers labels Oct 12, 2015
@@ -187,10 +188,17 @@ static gnrc_pktsnip_t *_make_netif_hdr(uint8_t *mhr)
hdr = (gnrc_netif_hdr_t *)snip->data;
gnrc_netif_hdr_init(hdr, src_len, dst_len);
if (dst_len > 0) {
broadcast = true;
tmp = 5 + dst_len;
Copy link
Member

Choose a reason for hiding this comment

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

tmp is unused

Copy link
Member

Choose a reason for hiding this comment

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

@DipSwitch tmp is used in line 205 (or 213 with this change).

@thomaseichinger thomaseichinger added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Oct 12, 2015
@@ -187,10 +188,17 @@ static gnrc_pktsnip_t *_make_netif_hdr(uint8_t *mhr)
hdr = (gnrc_netif_hdr_t *)snip->data;
gnrc_netif_hdr_init(hdr, src_len, dst_len);
if (dst_len > 0) {
broadcast = true;
Copy link
Member

Choose a reason for hiding this comment

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

Not that this code is optimised by any means, but as a proposal, you could set the flag here and remove it below if not applicable. Saves us one byte on stack, one assignment and one if-statement. \o/ 😊

Copy link
Member Author

Choose a reason for hiding this comment

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

Less code to maintain. I like it!

@thomaseichinger
Copy link
Member

Code looks good, one proposal for consideration above. Added the CI label.

@daniel-k daniel-k force-pushed the pr/at86rf2xx_detect_broadcast branch from fe8ced1 to 0b160a4 Compare October 12, 2015 15:35
@daniel-k
Copy link
Member Author

@thomaseichinger
Squashed after travis and strider were green.

@@ -191,6 +191,9 @@ static gnrc_pktsnip_t *_make_netif_hdr(uint8_t *mhr)
addr = gnrc_netif_hdr_get_dst_addr(hdr);
for (int i = 0; i < dst_len; i++) {
addr[i] = mhr[5 + (dst_len - i) - 1];
if(addr[i] != 0xff) {
hdr->flags |= GNRC_NETIF_HDR_FLAGS_BROADCAST;
Copy link
Member

Choose a reason for hiding this comment

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

@daniel-k That's the wrong way around. Isn't it? In this case it is not a broadcast address... I thought about setting the flag where you set broadcast = true; before and hdr->flags &= ~GNRC_NETIF_HRD_FLAGS_BROADCAST; here.

Copy link
Member Author

Choose a reason for hiding this comment

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

That's why you really want to have code reviews facepalm. Fixed in 78192eb

@daniel-k daniel-k force-pushed the pr/at86rf2xx_detect_broadcast branch from 43f66e9 to 78192eb Compare October 12, 2015 16:28
@thomaseichinger
Copy link
Member

Ok changes look good. I can't get a rf233 and a rf231 transceiver talk to each other with txtsnd though. This is unrelated to this change as it is the same with master from yesterday. @daniel-k can do you get link layer packet dumps? I see they are receiving, did I miss something?

@thomaseichinger
Copy link
Member

Ok, this is independent from this PR. Code looks good, Travis is green, ACK and go.

thomaseichinger added a commit that referenced this pull request Oct 13, 2015
at86rf2xx: detect broadcast and set NETIF flag when receiving
@thomaseichinger thomaseichinger merged commit 0db6246 into RIOT-OS:master Oct 13, 2015
@OlegHahm OlegHahm added this to the Release NEXT MAJOR milestone Oct 13, 2015
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 CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants