I know it's not a beauty, but can become quite handy if you want to measure what's really happening inside the stack.

This seems to be at first glance more of a gnrc_netdev2 change than a netdev2 change. Please clarify in the description. Why is it called netdev_retrans and not netdev2_retrans? More thorough review will follow when dependencies got merged (or when I find the time to differentiate your code from mine ^^)

Well, ideally, it would go into netdev2, but I need something to queue the packets while waiting for retransmission and therefore the pktbuf is quite handy.

Why netdev2? Isn't this a very radio-only feature?

Why radio-only?

@OlegHahm Would you mind factoring out the netstats?

Regarding the retransmissions, I think a combined approach is best:

• gnrc's powerful pktsnips show that packet queueing is best done in the network stack
• netdev2 still needs to communicate e.g., a busy medium

I propose that netdev2 devices do, if not configured to do some kind of internal retransmissions, return a defined error when the medium is busy when sending, e.g., "-EBUSY" or "-EAGAIN" (we should use one for the device actually being busy and the other for "medium is busy".

In gnrc, we devise a simple intermediate handler that overrides _send (and possibly _get/_set), on which radio devices (gnrc_iee802154/gnrc_cc110x) can be stacked.

Why radio-only?
Maybe it's not radio-only, but for some netdev's (e.g., ethernet), it doesn't make sense to support media access control. If that handling is inside gnrc_netdev2, it will be compiled in (and executed) for all types of devices.

@OlegHahm Would you mind factoring out the netstats?

Yes, makes sense, will do. Although without the retransmission mechanism the stats won't be accurate.

The problem that I'm current facing is that I lose interrupts on the SAMR21. If I send fragmented 6LoWPAN packets and the last fragment is rather small (e.g. <= 20 bytes of payload), I will only get one TX_END IRQ.

Problem fixed. Thanks @haukepetersen for the advice.

@kaspar030, here you go: #4801

Surprisingly it doesn't seem to affect the performance when running pinging (tested on SAMR21-xpro with 100 pings a 1008 bytes, i.e. 10 fragments per datagram).

Needs rebase. I did not look into the code, but if I understand the problem correctly: Can't this be solved with a tx_info struct, similar as I did with rx_info in #4648?

What can be solved?

Getting the number of retransmissions done by the driver.

I don't understand how. The transceiver and therefore the driver doesn't know anything about the number of retransmissions.

Huh? If not the transceiver, who else?

In this PR: gnrc_netdev2. That's basically the whole point of this PR. ;)

Ahhhh sorry I missunderstood the PR. I thought you introduced a feature to get the number of automatic retransmissions of the device... not that you take out the retransmissions to the MAC layer... Okay, then I wait until #4646 is merged for my final review :-)

rebased to current master after #4646 got merged.

Isn't netstats introduced in #4801?

Yes.

So why did you rebase to master then?

@smlng are you aware of this PR?

Might also be of interest for @zhuoshuguo and @daniel-k especially considering that they are working on a priority queue for MAC too.

Postponed due to feature freeze

Please see if you can unify this with #5941 and #5950 somehow (also needs rebase).

@OlegHahm ping?

(both PRs got merged in the meantime so rebasing is and unification with those is now required)

I can certainly rebase, but I'm not sure I will find the time for extensive testing.

Ok, then let's postpone

@OlegHahm What is the status of this?

Needs rebase.

The code looks pretty stale and I think it would be better to have this done in a matter as proposed in #7736, so that other stacks can benefit from that.