I'll try some old system with old kernel like 3 or 4.1, ...
I didn't try your suggestion yet, sorry, I'll do try it asap
]]>Also, my client id (duid, according to RFC 3315 is similar to yours, with the last 48 bits being the MAC-ADDRESS of my machine. Though this is scratching my mind too.
Can you try to backup /var/lib/dhcpcd/duid and change any value before your mac address? (be sure that the end result is a 128 bit value, so change just one number/letter to another within [0-9][a-f])
]]>The weird client ID... I believe that it is since beggining. You doesn't have this problem?
My network:
WAN is Mikrotik Router with DHCP Server
Both switches are same brand and type. Both are D-Link DGS-108/E
Windows Machine works while ArchLinux and ArchArm doesn't because macOS is disconnected from it's docking station. I believe that ArchArm Pi on Switch1 works. Only the one on Switch2 doesn't because it is same switch as USB-C docking station
]]>
pacman -S networkmanager
And it didn't work. Same crash as I posted in first post: https://bbs.archlinux.org/viewtopic.php … 9#p1769439
Then I did:
systemctl disable NetworkManager
Also didn't work. Same crash as I posted in first post: https://bbs.archlinux.org/viewtopic.php … 9#p1769439
I verified that windows ntb and macOS ntb works while connected to same switch as non-working Arch. I mentioned Arch because it seems to bit only Arch's problem. I can't verify, if other linux distros work but I tried one desktop Arch (the one I told you about in first post) and I also verified that Raspberry Pi with ArmArch also doesn't work. Exactly same problem as normal 64-bit Arch.
Another interesting thing is Arch's client id... Every system (windows, iOS, macOS, ...) uses 7 format (I don't know how to call it) like 1:aa:bb:cc:dd:ee:ff and every time starts with `1` but Arch uses 19 smt format and eveyr time starts with `ff`. Screenshot:
I have 3 arch machines in my local network.
First two rows is ArchLinux 64-bit ntb
Third and Fourth are two Raspberry Pi-s with ArmArchLinux
EDIT: the easy and sane way is to disable a service, not removing the program which is called by such service.
tried it but it didn't work... same as before
Please don't do this, post the exact step by step terminal input/output and logs if relevant.
]]>pacman -R networkmanager
restarted OS and tried it but it didn't work... same as before
]]>I am really sorry... I didn't check mine reply before sending
Nevermind, is not a big deal
Anyway, just do as I suggested in post #6: for the moment forget about dhcp and disable any network manager, shutdown the interface, then using the `ip` commands flush your interface configuration, restart the interface, assign a manual ip address and a route to your gateway.
]]>Dongle's and VAIO's MAC address AREN'T same. I edited original post but to be sure:
Dongle's MAC Address: 00:E0:4C:31:51:92
VAIO's 2 leases MAC Address: F0:BF:97:05:84:36
VAIO has one static lease on router because I set it up it before. It didn't have second lease for same interface before or I just didn't notice it.
]]>Now it's no surprise that this is not working. How did you setup your network on Arch?
]]>I just found strange thing that VAIO obtain 2 leases for 1 ethernet card
First MAC Address is F0:BF:97:05:84:36 and has static IP 10.0.0.12
Second MAC Address F0:BF:97:05:84:36 and dynamic IP lease 10.0.0.13
yes, both VAIO MAC Address are same, only client ID differs
]]>dongle is just other device connected to same switch
I see, this wasn't really clear from your first post. Anyway, I think this is the same issue: something is "stealing" your dhcp renewals or they're just being sent to the wrong device.
Dongle has PowerDelivery function which means that after disconnecting it from MBP it still working, has IP lease, etc...
Which address do you get and which one does your USB dongle gets? What's the address of your dhcp server?
Check for the mac address in your network (every point to point links) and if you can use something like wireshark to follow the frames when you connect/disconnect the dongle.
]]>USB dongle is other device which is independent from VAIO (ntb which has problem).
VAIO has built in ethernet card:
[user@ArchLinux-VAIO ~]$ ethtool -i enp19s0
driver: r8169
version: 2.3LK-NAPI
firmware-version: rtl_nic/rtl8168e-2.fw
expansion-rom-version:
bus-info: 0000:13:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no
dongle is just other device connected to same switch. Also all works while dongle is used (like is connected to MacBook Pro for example) but when it isn't, it cases problem. But only for VAIO with ArchLinux... Nothing else has problem... Dongle has PowerDelivery function which means that after disconnecting it from MBP it still working, has IP lease, etc...
]]>Anyway:
#After while [user@ArchLinux-VAIO ~]$ sudo arp -av Entries: 0 Skipped: 0 Found: 0
there's no mac address found from your arp cache, hence the dhcp lease expires (probably this USB dongle does other strange things, regardless that it works well with other systems/devices).
I'm not that good with layer 2 connectivity, anyway I think that basically your router passes dhcp offers to your USB interface correctly (they're generated from your laptop with the correct source mac address and sent in broadcast UDP frames, port 68 to 67), but something goes wrong when the renewal is issued. Either you or the router are not receiving the unicast UDP frames.
If I'm right, after stopping network manager, shutting down the interface, connect/disconnect the usb dongle and manually connecting (no network manager) specifing a greater lease time you should see your network timing out less frequently (assuming that your dhcp server allows you to set a greater lease time, this is done with the command `dhcpcd -l`).
If it works, we'll figure something better than a workaround. If it doesn't work, we're barking at the wrong tree.
]]>