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