My speed starts normal and slows within 24 hours, it seems like I'm being throttled.

MrRandom

I use Comcast and I've never been able to get my full speed except When I had a DOCSIS 2.0 modem I could max out my 33Mbps connection. My speed has always been stable until a couple weeks ago when my modem was rebooted, I'm assuming by Comcast. When Everything reconnected my downloads resumed at 1.9MB and I was downloading at 7.2MB before the modem rebooted.

This is my ISP speed...

This is my average speed through AirVPN...

This is what it's been dropping down too, 1.9MB on my bandwidth monitor...

If I disconnect and reconnect to the same server my speed goes back to normal. I'm not sure how long it lasts because I'm not testing my speed or looking at my computer 24 hours a day but I know it's less the 24 hours.

Last night I tried TCP port 443 and today when I tested my speed it was throttled again. UDP has never worked for me, it gives me terrible speed and the only ports I can really use are TCP 80 and TCP 443.

Edit: I do use an older version of Eddie because I never wanted to deal with the driver problems and I never had any problems with the older version. Here's a fresh log...

I 2017.11.30 00:58:54 - Session starting.
I 2017.11.30 00:58:54 - Installing tunnel driver
I 2017.11.30 00:58:54 - DNS of a network adapter forced (Realtek PCIe GBE Family Controller)
I 2017.11.30 00:58:54 - Checking authorization ...
! 2017.11.30 00:58:54 - Connecting to Alhena (Canada, Toronto, Ontario)
. 2017.11.30 00:59:41 - OpenVPN > OpenVPN 2.3.6 x86_64-w64-mingw32 [sSL (OpenSSL)] [LZO] [iPv6] built on Jan 12 2015
. 2017.11.30 00:59:41 - OpenVPN > library versions: OpenSSL 1.0.1k 8 Jan 2015, LZO 2.08
. 2017.11.30 00:59:41 - OpenVPN > MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:3100
. 2017.11.30 00:59:41 - OpenVPN > Control Channel Authentication: tls-auth using INLINE static key file
. 2017.11.30 00:59:41 - OpenVPN > Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2017.11.30 00:59:41 - OpenVPN > Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2017.11.30 00:59:41 - OpenVPN > Socket Buffers: R=[8192->8192] S=[8192->8192]
. 2017.11.30 00:59:41 - OpenVPN > Attempting to establish TCP connection with [AF_INET]162.219.176.2:443 [nonblock]
. 2017.11.30 00:59:41 - OpenVPN > TCP connection established with [AF_INET]162.219.176.2:443
. 2017.11.30 00:59:41 - OpenVPN > TCPv4_CLIENT link local: [undef]
. 2017.11.30 00:59:41 - OpenVPN > TCPv4_CLIENT link remote: [AF_INET]162.219.176.2:443
. 2017.11.30 00:59:42 - OpenVPN > TLS: Initial packet from [AF_INET]162.219.176.2:443, sid=70175a45 c343f34c
. 2017.11.30 00:59:42 - OpenVPN > VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org
. 2017.11.30 00:59:42 - OpenVPN > Validating certificate key usage
. 2017.11.30 00:59:42 - OpenVPN > ++ Certificate has key usage 00a0, expects 00a0
. 2017.11.30 00:59:42 - OpenVPN > VERIFY KU OK
. 2017.11.30 00:59:42 - OpenVPN > Validating certificate extended key usage
. 2017.11.30 00:59:42 - OpenVPN > ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
. 2017.11.30 00:59:42 - OpenVPN > VERIFY EKU OK
. 2017.11.30 00:59:42 - OpenVPN > VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=server, emailAddress=info@airvpn.org
. 2017.11.30 00:59:42 - OpenVPN > Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
. 2017.11.30 00:59:42 - OpenVPN > Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2017.11.30 00:59:42 - OpenVPN > Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
. 2017.11.30 00:59:42 - OpenVPN > Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2017.11.30 00:59:42 - OpenVPN > Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 4096 bit RSA
. 2017.11.30 00:59:42 - OpenVPN > [server] Peer Connection Initiated with [AF_INET]162.219.176.2:443
. 2017.11.30 00:59:42 - OpenVPN > SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
. 2017.11.30 00:59:42 - OpenVPN > PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 10.5.0.1,comp-lzo no,route-gateway 10.5.0.1,topology subnet,ping 10,ping-restart 60,ifconfig 10.5.0.36 255.255.0.0'
. 2017.11.30 00:59:42 - OpenVPN > OPTIONS IMPORT: timers and/or timeouts modified
. 2017.11.30 00:59:42 - OpenVPN > OPTIONS IMPORT: LZO parms modified
. 2017.11.30 00:59:42 - OpenVPN > OPTIONS IMPORT: --ifconfig/up options modified
. 2017.11.30 00:59:42 - OpenVPN > OPTIONS IMPORT: route options modified
. 2017.11.30 00:59:42 - OpenVPN > OPTIONS IMPORT: route-related options modified
. 2017.11.30 00:59:42 - OpenVPN > OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
. 2017.11.30 00:59:42 - OpenVPN > do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
. 2017.11.30 00:59:42 - OpenVPN > open_tun, tt->ipv6=0
. 2017.11.30 00:59:42 - OpenVPN > TAP-WIN32 device [Local Area Connection 2] opened: \\.\Global\{52F83D7D-A7C1-4EEF-9117-30A6F78E5440}.tap
. 2017.11.30 00:59:42 - OpenVPN > TAP-Windows Driver Version 9.9
. 2017.11.30 00:59:42 - OpenVPN > Set TAP-Windows TUN subnet mode network/local/netmask = 10.5.0.0/10.5.0.36/255.255.0.0 [sUCCEEDED]
. 2017.11.30 00:59:42 - OpenVPN > Notified TAP-Windows driver to set a DHCP IP/netmask of 10.5.0.36/255.255.0.0 on interface {52F83D7D-A7C1-4EEF-9117-30A6F78E5440} [DHCP-serv: 10.5.255.254, lease-time: 31536000]
. 2017.11.30 00:59:42 - OpenVPN > Successful ARP Flush on interface [17] {52F83D7D-A7C1-4EEF-9117-30A6F78E5440}
. 2017.11.30 00:59:42 - OpenVPN > TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0 u/d=up
. 2017.11.30 00:59:42 - OpenVPN > C:\Windows\system32\route.exe ADD 162.219.176.2 MASK 255.255.255.255 192.168.1.1
. 2017.11.30 00:59:42 - OpenVPN > ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=100 and dwForwardType=4
. 2017.11.30 00:59:42 - OpenVPN > Route addition via IPAPI succeeded [adaptive]
. 2017.11.30 00:59:42 - OpenVPN > C:\Windows\system32\route.exe ADD 192.168.1.1 MASK 255.255.255.255 192.168.1.1 IF 11
. 2017.11.30 00:59:42 - OpenVPN > ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=100 and dwForwardType=4
. 2017.11.30 00:59:42 - OpenVPN > Route addition via IPAPI succeeded [adaptive]
. 2017.11.30 00:59:42 - OpenVPN > C:\Windows\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.5.0.1
. 2017.11.30 00:59:42 - OpenVPN > ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
. 2017.11.30 00:59:42 - OpenVPN > Route addition via IPAPI succeeded [adaptive]
. 2017.11.30 00:59:42 - OpenVPN > C:\Windows\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 10.5.0.1
. 2017.11.30 00:59:42 - OpenVPN > ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
. 2017.11.30 00:59:42 - OpenVPN > Route addition via IPAPI succeeded [adaptive]
. 2017.11.30 00:59:42 - Starting Management Interface
. 2017.11.30 00:59:42 - OpenVPN > Initialization Sequence Completed
I 2017.11.30 00:59:42 - Flushing DNS
I 2017.11.30 00:59:42 - Checking route
I 2017.11.30 00:59:43 - Checking DNS
! 2017.11.30 00:59:43 - Connected.
. 2017.11.30 00:59:43 - OpenVPN > MANAGEMENT: Client connected from [AF_INET]127.0.0.1:3100
. 2017.11.30 00:59:43 - OpenVpn Management > >INFO:OpenVPN Management Interface Version 1 -- type 'help' for more info

OpenSourcerer

You're asking for support for an old version of Eddie, hard to know which one. Maybe 2-3 years old, if it's OpenVPN 2.3.6. You should consider upgrading, also because there are some security vulnerabilities between your version and today's OpenVPN 2.4+. I also think it might have a positive influence on your issue.

Sent via Tapatalk. Means, I don't have a computer available now.

larky

You aren't being "throttled" by Comcast. I'll bet you are a residential service customer. If its not the Eddie software then you probably just have more Comcast customers using the same bandwidth space you use, thus slicing up the bandwidth more thus you have a smaller portion of it than before. Contrary to popular belief and the sales pitch, what Comcast (or any ISP) actually provides you is a bandwidth 'tier' (AKA 'bandwidth range') and not a 'connection speed' range. Contrary to the impression of the ISP sales and marketing material ISP's do not sell 'connection speed', they sell bandwidth and you are not the only one using that bandwidth they provided. Bandwidth and throughput (AKA in common usage as 'connection speed') are not the same thing, and that speed test you did for your pics is not really 'connection speed'. Bandwidth can never increase throughput, it can only contribute to limiting throughput. An increase in bandwidth only lessens the limiting contribution amount, a decrease in bandwidth increases the limiting contribution amount. Of course there is a little more to it than that, but that's probably what you are seeing and thinking its "throttling".

Staff

You aren't being "throttled" by Comcast.

This is the traffic shaping policy of Comcast for various residential lines:

https://www.xfinity.com/support/internet/network-management-information/

They call it "network congestion management" now.

Note how a user bandwidth allocation gets capped if customers exceed for 15 minutes "a certain percentage of their upstream or downstream bandwidth" (chapter "Real World" Types of Bandwidth Consumption That Might be Considered Too Much"). However, if the customer is using an XFINITY service, he/she should receive a notification of the congestion.

What's more, and this is of utmost importance for Net Neutrality, Comcast also claims that traffic shaping " is "protocol-agnostic," which means the system does not manage congestion based on the application(s) being used. It is also content neutral, and does not depend on the type of content that is generating traffic congestion. Simply put, congestion-managed traffic is not based on specific applications or content, but on current network conditions and recent amounts of data transferred by users.".

Kind regards

larky

Yeah, Comcast calls the "throttling" "network congestion management" now.

anyway, according to the time/date stamp in his pics he wasn't being "network congestion" managed by Comcast. "network congestion management" was turned off across the entire Comcast network for a period of time, his time/date stamps are during the period it was turned off.

cse

MrRandom,

Welcome to the wonderful world of comcast (xfinity). I developed the same issue some months ago. I was finally able to solve the issue by choosing Protocol UDP, Port 41185, Ip 1 (in the Protocols option of the Preferences menu -- Eddie 2.13.6). I hope this works for you, too.

By the way, if you upgrade to Eddie 2.13.6, you may need to remove the check mark from the Check AirVPN DNS option in the DNS section of the Preferences menu. Also, be aware the "flushing DNS" process can take quite a while to complete, so don't assume your computer "froze". In my case, the process sometimes takes 2 - 3 minutes to complete. After that, it runs like a champ.

cse

MrRandom

Thanks everyone for all the reply's, I'll try updating Eddie. I didn't think it could be any kind of "network congestion management" because when I disconnect AirVPN my connection speed is normal. When I reconnect to AirVPN, even the same server, my speed is normal. There hasn't been any speed issues or problems with my connection to Comcast, it's only when I'm connected to AirVPN and only after it's been connected for a while that my speed drops. If I am being throttled some how it's only the VPN connection that's being affected.

I'll report back any updates in a day or so, positive or negative.

MrRandom

MrRandom,

Welcome to the wonderful world of comcast (xfinity). I developed the same issue some months ago. I was finally able to solve the issue by choosing Protocol UDP, Port 41185, Ip 1 (in the Protocols option of the Preferences menu -- Eddie 2.13.6). I hope this works for you, too.

By the way, if you upgrade to Eddie 2.13.6, you may need to remove the check mark from the Check AirVPN DNS option in the DNS section of the Preferences menu. Also, be aware the "flushing DNS" process can take quite a while to complete, so don't assume your computer "froze". In my case, the process sometimes takes 2 - 3 minutes to complete. After that, it runs like a champ.

cse

Thank you so much!! I just installed Eddie 2.13.6 and selected the UDP, Port 41185, Ip 1 protocol. I didn't have the "Waiting TUN Interface" problem I had before and my speed is amazing!! It was taking forever to fresh the servers to get the latency and scores so I just picked one of my favorite servers.

Only time will tell if this solves my slowdown issue but this is my speed as of about 10 minutes ago...

Staff

Yeah, Comcast calls the "throttling" "network congestion management" now.

anyway, according to the time/date stamp in his pics he wasn't being "network congestion" managed by Comcast. "network congestion management" was turned off across the entire Comcast network for a period of time, his time/date stamps are during the period it was turned off.

That's interesting, where can we see a map/report of the periods of Comcast network congestion, segment by segment (according to reports, infrastructure of Comcast is - as expected - different in different areas: in some areas congestions are rare, in other ones they are frequent)?

Out of curiosity, how did you infer the time zone of the customer from those log?

Kind regards

larky

"Out of curiosity, how did you infer the time zone of the customer from those log?"

Did not use "those" logs. Its sort of complicated but basically and briefly; The op first test pic is from his actual ISP, it shows 'Southfield MI < 50mi' which tells me the speedtest server cluster used for the speed test. I used that with some other detailed info I had access to due to work. It just so happens our company has been running some tests for the past several days on speedtest.net for Ookla who had a request from Comcast executive management for some specific testing in (what I was told) preparation for the Net Neutrality repeal. When I saw the first pic he posted (the one using his actual ISP - Xfinity = Comcast and the time/date in the pic) I already knew network congestion management was probably not a factor as the Comcast executive management liaison was working with us, his 'speed' test just happens to fall in that period of time when network congestion management was not a factor. I was able to match the time/date stamp and test results in his pic with those results (as shown the him in his pic) logged during some testing at speedtest.net and that logging also logged his real ISP IP for that period of testing and the time/date shown the user (in his pic, which was also logged during the test exactly as that shown the user). His was the only test from the Comcast ISP with those speedtest results at that speedtest server cluster at that specific GMT time/date (as shown in his pic, which is also logged exactly as shown the user - 11/30/2017 4:48 GMT) during the period the Comcast network congestion management was not a factor so it was easy to pick out from the testing logs and his logged (during testing) ISP IP would allow me to "infer" his timezone also.

With the info that was available to me, basically, Its the time/date stamps and the "Southfield MI" shown in his posted pic that would ultimately let me "infer" his timezone. Its the testing logged ISP IP that would lead me to confirm the "inference", and its the specifics of the speedtest results logged during testing as its shown to the user (see his pic, the 11/30/2017 4:48 GMT and the Ping = 23 ms and the Download 90.59 Mbps and the Upload 12.15 Mbps and the ISP Xfinity) during a specific time frame (network congestion management was not a factor period) that would let me know this speedtest.net 'speed test' was specific to one person only which is the person that posted the first post in this thread.

MrRandom

My speed is the same as it was yesterday so the suggestion from cse to update Eddie and use the UDP, Port 41185, Ip 1 protocol seems to have fixed my problem!!

A big THANK YOU to cse!!

The only issue I'm having now is the latency and scores not showing in Eddie but that's a different issue and there are already threads about it so it seem to be a knows issue/bug in Eddie.

Thanks again for all the help!!

zhang888

"Out of curiosity, how did you infer the time zone of the customer from those log?"

Did not use "those" logs. Its sort of complicated but basically and briefly; The op first test pic is from his actual ISP, it shows 'Southfield MI < 50mi' which tells me the speedtest server cluster used for the speed test. I used that with some other detailed info I had access to due to work. It just so happens our company has been running some tests for the past several days on speedtest.net for Ookla who had a request from Comcast executive management for some specific testing in (what I was told) preparation for the Net Neutrality repeal. When I saw the first pic he posted (the one using his actual ISP - Xfinity = Comcast and the time/date in the pic) I already knew network congestion management was probably not a factor as the Comcast executive management liaison was working with us, his 'speed' test just happens to fall in that period of time when network congestion management was not a factor. I was able to match the time/date stamp and test results in his pic with those results (as shown the him in his pic) logged during some testing at speedtest.net and that logging also logged his real ISP IP for that period of testing and the time/date shown the user (in his pic, which was also logged during the test exactly as that shown the user). His was the only test from the Comcast ISP with those speedtest results at that speedtest server cluster at that specific GMT time/date (as shown in his pic, which is also logged exactly as shown the user - 11/30/2017 4:48 GMT) during the period the Comcast network congestion management was not a factor so it was easy to pick out from the testing logs and his logged (during testing) ISP IP would allow me to "infer" his timezone also.

With the info that was available to me, basically, Its the time/date stamps and the "Southfield MI" shown in his posted pic that would ultimately let me "infer" his timezone. Its the testing logged ISP IP that would lead me to  confirm the "inference", and its the specifics of the speedtest results logged during testing as its shown to the user (see his pic, the 11/30/2017 4:48 GMT and the Ping = 23 ms and the Download 90.59 Mbps and the Upload 12.15 Mbps and the ISP Xfinity) during a specific time frame (network congestion management was not a factor period)  that would let me know this speedtest.net 'speed test' was specific to one person only which is the person that posted the first post in this thread.

That's one hell of an ingestive work you did. I only read between the lines, but that's a great reading.

Congrats Sir @larky, you are now an online digital forensics authority for me.

You could have a very nice career with the 3 letter agencies, in case you are not one of them. Wow.

My speed starts normal and slows within 24 hours, it seems like I'm being throttled.

Recommended Posts

Share this post

Link to post

NOT AN AIRVPN TEAM MEMBER. USE TICKETS FOR PROFESSIONAL SUPPORT.

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Join the conversation