qmi_wwan default RX URB size change to avoid babbling issue?

Peter Naulls peter at chocky.org
Mon Mar 28 15:36:36 UTC 2022


On 3/26/22 10:11, Peter Naulls wrote:
> On 3/25/22 09:28, Daniele Palmas wrote:
>>
>> https://www.spinics.net/lists/netdev/msg765710.html
>>
>> But I don't think it has been submitted.
>>
>> If I'm not wrong, the babble issue will probably also require a
>> follow-up patch to change the default rx urb size for the scenario
>> without qmap.
>>
> 
> Right.  Thanks for this anyway; I have reason to believe this is
> a major cause of our instability. I will test it is is and look at
> any future patches you have.

Further to this, I have an older version of the driver that's hacked up for 
qmap/bridge mode, but I can confirm that the patch triggers the following 
message (which is different in the mainstream driver, but may be a useful 
reference):


    while (skb->len > sizeof(struct qmap_hdr)) {
                 struct qmap_hdr *qhdr = (struct qmap_hdr *)skb->data;
                 struct net_device *qmap_net;
                 struct sk_buff *qmap_skb;
#ifdef QUECTEL_BRIDGE_MODE
                 uint bridge_mode = 0;
                 unsigned char *bridge_mac;
#endif
                 __be16 proto;
                 int pkt_len;
                 u8 offset_id = 0;
                 int err;
                 unsigned len = (be16_to_cpu(qhdr->pkt_len) + sizeof(struct 
qmap_hdr));

                 if (skb->len < len) {
                         dev_info(&dev->net->dev, "drop qmap unknown pkt, 
len=%d, pkt_len=%d\n", skb->len, be16_to_cpu(qhdr->pkt_len));
                         goto out;
                 }


So any processing loop for RX may need to account for the longer packet. I'll
see what I can do to attempt a fix for this case in the mainstream driver.


More information about the libqmi-devel mailing list