Thanks a lot Stuart! Really appreciate your insights.
I've been running some more tests and here are some new results:
1.
Without MAC spoofing and a statically assigned IP address, axe lasted
around twelve days on an AX88772B before throwing the following error:
axe0: watchdog timeout
axe0: usb error on tx: IN PROGRESS
axe0: usb error on tx: TIMEOUT
This time tcpdump shows only incoming packets but not outgoing packets.
(which is opposite from last time...)
Have not yet tested axen and ure without MAC spoofing yet, but I highly
suspect that there will be similar errors. I start to have a feeling
that the problems are specific to Raspberry Pi 4B because these USB
adapters seem really common and someone else would definitely have
discovered the issue before me should amd64 be affected.
2.
I tried changing MAC address to a fixed value on bse with
`lladdr XX:XX:XX:XX:XX:XX`, and it has been running without issue for
four days so far... But frankly I don't know how much randomness there
are in those issues.
> I'm still pondering the fact that you don't see incoming packets even
> when tcpdump is running, as (unless you used tcpdump -p) that
> would set the nic in promiscuous mode..
I believe I did `tcpdump -n -i <if>`, sometimes with '-vvv'.
Best Regards
On 8/6/21 3:46 AM, Stuart Henderson wrote:
> hopefully copying to bugs@ (if I remember how to do that correctly
> from slrn/gmane..) Please keep that in CC's when replying. Earlier misc@
> mail copied in below to keep things together in one place.
>
>
> On 2021-08-06, beebeetles@posteo.de <beebeetles@posteo.de> wrote:
>>> My first suggestion might be to stay with a single lladdr for a
>>> while to see if your setup works for more than a day and a half.
>>
>> Thanks for the suggestion!
>> It seems that with `lladdr random` removed, the problem does not
>> seem to disappear.
>
> On 2021-08-06, beebeetles@posteo.de <beebeetles@posteo.de> wrote:
>> Sorry, there was a typo: The problem *does disappear* with
>> `lladdr random` removed .
>
> Good, so you have a workaround for now.
>
>>>>> lladdr random
>>>>
>>>> Why this line?
>>>
>>> I was wondering the same thing. What problem do you think you are
>>> solving by doing this?
>>
>> I try to make it harder for my ISP to gather information about the
>> device I'm using, thus was using random MAC address.
>>
>>
>>> The "random" lladdr catches my eye. But I don't know how
>>> frequently that changes. Could it change every time the lease
>>> is renewed?
>>
>> Skimming through the code for dhcpleased, looks like there's no
>> invocation of the SIOCSIFLLADDR ioctl, so I would assume that the
>> lladdr stays the same unless the netstart script is re-run (thus
>> invoking ifconfig to change lladdr), but I will to test that to
>> make sure.
>>
>> It smells of a bug somewhere... I mean, as long as the lladdr does
>> not change in the middle of the lease, then the router should have
>> been able to successfully obtain a new IP address, right?
>
> It only changes when "ifconfig $_iface lladdr random" is actually
> called, i.e. normally just when the interface is configured at boot,
> unless you re-run netstart.
>
> I don't think it will be a problem of using a random lladdr in
> particular but more likely if the MAC address is changed at all.
> One area that might be implicated is the hardware address filters
> which need to be reprogrammed by the driver when the address is
> changed. Though the fact that it happens with at least ure, bse,
> axe makes me think that it might be some other issue. I'm still
> pondering the fact that you don't see incoming packets even
> when tcpdump is running, as (unless you used tcpdump -p) that
> would set the nic in promiscuous mode..
>
>
>
> On 2021-08-03, beebeetles@posteo.de <beebeetles@posteo.de> wrote:
>> Can anyone offer some suggestions on what I can do to nail down
>> the issue?
>>
>> Below are some of the observations I've made so far:
>>
>> - Doesn't matter whether I'm using dhclient of dhcpleased, same
>> issue.
>>
>> - When it stops working, tcpdump still shows outgoing packets,
>> checksums all OK, but no incoming packets.
>>
>> - `dhcpleasectl show interface <if>` shows that there is still
>> one day before the lease expires.
>>
>> - When this first happens, `arp -a` shows that the link layer
>> address of the gateway is still in the ARP table. But of course
>> it will expire after some time, and the router won't be able to
>> obtain the link layer address of the gateway again after that.
>>
>> - The `netstat -R` still shows the IP address of the gateway.
>>
>> - My ISP would offer a few short leases at first, and then offer a
>> two day lease. This issue seems always to occur around half way
>> of the two day lease period.
>>
>> - I tried several interface cards with drivers including axen, ure,
>> axe, bse. axen dies every 10-20 min, outputing some watchdog
>> timeout error; ure has the same issue described here, but throws
>> some rx/tx error to dmesg in addition; bse and axe doesn't seem
>> to output any errors, but both have the issue described here.
>>
>> - The issue doesn't occur when the IP address is statically
>> assigned.
>>
>> - Didn't experience this problem when I was running Linux on the
>> same machine (raspberry pi 4B).
>
>
No comments:
Post a Comment