Discussion:
Why extra network traffic?...
(too old to reply)
John Forkosh
2021-01-18 13:20:48 UTC
Permalink
...between Slackware -current64 downloaded 12/25/20
versus 09/01/19?

Below's the iftop output from two bootable slackware-current64's,
one on /dev/sda1 downloaded 9/1/19, and more recently 12/25/20 on sda2:

=====================================================================
01-16-21:09:50am from psi4star:/sda1/ Slack -current64 as of 09/01/19

Display paused 12.5Kb 25.0Kb 37.5Kb 50.0Kb 62.5Kb
---------------------------------------------------------------------
psi4star.forkosh.com => G3100.myfiosgateway.com 0b 0b 0b
<= 0b 0b 16b
G3100.myfiosgateway.com => all-systems.mcast.net 0b 0b 7b
<= 0b 0b 0b
---------------------------------------------------------------------
TX: cum: 58.3KB peak: 0b rates: 0b 0b 0b
RX: 42.3KB 312b 0b 0b 23b
TOTAL: 101KB 312b 0b 0b 23b
=====================================================================
01-18-21:06:50am from psi4star:/sda2/ Slack -current64 as of 12/25/20

Display paused 195Kb 391Kb 586Kb 781Kb 977Kb
---------------------------------------------------------------------
psi4star.forkosh.com => 255.255.255.255 142Kb 143Kb 143Kb
<= 0b 0b 0b
psi4star.forkosh.com => G3100.myfiosgateway.com 0b 0b 0b
<= 135Kb 135Kb 135Kb
G3100.myfiosgateway.com => all-systems.mcast.net 0b 29b 7b
<= 0b 0b 0b
---------------------------------------------------------------------
TX: cum: 2.91MB peak: 150Kb rates: 142Kb 143Kb 143Kb
RX: 2.75MB 141Kb 135Kb 135Kb 135Kb
TOTAL: 5.66MB 291Kb 277Kb 278Kb 278Kb
=====================================================================

As you can see, there seems to be a whole lot of extraneous FF.FF.FF.FF
back-and-forth traffic between the router and the box from the more
recent install (same thing happened on an earlier 2/28/20 install,
but the 9/1/19 install doesn't exhibit it).

All installs are /sbin/netconfig'ed identically, static 192.168.1.4 ip,
no nameserver. And internet access is started "manually" by root
with dhcpcd -d -h psi4star -s 192.168.1.4 eth0 (after running
an iptables firewall). And the traffic begins immediately after that.

I'm not seeing any difference in /etc/rc.d between the two installs
to explain it, nor in netconfig, etc, although my meager knowledge
about this stuff might easily have missed it.

Any way I can stop it? It's a little annoying because it keeps the
lights on my switches blinking continuously. And I'd been using
those lights as a kind of "visual firewall" -- when I wasn't doing
anything, they weren't blinking. So a lot of unexplained blinking
had been a sign of undesirable activity.
--
John Forkosh ( mailto: ***@f.com where j=john and f=forkosh )
Rich
2021-01-18 18:39:00 UTC
Permalink
Post by John Forkosh
psi4star.forkosh.com => 255.255.255.255 142Kb 143Kb 143Kb
As you can see, there seems to be a whole lot of extraneous FF.FF.FF.FF
back-and-forth traffic between the router and the box from the more
recent install
255.255.255.255 is the local subnet broadcast address.

Something is broadcasting. But simply looking at a sum total of
packets tells us exactly zero.

Install Wireshark
(https://slackbuilds.org/repository/14.2/network/wireshark/) and
monitor the network traffic itself. You'll more likely see what kind
of traffic it is, and once you know what kind it is, you'll be closer
to narrowing down a culprit.
John Forkosh
2021-01-19 02:28:07 UTC
Permalink
Post by Rich
Post by John Forkosh
psi4star.forkosh.com => 255.255.255.255 142Kb 143Kb 143Kb
As you can see, there seems to be a whole lot of extraneous FF.FF.FF.FF
back-and-forth traffic between the router and the box from the more
recent install
255.255.255.255 is the local subnet broadcast address.
Something is broadcasting. But simply looking at a sum total of
packets tells us exactly zero.
Install Wireshark
(https://slackbuilds.org/repository/14.2/network/wireshark/) and
monitor the network traffic itself. You'll more likely see what kind
of traffic it is, and once you know what kind it is, you'll be closer
to narrowing down a culprit.
Thanks, Rich, that's indeed very helpful (I'd mentioned "my meager
knowledge about this stuff" in original post:).

Looking at that wireshark readme, I immediately tried tcpdump first.
See the "[bad udp cksum 0x839d -> 0x5a9b!]" in the -vv dump below,
which is what I'm wildly guessing is what's maybe responsible for
the continual back-and-forth. (By the way, on install netconfig was
set up with hostname psi4star and domain forkosh.com, but I have
no idea what that ".bootpc" signifies.)

first
bash-5.1# tcpdump -c 10
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
20:57:46.297113 IP psi4star.forkosh.com.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request from e0:3f:49:17:5c:74 (oui Unknown), length 348
20:57:46.297380 IP psi4star.forkosh.com.35613 > G3100.myfiosgateway.com.domain:
39668+ PTR? 255.255.255.255.in-addr.arpa. (46)
20:57:46.298172 IP G3100.myfiosgateway.com.bootps > psi4star.forkosh.com.bootpc:
BOOTP/DHCP, Reply, length 327
20:57:46.298268 ARP, Request who-has psi4star.forkosh.com tell
psi4star.forkosh.com, length 28
20:57:46.309315 IP G3100.myfiosgateway.com.domain > psi4star.forkosh.com.35613:
39668 NXDomain 0/1/0 (114)
20:57:46.309463 IP psi4star.forkosh.com.59541 > G3100.myfiosgateway.com.domain:
23426+ PTR? 1.1.168.192.in-addr.arpa. (42)
20:57:46.310354 IP G3100.myfiosgateway.com.domain > psi4star.forkosh.com.59541:
23426* 1/0/0 PTR G3100.myfiosgateway.com. (79)
...
20:57:46.313041 IP psi4star.forkosh.com.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request from e0:3f:49:17:5c:74 (oui Unknown), length 348
20:57:46.314339 IP G3100.myfiosgateway.com.bootps > psi4star.forkosh.com.bootpc:
BOOTP/DHCP, Reply, length 327
20:57:46.314446 ARP, Request who-has psi4star.forkosh.com tell
psi4star.forkosh.com, length 28
10 packets captured
10 packets received by filter
0 packets dropped by kernel

and then
bash-5.1# tcpdump -vv -c 10
tcpdump: listening on eth0, link-type EN10MB (Ethernet),
capture size 262144 bytes
21:08:03.620514 IP (tos 0x0, ttl 64, id 7482, offset 0, flags [none],
proto UDP (17), length 376)
psi4star.forkosh.com.bootpc > 255.255.255.255.bootps: [udp sum ok]
BOOTP/DHCP, Request from e0:3f:49:17:5c:74 (oui Unknown),
length 348, xid 0x1705b830, secs 2421, Flags [none] (0x0000)
Client-IP psi4star.forkosh.com
Client-Ethernet-Address e0:3f:49:17:5c:74 (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Inform
etc
21:08:03.620786 IP (tos 0x0, ttl 64, id 60008, offset 0, flags [DF],
proto UDP (17), length 74)
psi4star.forkosh.com.47845 > G3100.myfiosgateway.com.domain:
[bad udp cksum 0x839d -> 0x5a9b!] 28812+ PTR?
255.255.255.255.in-addr.arpa. (46)
21:08:03.622626 IP (tos 0x0, ttl 64, id 59793, offset 0, flags [DF],
proto UDP (17), length 355)
G3100.myfiosgateway.com.bootps > psi4star.forkosh.com.bootpc: [udp sum ok]
BOOTP/DHCP, Reply, length 327, xid 0x1705b830, secs 2421,
Flags [none] (0x0000)
Client-IP psi4star.forkosh.com
Client-Ethernet-Address e0:3f:49:17:5c:74 (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: ACK
etc

So that "[bad udp cksum 0x839d -> 0x5a9b!]" at 21:08:03.620786
looks like maybe it's causing some kind of retransmit request,
which just iterates forever (at about 100 messages/second).
But that doesn't happen on the -current64 install from 09/01/19,
where there are no corresponding packets for tcpdump to display.
And I'm over my head trying to make any detailed sense of what
we're looking at here.
--
John Forkosh ( mailto: ***@f.com where j=john and f=forkosh )
John Forkosh
2021-01-19 04:10:00 UTC
Permalink
Post by John Forkosh
Post by Rich
Post by John Forkosh
psi4star.forkosh.com => 255.255.255.255 142Kb 143Kb 143Kb
As you can see, there seems to be a whole lot of extraneous FF.FF.FF.FF
back-and-forth traffic between the router and the box from the more
recent install
255.255.255.255 is the local subnet broadcast address.
Something is broadcasting. But simply looking at a sum total of
packets tells us exactly zero.
Install Wireshark
(https://slackbuilds.org/repository/14.2/network/wireshark/) and
monitor the network traffic itself. You'll more likely see what kind
of traffic it is, and once you know what kind it is, you'll be closer
to narrowing down a culprit.
Thanks, Rich, that's indeed very helpful (I'd mentioned "my meager
knowledge about this stuff" in original post:).
Looking at that wireshark readme, I immediately tried tcpdump first.
See the "[bad udp cksum 0x839d -> 0x5a9b!]" in the -vv dump below,
which is what I'm wildly guessing is what's maybe responsible for
the continual back-and-forth. (By the way, on install netconfig was
set up with hostname psi4star and domain forkosh.com, but I have
no idea what that ".bootpc" signifies.)
<< snipped all tcpdump output -- see preceding post for it >>
Post by John Forkosh
So that "[bad udp cksum 0x839d -> 0x5a9b!]" at 21:08:03.620786
looks like maybe it's causing some kind of retransmit request,
which just iterates forever (at about 100 messages/second).
But that doesn't happen on the -current64 install from 09/01/19,
where there are no corresponding packets for tcpdump to display.
And I'm over my head trying to make any detailed sense of what
we're looking at here.
Okay, so I "solved" (or at least stopped) the problem,
simply by copying /sbin/dhcpcd from the 9/1/19 -current64 install,
which is version 4.4.1 dated 8/22/19, to the /sbin/ directory
of the 12/25/20 install, which had been version 8.1.9 dated 4/22/20.
(Actually the new one was mv'ed to dhcpcd-8.1.9, the old one cp'ed
to dhcpcd-4.4.1, and dhcpcd is now a symlink to 4.4.1)
And now it "just works". Didn't have to change anything else at all.

So whatever is happening (is the underlying problem/cause) seems
related to the newer dhcpcd slackware64/n/ package (I didn't change
any dhclient stuff or anything else, just that one dhcpcd executable).
But I'd still like to know what the problem is -- have I configured
something wrong, doing something else wrong, or is there actually
some problem with the newer dhcpcd, or what? But I have no idea
how to further diagnose the situation.
--
John Forkosh ( mailto: ***@f.com where j=john and f=forkosh )
Rich
2021-01-19 05:27:38 UTC
Permalink
Okay, so I "solved" (or at least stopped) the problem, simply by
copying /sbin/dhcpcd from the 9/1/19 -current64 install, which is
version 4.4.1 dated 8/22/19, to the /sbin/ directory of the 12/25/20
install, which had been version 8.1.9 dated 4/22/20. (Actually the
new one was mv'ed to dhcpcd-8.1.9, the old one cp'ed to dhcpcd-4.4.1,
and dhcpcd is now a symlink to 4.4.1) And now it "just works".
Didn't have to change anything else at all.
So whatever is happening (is the underlying problem/cause) seems
related to the newer dhcpcd slackware64/n/ package (I didn't change
any dhclient stuff or anything else, just that one dhcpcd
executable). But I'd still like to know what the problem is -- have
I configured something wrong, doing something else wrong, or is there
actually some problem with the newer dhcpcd, or what? But I have no
idea how to further diagnose the situation.
Best guess, as I can't "see" your dhcpcd from across the world via
Usenet, is that the default dhcpcd was assuming you had an external
dhcp server on your local net, and you have no dhcp server, so it was
continiously poling looking for a dhcp server that is not there.

Your copied config likely does not assume a server somewhere else on
the local net (or it sets up your local machine as that server).
John Forkosh
2021-01-19 08:32:34 UTC
Permalink
Post by Rich
Okay, so I "solved" (or at least stopped) the problem, simply by
copying /sbin/dhcpcd from the 9/1/19 -current64 install, which is
version 4.4.1 dated 8/22/19, to the /sbin/ directory of the 12/25/20
install, which had been version 8.1.9 dated 4/22/20. (Actually the
new one was mv'ed to dhcpcd-8.1.9, the old one cp'ed to dhcpcd-4.4.1,
and dhcpcd is now a symlink to 4.4.1) And now it "just works".
Didn't have to change anything else at all.
So whatever is happening (is the underlying problem/cause) seems
related to the newer dhcpcd slackware64/n/ package (I didn't change
any dhclient stuff or anything else, just that one dhcpcd
executable). But I'd still like to know what the problem is -- have
I configured something wrong, doing something else wrong, or is there
actually some problem with the newer dhcpcd, or what? But I have no
idea how to further diagnose the situation.
Best guess, as I can't "see" your dhcpcd from across the world via
Usenet, is that the default dhcpcd was assuming you had an external
dhcp server on your local net, and you have no dhcp server, so it was
continiously poling looking for a dhcp server that is not there.
Your copied config likely does not assume a server somewhere else on
the local net (or it sets up your local machine as that server).
Thanks again, Rich. But I don't think that's the explanation.
There is no "copied config". I only copied the executable dhcpcd image
itself (btw, correction: the 12/25/20 version is indeed dhcpcd-8.1.9,
like I said above, but the 9/1/19 version is dhcpcd-8.0.3, sorry).
And just to double-check, I rebooted the old 9/1/19 partition, sda1,
and copied the new dhcpcd-8.1.9 version into the old sbin/ directory,
and symlinked dhcpcd to that new version. And now when run via
dhcpcd -d -h psi4star -s 192.168.1.4 eth0 it again generates all
that extraneous nuisance traffic. That is, the old dhcpcd-8.0.3 version
never generates nuisance traffic when run, regardless of partition
(/dev/sda1 has the 9/1/19 install and sda2 has 12/25/20), whereas
dhcpcd-8.1.9 always generates nuisance traffic. So any config
files/information I might not be aware of should be identical for
both. Moreover, I did check the etc/rc.d/ scripts and .conf files
as best I could (I'm no expert and maybe missed something), and
see no salient diffs (as far as I can tell).

But there is one goofy difference -- recall all those
"[bad udp cksum 0x839d -> 0x5a9b!]" errors I mentioned
when running the new dhcpcd-8.1.9 from its native sda2 partition?
Well, now when I run the new 8.1.9 on the older sda1 partition,
there are no errors, every single packet just says "[udp sum ok]".
Go figure. It's now just an endless sequence of requests/replies...

03:22:47.005477 IP psi4star.forkosh.com.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request from e0:3f:49:17:5c:74 (oui Unknown), length 349
03:22:47.006955 IP G3100.myfiosgateway.com.bootps >
psi4star.forkosh.com.bootpc: BOOTP/DHCP, Reply, length 327
03:22:47.007054 ARP, Request who-has psi4star.forkosh.com
tell psi4star.forkosh.com, length 28
and again and again and... (about 100/sec)

So I'm still clueless why dhcpcd-8.1.9 creates all that nuisance
traffic, whereas dhcpcd-8.0.3 doesn't. And in particular, what
I can do/fix/change so that the newer 8.1.9 version runs without
creating it.
--
John Forkosh ( mailto: ***@f.com where j=john and f=forkosh )
Loading...