beantwoord

packetloss again

  • 26 augustus 2017
  • 45 reacties
  • 2103 x bekeken

Please check the topic:
https://forum.tele2.nl/vast-internet-188/packet-loss-66187

1) The problem became again. Please fix
2) I did not received satisfaction in the last time. I expect, you'll return me money from previous time, and now again.
icon

Beste antwoord door wizd3m 27 september 2017, 13:51

I am kind of intrigued by your issue as I see in the screenshots that you connect to a server through SSH. Furthermore you connect to a Debian machine using kernel 2.6.

First of all, you are at risk for the Dirty CoW vulnerability using an older kernel. According to Debian GNU/Linux advisary any kernels older than the following are at risk:

- 3.16.36-1+deb8u2 for Debian 8
- 3.2.82-1 for Debian 7
- 4.7.8-1 for Debian unstable

So I advise you to upgrade your kernel before you experience any issue with Copy-on-Write. See https://dirtycow.ninja/

Furthermore. In your screenshots I cannot see where the server is located. And do you know for certain the issues do not arise on the remote network? The ping results are always from the outside in and not from your network to another place. As I would expect.

Then, In one of your posts you state the following:
physically problem locates between ethernet(or wifi) port inside YOUR DSL modem inside our apartment and your ipv4 gateway 82.173.117.1

That is a wrong assumption: 82.174.117.1 is NOT your gateway, but probably an IP adres of another customer. When you defined that IP adres as a gateway on your network (locally and remotely) than that could be the issue. Whenever that customer shuts down the modem, resets it or whatever, you will experience packetloss as the "gateway" is not reachable.

Depending on the service used by an ISP (PPPoE/PPPoA or whatever) a network could be defined very differently to a Local Network. ISPs usually depend on some kind of point-to-point protocol. Thus a gateway could be in the 10.x.x.x range, even when your public IP adres is like 82.x.x.x.

Another wrong assumption is that it is easy for an ISP to monitor 1 customer. Your modem is connected to a dslam which (for the sake of this argument) contains 200 customers. That dslam is connected to a single port on a switch on the ISP network. So all the network traffic for the 200 customers are on that one port. This also means that if there is packetloss on that port this should affect all 200 customers on the dslam including you. This also leads to the conclusion that it is not possible to monitor network traffic of 1 customer.

To conclude: As you did the assumption that 82.173.117.1 is your gateway and it is most likely that that IP adress has been assigned to another Tele2 customer, the issues you experience are (most probably) caused by you and not by Tele2.
Bekijk origineel bericht

Dit topic is gesloten. Maak een nieuw topic aan als je een vraag hebt.

45 reacties

Reputatie 5
Badge +3
Hey,

Regarding the malfunction did you try resetting your modem again? See if that fixed the problem like last time?

Regarding your request for reimbursement as said in the post you linked you need to fill in the form. Have you done that already?

I do want to say sorry you don't feel you received a satisfactory answer last time. How ever middle of the conversation you did not respond for 3 weeks. At that point i can't really help you anymore also regarding the first complaint you did say it was resolved.
Regarding the malfunction did you try resetting your modem again? See if that fixed the problem like last time?


Today resetting of the modem didn't help. And before this moment too.
Reputatie 5
Badge +3
I see since the reset your modem did not lose connection. Are you using any external hardware like a router, hub, external modem or wifi repeater etc.
Are you using any external hardware like a router, hub, external modem or wifi repeater etc.


Yes, I am. It's router with OpenWRT software. It's stable software, mantained by comminity, and it's work better then all vendor's devices, excluding, maybe, Juniper/Cisco/microtic proprietary devices.

So, the problem not in my router, and probably not in your DSL modem.

When I ping my router(internal IP), then no packetloss. When I login to the roter via ssh, and ping your DSL modem(192.168.1.1), then it also works without packetloss. But your gateway (82.173.117.1) in this cases drop a lot of packages.
The problem locates in the cable between your modem and your hardware, or inside your hardware, or maybe, the DSL/ppoe software/hardware inside your DSL modem has a bugs. Ethernet port/switch inside your DSL modem works fine (no packetloss between my router and your modem)
Reputatie 5
Badge +3
I understand you but we do not support external hardware. So i do have to request that you disconnect it and see if it works better. As i have done a test through your modem and had no packet loss. I deleted private information but here is the test:

ping addr=82.173.117.1 count=500
Legend : Ping successful(!)
Ping Timeout(.)
Hit ctrl-g to abort...
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
--- Ping statistics ---
500 packet(s) transmitted, 500 successful, 0% packet loss
rtt min/avg/max = 32 / 33 / 63 ms
It's not "external hardware" problem. Be an engineer, please! I think, If I public this story in the reddit, then tele2 will be funny and stupid for the reddit users.
In this moment I haven't packetloss. I sent a messages when it was. I have an access to a lot of external servers, and I checked connection from the outside too. The problem locates between LAN interface inside your DSL modem and your hardware in the phone station, I'm pretty sure.
And it's not "external hardware problem", LOL 🙂 The problem is same (when packetloss exist) if I use Wifi connection to your router too.
Reputatie 5
Badge +3
As sad before we do not see any packet loss on your connection. Sadly i can't help you out any further then that.
Packetloss became again. If you can't fix the problem, can I stop one year contract with your company, and buy subscription in another ISP?

Also, I'll do as more as I can to tell about your *wonderful* service in the internet, in Reddit, etc.

Also I want to get connection fee payment back because problem is in your side.
Reputatie 5
Badge +3
The problem is not on our side that is why i can't give you a refund. If you wish to cancel your subscription you have to contact our cancellation department
The problem is not on our side


physically problem locates between ethernet(or wifi) port inside YOUR DSL modem inside our apartment and your ipv4 gateway 82.173.117.1. I think, it's DSL hardware in the phone station or maybe last mile cable problems, because packetloss not related with rebooting DSL modems(probably, but I can't be sure whithout root access to the DSL modem).

The ethernet port and the wifi network interface inside your DSL modem works well, the all ICMP trafic between my hardware and your LAN part inside the DSL modem go well without packetloss.

But after packets go out wifi interface inside DSL modem or ethernet interface, before they achieve your host 82.173.117.1, sometimes something wrong. And 10-15% of packets are drop.

And I'm sure I can find problem myself(if I have a root access to DSL modem and your gateway), but of cource you can't give me an access to your host 82.173.117.1 and also you do not give root access to customer's DSL modems.
It's your work, not my. Why you can't run in this host monitoring tools in the background and add a alert in your Nagios/Zabbix/another monitoring? Why I have to explain you how to find and fix a problem? why you just can't solve it and stop this stupid dialog?
MY part of network works well, proof:

ping -c 20 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=63 time=0.910 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=63 time=0.668 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=63 time=0.643 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=63 time=0.674 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=63 time=0.661 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=63 time=0.605 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=63 time=0.633 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=63 time=0.618 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=63 time=0.609 ms
64 bytes from 192.168.1.1: icmp_seq=10 ttl=63 time=0.648 ms
64 bytes from 192.168.1.1: icmp_seq=11 ttl=63 time=0.598 ms
64 bytes from 192.168.1.1: icmp_seq=12 ttl=63 time=0.651 ms
64 bytes from 192.168.1.1: icmp_seq=13 ttl=63 time=0.688 ms
64 bytes from 192.168.1.1: icmp_seq=14 ttl=63 time=0.544 ms
64 bytes from 192.168.1.1: icmp_seq=15 ttl=63 time=0.634 ms
64 bytes from 192.168.1.1: icmp_seq=16 ttl=63 time=0.569 ms
64 bytes from 192.168.1.1: icmp_seq=17 ttl=63 time=0.662 ms
64 bytes from 192.168.1.1: icmp_seq=18 ttl=63 time=0.578 ms
64 bytes from 192.168.1.1: icmp_seq=19 ttl=63 time=0.604 ms
64 bytes from 192.168.1.1: icmp_seq=20 ttl=63 time=0.629 ms

--- 192.168.1.1 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19495ms
rtt min/avg/max/mdev = 0.544/0.641/0.910/0.074 ms


Your part of network does not work (same via ethernet and wifi):

ping -c 20 82.173.117.1
PING 82.173.117.1 (82.173.117.1) 56(84) bytes of data.
64 bytes from 82.173.117.1: icmp_seq=1 ttl=61 time=89.1 ms
64 bytes from 82.173.117.1: icmp_seq=2 ttl=61 time=99.8 ms
64 bytes from 82.173.117.1: icmp_seq=4 ttl=61 time=82.9 ms
64 bytes from 82.173.117.1: icmp_seq=5 ttl=61 time=39.9 ms
64 bytes from 82.173.117.1: icmp_seq=6 ttl=61 time=78.4 ms
64 bytes from 82.173.117.1: icmp_seq=7 ttl=61 time=58.1 ms
64 bytes from 82.173.117.1: icmp_seq=8 ttl=61 time=107 ms
64 bytes from 82.173.117.1: icmp_seq=9 ttl=61 time=76.9 ms
64 bytes from 82.173.117.1: icmp_seq=11 ttl=61 time=95.8 ms
64 bytes from 82.173.117.1: icmp_seq=12 ttl=61 time=84.8 ms
64 bytes from 82.173.117.1: icmp_seq=13 ttl=61 time=66.3 ms
64 bytes from 82.173.117.1: icmp_seq=14 ttl=61 time=77.5 ms
64 bytes from 82.173.117.1: icmp_seq=15 ttl=61 time=81.4 ms
64 bytes from 82.173.117.1: icmp_seq=16 ttl=61 time=69.3 ms
64 bytes from 82.173.117.1: icmp_seq=17 ttl=61 time=71.7 ms
64 bytes from 82.173.117.1: icmp_seq=19 ttl=61 time=43.3 ms
64 bytes from 82.173.117.1: icmp_seq=20 ttl=61 time=84.5 ms

--- 82.173.117.1 ping statistics ---
20 packets transmitted, 17 received, 15% packet loss, time 19144ms
rtt min/avg/max/mdev = 39.963/76.974/107.933/17.521 ms


Please fix it. You can't solve this flapping problem during several of months!
Jasper, if it's too difficult to understand for you, could you please ask a help from the more skillest colleague, please?
Because my next steps, to drop your(TELE2 NL) not very well rating in the facebook communities more, and made anti-ad you in the Reddit, and trying to write to the Tele2 management about a problems in the engineer team.
Actually you have 1.5 stars. After my review it will be 1 star... Tele2, do you really want it?

Please. Fix it. It's easy 😞 The skillest network engeneer need not more then 5 minutes to switch on monitoring of the port, add the custom allert, and when the allert run, understand where is locate problem (is it cable, is it DSL hardware, or is it DSL modem). And next, you just have to replace broken part. It's not a rocket science!
Reputatie 5
Badge +3
Sir i have had coworkers look at it and they come to the same conclusion. If even other technical departments say they don't see a packet loss in 500 packets send. I can't help you any further.
I want to chat with another person, not you. I not trust you, sorry. Maybe you see packetloss, but lie

For another an engineer: Jasper ignore fact that packetloss exist not all time, but time to time. You have to setting up custom alert for the 1-2 weeks in your monitoring for my port. Every 1-2 weeks I have several of hours of the packetloss. Now connection works.
Reputatie 7
Badge +4
I think you want too much from a consumer inteŕnetline. These lines come without SLA, and setting long periods of monitoring is probably not part of a fault investigation.
A business line has an SLA, even with premium repair times but costs a lot more money to support that service.
It happen again right now.

I ping my modem from the an external server, and your gateway:

my modem:

82.173.117.XXX
PING 82.173.117.XXX (82.173.117.XXX) 56(84) bytes of data.
64 bytes from 82.173.117.XXX: icmp_req=2 ttl=56 time=77.9 ms
64 bytes from 82.173.117.XXX: icmp_req=3 ttl=56 time=78.1 ms
64 bytes from 82.173.117.XXX: icmp_req=4 ttl=56 time=86.7 ms
64 bytes from 82.173.117.XXX: icmp_req=5 ttl=56 time=82.5 ms
64 bytes from 82.173.117.XXX: icmp_req=6 ttl=56 time=74.3 ms
64 bytes from 82.173.117.XXX: icmp_req=7 ttl=56 time=86.5 ms
64 bytes from 82.173.117.XXX: icmp_req=8 ttl=56 time=71.2 ms
64 bytes from 82.173.117.XXX: icmp_req=9 ttl=56 time=78.3 ms
64 bytes from 82.173.117.XXX: icmp_req=10 ttl=56 time=79.3 ms
^C
--- 82.173.117.XXX ping statistics ---
11 packets transmitted, 9 received, 18% packet loss, time 10007ms
rtt min/avg/max/mdev = 71.223/79.467/86.737/4.860 ms


your router:


ping 82.173.117.1
PING 82.173.117.1 (82.173.117.1) 56(84) bytes of data.
64 bytes from 82.173.117.1: icmp_req=1 ttl=56 time=27.4 ms
64 bytes from 82.173.117.1: icmp_req=2 ttl=56 time=27.8 ms
64 bytes from 82.173.117.1: icmp_req=3 ttl=56 time=27.8 ms
64 bytes from 82.173.117.1: icmp_req=4 ttl=56 time=27.8 ms
64 bytes from 82.173.117.1: icmp_req=5 ttl=56 time=27.7 ms
64 bytes from 82.173.117.1: icmp_req=6 ttl=56 time=28.2 ms
64 bytes from 82.173.117.1: icmp_req=7 ttl=56 time=28.2 ms
64 bytes from 82.173.117.1: icmp_req=8 ttl=56 time=27.8 ms
64 bytes from 82.173.117.1: icmp_req=9 ttl=56 time=27.8 ms
64 bytes from 82.173.117.1: icmp_req=10 ttl=56 time=28.0 ms
^C
--- 82.173.117.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9011ms
rtt min/avg/max/mdev = 27.499/27.887/28.234/0.259 ms


traceroute:

traceroute 82.173.117.1
traceroute to 82.173.117.1 (82.173.117.1), 30 hops max, 60 byte packets
1 85-10-201-33.clients.your-server.de (85.10.201.33) 0.368 ms 0.365 ms 0.368 ms
2 core12.nbg1.hetzner.com (213.239.203.225) 0.351 ms 0.351 ms 0.339 ms
3 core4.fra.hetzner.com (213.239.245.245) 3.404 ms core4.fra.hetzner.com (213.239.245.33) 3.320 ms 3.320 ms
4 tele2.sara1.nl-ix.net (193.239.116.138) 9.076 ms 9.387 ms 9.066 ms
5 * * *
6 ip1-117-173-82.adsl2.static.versatel.nl (82.173.117.1) 30.702 ms 27.255 ms 29.220 ms


@eric please tell me honestly the official view: is it NORMAL for the TELE2, packetloss during 4-6 hours every week, or it's not normal? If it is officially ok, I want to share this information in the public, if not, I can help you to do your work instead of you. If your monitoring is proprieatary, and you have a limits by license, theare are lot of chip solutions, based in the bash/python/etc scripts and cron/atd daemons. It's really easy. I can write it for you instead of you.
So, if you're not trust me, this is a screenshot of ping procedure your DSL modem from my an external server
eric please tell me honestly the official view: .

Hello polnoch, eric cannot give you the official Tele2 view as he is just another customer (like me and you)
Jasper and other moderators on this forum have van Tele2 behind their name.
OK. Am I understand correctly? Tele2 don't give a f*ck that my connection doesn't work properly?
Reputatie 7
Badge +4
They do, but this is a forum where you connunicate with other customers as well. Direct customer care is only by phone.
packetloss became again. It exist when I ping public IP of tele2's DSL modem from an external server.

So, no any reaction in facebook.

@Jasper van Tele2, I see, you and your employer, you're both unconscionable. Or maybe you're frauds?
I am kind of intrigued by your issue as I see in the screenshots that you connect to a server through SSH. Furthermore you connect to a Debian machine using kernel 2.6.

First of all, you are at risk for the Dirty CoW vulnerability using an older kernel. According to Debian GNU/Linux advisary any kernels older than the following are at risk:

- 3.16.36-1+deb8u2 for Debian 8
- 3.2.82-1 for Debian 7
- 4.7.8-1 for Debian unstable

So I advise you to upgrade your kernel before you experience any issue with Copy-on-Write. See https://dirtycow.ninja/

Furthermore. In your screenshots I cannot see where the server is located. And do you know for certain the issues do not arise on the remote network? The ping results are always from the outside in and not from your network to another place. As I would expect.

Then, In one of your posts you state the following:
physically problem locates between ethernet(or wifi) port inside YOUR DSL modem inside our apartment and your ipv4 gateway 82.173.117.1

That is a wrong assumption: 82.174.117.1 is NOT your gateway, but probably an IP adres of another customer. When you defined that IP adres as a gateway on your network (locally and remotely) than that could be the issue. Whenever that customer shuts down the modem, resets it or whatever, you will experience packetloss as the "gateway" is not reachable.

Depending on the service used by an ISP (PPPoE/PPPoA or whatever) a network could be defined very differently to a Local Network. ISPs usually depend on some kind of point-to-point protocol. Thus a gateway could be in the 10.x.x.x range, even when your public IP adres is like 82.x.x.x.

Another wrong assumption is that it is easy for an ISP to monitor 1 customer. Your modem is connected to a dslam which (for the sake of this argument) contains 200 customers. That dslam is connected to a single port on a switch on the ISP network. So all the network traffic for the 200 customers are on that one port. This also means that if there is packetloss on that port this should affect all 200 customers on the dslam including you. This also leads to the conclusion that it is not possible to monitor network traffic of 1 customer.

To conclude: As you did the assumption that 82.173.117.1 is your gateway and it is most likely that that IP adress has been assigned to another Tele2 customer, the issues you experience are (most probably) caused by you and not by Tele2.
Reputatie 7
Badge +4
Wow , dat is nog eens een onderbouwde reactie! I rest my case...
Reputatie 5
Badge +3
Well @wizd3m this is a good answer. Only thing I want to add to that is I can confirm that 82.174.117.1 is a Tele2 ip adress but not that of @polnoch
First of all, you are at risk for the Dirty CoW vulnerability using an older kernel. According to Debian GNU/Linux advisary any kernels older than the following are at risk:


It's not standard debian, it's openvz host with the openvz kernel. It's not 2.6.32 mainstream kernel. It's RHEL-patched kernel. EL kernels have an alien numeration 🙂 It's double-patched kernel (at first, mainline kernel by RedHat and 2.6.32 EL currently supports!, at second, by openvz project)

To conclude: As you did the assumption that 82.173.117.1 is your gateway and it is most likely that that IP adress has been assigned to another Tele2 customer, the issues you experience are (most probably) caused by you and not by Tele2.


No, it's not. I haven't a root an access to your DSL modem. But I have a packetloss when I try to ping your DSL modem. It's your device, not my. If it possible to buy DSL modem with a root an access to it, then I can debug and understand where locates a problem, inside DSL modem or between a modem and your hardware in the phone station, and help to do your work. But actually I haven't an access to YOUR modem in my apartment, and can't do your work instead of you.

But we can see, I can ping another YOUR customer without packetloss, and I can't ping without packetloss your DSL modem in my apartment. You're admin of my DSL modem. It's your work to debug the problem and fix it. If you can give me a root shell to the DSL modem, then I can debug the problem instead of you and save your time (but you should fix phone hardware or DSL modem youself)