We have intermittent connection problems over the last few days, especially severe yesterday and today (Feb.23)
My family member is taking on-line classes every day, several hours a day and is very frustrated with those outages and intermittent connection problems.
We have Cable 15 Pro (15/1 Mbps). We do not really need a very high speed/bandwidth, but we do need reliable and guaranteed 15Mbs down & 1mbs up at all times.
I have submitted a support request at help.teksavvy.com => Submit a Support Request => Technical Support.
In drop-down menu, they also have another option: "Forum- TekSavvy".
Which of the two would be better to report connection problems and outages ?
Modem: Thomson DCM476
Router: D-link-868L
↧
[Cable] intermittent/severe connection problems, Waterloo
↧
[Cable] Slow speeds & poor pings on rCable North Richmond Hill/Oak Ridges
Using rCable 60/10 @ Yonge/Stouffville Rd:
Fast.com: 14Mbps
Speedtest.net using teksavvy server: 13.55 Mbps down / 7.54Mbps up / 19ms ping
Traceroutes:
Tracing route to google-public-dns-b.google.com [8.8.4.4]over a maximum of 30 hops: 1 1 ms <1 ms <1 ms 192.168.0.1 2 14 ms 28 ms 33 ms 69.63.255.158 3 * * * Request timed out. 4 25 ms 30 ms 36 ms xe-1-0-2-6071-agg01-tor2.teksavvy.com [198.48.248.81] 5 16 ms 34 ms 36 ms ae1-0-bdr01-tor.teksavvy.com [206.248.155.13] 6 26 ms 25 ms 38 ms 72.14.212.134 7 25 ms 14 ms 47 ms 209.85.255.197 8 14 ms 12 ms 27 ms 108.170.234.17 9 381 ms 415 ms 418 ms google-public-dns-b.google.com [8.8.4.4] Tracing route to google-public-dns-a.google.com [8.8.8.8]over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms 192.168.0.1 2 35 ms 20 ms 18 ms 69.63.255.158 3 * * * Request timed out. 4 124 ms 79 ms 105 ms xe-1-0-2-221-agg01-tor.teksavvy.com [198.48.240.169] 5 15 ms 20 ms 15 ms ae2-0-bdr01-tor2.teksavvy.com [206.248.155.17] 6 16 ms 17 ms 35 ms 72.14.211.14 7 15 ms 12 ms 13 ms 216.239.62.197 8 13 ms 51 ms 37 ms 108.170.234.29 9 25 ms 13 ms 30 ms google-public-dns-a.google.com [8.8.8.8]
Any ideas? All above tests were conducted within the last 20 minutes.
↧
↧
[DSL] QoS settings tweaks
Am trying out Tomato and looking for some input on what value should go in this field in Tomato: DSL Overhead Value - ATM Encapsulation Type:
[att=1]
Which of these applies for DSL?
↧
Extremely high ping/lag, Cambridge
rCable 30/5 Cambridge.
This is weird. Things are very very laggy here. I tried a ping test which confirmed something is amiss:
$ ping www.google.ca -c 15PING www.google.ca (206.248.169.121) 56(84) bytes of data.64 bytes from 206-248-169-121.dsl.teksavvy.com (206.248.169.121): icmp_seq=1 ttl=59 time=64.8 ms64 bytes from 206-248-169-121.dsl.teksavvy.com (206.248.169.121): icmp_seq=2 ttl=59 time=58.9 ms64 bytes from 206-248-169-121.dsl.teksavvy.com (206.248.169.121): icmp_seq=3 ttl=59 time=196 ms64 bytes from 206-248-169-121.dsl.teksavvy.com (206.248.169.121): icmp_seq=4 ttl=59 time=1021 ms64 bytes from 206-248-169-121.dsl.teksavvy.com (206.248.169.121): icmp_seq=5 ttl=59 time=1016 ms64 bytes from 206-248-169-121.dsl.teksavvy.com (206.248.169.121): icmp_seq=6 ttl=59 time=713 ms64 bytes from 206-248-169-121.dsl.teksavvy.com (206.248.169.121): icmp_seq=7 ttl=59 time=296 ms64 bytes from 206-248-169-121.dsl.teksavvy.com (206.248.169.121): icmp_seq=8 ttl=59 time=1014 ms64 bytes from 206-248-169-121.dsl.teksavvy.com (206.248.169.121): icmp_seq=9 ttl=59 time=1033 ms64 bytes from 206-248-169-121.dsl.teksavvy.com (206.248.169.121): icmp_seq=10 ttl=59 time=1015 ms64 bytes from 206-248-169-121.dsl.teksavvy.com (206.248.169.121): icmp_seq=11 ttl=59 time=1014 ms64 bytes from 206-248-169-121.dsl.teksavvy.com (206.248.169.121): icmp_seq=12 ttl=59 time=109 ms64 bytes from 206-248-169-121.dsl.teksavvy.com (206.248.169.121): icmp_seq=13 ttl=59 time=1025 ms64 bytes from 206-248-169-121.dsl.teksavvy.com (206.248.169.121): icmp_seq=14 ttl=59 time=415 ms64 bytes from 206-248-169-121.dsl.teksavvy.com (206.248.169.121): icmp_seq=15 ttl=59 time=41.0 ms --- www.google.ca ping statistics ---15 packets transmitted, 15 received, 0% packet loss, time 14028msrtt min/avg/max/mdev = 41.070/602.448/1033.984/421.849 ms, pipe 2
Well now that just does not look right!
traceroute doesn't help though, but shows that my equipment is not the culprit at least, nor are some of TekSavvy's routers:
traceroute www.google.catraceroute to www.google.ca (206.248.169.120), 30 hops max, 60 byte packets 1 192.168.1.1 (192.168.1.1) 1.144 ms 1.602 ms 2.074 ms 2 * * * 3 * * * 4 xe-0-1-0-612-agg01-tor.teksavvy.com (198.48.244.193) 16.473 ms 18.871 ms 16.543 ms 5 ae0-2160-bdr01-tor.teksavvy.com (192.171.59.69) 18.122 ms 19.222 ms ae2-0-bdr01-tor2.teksavvy.com (206.248.155.17) 19.061 ms 6 ae8-0-bdr01-tor2.teksavvy.com (206.248.155.9) 19.061 ms * * 7 * * * 8 * * * 9 * * *10 * * *11 * * *12 * * *13 * * *14 * * *15 * * *16 * * *17 * * *18 * * *19 * * *20 * * *21 * * *22 * * *23 * * *24 * * *25 * * *26 * * *27 * * *28 * * *29 * * *30 * * *
(looks like all Rogers equipment does not respond)
A speed test looks normal:
but the devil's in the details:quote:Server View
New York, NY, USA (INTERNAP) d8 3.45 Mb/s 970.6±22.4ms 4% 205
Montreal, QC, Canada (zerofail) d4 2.15 Mb/s 976.3±19.3ms 2.4% 121
Toronto, Canada (teksavvy.ca) d4 3.83 Mb/s 964.1±13.8ms 3.3% 133(the numbers after the "Mb/s" are the RTT/jitter averages).
I don't put much stock in bufferbloat but the test soared to nearly 1000 ms.
I guess I'm the only one noticing this as I'm not seeing any other reports on this forum?
I'm running a smokeping and will post as it comes in.
I'll post signal stats next.
↧
new router for 250/20.. recommendations?
Hi, so last week I got the upgrade to 250/20 service from a pretty decent 100/10 (with a bit of bufferbloat). However, I noticed that consistently on all speed tests with the same hardare I'm only getting speeds of 145/20. Bypassing the router and plugging the modem directly into a fresh installed system with cat6 cable I get the full speeds +/- 10mpbs.. I also tried disabling all QoS settings I had set (to counter the bufferbloat previously) and also made sure all the cables I was testing with were cat6.. but still no improvement
The router I'm using is a tp-link N600 model with openwrt, which I think needs to be upgraded as it all points to it being the bottleneck.
Is this expected? even though it's a gigabit wan port, I'm understanding that somewhere internally it can't handle these wan speeds. Am I completely wrong? or should I upgrade..? or is there something else I'm missing?
If I'm upgrading, so far I've been looking at AC1900 based routers as a starting point. Anything that would be recommended? I twitch stream occasionally with friends, lots of gaming, but also a lot of photo/video uploading.. anything you can recommend would be helpful
thanks
↧
↧
[DSL] Is "Zyxel VSG1432-B101" good?
I have purchased a Zyxel VSG1432-B101 modem from Teksavvy about 5 years ago.
Is it still good for 50/10Mbps DSL as far as hardware and firmware?
↧
[TekTalk] What is password for Grandstream HT812 supplied by TS?
From a Grandstream HT812 user guide, the admin password is supposed to be admin, and a user-level pw is supposed to be 123. Neither one work on the unit I'm playing with right now. Does TS change or set the PW to something different if you obtain this box from them?
↧
Firewall rules
Not really TekSavvy specific, but it is in regard to my TekSavvy connection. What sort of firewall rules do you guys run?
↧
[DSL] Got screwed up by Bell
I saw a lot of people calling Bell as Bhell and Rogers as Robbers, I don't understand why, I know they will screw you up on bill and overage issues, but don't really think there are other hidden tricks... But now Bell told me why.
I upgraded my DSL from grandfathered 15/1 to 15/10 a few days ago, and a bell tech visited my home to do the activation. Actually he had nothing to do because the POTS splitter was already installed a long time ago and what he had to do was just to change the profile to 15/10. I oversaw him choosing the profile from a drop down list from his handheld gadget, and he chose the 15xxx down/3008 kbps up. I told him: Sir I paid for 15/10, even though 10 up is not totally attainable, could you please give me at least 7 or 8 up. Because I really want faster uplooad speed. He replied: Normally, 1 Mbps up is enough for normal use... and showed me the Bell webpage of this profile which indicates most people get 3Mbps
And I just saw under this profile there is 15xxx/35xx. I asked him to move to this, but he said that it will be the same "user experience". I oversaw the next profile which was 16xxx/11xx, which I thought was a profile to compensate overheads and perfect for 15/10. I asked, he said: you bought only 15 down, I cannot set 16xxx... I begged him several times, he finally agreed to call his supervisor, and he supervisor authorized him to give me 16xxx/11xx, I thanked him again, and he left.
Finally I got what I paid for. But I had to beg him to get what I paid for. I now understand why people call Bell "Bhell"...
(PS: even on a Stinger, I can get pretty good line stats.. So why does Bell only wants to give me 3M upload...)
↧
↧
sCable - DHCP IP but no route to internet ??
lost my connection at 1:04am. tried reboot of cable modem. i get an ip address fine. but not outbound routes. cant connect to google or anywhere else. teksavvy screwed up internet in BC ??
↧
New TPIA speeds for rCable
https://www.dslreports.com/forum/r31278008-Rogers-introduce-75-10-150-15-500-20-1024-30-withdrawal-100-10-1024-50
↧
[Cable] got a new drop hung so how do these stats look?
Downstream Channel
Channel Lock Status Modulation Channel ID Symbol Rate Frequency Power SNR
1 Locked QAM256 47 5360537 693000000 Hz 4.5 dBmV 41.9 dB
2 Locked QAM256 44 5360537 675000000 Hz 3.9 dBmV 41.3 dB
3 Locked QAM256 45 5360537 681000000 Hz 3.9 dBmV 41.4 dB
4 Locked QAM256 46 5360537 687000000 Hz 4.2 dBmV 41.4 dB
5 Locked QAM256 43 5360537 669000000 Hz 3.9 dBmV 41.4 dB
6 Locked QAM256 9 5360537 357000000 Hz 0.2 dBmV 39.4 dB
7 Locked QAM256 10 5360537 363000000 Hz 0.2 dBmV 39.0 dB
8 Locked QAM256 11 5360537 369000000 Hz 0.6 dBmV 39.4 dB
Upstream Channel
Channel Lock Status Modulation Channel ID Symbol Rate Frequency Power
1 Locked QAM64 3 2560 Ksym/sec 38596000 Hz 35.5 dBmV
2 Locked QAM64 2 5120 Ksym/sec 23700000 Hz 34.3 dBmV
3 Locked QAM64 1 5120 Ksym/sec 30596000 Hz 35.5 dBmV
4 Not Locked Unknown 0 0 Ksym/sec 0.0 dBmV
So do these numbers look ok? The service was initially installed on the bad drop, with an 8db attenuator and the levels were out of whack on some frequency's.
The new drop has been hung, with no attenuator on the line now, that I know of. I do have the original 8db attenuator sitting on my desk here. do I need it, or do my levels look fine now?
↧
rationale for MLPPP unlimited plan requirement
Hi all, I just want to ask about the requirement that connections be on the unlimited tier before MLPPP is allowed. I thought I had done my research before planning to use MLPPP, because I'd seen the older posts on this forum that talked about adding up the caps that each connection had, and it was only after having set up the internal wiring I needed, while I was placing the order, that I was blindsided by the requirement, which forced me to stop and reconsider.
Last I heard, the cost structure for Teksavvy to provision a DSL connection for a customer involves both a per-user monthly fee for the line itself, and then interconnect bandwidth costs that are shared among all of their customers. This is still current according to this page.
Now, if I was trying to bond several very fast connections together to get a faster one than the maximum offered, then it would be reasonable for Teksavvy to argue that such a fast connection is putting strong upward pressure on Teksavvy's need to pay for more interconnect bandwidth. However, I'm just a long time customer who has moved from a suburban to a rural address. I used to be able to get 25Mb down for about $50 a month on Teksavvy Cable, which was great, and it's worth noting that Rogers has higher interconnect fees according to the above link. Now I'm looking at a 4x MLPPP connection that would at best get less than 14Mbps down. That's going to impose a much lower requirement for the interconnect bandwidth, and yet I've been told that instead of the $125 a month I was expecting it to cost (already quite high), it's going to be $160 per month instead.
I've always thought of Teksavvy as an organization that tries to deliver good prices to its customers, based on what is fair as opposed to what they can get away with. Knowing what I do about the underlying cost structure, I'm struggling to understand why Teksavvy decided to price MLPPP this way. I'm sending this message to politely ask for:
a reply from a Teksavvy employee with a friendly explanation of why this policy change was adopted.
an up to date page on Teksavvy's website describing the MLPPP situation now, to prevent any other potential users from wasting time and money pursing a plan that's based on out of date information, like I did.
↧
↧
New tiers since Rogers dropped 250?
I was looking at Rogers site and it looks like they don't have a 250mbps plan anymore. I see that they now have a 500mbps plan though. Is there any change to what Teksavvy will be offering? My apologies if this has already been addressed.
↧
[DSL] Is dsl sometimes rather slow to reconect?
Been on dsl every since teksavvy switched me over from the appalling unstable cable in my area.
The smart 505 is a rock solid modem with a decent router with the most unfriendly firmware i every seen....teksavvy provides config files to get around this :)
One thing i have noticed is it can be slow to reconnect at times if there down time or off for whatever reason.
Anyone else notice this and is it firmware related or just a fact of dsl these days?
Otherwise its incredibly boring since it just works ;)
↧
[Cable] Rogers got a funny defination of everythings working fine lol
Last year when i had cable internet one rogers tech damaged the drop line with his ladder but as it turned out that was the least of the problems .
The main hub for the are has been damaged for ages and many of the lines where in such bad shape hd cable was a nightmare let alone internet.
The last person with rogers around her canceled it and left for dsl.
Seems they finally clued in and start actually doing major repairs for 10 hours straight.
At this point its a little late i suspect and you think it would dawn on rogers/bell that shafting its users kind of doesn't work in the long run.
↧
[DSL] IPv6 goes down after 2 weeks
For the longest time, I have had weird problems with IPv6 at TSI. Originally, I thought the problem was related to my weird FreeBSD router I was running back then. After getting an omnia router that runs a more or less standard OpenWRT distribution, I figured my chances would have been a bit better at getting a more reliable IPv6 connexion.
Some background: I have a static IPv4 and IPv6 (/56) allocation over a dry DSL loop in the Montreal area.
The symptom is that the IPv6 network would suddenly stop working after about 2 weeks of router uptime. The user-visible effect is that there are abysmal delays in loading everything: IPv4 still works, so some applications fallback (Chrome falls back to IPv4 immediately, which is nice; Firefox just totally fails to fallback; Debian's APT takes 6 minutes to fall back, etc).
In the FreeBSD router, restarting the dhcpcd daemon fixed the issue, presumably because the /56 netblock would get requested again and properly rerouted inside TSI's network. With the new router, rebooting it fixes the issue.
After calling the first time about this in early January, we left the issue aside because I made the mistake of rebooting the router which... fixed the issue, so they weren't able to diagnose it further. But then I waited for the problem to inevitably manifest itself again and, lo and behold, in mid February IPv6 was down again. After a day or two of exchanges between the various support levels at TSI, I was told that the problem was that:
He uses static point-to-point /64 and static PD /56. Static /56 doesn't work with static /64 with some types of CPE, including SmartRG. To make PD /56 work you can remove static /64 and then he will get dynamic /128 and static /56.
Now of course, for the changes to take effect, I had to reboot the router, which, tada!, fixed the issue again. But now, two weeks later, IPv6 is down again.
So I do not believe the diagnostic was accurate. Now Both the /128 IP and IPs in the /56 fail to route. My router has the IP blocks 2607:f2c0:8006:2::ab8b/128 and 2607:f2c0:f00f:8f00::/56.
Here's the traceroute to the /56 from a IPv6-router machine in the Debian.org infrastructure:
anarcat@paradis:~$ traceroute6 2607:f2c0:f00f:8f00:beae:c5ff:fe89:e238
traceroute vers 2607:f2c0:f00f:8f00:beae:c5ff:fe89:e238 (2607:f2c0:f00f:8f00:beae:c5ff:fe89:e238) de 2001:41c8:1000:21::21:31, port 33434, du port 32834, 30 sauts max, 60 octets/paquet
1 bm-bl1.debian.org (2001:41c8:1000:20::20:241) 0.428 ms 0.286 ms 0.317 ms
2 2001:41c8:61::2 (2001:41c8:61::2) 10.312 ms 0.704 ms 1.019 ms
3 * * *
4 2001:41c8:0:116::1 (2001:41c8:0:116::1) 6.350 ms 6.177 ms 6.465 ms
5 * * *
6 lonap.he.net (2001:7f8:17::1b1b:1) 8.061 ms 6.004 ms 17.036 ms
7 10ge2-9.core1.lon2.he.net (2001:470:0:2cd::1) 53.062 ms 32.648 ms 23.478 ms
8 100ge1-1.core1.nyc4.he.net (2001:470:0:2cf::2) 75.309 ms 75.343 ms 83.178 ms
9 100ge10-1.core1.nyc6.he.net (2001:470:0:259::2) 75.420 ms 75.218 ms 80.591 ms
10 * * *
11 ae2-10-bdr01-mtl.teksavvy.com (2607:f2c0:ffff:14:15::1) 85.330 ms 85.371 ms 85.515 ms
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
Notice how the traceroute to the /128 routes differently:
anarcat@paradis:~$ traceroute6 2607:f2c0:8006:2::ab8b
traceroute vers 2607:f2c0:8006:2::ab8b (2607:f2c0:8006:2::ab8b) de 2001:41c8:1000:21::21:31, port 33434, du port 64582, 30 sauts max, 60 octets/paquet
1 bm-bl1.debian.org (2001:41c8:1000:20::20:241) 0.285 ms 0.200 ms 0.064 ms
2 2001:41c8:61::2 (2001:41c8:61::2) 0.715 ms 0.518 ms 0.538 ms
3 po1.cr1.yrk.bytemark.co.uk (2001:41c8:0:10e::1) 0.966 ms * 1.411 ms
4 2001:41c8:0:115::1 (2001:41c8:0:115::1) 6.126 ms 6.478 ms 6.202 ms
5 * * *
6 lonap.he.net (2001:7f8:17::1b1b:1) 6.094 ms 5.901 ms 6.306 ms
7 10ge2-9.core1.lon2.he.net (2001:470:0:2cd::1) 10.053 ms 7.712 ms 24.821 ms
8 100ge1-1.core1.nyc4.he.net (2001:470:0:2cf::2) 80.105 ms 75.682 ms 80.548 ms
9 100ge10-1.core1.nyc6.he.net (2001:470:0:259::2) 142.866 ms 75.301 ms 75.470 ms
10 * * *
11 ae2-10-bdr01-mtl.teksavvy.com (2607:f2c0:ffff:14:15::1) 85.561 ms 85.167 ms 85.343 ms
12 xe-2-0-0-2230-bdr01-tor.teksavvy.com (2607:f2c0:ffff:1:14:2:0:1) 88.488 ms 89.022 ms 88.142 ms
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
The packets never reach my network: they fall over the side within TSI's network. This, for me, is a clear indication there is a routing problem inside TSI's network.
It's interesting to note that killing the odhcp6c daemon fixed routing here for now. This is probably because this causes the IPv6 interface to go down, which causes the netifd daemon to bring it backup up, which restarts odhcp6c, which requests the netblock again and fixes routing. The program starts with: odhcp6c -s /lib/netifd/dhcpv6.script -P0 -t120 pppoe-wan.
Having heard some reports that dhcpc5 works better with TSI, I have also attempted to make that work on the OpenWRT platform instead of the odhcp6v shipped with OpeWRT. But it's tricky: odhcp6c starts up automatically and will create the same problems... it's unclear how to disable it short of uninstalling the package completely, which will just disable IPv6 altogether. I believe, therefore, that it is impossible to use dhcpcd instead of udhcpc in OpenWRT.
For now I think I may just setup a cronjob to automatically restart the odhcp6c program at regular intervals, but that's a rather ugly patch.
Why should I need to re-request those netblocks every other week? Is there something wrong inside the TSI network that makes those routes disappear?
In general, I have found my customer support experience to be pleasant with TSI. People are polite and supportive. But what I have heard is that while IPv6 is *provided* as a service, it's not actually *supported* right now. Level 1 staff have no idea how to answer requests and level 2 don't really know what's going on either. It would be great to be able to talk with more skilled staff at TSI to try and diagnose those issues, because it will make things better for everyone in the long term...
A short timeline of the situation:
* Wed, 11 Jan 2017 10:02:42 -0500, me: first officially reported outage, modem rebooted
* Sun, 15 Jan 2017 15:46:02 +0000, TSI: callback
* Sun, 15 Jan 2017 16:53:49 -0500, me: detailed report of the situation added to ticket
* Sun, 15 Jan 2017 22:21:22 +0000, TSI: account handled by Tier 2 team
* Wed, 18 Jan 2017 23:05:00 +0000, TSI: ticket closed because the issue was fixed
* Wed, 15 Feb 2017 16:08:49 -0500, me: second outage, ticket reopened, modem not rebooted
* Thu, 16 Feb 2017 23:52:54 +0000, TSI: response regarding disabling the /64
* Fri, 17 Feb 2017 15:26:49 -0500, me & TSI: phone call, /64 disabled, modem rebooted
* Sun, 19 Feb 2017 09:06:25 +0000, TSI: ticket marked as resolved
* Thu, 2 Mar 2017 10:12:25 -0500, me: third outage, this report created
Delays between outages:
* Wed 11 Jan 2017 - Wed 15 Feb 2017: 35 days, or almost exactly 5 weeks
* Fri 17 Feb 2017 - Thu 2 Mar 2017: 13 days, or about 2 weeks
It's interesting to me that this happens about always on a wednesday or a thursday, and pretty much aligned with round weeks since the last outage. To me this speaks of some automated process of some sort *somewhere*. I'll keep on documenting the delays between outages... in two weeks, I guess. :)
↧
↧
Anyone notice some weird Google Sign in activity?
I've had google accounts for yeeeeears, and some brand new. Never had any problems.
I know my password I know the account name.
Then yesterday. BOOM. Google doesn't recognize my login. Says they're fradulent. Saaaamme IP address I've had for the past, at least 6 months.
Got locked out of one of my accounts. Scary. Had to get the account texted (which I hate) to verify it.
One string of accounts I use as google drive of the eight, 001 had to be texted, 004 had to be texted, but the rest of the accounts from 002 to 008 were fine.
My main 2 accounts that I've had for many,many years I had to go to secondary questions.
↧
increased upload speeds on sCable
As per this document on sCable, https://community.shaw.ca/docs/DOC-10791/?emid=res-clm-em-3022017-Marnewsletter-v1-L9
Will we see the same increase on teksavvy?
The 0.5mbit upload I have now is pretty painful.
I have problems with uploads to google drive even completing. 1.5 isn't great, but its a start...
↧
[DSL] DSL Outage/Issues in Oakville?
Anyone else having issues with DSL in the Oakville area? Since at around 8pm I haven't had access. Tried rebooting my SR505N model to no avail.
Seems like a DNS issue, but I've tried using googles (8.8.8.8) and that didn't work either.
Stats/logs below.
Ping Gateway and DNS are FAILED.
Test the connection to your DSL service provider
Test xDSL Synchronization: PASS Help
Test ATM OAM F5 segment ping: DISABLED Help
Test ATM OAM F5 end-to-end ping: DISABLED Help
Test the connection to your Internet service provider
Test PPP server connection: PASS Help
Test authentication with ISP: PASS Help
Test the assigned IP address: PASS Help
Ping default gateway: FAIL Help
Ping primary Domain Name Server: FAIL Help
Device Info
Board ID: 963168MBV_17AZZ
Symmetric CPU Threads: 2
Build Timestamp: 160513_1721
Software Version: 2.5.0.11
Configuration File Origin: TekSavvy
Bootloader (CFE) Version: 1.0.38-114.185
DSL PHY and Driver Version: A2pv6F039j.d25d
Wireless Driver Version: 6.30.163.23.cpe4.12L08.1
Uptime: 0D 0H 5M 48S
System Base MAC Address: 00:23:6a:ec:eb:b9
Serial Number: SR505NA0B5-9025674
This information reflects the current status of your WAN connection.
B0 Traffic Type: PTM
B0 Line Rate - Upstream (Kbps): 11321
B0 Line Rate - Downstream (Kbps): 16192
B1 Traffic Type: Inactive
B1 Line Rate - Upstream (Kbps): 0
B1 Line Rate - Downstream (Kbps): 0
LAN IPv4 Address: 1.1.1.1
Default Gateway: ppp0.1
WAN IPv4 Address 107.179.148.81
Primary DNS Server: 206.248.154.170
Secondary DNS Server: 206.248.154.22
LAN IPv6 ULA Address:
Default IPv6 Gateway:
Date/Time: Thu Jan 1 00:05:48 1970
SR505N Log
Date/Time Facility Severity Message
Jan 1 00:00:24 daemon err syslog: caTmBlk:Time Blocking: Shutting down, sig -1
Jan 1 00:00:52 daemon err syslog: CDM:subnetHandler_ReportIPv4Host: Failed to locate subnet for ::29
Jan 1 00:00:52 daemon err syslog: CDM:subnetHandler_ReportIPv4Host: Failed to locate subnet for ::29
Jan 1 00:00:52 daemon err syslog: CDM:subnetHandler_ReportIPv4Host: Failed to locate subnet for ::29
Jan 1 00:00:54 daemon err syslog: CDM:caCdmPollForMessages: unrecognized msg 0x10000250
Jan 1 00:01:22 daemon crit kernel: Line 0: xDSL G.994 training
Jan 1 00:01:30 daemon crit kernel: Line 0: VDSL G.993 started
Jan 1 00:01:32 daemon crit kernel: Line 0: VDSL2 link down
Jan 1 00:02:10 daemon crit kernel: Line 0: xDSL G.994 training
Jan 1 00:02:15 daemon crit kernel: Line 0: VDSL G.993 started
Jan 1 00:02:34 daemon crit kernel: Line 0: VDSL2 link up, Bearer 0, us=11321, ds=16192
Jan 1 00:02:36 daemon crit syslog: PPP server detected.
Jan 1 00:02:36 daemon crit syslog: PPP session 7764 established.
Jan 1 00:02:39 daemon crit syslog: PPP LCP UP.
Jan 1 00:03:09 daemon err syslog: [PPPoE] No response to PAP authenticate-requests
Jan 1 00:03:09 daemon err syslog: [PPPoE] Couldn't increase MRU to 1500
Jan 1 00:03:09 daemon err syslog: User name and password authentication failed.
Jan 1 00:03:14 daemon crit syslog: PPP server detected.
Jan 1 00:03:14 daemon crit syslog: PPP session 7765 established.
Jan 1 00:03:18 daemon crit syslog: PPP server detected.
Jan 1 00:03:18 daemon crit syslog: PPP session 7766 established.
Jan 1 00:03:21 daemon crit syslog: PPP LCP UP.
Jan 1 00:03:30 daemon crit syslog: PPP server detected.
Jan 1 00:03:30 daemon crit syslog: PPP session 1 established.
Jan 1 00:03:33 daemon crit syslog: PPP LCP UP.
Jan 1 00:03:51 daemon err syslog: [PPPoE] No response to PAP authenticate-requests
Jan 1 00:03:51 daemon err syslog: [PPPoE] Couldn't increase MRU to 1500
Jan 1 00:03:51 daemon err syslog: User name and password authentication failed.
Jan 1 00:03:52 daemon crit syslog: Received valid IP address from server. Connection UP.
Jan 1 00:03:55 daemon crit syslog: PPP server detected.
Jan 1 00:03:55 daemon crit syslog: PPP session 2 established.
Jan 1 00:03:58 daemon crit syslog: PPP LCP UP.
Jan 1 00:03:59 daemon crit syslog: Received valid IP address from server. Connection UP.
Jan 1 00:04:07 daemon err syslog: caTmBlk:Time Blocking: Shutting down, sig -1
Jan 1 00:05:11 daemon err syslog: stund:gethostbyname acs.clearaccess.com failed!
Jan 1 00:09:20 daemon err syslog: httpd:560.122:do_ej:551:Could not open /webs/ping.html?target_host_address=google.com
Statistics -- xDSL
Mode: VDSL2
Traffic Type: PTM
Status: Up
Link Power State: L0
Downstream Upstream
Line Coding(Trellis): On On
SNR Margin (dB): 29.4 7.7
Attenuation (dB): 19.5 0.0
Output Power (dBm): 13.1 10.8
Attainable Rate (Kbps): 39901 13976
PhyR Status: Inactive Inactive
G.inp Status: Inactive Inactive
Path 0 Path 1
Downstream Upstream Downstream Upstream
Rate (Kbps): 16192 11321 0 0
B (# of bytes in Mux Data Frame): 237 240 0 0
M (# of Mux Data Frames in an RS codeword): 1 1 0 0
T (# of Mux Data Frames in an OH sub-frame): 39 22 0 0
R (# of redundancy bytes in the RS codeword): 16 14 0 0
S (# of data symbols over which the RS code word spans): 0.4669 0.6764 0.0000 0.0000
L (# of bits transmitted in each data symbol): 4352 3016 0 0
D (interleaver depth): 1 1 0 0
I (interleaver block size in bytes): 254 255 0 0
N (RS codeword size): 254 255 0 0
Delay (msec): 0 0 0 0
INP (DMT symbol): 0.00 0.00 0.00 0.00
OH Frames: 0 0 0 0
OH Frame Errors: 0 0 0 0
RS Words: 2158999 1496361 0 0
RS Correctable Errors: 0 3 0 0
RS Uncorrectable Errors: 0 0 0 0
RS Codewords Received: 0 0 0 0
RS Codewords Corrected: 0 0 0 0
RS Codewords Uncorrected: 0 0 0 0
HEC Errors: 0 0 0 0
OCD Errors: 0 0 0 0
LCD Errors: 0 0 0 0
Total Cells: 7909104 0 0 0
Data Cells: 240 0 0 0
Bit Errors: 0 0 0 0
Total ES: 0 1
Total SES: 0 1
Total UAS: 139 139
↧