After an unknown ACK is received no more packets can be send.
I am using a BeaglePlay with the lastest bcfserial from the develop branch. While letting a ping run from the BeaglePlay to a BeagleConnect Freedom the bcfserial driver will throw a "unknown ack" error with a random / changing tx seq number, e.g.:
bcfserial serial1-0: unknown ack 76
The actual seq number received (in buffer[0]) is always 0. Only a module unload and reload will bring the interface back to life.
After going through the commits of bcfserial i got interested in the commit for "Fix kernel crash (#22)". The bcfserial->tx_skb is neither freed nor set to NULL. As i have no insight of what is running on the other side of the serial link causing the issue, I made a little patch of my own which fixes the symptom:
diff --git a/bcfserial.c b/bcfserial.c index 2c55913..33f3d0e 100644 --- a/bcfserial.c +++ b/bcfserial.c @@ -412,6 +412,11 @@ static void bcfserial_wpan_rx(struct bcfserial *bcfserial, const u8 *buffer, siz ieee802154_xmit_complete(bcfserial->hw, skb, false); } else { dev_err(&bcfserial->serdev->dev, "unknown ack %u\n", bcfserial->tx_ack_seq);
-
ieee802154_wake_queue(bcfserial->hw);
-
if (bcfserial->tx_skb) {
-
dev_kfree_skb_irq(bcfserial->tx_skb);
-
bcfserial->tx_skb = NULL;
-
} } } else if (bcfserial->response_size == count && bcfserial->response_buffer) { //TODO replace with semaphore
This makes sure the interface doesn't get stuck and data can flow. We probably loose a packet here, but well...it's wireless anyway.
Cheers,
KP