[conspire] desktop and my laptop can't ping one to another
Michael Paoli
Michael.Paoli at cal.berkeley.edu
Wed Jul 29 23:44:30 PDT 2020
> From: "Ruben Safir" <ruben at mrbrklyn.com>
> Subject: Re: [conspire] desktop and my laptop can't ping one to another
> Date: Wed, 29 Jul 2020 11:54:26 -0400
> On Wed, Jul 29, 2020 at 08:07:51AM -0700, Michael Paoli wrote:
>> So, what about the ARP table and /etc/ethers - if that's present?
>> What are the Ethernet MAC addresses associated with each IP
>> in question, and are each making it into the ARP table of
>> the other - if they're on same subnet ... (or in /etc/ethers).
>> What does the routing, subnets, masks, etc. for each look like?
>> And gateways/routers?
>
> IMO your making this two complicated without reason. He doesn't need
> top confirm the arp tables, and the ethernet mac addresses. This is not
And your != you are. Good thing I didn't make it three complicated.
Need top confirm?
Maybe a wee bit more care/attention in the writing ... that's like
three typos/spellos in the first two lines of (new) content. Fairly
high error rate. That would be a very bad error rate for
configuration files or specification documents.
> top confirm the arp tables, and the ethernet mac addresses. This is not
> a demonstration of networking principles for a networking class.
>
> He has two machines and he just needs to see if they can ping each
> other, and there is a wifi gateway in between.
Ain't generally nothin' wrong with teaching and learning.
And he isn't the only reader on this list. Often others
are interested in learning and relevant principles too.
And, among other relevant bits, some basic divide-and-conquer is
highly relevant. E.g. can anything at all on same subnet (I'm
guessing/presuming all this stuff is on the same subnet)
ping anything else via that same Wi-Fi "gateway". If none can
ping through it, maybe the "issue" is the Wi-Fi "gateway" - likely
firewalling thereupon. That's also often highly common. E.g.
it may quite be set up as if one were going to be at some cafe
with various patrons sharing a common Wi-Fi AP. Often for
security it's set up so various devices on there can't talk to
other devices on there ... e.g. protect the weak vulnerable
unpatched unupdated Microsoft Windows computer, from somebody
else's Microsoft Windows computer at the cafe that's already got
a bunch of malware botnet software running on it to try and
take over any additional systems it can get to. Why let the
Wi-Fi AP allow such an infected compromised computer to take
over additional vulnerable computers that are patron guests of
the business cafe's Wi-Fi? So, yeah, often those will rather to
quite restrict access through such "gateway" to others on the same
local subnet. Many home/SOHO "gateway" devices may be similarly
configured ... at least by default. A lot 'o ISPs are "lazy",
and don't want calls from customers about "How come all my
computers are infected? Just 'case somebody brought in one
infected computer? I though you guys were here to *protect*
and help me?" ... and will leave it to customers to weaken such
(often too extreme or draconian) security at their own
risk/peril/knowledge/responsibility.
So, hence, e.g. connecting the two computers direct (e.g. via crossover
cable) or "direct" (layer-2), with nothing but a switch (or even hub)
between - with no firewalling on it at all - quite relevant to
isolating issue ... as is the question of whether anything on the subnet
can ping anything else on the subnet - e.g. is there a pattern there,
does it correlate to the "gateway", or does it correlate to just
the laptop/desktop pair in question - or just one of those two?
Also relevant, can the laptop/desktop in question ping anything
on The Internet? ... or anything else on the subnet? And vice
versa - can anything else on the subnet ping the laptop or desktop?
And lots of the other troubleshooting bits/questions - those go to
more direct alternative approaches - rather that and more stab-in-the-dark
divide and conquer to start isolating ... go more direct, actually "see"
what is/isn't happening with the intended traffic ... and where.
Oh, other bits that are useful that I forgot to mention earlier ...
host(s) doing firewall bits? What about firewall logs or turning on
such logging - what does that show? Does it show
ICMP echo request/reply being dropped/filtered/rejected? Does it
even show it at all (firewall can also be used to pass and log
traffic or specific traffic). And ... blinkin' lights.
What do the lights on the relevant physical ports indicate?
Alas, not all hardware these days (and especially on laptops) includes
the relevant status/diagnostic LEDs ... and that's even more
absent on Wi-Fi ... but often such indicators tell, or help to tell,
what's going on (or not going on) ... at least in part. Even,
e.g. on physical, what speeds have been negotiated.
Oh, yeah, ... and blinkin' lights ... if there's an activity indicator,
that can also be highly useful - particularly if the traffic isn't
too chatty, and one can see - or see lack of - activity from the
ping packets. E.g. "quiet" enough to be able to see one little
activity flash per second from the one ping packet (and/or response)
per second? Bit noisier? What if does a fast little burst of ping
packets - then stops it ... then does it again for a bit? But if
the traffic / activity light is too "noisy"/chatty for that, not
so useful - especially if one can't feasibly quell such traffic even
for ping troubleshooting purposes. Oh, and nowadays, the blinkin'
lights for activity may not be as super-fast and responsive as they
once were. Security 'n all that. Notably on older equipment,
sometime the response on activity LEDs was so fast, that those LEDs
could be used to fully read network traffic from them - allowing one
to snoop all the wire traffic just from the flashing of the
LED ... "oops". Your server "room" (closet...ish) has a window?
Visible from about 20 other offices in that other building across the
street? Uh huh. There are reasons these things generally go in
windowless rooms.
So "that's too complicated" ... hardly so. One doesn't have to necessarily
use all of it ... but many possible things to look at were presented.
Any (and/or all) of them can be used to troubleshoot - to at least
start isolating where the issue is - or is more likely to be.
And if you want to disable a bunch 'o stuff in the picture (e.g.
Docker, VMs, etc.), sure, can do that too ... but if those are
expected to nominally be a functioning operational "up" part of
the setup, might not be so desirable to start disabling those
components.
two - quantity 2
too - also, excessive, or besides
to - https://www.merriam-webster.com/dictionary/to
you're - contraction for you are
your - possessive of you, that belonging to you
Example usages below.
And you're still making your signature way too long to be
appropriate for email/list. Also fails
S/N netiquette on signature length vs. new content.
Maybe try dropping it down to just two lines. Probably
wouldn't kill you or cause the world to end.
>> What about sniffing of traffic, most notably relevant ARP
>> related traffic and ICMP traffic - what does that
>> show? Is traffic making it in/out the correct interfaces
>> and to correct target(s)? What about firewall(s) on
>> host(s) and/or along the way?
>>
>> What else can/can't these hosts get to - and especially
>> on the same subnet? What else can/can't they ping?
>>
>> $ dig -x 75.75.75.75 +short
>> cdns01.comcast.net.
>> $ dig -x 75.75.76.76 +short
>> cdns02.comcast.net.
>> $
>>
>> This looks likely to be some home/office Comcast ISP setup.
>> What's between the hosts? Is it some Comcast
>> home/business "router"(/firewall/NAT/SNAt/...) device?
>> Is it firewalling the hosts from each other?
>> If the hosts are on same subnet, what if one connects them direct
>> with a crossover cable, or via just a switch with no firewall on it?
>>
>> >From: "Rick Moen" <rick at linuxmafia.com>
>> >Subject: [conspire] (forw) Re: Federales in Portland?
>> >Date: Tue, 28 Jul 2020 13:57:57 -0700
>>
>> >I'm assuming Denny meant to send this request for help to the public
>> >forum, rather than to me privately.
>> >
>> >----- Forwarded message from Denny Yang <yangcdenny at gmail.com> -----
>> >
>> >Date: Tue, 28 Jul 2020 13:34:43 -0700
>> >From: Denny Yang <yangcdenny at gmail.com>
>> >To: Rick Moen <rick at linuxmafia.com>
>> >Subject: Re: [conspire] Federales in Portland?
>> >
>> > Hi Rick,
>> >
>> >I hope this email finds you well.
>> >
>> >Right now my desktop and my laptop can't ping one to another.
>> >
>> >Here are the settings that I have so far for each machine. The desktop is
>> >connected to the router, and the laptop is using WIFI.
>> >
>> >*DESKTOP:*
>> >
>> >*#ip addr show *
>> >$enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP
>> >group default qlen 1000
>> > link/ether 8c:ec:4b:45:35:4c brd ff:ff:ff:ff:ff:ff
>> > inet 192.168.1.2/24 brd 192.168.1.255 scope global dynamic
>> >noprefixroute enp2s0
>> >
>> >#systemctl status NetworkManager.service = active/running, no
>> error messages
>> >
>> >*#netstat -rn*
>> >Kernel IP routing table
>> >Destination Gateway Genmask Flags MSS Window irtt
>> >Iface
>> >0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0
>> >enp2s0
>> >172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0
>> >docker0
>> >192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0
>> >enp2s0
>> >192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0
>> >virbr0
>> >
>> >*#/etc/resolv.conf*
>> ># Generated by NetworkManager
>> >nameserver 192.168.1.1
>> >
>> >*# firewall-cmd --zone=public --list-services*
>> >cockpit dhcpv6-client ftp ssh
>> >
>> >*# firewall-cmd --zone=public --list-ports*
>> >514/tcp
>> >
>> >*LAPTOP: *
>> >
>> >*ip addr show*
>> >wlp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
>> >group default qlen 1000
>> > link/ether 7c:67:a2:13:3c:a1 brd ff:ff:ff:ff:ff:ff
>> > inet 10.232.185.182/14 brd 10.235.255.255 scope global dynamic
>> >noprefixroute wlp1s0
>> >
>> >#systemctl status NetworkManager.service = active/running, no
>> error messages
>> >
>> >*# netstat -rn*
>> >Kernel IP routing table
>> >Destination Gateway Genmask Flags MSS Window irtt
>> >Iface
>> >0.0.0.0 10.232.0.1 0.0.0.0 UG 0 0 0
>> >wlp1s0
>> >10.232.0.0 0.0.0.0 255.252.0.0 U 0 0 0
>> >wlp1s0
>> >172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0
>> >docker0
>> >192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0
>> >virbr0
>> >
>> >*#/etc/resolv.conf*
>> >Generated by NetworkManager
>> >nameserver 75.75.75.75
>> >nameserver 75.75.76.76
>> >nameserver 2001:558:feed::1
>> ># NOTE: the libc resolver may not support more than 3 nameservers.
>> ># The nameservers listed below may not be recognized.
>> >nameserver 2001:558:feed::2
>> >
>> >*# firewall-cmd --zone=public --list-services*
>> >cockpit dhcpv6-client ftp ssh
>> >
>> >*# firewall-cmd --zone=public --list-ports*
>> >515/tcp 514/tcp
>> >
>> >Again, I apologize for this lengthy email. It's driving me nuts now why
>> >these two machines can't communicate with each other.
>> >I have a feeling that this has to do with the laptop IP 10.net. But still
>> >don't know where the problem is.
More information about the conspire
mailing list