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