You are not logged in.
Greetings, Dev-Ones
I installed Chimaera 64 bit with runit and SLiM, and added a static IP address for eth0 to /etc/network/interfaces. SliM was later swapped out in favour of lightdm. Eth0 seems to be a "Realtek RTL8111/8168/8411" device with driver "r8169"
My /etc/apt/sources.list starts with
# deb cdrom:[Devuan GNU/Linux 4.0 chimaera amd64 - desktop 20210906]/ chimaera contrib main non-free
so I assume that's the vintage of the beta that was installed.
I noticed occasional errors while webbrowsing "Hmm. We’re having trouble finding that site....We can’t connect to the server" etc
I tried a few pings, and noticed the occasional dropped packet. But pings are like salted snacks, you can't have just one.
To remove the uncertainty associated with pinging unreliable, fly-by-night organisations on the Web (e.g. Facebook) I ping my ADSL router/gateway/DHCP server device by IP number.
Eventually, I noticed that if I use DHCP to assign an address, the percentage of dropped packets is usually 0, never over 1. However, with a static
IP assigned in /etc/network/interfaces, the dropped packets percentage is very often between 5 and 50.
I then removed the static eth0 address from /etc/network/interfaces, and tried to assign the static IP using NetworkManager. The dropping of packets continued.
The issue seems to be that something about static IP (OK, my setup of static IP) makes networking unreliable (not broken, just 5-50% unreliable). This seems consistent whether eth0 is managed by NetworkManager or /etc/network/interfaces
Has anyone else noticed anything like this? In particular...has anyone solved this with one simple trick? It will have to be simple.
Maybe someone can point me to a foolproof, painstakingly detailed and yet laughably simple guide for assigning static IP via NetworkManager?
Maybe I'm just holding it wrong.
Offline
Perhaps of interest: If I remove eth0 from /etc/network/interfaces, give it to NetworkManager to manage via DHCP, and assign a static IP by reserving it in the router - that *seems* to work fine. That's a rather embarrassing admission of failure, though. And easily forgotten as I cycle through my collection of junkshop routers as old age, lightning strikes and power surges cause them to shuffle off this mortal coil. And inconvenient if I have to reconfigure BOINC, ssh, hosts.allow and shares.
I hope it won't come to that?
Offline
So...might have found something. My cellphone (which has Kodi installed and sometimes does media server/player duties) had a static IP which is the same as the the static IP I chose for my PC !
The cellphone has been moved to a new address. Now, on my PC, I am trying to use static that has been set up with NetworkManager. Results are promising, but it's an intermittent error, so it's quite difficult to confirm its absence. (Maybe the phone sleeps a lot, and causes fewer problems while asleep? A bit like me, really)
Last month, during the course of my investigation of this intermittent issue, I moved my network from a non-RFC1918-approved network prefix to an RFC1918-approved one. At the same time, I moved my main PC from a static ip that I have used for over a year, to one which conflicted with the phone. The has now been rectified, but I still have no explanation for the same issue which existed with the old address, with which there was no conflict. Maybe I can blame NetworkManager for fighting with the /etc/network/interfaces configuration?
I this works out, I will have to apologise to a lot of old freebie&junkshop cables and hubs/routers.
Is there a simple network diagnostic tool which can easily sniff out ip address duplication? Ping seems to offer a hint, but it's not very good at explaining the problem.
I realise I did not include the actual "error" rmessage, for when I forget about this in a few months time:
.......ping statistics ---
100 packets transmitted, 67 received, 33% packet loss, time 160343ms
rtt min/avg/max/mdev = 170.934/172.424/180.124/1.268 ms
Last edited by entropyagent (2021-10-09 13:45:48)
Offline
Is there a simple network diagnostic tool which can easily sniff out ip address duplication?
ip a
ip r
FWIW that R8169 driver is a complete POS so I would blame that first. See also https://pkginfo.devuan.org/cgi-bin/poli … s&x=submit
Brianna Ghey — Rest In Power
Offline
ip a ip r
Would I have to enter these commands on every machine in the network, including the ones I have forgotten about, and the ones without shells?
I admit, it would be effective if I remembered them all, but somewhat inconvenient.
How about "arping -c 10 -d <ipaddress>" ? I just read about it now and the man says:
-d Find duplicate replies. Exit with 1 if there are answers from
two different MAC addresses.
That looks very promising - is it solid and reliable?
How about sudo nmap -sn <network> ?
Maybe I will test these if I need to continue my investigating. I could put the phone back, and see if they sniff it out.
Of course, due to PEBKAC I only thought of dupips when I noticed the (forgotten by me) persistent address on my phone. I mean, what kind of sick, twisted mind gives a phone a static IP?
Thanks for the r8168 tip, I hope I will not have to investigate it further, but it's "good to know"
Offline
Would I have to enter these commands on every machine in the network, including the ones I have forgotten about, and the ones without shells?
Yes. You don't even need a TTY to run a remote command via ssh.
I admit, it would be effective if I remembered them all, but somewhat inconvenient.
Check the router interface instead then, that should list all attached devices and their addresses.
How about "arping -c 10 -d <ipaddress>" ? I just read about it now and the man says:
-d Find duplicate replies. Exit with 1 if there are answers from two different MAC addresses.
That looks very promising - is it solid and reliable?
No idea, I've never used that tool. Double-check your man page though because the chimaera version of that command doesn't have a -d option.
Brianna Ghey — Rest In Power
Offline
OK, thanks for the tips.
I checked my arping's friendly man page again (from which the above code snippet was taken), it definitely mentions the -d parm. The command accepts the -d without complaint. Of course, I have no idea if it does anything with it. I hope I have not messed up my sources.list.
cat /etc/issue;sudo apt show arping
Devuan GNU/Linux 4 \n \l
Package: arping
Version: 2.21-2
Priority: optional
Section: net
Maintainer: Salvatore Bonaccorso <carnil@debian.org>
Installed-Size: 78.8 kB
Depends: libc6 (>= 2.25), libnet1 (>= 1.1.2.1), libpcap0.8 (>= 1.5.1)
Conflicts: iputils-arping
Homepage: http://www.habets.pp.se/synscan/programs.php?prog=arping
Tag: admin::monitoring, implemented-in::c, interface::commandline,
network::scanner, protocol::ip, role::program, scope::utility
Download-Size: 31.6 kB
APT-Manual-Installed: yes
APT-Sources: http://deb.devuan.org/merged chimaera/main amd64 Packages
Description: sends IP and/or ARP pings (to the MAC address)
The arping utility sends ARP and/or ICMP requests to the specified host
and displays the replies. The host may be specified by its hostname,
its IP address, or its MAC address.
Offline
I checked my arping's friendly man page again (from which the above code snippet was taken), it definitely mentions the -d parm. The command accepts the -d without complaint. Of course, I have no idea if it does anything with it.
Oops, sorry, I was looking at the irputils-arping man page. Silly mistake.
Last edited by Head_on_a_Stick (2021-10-09 23:10:09)
Brianna Ghey — Rest In Power
Offline