Hello. On 30/07/15 10:55, Alexander Aring wrote:
Hi, this patch series contains a RFC for changing the max_frame_retries behaviour. The current behaviour is that we allow a range from -1 until 7 (802.15.4 standard describes a range from 0 until 7 only). Nevertheless for historical reason we have the "-1" value, which describes no aret handling. The point is when the ack request bit is set inside the mac header the transceiver need to handle the ack somehow, this is mostly the aret mode which is done by hardware. Instead to having this as mac setting which doesn't allow a change during interface up, we simple do this handling per frame indicated by the ack request bit.
I think it is sound to handle it per frame to give us the opportunity to change this setting without taking the interface down. I wonder about the frame retry counter which needs to be written in some transceiver register to be used by the hardware directly. That one can only be done when the interface is down. Whcih means we can decide if we want ARET handling per frame but not how often the retry happens. Do I miss something?
Instead of max_frame_retries "-1" value which could be useful for making a default ack request bit handling if no information is given if it should be set or not, we have now the ack request default entry inside the mib. This could be useful for the 6LoWPAN stack which have this as default behaviour for data frames.
You have the wpan-tools bits for the new netlink command pushed somewhere to test out with this patchset?
I'm going to review the implementation now and run some tests with this code enabled.
regards Stefan Schmidt -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
