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

Groups > linux.debian.user > #176972 > unrolled thread

The connections resets after some time.

Back to article view | Back to linux.debian.user

Contents

  The connections resets after some time. Daniel Bareiro <daniel-listas@gmx.net> - 2017-01-24 16:00 +0100
    Re: The connections resets after some time. Armando Cerna <armando@cerna.ca> - 2017-01-24 17:00 +0100
      Re: The connections resets after some time. Daniel Bareiro <daniel-listas@gmx.net> - 2017-01-24 17:20 +0100
    Re: The connections resets after some time. Henrique de Moraes Holschuh <hmh@debian.org> - 2017-01-24 17:40 +0100
      Re: The connections resets after some time. Daniel Bareiro <daniel-listas@gmx.net> - 2017-01-24 21:00 +0100
      Re: The connections resets after some time. Daniel Bareiro <daniel-listas@gmx.net> - 2017-01-27 22:30 +0100
        Re: The connections resets after some time. Henrique de Moraes Holschuh <hmh@debian.org> - 2017-01-27 23:20 +0100
          Re: The connections resets after some time. Daniel Bareiro <daniel-listas@gmx.net> - 2017-01-27 23:40 +0100
            Re: The connections resets after some time. Daniel Bareiro <daniel-listas@gmx.net> - 2017-01-28 00:40 +0100
              Re: The connections resets after some time. Henrique de Moraes Holschuh <hmh@debian.org> - 2017-01-28 15:50 +0100
                Re: The connections resets after some time. Daniel Bareiro <daniel-listas@gmx.net> - 2017-01-28 16:50 +0100
                  Re: The connections resets after some time. Daniel Bareiro <daniel-listas@gmx.net> - 2017-01-28 19:40 +0100

#176972 — The connections resets after some time.

[Multipart message — attachments visible in raw view] — view raw

Hi all!

It's been a bit more than a week since I've been observing that, from
time to time, I lose the established connections. I realize this because
I have for example an SSH connection against a server in France that
freezes and a few minutes later I see that Pidgin reconnects.

It is quite strange. At first I noticed this from my notebook connected
via wifi to a wireless router that is connected to a switch.

Here some connection loss records (there may have been more, but these
are the ones that I registered):

------------------------------------------------------------------------
13/01:
------

08.09
09.16
10.29
12.06
13.09
14.10
15.33
18.02
20.31
22.13

14/01:
------

07.33
08.42
09.54
11.13
12.27
15.09
16.05
17.27
19.54
22.15

15/01:
------

13.23
18.01
19.16
20.35
22.55

16/01:
------

00.10
10.05
11.16

12.10 => Here, to rule out that this was a problem in the wireless
connection, I connected the notebook to the same router but this time
wired. Reconnections persisted, as you can see.

12.34
14.58
16.11

16.17 => So I did what I think would be the definitive test: I connected
the notebook to the cablemodem directly, wired. Reconnections persisted.

17.30
18.40
19.57

20.56 => Again change to wireless mode as the cuts are given by
connecting directly.

21.10
22.44

17/01:
------
07.21
08.14
09.53
10.44

14.25
15.39
17.21

17.38 => Reset cablemodem and set it up again.

18/01:
------

20.35 => There were no cuts from 17.38 on 17/01 until this time.

19/01:
------
07.48
09.02
10.15
11.22
12.19
15.05
16.11
17.35
18.42
20.01

Reboot cablemodem from the Internet provider at approximately 9:00 pm to
see if this solves the problem.

20/01:
------
17.21
18.36
19.44
21.15
22.21
23.27

21/01:
------
01.56
03.09

10.05
10.37
11.49
13.18
14.17
15.32
16.46
18.09
19.13
20.31
22.08
22.58

22/01:
------
00.11
01.21
02.37

10.07
11.21
12.36
13.43
16.11
17.26
19.12
20.14
21.39
22.31
23.35

23/01:
------

07.05
08.18
09.26
10.40
15.40
16.59
18.04
19.20
20.32
21.50

24/01:
------

05.38
06.30
07.42

10.12
11.21
------------------------------------------------------------------------

To rule out a problem with the notebook (with Debian Jessie 8.6), I have
tried connecting a PC (also with Debian Jessie 8.6) directly to the
cablemodem, wired, and observed the same behavior.

It's very weird. The cablemodem does not lose Upstream and Downstream
synchronization, but nevertheless I see that the established connections
are lost (for example, instant messaging, SSH, or HTTP, to mention a few).

I do not know if it will be related, but on 05/01 there was a service
interruption between 09.25 and 11.35. After the service was restored, I
noticed that I was changed from CMTS 10.94.0.1 to 10.96.0.1. Maybe some
problem in configuring this CMTS?

Thinking that this could be because it changes the public IP, I checked
the log of a script that I have to update against Afraid DNS service.
But several days ago the IP does not change so that does not seem to be
the problem.


What do you think? Will it be a problem of the Internet provider?


Thanks in advance.

Kind regards,
Daniel

[toc] | [next] | [standalone]

#176973

Have you tried maintaining the ssh connection from a different internet
connection?  Assuming you have no issues it is probably related to the
ISP.  It would also be a good test to to try sshing to a server in
another location and seeing if your connection drops but given that you
are experiencing pidgin dropping as well.  I would assume it's internet
related.  Do you have another computer you can test with?

-- 
  Armando Cerna
  armando@cerna.ca

On Tue, Jan 24, 2017, at 06:52 AM, Daniel Bareiro wrote:
> Hi all!
> 
> It's been a bit more than a week since I've been observing that, from
> time to time, I lose the established connections. I realize this because
> I have for example an SSH connection against a server in France that
> freezes and a few minutes later I see that Pidgin reconnects.
> 
> It is quite strange. At first I noticed this from my notebook connected
> via wifi to a wireless router that is connected to a switch.
> 
> Here some connection loss records (there may have been more, but these
> are the ones that I registered):
> 
> ------------------------------------------------------------------------
> 13/01:
> ------
> 
> 08.09
> 09.16
> 10.29
> 12.06
> 13.09
> 14.10
> 15.33
> 18.02
> 20.31
> 22.13
> 
> 14/01:
> ------
> 
> 07.33
> 08.42
> 09.54
> 11.13
> 12.27
> 15.09
> 16.05
> 17.27
> 19.54
> 22.15
> 
> 15/01:
> ------
> 
> 13.23
> 18.01
> 19.16
> 20.35
> 22.55
> 
> 16/01:
> ------
> 
> 00.10
> 10.05
> 11.16
> 
> 12.10 => Here, to rule out that this was a problem in the wireless
> connection, I connected the notebook to the same router but this time
> wired. Reconnections persisted, as you can see.
> 
> 12.34
> 14.58
> 16.11
> 
> 16.17 => So I did what I think would be the definitive test: I connected
> the notebook to the cablemodem directly, wired. Reconnections persisted.
> 
> 17.30
> 18.40
> 19.57
> 
> 20.56 => Again change to wireless mode as the cuts are given by
> connecting directly.
> 
> 21.10
> 22.44
> 
> 17/01:
> ------
> 07.21
> 08.14
> 09.53
> 10.44
> 
> 14.25
> 15.39
> 17.21
> 
> 17.38 => Reset cablemodem and set it up again.
> 
> 18/01:
> ------
> 
> 20.35 => There were no cuts from 17.38 on 17/01 until this time.
> 
> 19/01:
> ------
> 07.48
> 09.02
> 10.15
> 11.22
> 12.19
> 15.05
> 16.11
> 17.35
> 18.42
> 20.01
> 
> Reboot cablemodem from the Internet provider at approximately 9:00 pm to
> see if this solves the problem.
> 
> 20/01:
> ------
> 17.21
> 18.36
> 19.44
> 21.15
> 22.21
> 23.27
> 
> 21/01:
> ------
> 01.56
> 03.09
> 
> 10.05
> 10.37
> 11.49
> 13.18
> 14.17
> 15.32
> 16.46
> 18.09
> 19.13
> 20.31
> 22.08
> 22.58
> 
> 22/01:
> ------
> 00.11
> 01.21
> 02.37
> 
> 10.07
> 11.21
> 12.36
> 13.43
> 16.11
> 17.26
> 19.12
> 20.14
> 21.39
> 22.31
> 23.35
> 
> 23/01:
> ------
> 
> 07.05
> 08.18
> 09.26
> 10.40
> 15.40
> 16.59
> 18.04
> 19.20
> 20.32
> 21.50
> 
> 24/01:
> ------
> 
> 05.38
> 06.30
> 07.42
> 
> 10.12
> 11.21
> ------------------------------------------------------------------------
> 
> To rule out a problem with the notebook (with Debian Jessie 8.6), I have
> tried connecting a PC (also with Debian Jessie 8.6) directly to the
> cablemodem, wired, and observed the same behavior.
> 
> It's very weird. The cablemodem does not lose Upstream and Downstream
> synchronization, but nevertheless I see that the established connections
> are lost (for example, instant messaging, SSH, or HTTP, to mention a
> few).
> 
> I do not know if it will be related, but on 05/01 there was a service
> interruption between 09.25 and 11.35. After the service was restored, I
> noticed that I was changed from CMTS 10.94.0.1 to 10.96.0.1. Maybe some
> problem in configuring this CMTS?
> 
> Thinking that this could be because it changes the public IP, I checked
> the log of a script that I have to update against Afraid DNS service.
> But several days ago the IP does not change so that does not seem to be
> the problem.
> 
> 
> What do you think? Will it be a problem of the Internet provider?
> 
> 
> Thanks in advance.
> 
> Kind regards,
> Daniel
> 
> Email had 1 attachment:
> + signature.asc
>   1k (application/pgp-signature)

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

#176976

[Multipart message — attachments visible in raw view] — view raw

Hi, Armando.

On 24/01/17 12:54, Armando Cerna wrote:

> Have you tried maintaining the ssh connection from a different internet
> connection?  Assuming you have no issues it is probably related to the
> ISP.  It would also be a good test to to try sshing to a server in
> another location and seeing if your connection drops but given that you
> are experiencing pidgin dropping as well.  I would assume it's internet
> related.  Do you have another computer you can test with?

Yes. As I mentioned in the other mail, I tried with a PC in my local
network and connected it directly to the cablemodem in a wired way. And
the behavior was the same. Another test I did not mention is that, with
the notebook connected to the cablemodem in a wired way, I tried
connecting via VPN to my local network via ssh using the public IP
assigned to the cablemodem. And after a while I lost the connection.

Both the notebook and this PC have Debian 8.6. It could be a recent bug.
But it is strange because for example I do not remember having had
problems on last December.


Thanks for your interest.

Kind regards,
Daniel

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

#176979

On Tue, 24 Jan 2017, Daniel Bareiro wrote:
> It's very weird. The cablemodem does not lose Upstream and Downstream
> synchronization, but nevertheless I see that the established connections
> are lost (for example, instant messaging, SSH, or HTTP, to mention a few).

Are you under any sort of stateful packet filtering device (L3+
firewall, NAT/CGNAT gateway, anti-virus device)?   Inquire your ISP.

Such devices can _and do_ cause this sort of issue when they hit
resource limits of any sort (such as going over peak capacity of
connection setup/teardown rate, throughput, etc), or during failover,
etc.

It could also be caused by link or routing problems in the ISP backbone,
backhaul, and even in the Internet border itself (ISP to ISP eBGP
links).

> I do not know if it will be related, but on 05/01 there was a service
> interruption between 09.25 and 11.35. After the service was restored, I
> noticed that I was changed from CMTS 10.94.0.1 to 10.96.0.1. Maybe some
> problem in configuring this CMTS?

It could be an issue in the ISP's backhaul or backbone, yes.  In that
case, it might be limited to this CMTS, or to a network region, or even
to large sections of the ISP's network.

Ask people you know that use the same ISP in your neighborhood and also
elsewhere in the same city, that might give you extra data on the extent
of the issues.

> Thinking that this could be because it changes the public IP, I checked
> the log of a script that I have to update against Afraid DNS service.
> But several days ago the IP does not change so that does not seem to be
> the problem.

What is your ISP's AS number, please?  If you don't know, please look it
up by connecting with a browser to http://bgp.he.net.

> What do you think? Will it be a problem of the Internet provider?

>From the data you provided, it certainly looks like a problem in either
your ISP's network, or their upstream ISPs.

-- 
  Henrique Holschuh

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

#176986

[Multipart message — attachments visible in raw view] — view raw

Hi, Henrique.

On 24/01/17 13:37, Henrique de Moraes Holschuh wrote:

>> It's very weird. The cablemodem does not lose Upstream and Downstream
>> synchronization, but nevertheless I see that the established connections
>> are lost (for example, instant messaging, SSH, or HTTP, to mention a few).

> Are you under any sort of stateful packet filtering device (L3+
> firewall, NAT/CGNAT gateway, anti-virus device)?   Inquire your ISP.
> 
> Such devices can _and do_ cause this sort of issue when they hit
> resource limits of any sort (such as going over peak capacity of
> connection setup/teardown rate, throughput, etc), or during failover,
> etc.
> 
> It could also be caused by link or routing problems in the ISP backbone,
> backhaul, and even in the Internet border itself (ISP to ISP eBGP
> links).

Very interesting observations. Thank you! Below I add the news.

>> I do not know if it will be related, but on 05/01 there was a service
>> interruption between 09.25 and 11.35. After the service was restored, I
>> noticed that I was changed from CMTS 10.94.0.1 to 10.96.0.1. Maybe some
>> problem in configuring this CMTS?

> It could be an issue in the ISP's backhaul or backbone, yes.  In that
> case, it might be limited to this CMTS, or to a network region, or even
> to large sections of the ISP's network.
> 
> Ask people you know that use the same ISP in your neighborhood and also
> elsewhere in the same city, that might give you extra data on the extent
> of the issues.

At 12.37 GMT-3 I detected a restart of the cablemodem. After verifying,
I see that I am still in the same CMTS 10.96.0.1. I telephoned the
Support area of the ISP to ask if this reboot was linked to some change
(for example, some adjustment in the parameters of the binary that
receives the cablemodem) but they did not know. I was told that they
will ask the technical area for an update. So far everything seems
stable, although I would like to know what they changed, if they touched
something. I will keep it under observation and call again tomorrow.

>> Thinking that this could be because it changes the public IP, I checked
>> the log of a script that I have to update against Afraid DNS service.
>> But several days ago the IP does not change so that does not seem to be
>> the problem.

> What is your ISP's AS number, please?  If you don't know, please look it
> up by connecting with a browser to http://bgp.he.net.

Very interesting site. This is the AS number:

http://bgp.he.net/AS27984

>> What do you think? Will it be a problem of the Internet provider?

> From the data you provided, it certainly looks like a problem in either
> your ISP's network, or their upstream ISPs.


Thank you very much for your interest and your time.

Kind regards,
Daniel

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

#177056

[Multipart message — attachments visible in raw view] — view raw

Hi again, Henrique.

On 24/01/17 13:37, Henrique de Moraes Holschuh wrote:

>> It's very weird. The cablemodem does not lose Upstream and Downstream
>> synchronization, but nevertheless I see that the established
>> connections are lost (for example, instant messaging, SSH, or HTTP,
>> to mention a few).

> Are you under any sort of stateful packet filtering device (L3+
> firewall, NAT/CGNAT gateway, anti-virus device)?   Inquire your ISP.
>
> Such devices can _and do_ cause this sort of issue when they hit
> resource limits of any sort (such as going over peak capacity of
> connection setup/teardown rate, throughput, etc), or during failover,
> etc.
>
> It could also be caused by link or routing problems in the ISP
> backbone, backhaul, and even in the Internet border itself (ISP to
> ISP eBGP links).
>
> (...)

I thought about doing a test with MTR. Maybe it could provide some
interesting information. This way I left in a later window an ssh
connection to a server running htop, and a window ahead running MTR.

When the window with htop freezes, MTR shows as a cascade failure from
the cablemodem, turning red the hosts from this (192.168.1.1). This
stays red for about three or four seconds and then goes
back to black.

https://ibin.co/3AMfJ9PYCGJ4.png

When any router turns red means 100% packet loss? Because in the
screenshot this value was not in 100 for the cablemodem on that moment.


What do you think? Will it be a problem with the cablemodem?

Kind regards,
Daniel

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

#177058

On Fri, 27 Jan 2017, Daniel Bareiro wrote:
> I thought about doing a test with MTR. Maybe it could provide some
> interesting information. This way I left in a later window an ssh
> connection to a server running htop, and a window ahead running MTR.
> 
> When the window with htop freezes, MTR shows as a cascade failure from
> the cablemodem, turning red the hosts from this (192.168.1.1). This
> stays red for about three or four seconds and then goes
> back to black.
> 
> https://ibin.co/3AMfJ9PYCGJ4.png

Why is it getting packet loss to the *first* hop?  Wifi?  Do that test
using an ethernet connection...

> What do you think? Will it be a problem with the cablemodem?

I don't know which hop is your cable modem, but you need to explain the
first hop losing packets.  If it drops return packets that often, you
cannot assume where any loss after that one is happening: it could be
just their return packets being dropped by the first hop.

-- 
  Henrique Holschuh

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

#177059

[Multipart message — attachments visible in raw view] — view raw

Hi, Henrique.

On 27/01/17 19:11, Henrique de Moraes Holschuh wrote:

>> I thought about doing a test with MTR. Maybe it could provide some
>> interesting information. This way I left in a later window an ssh
>> connection to a server running htop, and a window ahead running MTR.
>>
>> When the window with htop freezes, MTR shows as a cascade failure from
>> the cablemodem, turning red the hosts from this (192.168.1.1). This
>> stays red for about three or four seconds and then goes
>> back to black.
>>
>> https://ibin.co/3AMfJ9PYCGJ4.png

> Why is it getting packet loss to the *first* hop?  Wifi?  Do that test
> using an ethernet connection...

The first hop (192.168.2.1) is my TP-Link WDR-3600 router with OpenWRT.
At the time of the test with mtr, I was connected with my notebook to
that router wirelessly. The second hop (10.1.0.10) is my firewall with
Debian Jessie. It called my attention to see packet loss in both,
although I was struck by the fact that from the cablemodem everything
turned red for a few seconds at the time the connections freeze.

>> What do you think? Will it be a problem with the cablemodem?

> I don't know which hop is your cable modem, but you need to explain the
> first hop losing packets.  If it drops return packets that often, you
> cannot assume where any loss after that one is happening: it could be
> just their return packets being dropped by the first hop.

The cablemodem is 192.168.1.1, so the CMTS is 10.96.0.1. I've been
watching mtr for a few minutes waiting for the ssh connections to freeze
and I've only seen that the hops from the cablemodem turn red when
everything freezes. I'm going to do the test again by connecting
directly via ethernet to ensure the results are reproducible.

Thanks for your reply and your time.


Kind regards,
Daniel

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

#177061

[Multipart message — attachments visible in raw view] — view raw

Hi again, Henrique.

On 27/01/17 19:32, Daniel Bareiro wrote:

>>> What do you think? Will it be a problem with the cablemodem?

>> I don't know which hop is your cable modem, but you need to explain the
>> first hop losing packets.  If it drops return packets that often, you
>> cannot assume where any loss after that one is happening: it could be
>> just their return packets being dropped by the first hop.

> The cablemodem is 192.168.1.1, so the CMTS is 10.96.0.1. I've been
> watching mtr for a few minutes waiting for the ssh connections to freeze
> and I've only seen that the hops from the cablemodem turn red when
> everything freezes. I'm going to do the test again by connecting
> directly via ethernet to ensure the results are reproducible.

I did the test again by connecting the notebook with a cable to the
TP-Link router (192.168.2.1). When the connections are dropped, all the
hops are shown in red from the cablemodem (192.168.1.1) for about three
to four seconds. This is the screenshot:

https://ibin.co/3ANVFzZi7BHg.png


Kind regards,
Daniel

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

#177070

On Fri, 27 Jan 2017, Daniel Bareiro wrote:
> >>> What do you think? Will it be a problem with the cablemodem?
> >> I don't know which hop is your cable modem, but you need to explain the
> >> first hop losing packets.  If it drops return packets that often, you
> 
> > The cablemodem is 192.168.1.1, so the CMTS is 10.96.0.1. I've been

10.96.0.1 could be the CMTS, or it could be an aggregation router,
depends on the CMTS being transparent or not to the IP L3.

> > watching mtr for a few minutes waiting for the ssh connections to freeze
> > and I've only seen that the hops from the cablemodem turn red when
> > everything freezes. I'm going to do the test again by connecting
> > directly via ethernet to ensure the results are reproducible.
> 
> I did the test again by connecting the notebook with a cable to the
> TP-Link router (192.168.2.1). When the connections are dropped, all the

Do it _directly_ connected to the cable modem, please.  And by that I
also mean without any VMs, containers, virtual network devices, or NAT
in the middle.

> https://ibin.co/3ANVFzZi7BHg.png

It does look like the cable-modem, but this is not yet certain.  And it
could also be ethernet cabling or a switch (if you have one), etc.
Basically anything between the test node (your laptop/computer) and the
cable modem, *including* infrastructure.

If you can do it at no cost, ask the ISP to replace that cable modem
just in case.  These things *do* age, I had to replace three of them
over the last 8 years.  One of them did not outright die, it would lose
packets or connect at low bandwidth at the DOCSIS layer.

-- 
  Henrique Holschuh

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

#177072

[Multipart message — attachments visible in raw view] — view raw

Hi, Henrique.

On 28/01/17 11:40, Henrique de Moraes Holschuh wrote:

>>>>> What do you think? Will it be a problem with the cablemodem?
>>>> I don't know which hop is your cable modem, but you need to explain the
>>>> first hop losing packets.  If it drops return packets that often, you

>>> The cablemodem is 192.168.1.1, so the CMTS is 10.96.0.1. I've been

> 10.96.0.1 could be the CMTS, or it could be an aggregation router,
> depends on the CMTS being transparent or not to the IP L3.

Thanks for the observation.

>>> watching mtr for a few minutes waiting for the ssh connections to freeze
>>> and I've only seen that the hops from the cablemodem turn red when
>>> everything freezes. I'm going to do the test again by connecting
>>> directly via ethernet to ensure the results are reproducible.

>> I did the test again by connecting the notebook with a cable to the
>> TP-Link router (192.168.2.1). When the connections are dropped, all the

> Do it _directly_ connected to the cable modem, please.  And by that I
> also mean without any VMs, containers, virtual network devices, or NAT
> in the middle.

Yesterday I did another test connecting a PC with cable directly to the
cablemodem. The test was done with the PC without virtualization in the
middle. The result was similar to the previous ones.

https://ibin.co/3AOR4sbcReOc.png

When the hops all turn red, does that mean the cablemodem is not responding?

>> https://ibin.co/3ANVFzZi7BHg.png

> It does look like the cable-modem, but this is not yet certain.  And it
> could also be ethernet cabling or a switch (if you have one), etc.
> Basically anything between the test node (your laptop/computer) and the
> cable modem, *including* infrastructure.

With the previous test we discard any intermediate elements of the network.

> If you can do it at no cost, ask the ISP to replace that cable modem
> just in case.  These things *do* age, I had to replace three of them
> over the last 8 years.  One of them did not outright die, it would lose
> packets or connect at low bandwidth at the DOCSIS layer.

The last time I spoke with the Support area of the ISP was last Thursday
and they told me that from the Technology sector they asked to send a
technician to make a repair because they had checked the CMTS and they
did not find problems there. That was before doing these tests with MTR.

In the case it provides any additional information, the cablemodem is a
Cisco DPC3825. It does not seem to have SSH access. The only access I
see is via web and there I have not seen any log that can provide more
information than those already obtained with these tests.


Thanks for your reply and your time.

Kind regards,
Daniel

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

#177080

[Multipart message — attachments visible in raw view] — view raw

Hi, Henrique.

>>>> watching mtr for a few minutes waiting for the ssh connections to freeze
>>>> and I've only seen that the hops from the cablemodem turn red when
>>>> everything freezes. I'm going to do the test again by connecting
>>>> directly via ethernet to ensure the results are reproducible.

>>> I did the test again by connecting the notebook with a cable to the
>>> TP-Link router (192.168.2.1). When the connections are dropped, all the

>> Do it _directly_ connected to the cable modem, please.  And by that I
>> also mean without any VMs, containers, virtual network devices, or NAT
>> in the middle.

> Yesterday I did another test connecting a PC with cable directly to the
> cablemodem. The test was done with the PC without virtualization in the
> middle. The result was similar to the previous ones.
> 
> https://ibin.co/3AOR4sbcReOc.png
> 
> When the hops all turn red, does that mean the cablemodem is not responding?

I asked you this question because I did another test where I noticed
that although the ping to the cablemodem is not interrupted, MTR shows
all the hops in red:

14.44 GMT-3 => MTR stays red from ping 3153 to 3160 (seven seconds).
         - Server in FR   => 18:44:15 GMT+1 (drops connection)
         - Server en EEUU => 12:44:17 GMT-5 (drops connection)
         - Ping to cablemodem is not interrupted:

https://ibin.co/3AT1DTFK65tS.png

------------------------------------------------------------------------------
viper@defiant:~$ ping 192.168.1.1 | while read pong; do echo "$(date):
$pong"; done
(...)
sáb ene 28 14:43:39 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3184
ttl=64 time=0.595 ms
sáb ene 28 14:43:40 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3185
ttl=64 time=0.542 ms
sáb ene 28 14:43:41 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3186
ttl=64 time=0.542 ms
sáb ene 28 14:43:42 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3187
ttl=64 time=0.624 ms
sáb ene 28 14:43:43 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3188
ttl=64 time=0.555 ms
sáb ene 28 14:43:44 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3189
ttl=64 time=0.556 ms
sáb ene 28 14:43:45 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=319
0
ttl=64 time=0.630 ms
sáb ene 28 14:43:46 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3191
ttl=64 time=0.573 ms
sáb ene 28 14:43:47 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3192
ttl=64 time=0.568 ms
sáb ene 28 14:43:48 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3193
ttl=64 time=0.581 ms
sáb ene 28 14:43:49 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3194
ttl=64 time=0.566 ms
sáb ene 28 14:43:50 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3195
ttl=64 time=0.531 ms
sáb ene 28 14:43:51 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3196
ttl=64 time=0.610 ms
sáb ene 28 14:43:52 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3197
ttl=64 time=0.543 ms
sáb ene 28 14:43:53 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3198
ttl=64 time=0.554 ms
sáb ene 28 14:43:54 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3199
ttl=64 time=0.627 ms
sáb ene 28 14:43:55 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=320
0
ttl=64 time=0.564 ms
sáb ene 28 14:43:56 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3201
ttl=64 time=0.539 ms
sáb ene 28 14:43:57 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3202
ttl=64 time=0.606 ms
sáb ene 28 14:43:58 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3203
ttl=64 time=0.566 ms
sáb ene 28 14:43:59 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3204
ttl=64 time=0.576 ms
sáb ene 28 14:44:00 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3205
ttl=64 time=0.618 ms
sáb ene 28 14:44:01 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3206
ttl=64 time=0.572 ms
sáb ene 28 14:44:02 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3207
ttl=64 time=0.560 ms
sáb ene 28 14:44:03 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3208
ttl=64 time=0.642 ms
sáb ene 28 14:44:04 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3209
ttl=64 time=0.564 ms
sáb ene 28 14:44:05 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=321
0
ttl=64 time=0.558 ms
sáb ene 28 14:44:06 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3211
ttl=64 time=0.594 ms
sáb ene 28 14:44:07 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3212
ttl=64 time=0.547 ms
sáb ene 28 14:44:08 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3213
ttl=64 time=0.536 ms
sáb ene 28 14:44:09 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3214
ttl=64 time=0.612 ms
sáb ene 28 14:44:10 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3215
ttl=64 time=0.540 ms
sáb ene 28 14:44:11 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3216
ttl=64 time=0.625 ms
sáb ene 28 14:44:12 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3217
ttl=64 time=0.764 ms
sáb ene 28 14:44:13 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3218
ttl=64 time=0.595 ms
sáb ene 28 14:44:14 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3219
ttl=64 time=0.539 ms
sáb ene 28 14:44:15 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=322
0
ttl=64 time=0.607 ms
sáb ene 28 14:44:16 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3221
ttl=64 time=0.551 ms
sáb ene 28 14:44:17 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3222
ttl=64 time=0.573 ms
sáb ene 28 14:44:18 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3223
ttl=64 time=0.656 ms
sáb ene 28 14:44:19 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3224
ttl=64 time=0.603 ms
sáb ene 28 14:44:20 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3225
ttl=64 time=0.570 ms
sáb ene 28 14:44:21 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3226
ttl=64 time=0.633 ms
sáb ene 28 14:44:22 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3227
ttl=64 time=0.588 ms
sáb ene 28 14:44:23 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3228
ttl=64 time=0.607 ms
sáb ene 28 14:44:24 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3229
ttl=64 time=0.614 ms
sáb ene 28 14:44:25 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=323
0
ttl=64 time=0.614 ms
sáb ene 28 14:44:26 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3231
ttl=64 time=0.550 ms
sáb ene 28 14:44:27 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3232
ttl=64 time=49.9 ms
sáb ene 28 14:44:28 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3233
ttl=64 time=0.501 ms
sáb ene 28 14:44:29 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3234
ttl=64 time=0.537 ms
sáb ene 28 14:44:30 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3235
ttl=64 time=0.503 ms
sáb ene 28 14:44:31 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3236
ttl=64 time=0.549 ms
sáb ene 28 14:44:32 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3237
ttl=64 time=0.558 ms
sáb ene 28 14:44:33 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3238
ttl=64 time=0.528 ms
sáb ene 28 14:44:34 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3239
ttl=64 time=0.556 ms
sáb ene 28 14:44:35 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=324
0
ttl=64 time=0.513 ms
sáb ene 28 14:44:36 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3241
ttl=64 time=0.533 ms
sáb ene 28 14:44:37 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3242
ttl=64 time=0.571 ms
sáb ene 28 14:44:38 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3243
ttl=64 time=0.524 ms
sáb ene 28 14:44:39 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3244
ttl=64 time=0.507 ms
sáb ene 28 14:44:40 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3245
ttl=64 time=0.564 ms
sáb ene 28 14:44:41 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3246
ttl=64 time=0.551 ms
sáb ene 28 14:44:42 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3247
ttl=64 time=0.518 ms
sáb ene 28 14:44:43 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3248
ttl=64 time=0.571 ms
sáb ene 28 14:44:44 ART 2017: 64 bytes from 192.168.1.1: icmp_seq=3249
ttl=64 time=0.530 ms
------------------------------------------------------------------------------

That is, when MTR turns everything red, the two connections to the
servers are frozen. I'm not sure what this means that MTR puts each hop
in red because if I leave a ping against the cablemodem, the ping is
never interrupted. At one point the latency is triggered to almost 50
ms, but that happens about 10 s after the connections are dropped.


Kind regards,
Daniel

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web