Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.os.linux.networking > #4528

Re: Understanding Send-Q and Recv-Q by netstat

From "Carlos E.R." <robin_listas@es.invalid>
Newsgroups comp.os.linux.networking
Subject Re: Understanding Send-Q and Recv-Q by netstat
Date 2020-04-01 05:52 +0200
Message-ID <npfdlg-bm2.ln1@Telcontar.valinor> (permalink)
References (16 earlier) <r5ogek$9ht$1@tncsrv09.home.tnetconsulting.net> <a7m5lg-mqt.ln1@Telcontar.valinor> <r5qjqs$aq6$1@tncsrv09.home.tnetconsulting.net> <593alg-01p.ln1@Telcontar.valinor> <r5u3to$j11$3@tncsrv09.home.tnetconsulting.net>

Show all headers | View raw


On 31/03/2020 02.46, Grant Taylor wrote:
> On 3/30/20 3:00 PM, Carlos E.R. wrote:
>> Maybe it is more resilient to eavesdropping, unless they hack one of 
>> the nodes. Maybe they have added cryptography to it :-?
> 
> I haven't heard any indication that cryptography was part of it.  But my 
> ignorance of such doesn't preclude it from possibly existing.
> 
> I speculate that point-to-point dial up connections are more problematic 
> to snoop on than Internet traffic.
> 
> I'm sure that it can be done, but someone has to want to do it.  Where 
> as snooping on Internet traffic is an old hat trick.

Oh, snooping on telephone is easy if you have the power to do it.

If the network is digital (I know that parts of the old soviet union was 
analogical by year 2000, but I have no idea about now) is easy. 
Basically, you just tell a processor to copy a stream of incoming bytes 
to another position in memory map besides the one of the destination 
phone. No one outside finds out, there are no clicks to hear, and the 
copy is bit perfect.

Now, once you have the bit stream you need a digital signal processor to 
analyze the bit stream to recreate the equivalent modem signal and 
decode the original digital stream - without the recourse to negotiate 
anything; the stream is unidirectional, listen only. I'm sure any 
intelligence agency or police body has that capability.

The only real tricky part is having the power to snoop.

If not, then the alternative is a physical wire tap at the line, but 
this might be detected. Maybe not if it is high impedance.


Not that I have ever done it :-D

-- 
Cheers, Carlos.

Back to comp.os.linux.networking | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Re: Understanding Send-Q and Recv-Q by netstat navinpksh@gmail.com - 2020-03-26 01:18 -0700
  Re: Understanding Send-Q and Recv-Q by netstat Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-03-26 11:41 +0000
  Re: Understanding Send-Q and Recv-Q by netstat Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2020-03-26 14:13 +0200
  Re: Understanding Send-Q and Recv-Q by netstat "Carlos E.R." <robin_listas@es.invalid> - 2020-03-26 13:55 +0100
    Re: Understanding Send-Q and Recv-Q by netstat navinpksh@gmail.com - 2020-03-26 07:05 -0700
      Re: Understanding Send-Q and Recv-Q by netstat "Carlos E.R." <robin_listas@es.invalid> - 2020-03-26 22:05 +0100
      Re: Understanding Send-Q and Recv-Q by netstat Grant Taylor <gtaylor@tnetconsulting.net> - 2020-03-26 15:59 -0600
        Re: Understanding Send-Q and Recv-Q by netstat navinpksh@gmail.com - 2020-03-27 10:15 -0700
          Re: Understanding Send-Q and Recv-Q by netstat Grant Taylor <gtaylor@tnetconsulting.net> - 2020-03-27 13:23 -0600
          Re: Understanding Send-Q and Recv-Q by netstat Grant Taylor <gtaylor@tnetconsulting.net> - 2020-03-27 13:34 -0600
          Re: Understanding Send-Q and Recv-Q by netstat "Carlos E.R." <robin_listas@es.invalid> - 2020-03-27 21:52 +0100
            Re: Understanding Send-Q and Recv-Q by netstat Grant Taylor <gtaylor@tnetconsulting.net> - 2020-03-27 15:52 -0600
              Re: Understanding Send-Q and Recv-Q by netstat "Carlos E.R." <robin_listas@es.invalid> - 2020-03-27 23:23 +0100
                Re: Understanding Send-Q and Recv-Q by netstat Grant Taylor <gtaylor@tnetconsulting.net> - 2020-03-27 16:59 -0600
                Re: Understanding Send-Q and Recv-Q by netstat Ted Heise <theise@panix.com> - 2020-03-28 12:44 +0000
                Re: Understanding Send-Q and Recv-Q by netstat "Carlos E.R." <robin_listas@es.invalid> - 2020-03-28 22:24 +0100
                Re: Understanding Send-Q and Recv-Q by netstat Grant Taylor <gtaylor@tnetconsulting.net> - 2020-03-28 15:43 -0600
                Re: Understanding Send-Q and Recv-Q by netstat "Carlos E.R." <robin_listas@es.invalid> - 2020-03-29 06:53 +0200
                Re: Understanding Send-Q and Recv-Q by netstat "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2020-03-29 01:28 -0400
                Re: Understanding Send-Q and Recv-Q by netstat "Carlos E.R." <robin_listas@es.invalid> - 2020-03-29 15:13 +0200
                Re: Understanding Send-Q and Recv-Q by netstat Grant Taylor <gtaylor@tnetconsulting.net> - 2020-03-29 10:53 -0600
                Re: Understanding Send-Q and Recv-Q by netstat "Carlos E.R." <robin_listas@es.invalid> - 2020-03-30 23:00 +0200
                Re: Understanding Send-Q and Recv-Q by netstat Grant Taylor <gtaylor@tnetconsulting.net> - 2020-03-30 18:46 -0600
                Re: Understanding Send-Q and Recv-Q by netstat "Carlos E.R." <robin_listas@es.invalid> - 2020-04-01 05:52 +0200
                Re: Understanding Send-Q and Recv-Q by netstat Grant Taylor <gtaylor@tnetconsulting.net> - 2020-04-01 10:03 -0600
                Re: Understanding Send-Q and Recv-Q by netstat "Carlos E.R." <robin_listas@es.invalid> - 2020-04-01 22:25 +0200

csiph-web