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

Groups > comp.os.linux.networking > #4504 > unrolled thread

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

Back to article view | Back to comp.os.linux.networking

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

Page 2 of 2 — ← Prev page 1 [2]

#4524

On 3/28/20 10:53 PM, Carlos E.R. wrote:
> I knew of separate networks that used Fidonet protocols and software, 
> but not connected to it. But I did not know, in my country, of different 
> protocols to form a BBS network …

Agreed.

> … except perhaps to connect a very small number of BBS, like two or 
> three that had some areas in common.

I suspect that type of thing happened a number of places on a very small 
scale.  There needs to be a good reason to not re-use FTN if both boards 
support it.  The only reason that I can think of is if one of the boards 
does not support FTN and something else must be used between them.

> Also I heard, this century, that Fidonet software was used and developed 
> in Russia, at least for some years.

I heard it described as Russians are the predominant remaining users of 
FidoNet (proper) and / or FTNs.  The subtext was that it's a 
communications mechanism that survives that doesn't /depend/ on the 
Internet.  Since the Russians are the predominant users, they are the 
logical place for most support to come from, ergo development.



-- 
Grant. . . .
unix || die

[toc] | [prev] | [next] | [standalone]

#4526

On 29/03/2020 18.53, Grant Taylor wrote:
> On 3/28/20 10:53 PM, Carlos E.R. wrote:
>> I knew of separate networks that used Fidonet protocols and software, 
>> but not connected to it. But I did not know, in my country, of 
>> different protocols to form a BBS network …
> 
> Agreed.
> 
>> … except perhaps to connect a very small number of BBS, like two or 
>> three that had some areas in common.
> 
> I suspect that type of thing happened a number of places on a very small 
> scale.  There needs to be a good reason to not re-use FTN if both boards 
> support it.  The only reason that I can think of is if one of the boards 
> does not support FTN and something else must be used between them.
> 
>> Also I heard, this century, that Fidonet software was used and 
>> developed in Russia, at least for some years.
> 
> I heard it described as Russians are the predominant remaining users of 
> FidoNet (proper) and / or FTNs.  The subtext was that it's a 
> communications mechanism that survives that doesn't /depend/ on the 
> Internet.  Since the Russians are the predominant users, they are the 
> logical place for most support to come from, ergo development.

Yes.

Maybe it is more resilient to eavesdropping, unless they hack one of the 
nodes. Maybe they have added cryptography to it :-?


-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#4527

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.



-- 
Grant. . . .
unix || die

[toc] | [prev] | [next] | [standalone]

#4528

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.

[toc] | [prev] | [next] | [standalone]

#4529

On 3/31/20 9:52 PM, Carlos E.R. wrote:
> Oh, snooping on telephone is easy if you have the power to do it.

I agree with everything that you've said.

My comment is that the access required to do what you have described is 
significantly higher and there are correspondingly fewer people that can 
do that.  Especially with comparison to people doing functional 
equivalents at the IP layer.



-- 
Grant. . . .
unix || die

[toc] | [prev] | [next] | [standalone]

#4530

On 01/04/2020 18.03, Grant Taylor wrote:
> On 3/31/20 9:52 PM, Carlos E.R. wrote:
>> Oh, snooping on telephone is easy if you have the power to do it.
> 
> I agree with everything that you've said.
> 
> My comment is that the access required to do what you have described is 
> significantly higher and there are correspondingly fewer people that can 
> do that.  Especially with comparison to people doing functional 
> equivalents at the IP layer.

Yes, there is so.

-- 
Cheers, Carlos.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.os.linux.networking

csiph-web