On 12/06/2021 17:05, Marc Haber wrote:
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>> I see you dont understand basic networking
>>
>> When you do, please respond intelligently
>
> Pascal is right, and my upbringing forbids me to say what I think
> about you.
>
I see yet another baseless assertion

Tell me exactly why you think I am wrong

And how and why ARP and ethernet broadcasts and switches work, if not as
I have described?

Andy fool with a linux computer on a switch can run tcpdump , arp -a and
ascertain the truth of my assertions

--
“It is dangerous to be right in matters on which the established
authorities are wrong.”

― Voltaire, The Age of Louis XIV

On 12/06/2021 17:12, Dan Espen wrote:
> Marc Haber <mh+usenetspam1118@zugschl.us> writes:
>
>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>> I see you dont understand basic networking
>>>
>>> When you do, please respond intelligently
>>
>> Pascal is right, and my upbringing forbids me to say what I think
>> about you.
>
> He may be right, but it would be nice if he gave some hints so some of us
> could learn something.
>
Well, as I said. if you are on an ethernet switch and have a linux
computer, type arp -a, and tcpdump, and see just what DOES happen. No
need to take my word for it.

--
In todays liberal progressive conflict-free education system, everyone
gets full Marx.

Le 12-06-2021, The Natural Philosopher <tnp@invalid.invalid> a écrit :
> On 12/06/2021 15:03, Pascal Hambourg wrote:
>> No.
> I see you dont understand basic networking

Pascal, like everyone else can make mistakes, and you can desagree with
him on some points. But saying he doesn't understand basic networking is
very funny.

--
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

On 12.6.21 15.26, The Natural Philosopher wrote:
> On 12/06/2021 12:03, Marc Haber wrote:
>>> I have (WIFI) clients at 192.168.0.100 to 192.168.0.110, with the router
>>> being 192.168.0.1, and they all can "see" each other. There was no need
>>> for any "port mirroring" or other configurations after I received it.
>> Usually, on a properly functioning switch, Client B cannot "see" the
>> traffic that occurs between Clients A and C despite being able to both
>> communicate with A and C.
>
> It all depends what you mean by 'see'...
>
> Switches will only relay packets to MAC addresses known to be on a given
> segment.
>
> Initial discovery is done, on an IP network, by means of an Ethernet
> 'all stations' broadcast...of the desired IP address. The desired IP
> address responds, on its own MAC address, and the switch then 'knows'
> where it is.
>
> Two computers on a switch may 'see' each other, but that's only because
> they have stored the same relationship between IP address and MAC
> address, in their own 'ARP' tables. So they 'know' what MAC address to
> send an IP address on. And the switch 'knows' which segment the MAC
> address is on....

Please get a switch chip datasheet from
<http://ww1.microchip.com/downloads/en/DeviceDoc/ks8995ma.pdf>.

It is one of the quite similar chips doing the works in switches.
Start reading from page 26. The switch description starts from
page 29.

It is fruitless to argue about a mixture of level 2 and level 3
networking functions, when the switches run on layer 2 only.
They do not care about the TCP/IP packets inside the Ethernet
frames.

--

-TV

On 12/06/2021 18:08, Stéphane CARPENTIER wrote:
> Le 12-06-2021, The Natural Philosopher <tnp@invalid.invalid> a écrit :
>> On 12/06/2021 15:03, Pascal Hambourg wrote:
>>> No.
>> I see you dont understand basic networking
>
> Pascal, like everyone else can make mistakes, and you can desagree with
> him on some points. But saying he doesn't understand basic networking is
> very funny.
>
Then he is being deliberately insulting for some reason and got exactly
what he deserved

--
No Apple devices were knowingly used in the preparation of this post.

On 12/06/2021 18:24, Tauno Voipio wrote:
> On 12.6.21 15.26, The Natural Philosopher wrote:
>> On 12/06/2021 12:03, Marc Haber wrote:
>>>> I have (WIFI) clients at 192.168.0.100 to 192.168.0.110, with the
>>>> router
>>>> being 192.168.0.1, and they all can "see" each other. There was no need
>>>> for any "port mirroring" or other configurations after I received it.
>>> Usually, on a properly functioning switch, Client B cannot "see" the
>>> traffic that occurs between Clients A and C despite being able to both
>>> communicate with A and C.
>>
>> It all depends what you mean by 'see'...
>>
>> Switches will only relay packets to MAC addresses known to be on a
>> given segment.
>>
>> Initial discovery is done, on an IP network, by means of an Ethernet
>> 'all stations' broadcast...of the desired IP address. The desired IP
>> address responds, on its own MAC address, and the switch then 'knows'
>> where it is.
>>
>> Two computers on a switch may 'see' each other, but that's only
>> because they have stored the same relationship between IP address and
>> MAC address, in their own 'ARP' tables. So they 'know' what MAC
>> address to send an IP address on. And the switch 'knows' which segment
>> the MAC address is on....
>
>
> Please get a switch chip datasheet from
> <http://ww1.microchip.com/downloads/en/DeviceDoc/ks8995ma.pdf>.
>
> It is one of the quite similar chips doing the works in switches.
> Start reading from page 26. The switch description starts from
> page 29.
>
> It is fruitless to argue about a mixture of level 2 and level 3
> networking functions, when the switches run on layer 2 only.
> They do not care about the TCP/IP packets inside the Ethernet
> frames.
>
But that is what he said..

"Two computers on a switch may 'see' each other, but that's only
because they have stored the same relationship between IP address and
MAC address, in their own 'ARP' tables. So they 'know' what MAC
address to send an IP address on.

*And the switch 'knows' which segment
the MAC address is on*...."
>

--
No Apple devices were knowingly used in the preparation of this post.

The Natural Philosopher <tnp@invalid.invalid> writes:

> On 12/06/2021 17:12, Dan Espen wrote:
>> Marc Haber <mh+usenetspam1118@zugschl.us> writes:
>>
>>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>> I see you dont understand basic networking
>>>>
>>>> When you do, please respond intelligently
>>>
>>> Pascal is right, and my upbringing forbids me to say what I think
>>> about you.
>> He may be right, but it would be nice if he gave some hints so some
>> of us
>> could learn something.
>>
> Well, as I said. if you are on an ethernet switch and have a linux
> computer, type arp -a,

Cool answer.
That shows me the 3 routers on my network.
The FIOS router,
The extender router I put in my kitchen,
and well, I didn't think I had another router.
The third router is my FIOS DVR master station.

> and tcpdump, and see just what DOES happen. No
> need to take my word for it.

That's a lot of output.
I wondered if there was some easier way to look at what is going on.
Which led me to install wireshark.
Looks like it is simpler to use tcpdump.

--
Dan Espen

On Sat, 12 Jun 2021 16:34:15 +0100, The Natural Philosopher wrote:
>
> On 12/06/2021 16:30, Andreas Kohlbach wrote:
>> On Sat, 12 Jun 2021 14:17:15 +0100, The Natural Philosopher wrote:
>>>
>>> Up to a point. Traffic is enrcypted on WPA/WPA2.
>> The connection between devices and the router is, not the traffic
>> between
>> them. Not by default.
>>
>
> What on earth does that mean?
>
> All traffic goes via the wifi point so all traffic is encrypted...

Let's say I connect two WIFI devices to my router. The connection is via
WPA2. But the devices can for example ping each other. A ping doesn't use
encryption.
--
Andreas

Andreas Kohlbach <ank@spamfence.net> wrote:
>A ping doesn't use
>encryption.

A ping IP datagram will of course use the same encryption that is used
by TCP/UDP/something IP traffic going over the same layer 2 link.

Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

On Sat, 12 Jun 2021 22:21:00 +0200, Marc Haber wrote:
>
> Andreas Kohlbach <ank@spamfence.net> wrote:
>>A ping doesn't use
>>encryption.
>
> A ping IP datagram will of course use the same encryption that is used
> by TCP/UDP/something IP traffic going over the same layer 2 link.

Okay, on different layer everything is encrypted when using WIFI with WPA2.
--
Andreas

PGP fingerprint 952B0A9F12C2FD6C9F7E68DAA9C2EA89D1A370E0

On Fri, 11 Jun 2021 13:09:46 -0400, Andreas Kohlbach
<ank@spamfence.net> wrote:

>On Fri, 11 Jun 2021 00:22:21 -0400, Margin <M287v1.cloud> wrote:
>>
>> Say you have an office with 100, or 500, PCs - mostly Windows.
>
>Congratulations!

ANY Windows boxes are a disaster-in-waiting ....

>> ONE of them clicks the fatal e-mail and unloads an encryption
>> virus against every available local/network drive.
>>
>> How best to find THE offender, so it can be nuked, sterilized
>> and re-installed from scratch ?
>>
>> In theory, something like tcpdump could record CIFS traffic
>> and keep logs for a day or so (data volume can be HIGH).
>> Alas now that SWITCHES have replaced HUBS, no given
>> machine sees ALL the network traffic. And no, you aren't
>> going to buy a gigabit or especially 10/gb hub these days.
>
>Assuming access to file's metadata I'd probably go for the date stamps,
>further assuming the ransomware isn't manipulating them itself
>(i.e. setting all of them to 1.1.1980 or something). And that all
>computers have a synchronous time, more or less accurate.
>
>You need to know at least one file existing on every computer which was
>encrypted and check their date stamp on every computer in the
>network. The one with the oldest should be the patient 0.
>
>> I have a theory that a software-based firewall/router - first
>> thing after the cable modem - MIGHT be able to see all of
>> the traffic all of the time ... but I'll have to test this in several
>> ways.
>>
>> The offending box will be the one generating huge volumes
>> of SMB/CIFS traffic to the NAS's in the last hour before
>> everything crashes.
>
>For my knowledge ransomware works like any (also human) virus or zombie
>outbreak: every infected will infect others without the need of patient 0.
>
>It'll be pointless to find patient 0.

Depends. State-sponsored malware, especially in an
environment using central/remote-management and
some ability to push "updates" to every machine on
the intranet ... yes, BIG problem.

However the low-budget kinda script-kiddies more
likely to go for the relatively non-infrastructure targets,
well, you're more likely looking at a JavaScript or
maybe one that installs an evil executable on the
ONE machine.

If it IS the "one machine" variant, how do you find
the ONE MACHINE ?

Oh, TRIED it on a software-based firewall/router.
Tcpdump and others could NOT see CIFS traffic.
All the ARP you wanted, but not CIFS. The actual
software that came with the thing COULD see it,
or at least identify traffic volume from individual
boxes - but did not really pin down the TYPE of
traffic from said boxes.

This MIGHT be fixable ... maybe .....

On Fri, 11 Jun 2021 17:27:56 +0000 (UTC), Anass Luca
<AL@invalid.invalid> wrote:

>Margin <M287v1.cloud> wrote:
>> Say you have an office with 100, or 500, PCs - mostly Windows.
>
>If this is true, then the remainder of your post should have gone to a
>windows newsgroup.

I would not lower myself to that ...

On Fri, 11 Jun 2021 20:17:48 -0400, John-Paul Stewart
<jpstewart@personalprojects.net> wrote:

>On 2021-06-11 12:22 a.m., Margin wrote:
>>
>> In theory, something like tcpdump could record CIFS traffic
>> and keep logs for a day or so (data volume can be HIGH).
>> Alas now that SWITCHES have replaced HUBS, no given
>> machine sees ALL the network traffic. And no, you aren't
>> going to buy a gigabit or especially 10/gb hub these days.
>>
>> I have a theory that a software-based firewall/router - first
>> thing after the cable modem - MIGHT be able to see all of
>> the traffic all of the time ... but I'll have to test this in several
>> ways.
>
>The firewall/router will only see the traffic going through it, in to or
>out of the LAN. It won't see any traffic that is entirely internal to
>the LAN.

Well, some - but maybe not all - of the LAN traffic
goes through it.

The "not all" aspect is the problem.

Know anybody who makes a gigabit/10gb HUB type
devices - where ALL the traffic can be seen ?

>However, most managed switches can be configured for "port mirroring" to
>send duplicates of all packets to a specific port on that switch for the
>sort of monitoring you're considering. Read up on "port mirroring" and
>see if your switch supports it.

Depends of the scale/budget of the org. UNmanaged switches
are the norm. Cheap and easy.

So, how to get AROUND that ?

This is hardly a trivial question these days.

On Sat, 12 Jun 2021 13:26:08 +0100, The Natural Philosopher
<tnp@invalid.invalid> wrote:

>On 12/06/2021 12:03, Marc Haber wrote:
>>> I have (WIFI) clients at 192.168.0.100 to 192.168.0.110, with the router
>>> being 192.168.0.1, and they all can "see" each other. There was no need
>>> for any "port mirroring" or other configurations after I received it.
>> Usually, on a properly functioning switch, Client B cannot "see" the
>> traffic that occurs between Clients A and C despite being able to both
>> communicate with A and C.
>
>It all depends what you mean by 'see'...
>
>Switches will only relay packets to MAC addresses known to be on a given
>segment.

Well, this is part of the problem ... "optimization" has
become a vulnerability. No one PC sees ALL the traffic
on the intranet.

Try Wireshark or equivalent - YOUR box will NOT see
everything going on.

So, since I can't buy a gigabit+ HUB that ALL the traffic
passes through, the only solution seems to be to MAKE
one from scratch - and monitor from that. The hardware
requirements are not too high, one notch above a rPi4,
but the software might be a bit of a trick. SuperMicro
sells a dynamite "micro-server" board (does all KINDS
of stuff) that'd be perfect - you can even get it pre-boxxed.

Basically, you need one "hub" that EVERYTHING has to
pass through for every LAN segment. If it's a small office
there will probably be only one segment ... 192.168.0.0/24
or whatever.

So, what am I looking at .... CableModem -> firewall/router ->
"Hub" -> various switches ? The "central" distribution device
has to be the faux Hub - ALL traffic has to pass through it
with minimal slowdown.

>'all stations' broadcast...of the desired IP address. The desired IP
>address responds, on its own MAC address, and the switch then 'knows'
>where it is.
>
>Two computers on a switch may 'see' each other, but that's only because
>they have stored the same relationship between IP address and MAC
>address, in their own 'ARP' tables. So they 'know' what MAC address to
>send an IP address on. And the switch 'knows' which segment the MAC
>address is on....
>
>A google of Address Resolution Protocol and Ethernet Broadcast should
>make it all clear.
>
>What port mirroring does is stop the switch from being selective about
>which port it sends an MAC address directed packet down, and send it to
>other or all ports.
>
>If you have a linux or *nix machine, tcpdump enables you to see that all
>traffic on a given Ethernet segments is *apart from Ethernet broadcasts*
>limited to that machine alone.
>
>The move from coaxial ethernet to switches destroyed the hackers dream
>of being able to see in clear everything that was happening on a network.
>
>Wifi largely reinstated it :-)
>Wifi acts like a coaxial network.
>
>It is encrypted but...if you capture the encryption handshakes, it can
>be decrypted...

On 12/06/2021 19:07, Andreas Kohlbach wrote:
> On Sat, 12 Jun 2021 16:34:15 +0100, The Natural Philosopher wrote:
>>
>> On 12/06/2021 16:30, Andreas Kohlbach wrote:
>>> On Sat, 12 Jun 2021 14:17:15 +0100, The Natural Philosopher wrote:
>>>>
>>>> Up to a point. Traffic is enrcypted on WPA/WPA2.
>>> The connection between devices and the router is, not the traffic
>>> between
>>> them. Not by default.
>>>
>>
>> What on earth does that mean?
>>
>> All traffic goes via the wifi point so all traffic is encrypted...
>
> Let's say I connect two WIFI devices to my router. The connection is via
> WPA2. But the devices can for example ping each other. A ping doesn't use
> encryption.
>
I would not be sure about that. WPA encryption is below IP/ICMP layer.

--
"The great thing about Glasgow is that if there's a nuclear attack it'll
look exactly the same afterwards."

Billy Connolly

On 12/06/2021 21:21, Marc Haber wrote:
> Andreas Kohlbach <ank@spamfence.net> wrote:
>> A ping doesn't use
>> encryption.
>
> A ping IP datagram will of course use the same encryption that is used
> by TCP/UDP/something IP traffic going over the same layer 2 link.
>
> Greetings
> Marc
>
That is my understanding too.

--
"The great thing about Glasgow is that if there's a nuclear attack it'll
look exactly the same afterwards."

Billy Connolly

On 13/06/2021 05:51, Margin wrote:
> On Sat, 12 Jun 2021 13:26:08 +0100, The Natural Philosopher
> <tnp@invalid.invalid> wrote:
>
>> On 12/06/2021 12:03, Marc Haber wrote:
>>>> I have (WIFI) clients at 192.168.0.100 to 192.168.0.110, with the router
>>>> being 192.168.0.1, and they all can "see" each other. There was no need
>>>> for any "port mirroring" or other configurations after I received it.
>>> Usually, on a properly functioning switch, Client B cannot "see" the
>>> traffic that occurs between Clients A and C despite being able to both
>>> communicate with A and C.
>>
>> It all depends what you mean by 'see'...
>>
>> Switches will only relay packets to MAC addresses known to be on a given
>> segment.
>
> Well, this is part of the problem ... "optimization" has
> become a vulnerability. No one PC sees ALL the traffic
> on the intranet.
>
I think that it has reduced vulnerabilities immensely as well as
improving speeds dramatically

It just makes your situation very hard to tackle.

> Try Wireshark or equivalent - YOUR box will NOT see
> everything going on.
>
> So, since I can't buy a gigabit+ HUB that ALL the traffic
> passes through, the only solution seems to be to MAKE
> one from scratch - and monitor from that. The hardware
> requirements are not too high, one notch above a rPi4,
> but the software might be a bit of a trick. SuperMicro
> sells a dynamite "micro-server" board (does all KINDS
> of stuff) that'd be perfect - you can even get it pre-boxxed.
>
> Basically, you need one "hub" that EVERYTHING has to
> pass through for every LAN segment. If it's a small office
> there will probably be only one segment ... 192.168.0.0/24
> or whatever.
>
Thus crippling performance.

> So, what am I looking at .... CableModem -> firewall/router ->
> "Hub" -> various switches ? The "central" distribution device
> has to be the faux Hub - ALL traffic has to pass through it
> with minimal slowdown.
>
buy a managed hub that *will* allow port mirroring and traffic
monitoring. I am sure such exist.

--
“The fundamental cause of the trouble in the modern world today is that
the stupid are cocksure while the intelligent are full of doubt."

- Bertrand Russell

Dan Espen <dan1espen@gmail.com> wrote:
>Marc Haber <mh+usenetspam1118@zugschl.us> writes:
>
>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>I see you dont understand basic networking
>>>
>>>When you do, please respond intelligently
>>
>> Pascal is right, and my upbringing forbids me to say what I think
>> about you.
>
>He may be right, but it would be nice if he gave some hints so some of us
>could learn something.

The problem is that TNP's musings are so absurd that it would need to
write a textbook way beyond any tl;dr to properly explain that. TNP
has got all those pesky little network layers mixed up that one would
nee to start from Adam and Eve to properly explain that.

Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Dan Espen <dan1espen@gmail.com> wrote:
>That's a lot of output.
>I wondered if there was some easier way to look at what is going on.
>Which led me to install wireshark.
>Looks like it is simpler to use tcpdump.

It is not. Just way more confusing for the beginner.

I recommend filtering away the "noise" (using "not foo and not bar"
expressions) instead of just selecting what you want to see.

Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Marc Haber <mh+usenetspam1118@zugschl.us> writes:

> Dan Espen <dan1espen@gmail.com> wrote:
>>That's a lot of output.
>>I wondered if there was some easier way to look at what is going on.
>>Which led me to install wireshark.
>>Looks like it is simpler to use tcpdump.
>
> It is not. Just way more confusing for the beginner.
>
> I recommend filtering away the "noise" (using "not foo and not bar"
> expressions) instead of just selecting what you want to see.

I start up wireshark, it shows me 5 interfaces, none of which make sense
to me. I leave them enabled, type something in the filter box.

At this point I have no idea what to do next to see anything.

It sure is confusing for this beginner.

--
Dan Espen

On Sun, 13 Jun 2021 09:41:21 +0100, The Natural Philosopher wrote:
>
> On 12/06/2021 19:07, Andreas Kohlbach wrote:
>
>> Let's say I connect two WIFI devices to my router. The connection is
>> via
>> WPA2. But the devices can for example ping each other. A ping doesn't use
>> encryption.
>>
> I would not be sure about that. WPA encryption is below IP/ICMP layer.

From what I understand, traffic from a host, encrypted not not, is
encapsulated in a "secure layer". While ping data for example are not
encrypted, they get "packed up" for transfer over the air. Before
reaching the target machine the traffic gets unpacked again. The target
machine only receives unencrypted data (*after* the traffic went over the
air encrypted) in this case.

Anyway, that does not help the OP. He wants to find out the first
infected machine. Which I still find pointless.

The only interesting thing is to find the very first machine (the of the
scammer) starting it all to acquire GEO data for an ICBM. :-D
--
Andreas

Le 13/06/2021 à 13:00, Marc Haber a écrit :
> Dan Espen <dan1espen@gmail.com> wrote:
>>
>> He may be right, but it would be nice if he gave some hints so some of us
>> could learn something.

Of course. My apologies for the laconic answer. I had no time for a more
complete answser and just wanted to prevent anyone from learning
something wrong, hoping that someone else may add clarifications.

> The problem is that TNP's musings are so absurd that it would need to
> write a textbook way beyond any tl;dr to properly explain that. TNP
> has got all those pesky little network layers mixed up that one would
> nee to start from Adam and Eve to properly explain that.

I a not going to explain networking from scratch, but I will try to
elaborate a bit on my initial answer.

Explanations about my initial reply.

Le 12/06/2021 à 16:03, Pascal Hambourg a écrit :
> Le 12/06/2021 à 14:26, The Natural Philosopher a écrit :
>
>> Switches will only relay packets to MAC addresses known to be on a
>> given segment.
>
> No.

A switch will forward all valid data frames.
If it knows that the host with a given MAC address is associated with a
given port, it will forward a frame destined for this address only on
that port. Otherwise it will forward a frame on all ports but the one
which received the frame.

>> Initial discovery is done, on an IP network, by means of an Ethernet
>> 'all stations' broadcast.
>
> No.

"IP" means not only IPv4 but also IPv6.
IPv4 may use ethernet broadcast for address resolution (ARP) an others.
But IPv6 does not use ethernet broadcast at all, it uses ethernet
multicast instead.

>> Two computers on a switch may 'see' each other, but that's only
>> because they have stored the same relationship between IP address and
>> MAC address, in their own 'ARP' tables.
>
> No.

Computers can communicate with IPv4 broadcast or multicast, not
requiring any IP-MAC relationship in their ARP table. Also, they can
communicate with IPv6, which does not use ARP but NDP (Neighbour
Discovery Protocol) instead, or even non IP protocols (e.g. IPX).

>> What port mirroring does is stop the switch from being selective about
>> which port it sends an MAC address directed packet down, and send it
>> to other or all ports.
>
> No.

Port mirroring forwards all traffic received (and maybe sent) on a port
to another port. It has nothing to do with MAC addresses.

>> If you have a linux or *nix machine, tcpdump enables you to see that
>> all traffic on a given Ethernet segments is *apart from Ethernet
>> broadcasts* limited to that machine alone.
>
> No.

tcpdump will also show multicast frames and unicast frames destined for
other MAC addresses when the switch does not know which port they are
associated with.

Le 13-06-2021, Andreas Kohlbach <ank@spamfence.net> a écrit :
> On Sun, 13 Jun 2021 09:41:21 +0100, The Natural Philosopher wrote:
>>
>> On 12/06/2021 19:07, Andreas Kohlbach wrote:
>>
>>> Let's say I connect two WIFI devices to my router. The connection is
>>> via
>>> WPA2. But the devices can for example ping each other. A ping doesn't use
>>> encryption.
>>>
>> I would not be sure about that. WPA encryption is below IP/ICMP layer.
>
> From what I understand, traffic from a host, encrypted not not, is
> encapsulated in a "secure layer". While ping data for example are not
> encrypted, they get "packed up" for transfer over the air. Before
> reaching the target machine the traffic gets unpacked again. The target
> machine only receives unencrypted data (*after* the traffic went over the
> air encrypted) in this case.

When you are using wifi from your laptop to access an Internet website,
with https or with ping, the packets aren't going through the air from
your laptop to the website. The packets are going through the air from
your laptop to your box, then from your box to your ISP, then after a
lot of routers, switches or whatever, to the server hosting the website.

The WPA is only taking care of what's going on between your laptop and
your box. So everything you send from your laptop is encrypted between
your laptop and your box by the WPA.

After the packets left your box, it depends. If you put a VPN,
everything will be encrypted between your computer and the end of your
VPN. If you have nothing special, the ping won't be longer encrypted
except from some part of the way which can be encrypted. The https will
be encrypted from begin to end whatever the rest.

--
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

Le 13-06-2021, Dan Espen <dan1espen@gmail.com> a écrit :
> Marc Haber <mh+usenetspam1118@zugschl.us> writes:
>
>> Dan Espen <dan1espen@gmail.com> wrote:
>>>That's a lot of output.
>>>I wondered if there was some easier way to look at what is going on.
>>>Which led me to install wireshark.
>>>Looks like it is simpler to use tcpdump.
>>
>> It is not. Just way more confusing for the beginner.
>>
>> I recommend filtering away the "noise" (using "not foo and not bar"
>> expressions) instead of just selecting what you want to see.
>
> I start up wireshark, it shows me 5 interfaces, none of which make sense
> to me. I leave them enabled, type something in the filter box.
>
> At this point I have no idea what to do next to see anything.
>
> It sure is confusing for this beginner.

If you have systemd on your computer with the default, you should have
an interface beginning with wlp (for wifi) or enp (for Ethernet). You
chose the one you are using. To help you, there is the trafic seen on the
interfaces on the right of the names. You can choose any if you want to
see all the trafic, it will be just more noisy.

If you know an http (not https) website you can do something like (I
don't know the exact English terms in the menu) :
Analyse -> Follow -> http stream

It's very interesting to begin with.

Maybe you don't encrypt your connexion when you read/write the
newsgroups and you can follow the TCP stream.

--
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io