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, beebeet...@posteo.de <beebeet...@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, beebeet...@posteo.de <beebeet...@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, beebeet...@posteo.de <beebeet...@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).
