Re: The connections resets after some time.
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=3190 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=3200 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=3210 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=3220 ttl=64 time=0.607 ms sáb ene 28 14:44:16 ART 2017: 64 bytes
Re: The connections resets after some time.
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 signature.asc Description: OpenPGP digital signature
Re: The connections resets after some time.
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
Re: The connections resets after some time.
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 signature.asc Description: OpenPGP digital signature
Re: The connections resets after some time.
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 signature.asc Description: OpenPGP digital signature
Re: The connections resets after some time.
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
Re: The connections resets after some time.
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 signature.asc Description: OpenPGP digital signature
Re: The connections resets after some time.
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 signature.asc Description: OpenPGP digital signature
Re: The connections resets after some time.
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
Re: The connections resets after some time.
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 signature.asc Description: OpenPGP digital signature
Re: The connections resets after some time.
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 arma...@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)
The connections resets after some time.
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 signature.asc Description: OpenPGP digital signature
