Hi, when studying the inet codebase, I noticed something that I think could lead to a bug as described in the title.

We know that Radio::updateTransceiverState() gets called after each events of the Radio, e.g. initialization, start/end transmission and start/end reception. In Radio::updateTransceiverState(), to determine whether the radio is busy or idle, RadioMedium::listenOnMedium is called. RadioMedium::listenOnMedium takes into account all the transmissions that are on-going to compute the noise level. But when using the various RadioMedium.*Filter options (e.g. macAddressFilter) the radios don't necessarily process all the transmissions that are happening on the RadioMedium. This could e.g. lead to the following situations:

• Radio is in RECEPTION_STATE_IDLE, a new transmission occurs, but due to some filter configuration the radio doesn't receive the signal, thus no event occurs in the radio module, Radio::updateTransceiverState() is not called and the radio stays in RECEPTION_STATE_IDLE. But the new transmission could have introduced noise on the RadioMedium such that the radio should become busy.
• Viceversa, radio is in RECEPTION_STATE_BUSY due to some series of events. An on-going transmission finishes on the RadioMedium, but radio was never aware of that transmission due to some filter configuration. Radio::updateTransceiverState() is not called, radio remains in RECEPTION_STATE_BUSY. But the end of the transmission (if could even be the last transmission) could have reduced the noise on the RadioMedium such that the radio should become idle.

If you think this is possible, I can work on a reproduction and fix for this.