nanobot

This particular plan is $40 USD / mo. Add my TV and such, $170 / mo...cable is expensive ?

When I worked for one of the Tier-1 ISP's (think backbone's backbone) we set speeds by literally establishing a link timing variance. Basically, 6Mbps means we can set the clock-rate on the link to 6Mhz assuming 1 bit per cycle. If we had a technology (like DOCSIS) which could transmit N signals per second, we set the clock rate to desired speed / symbol count. Very basic, very easy to test, guarantees both sides understand what to do. I don't know if that's what CenturyLink is doing, but it's highly likely.

Are you connecting directly to your modem / router (whatever they call these silly boxes these days)? If not, are you connecting to a different switch? How long do you wait when you plug in? If it's less than 30 seconds, give it a good minute or two after plugging in to see if the situation changes (whatever the device is, it's entirely possible it's running Spanning Tree which typically takes 30 seconds to validate that you didn't just create a switch loop in your network). If you're waiting longer than that, the suggestion by @CA3LE is the next place I'd look. After that, perhaps test the cable and device port you are using (I see cables go bad every day).

If you're 2.5 miles from the "home office" (typically an MDF/IDF - main / intermediary data facility), you are outside the "sweet-zone" of ADSL. Typically, (A)DSL sees maximum throughput at 2 miles or less from a MDF/IDF. Basically, the distance between your demarcation point (modem) and your ISP's closet. You're only half-a-mile outside the sweet-zone, so I would still expect you to see reasonable speeds. That said, you might never see a stable 6Mbps, due to ADSL typically using older, buried phone / Cat3 lines. (Unless CenturyLink ran shielded coax/twinax copper or fiber, which I highly, highly doubt.) The burst you see with TMN is likely because the lines are cool, so there's no electromagnetic field around them. Because ADSL is typically Cat3, it's often minimally (if at all) twisted, unshielded, and poor-cabling, so it's easy for the cabling to build an electromagnetic field that interferes with signal transmission. This field won't exist at an idle, it will only exist when data is being transmitted. Once the field has built up (often as quick as 50-2500ns) it starts creating cross-talk and signaling interference, slowing the throughput you can achieve. (Basically, error-rates go up, and as a result more of your bandwidth is spent on handling those errors.) Unfortunately, without replacing the cabling, your speeds probably can't be improved much. All that said, does CenturyLink offer 5Mbps? If so, I would downgrade to that and run some more testing. If their signaling is wonky, you'll see a similar drop (I would expect either 1Mbps or 833kbps drop when you switch if they have a signaling calculation incorrect). If you don't see a drop, save yourself the money and keep the 5Mbps connection. If you see a drop, document it (now, the 5 vs. 6, and then, the x vs. 5). If you still have a drop, call CenturyLink and explain the situation. I have no idea how well they'll assist you, but they should be able to make other accommodations (provide 6Mbps but bill at 5Mbps, for example).

This is Wi-Fi over 802.11ac (MIMO 1300) -- capped out my 100Mbps internet connection. Windows reports it is allegedly running at 520Mbps, I'll have to prove that one of these days.

I only noticed it when the "T" went away, I thought "wtf? Did they remove my pin?" Nah, now it actually looks decent. Also a dark theme, so we got that going for us.

@CA3LE It only took Apple well over a decade, but Safari finally has Favicon support with the new macOS Mojave / Safari 12 update... Thanks, nanobot

https://www.cnbc.com/2017/09/07/credit-reporting-firm-equifax-says-cybersecurity-incident-could-potentially-affect-143-million-us-consumers.html If anyone wondered how the U.S. is doing right now, that should sum it up. Thanks, EBrown

I wonder if it could potentially be a performance issue? A basic network test in Chrome shows a lot of traffic loading past the 0.5s - 1.0s mark, Google puts a weight on performance as well. I have noticed the past few days that it has feel somewhat laggy here - on my phone it takes 10-15s to do a full refresh over LTE or WIFI. I also know the canonical tag issue mentioned by @Sean can have a negative effect if it's not properly set - Google may be indexing all the different variants, but the main page is not shown as it sees it as a "duplicate" of the uk.testmy.net page. Also, the EPOCH time for that expires is `375007920`. I also wonder if there aren't bigger issues - my search results (attached) for even `testmy.net` only have TMN as the top 6 results, which makes me think Google doesn't have a bigger problem with something. Thanks, EBrown

Have you looked at the Google Search Console? https://www.google.com/webmasters/tools/ It usually has good information as to why pages aren't indexed, or are prioritized lower than others. Thanks, EBrown

I believe @CA3LE mentioned something about this years ago, and for some browsers the culprit is poor hard-drive performance. Some browsers (especially when downloading large files) will attempt to save them to disk (especially if they don't know how you plan to use the result). This is usually a mostly unbuffered operation, meaning that the browser writes to disk as it downloads the data. Firefox is very likely streaming to RAM and then dumping it when complete. I would recommend looking into disk IOPS during testing, to determine if this is the case. Thanks, EBrown

I would not recommend doing general PC cleaning with an air compressor for three reasons: 1. Air (especially dry) traveling at high speeds and pressures creates static electricity, which can short and damage or destroy components. 2. Forcing air into a case with that pressure and speed can embed particulate into undesirable locations. 3. It is impossible to control the debris leaving the PC in that manner, and dust particulate may create a hazard to persons nearby. Instead, what I would recommend is two stage: 1. Remove all fans (including CPU heatsink and fan) from the computer, blow each fan out with compressed air individually. Make sure to blow air into the clean side of the fan/heatsink being cleaned (to force air out the same path it came in, which is usually where the dust cakes up). 2. With the fans removed, remove the CPU itself and RAM sticks, then ground the PC and a vaccum and use a small precision attachment on a vacuum cleaner to remove the remaining dust from the PC case. Make sure not to directly attack / suck against the motherboard itself (or hard drives, PSU, etc.), and do this in a room with about 40-60% relative humidity. (The humidity will help reduce static discharge in the air and help prevent ESD from damaging components in the PC.) Been cleaning PC's this way for years, and currently zero failure incidents as a result of cleaning. (Knock on wood.) Thanks, EBrown

Regarding the IP thing: @CA3LE if I recall correctly, the SQUID proxy they mention utilizes the `X-Forwarded-For` header, are you perhaps checking that as well? I know I had a similar issue with an Enterprise software application that was logging IP addresses, so I began logging the TCP/IP address and the X-Forwarded-For, as I was getting bizarre results similarly to what you are getting here. I know, for a fact, that the 224.0.0.0/4 address space is Class-D (multicast) so no user should actually have that address, and 240.0.0.0/4 should be Class-E, and that's usually experimental / R&D. Arin is being slow so while I'm looking into these additional details: @C0RR0SIVE: The 250.x.x.x address is part of the experimental space, AFAIK (unless any new RFC's are out) it's used by R&D and for experimental use only. So Arin finally loaded, and I'll give you guys the public URL: https://whois.arin.net/rest/net/NET-240-0-0-0-0/ As I thought, this is still in the "special use" range, which should be mostly non-routed (though I don't think there are any bars against routing these addresses, it's just not common). Thanks, EBrown

So I started nmap up, ran some scans (I'm sure @CA3LE won't mind me running some penetration tests against his server) on the SSL ports, and I couldn't find RC4 on the list of ciphers, at all, but then I did on an SMTPS (465) port, but you shouldn't be affected by that. So I got curious, and researched further, and you said it happens about every 10th website, so I have a few follow up questions: 1. Are you using Wireless? a. If so, are you using WEP? Apparently RC4 was used in the WEP security standard (which has been an insecurity standard for years now). 2. Are you certain there is no MITM attack against you? For those interested, here's the result of my nmap scan: Elliotts-iMac:~ elliottbrown$ nmap --script ssl-cert,ssl-enum-ciphers -p 443,465,993,995 www.testmy.net Starting Nmap 7.50 ( https://nmap.org ) at 2017-07-20 18:29 EDT Nmap scan report for www.testmy.net (64.111.22.10) Host is up (0.088s latency). rDNS record for 64.111.22.10: testmy.net PORT STATE SERVICE 443/tcp open https | ssl-cert: Subject: commonName=testmy.net | Subject Alternative Name: DNS:testmy.net | Issuer: commonName=Let's Encrypt Authority X3/organizationName=Let's Encrypt/countryName=US | Public Key type: rsa | Public Key bits: 2048 | Signature Algorithm: sha256WithRSAEncryption | Not valid before: 2017-07-06T06:00:00 | Not valid after: 2017-10-04T06:00:00 | MD5: 415f 2e2b ee78 0642 6813 4e47 743b 9831 |_SHA-1: ecac a111 d818 d982 1039 acea 2fe4 9b6c c975 ca43 | ssl-enum-ciphers: | TLSv1.0: | ciphers: | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: server | TLSv1.1: | ciphers: | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: server | TLSv1.2: | ciphers: | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: server |_ least strength: A 465/tcp open smtps | ssl-cert: Subject: commonName=Plesk/organizationName=Odin/stateOrProvinceName=Washington/countryName=US | Issuer: commonName=Plesk/organizationName=Odin/stateOrProvinceName=Washington/countryName=US | Public Key type: rsa | Public Key bits: 2048 | Signature Algorithm: sha256WithRSAEncryption | Not valid before: 2016-05-03T21:11:36 | Not valid after: 2017-05-03T21:11:36 | MD5: a6bd 9cdc 510e 115e 98b5 bca2 ff64 1af8 |_SHA-1: 47a4 68dd ce19 fa99 e4d2 b60e 94a5 0599 217d c1f9 | ssl-enum-ciphers: | SSLv3: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D | TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 1024) - A | TLS_DH_anon_WITH_3DES_EDE_CBC_SHA - F | TLS_DH_anon_WITH_AES_128_CBC_SHA - F | TLS_DH_anon_WITH_AES_256_CBC_SHA - F | TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA - F | TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA - F | TLS_DH_anon_WITH_RC4_128_MD5 - F | TLS_DH_anon_WITH_SEED_CBC_SHA - F | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_RC4_128_SHA (secp256r1) - C | TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA - F | TLS_ECDH_anon_WITH_AES_128_CBC_SHA - F | TLS_ECDH_anon_WITH_AES_256_CBC_SHA - F | TLS_ECDH_anon_WITH_RC4_128_SHA - F | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_IDEA_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C | TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C | TLS_RSA_WITH_SEED_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: client | warnings: | 64-bit block cipher 3DES vulnerable to SWEET32 attack | 64-bit block cipher IDEA vulnerable to SWEET32 attack | Broken cipher RC4 is deprecated by RFC 7465 | CBC-mode cipher in SSLv3 (CVE-2014-3566) | Ciphersuite uses MD5 for message integrity | Key exchange (dh 1024) of lower strength than certificate key | TLSv1.0: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D | TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 1024) - A | TLS_DH_anon_WITH_3DES_EDE_CBC_SHA - F | TLS_DH_anon_WITH_AES_128_CBC_SHA - F | TLS_DH_anon_WITH_AES_256_CBC_SHA - F | TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA - F | TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA - F | TLS_DH_anon_WITH_RC4_128_MD5 - F | TLS_DH_anon_WITH_SEED_CBC_SHA - F | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_RC4_128_SHA (secp256r1) - C | TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA - F | TLS_ECDH_anon_WITH_AES_128_CBC_SHA - F | TLS_ECDH_anon_WITH_AES_256_CBC_SHA - F | TLS_ECDH_anon_WITH_RC4_128_SHA - F | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_IDEA_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C | TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C | TLS_RSA_WITH_SEED_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: client | warnings: | 64-bit block cipher 3DES vulnerable to SWEET32 attack | 64-bit block cipher IDEA vulnerable to SWEET32 attack | Broken cipher RC4 is deprecated by RFC 7465 | Ciphersuite uses MD5 for message integrity | Key exchange (dh 1024) of lower strength than certificate key | TLSv1.1: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D | TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 1024) - A | TLS_DH_anon_WITH_3DES_EDE_CBC_SHA - F | TLS_DH_anon_WITH_AES_128_CBC_SHA - F | TLS_DH_anon_WITH_AES_256_CBC_SHA - F | TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA - F | TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA - F | TLS_DH_anon_WITH_RC4_128_MD5 - F | TLS_DH_anon_WITH_SEED_CBC_SHA - F | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_RC4_128_SHA (secp256r1) - C | TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA - F | TLS_ECDH_anon_WITH_AES_128_CBC_SHA - F | TLS_ECDH_anon_WITH_AES_256_CBC_SHA - F | TLS_ECDH_anon_WITH_RC4_128_SHA - F | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_IDEA_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C | TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C | TLS_RSA_WITH_SEED_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: client | warnings: | 64-bit block cipher 3DES vulnerable to SWEET32 attack | 64-bit block cipher IDEA vulnerable to SWEET32 attack | Broken cipher RC4 is deprecated by RFC 7465 | Ciphersuite uses MD5 for message integrity | Key exchange (dh 1024) of lower strength than certificate key | TLSv1.2: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D | TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 1024) - A | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 1024) - A | TLS_DH_anon_WITH_3DES_EDE_CBC_SHA - F | TLS_DH_anon_WITH_AES_128_CBC_SHA - F | TLS_DH_anon_WITH_AES_128_CBC_SHA256 - F | TLS_DH_anon_WITH_AES_128_GCM_SHA256 - F | TLS_DH_anon_WITH_AES_256_CBC_SHA - F | TLS_DH_anon_WITH_AES_256_CBC_SHA256 - F | TLS_DH_anon_WITH_AES_256_GCM_SHA384 - F | TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA - F | TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA - F | TLS_DH_anon_WITH_RC4_128_MD5 - F | TLS_DH_anon_WITH_SEED_CBC_SHA - F | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A | TLS_ECDHE_RSA_WITH_RC4_128_SHA (secp256r1) - C | TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA - F | TLS_ECDH_anon_WITH_AES_128_CBC_SHA - F | TLS_ECDH_anon_WITH_AES_256_CBC_SHA - F | TLS_ECDH_anon_WITH_RC4_128_SHA - F | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_IDEA_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C | TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C | TLS_RSA_WITH_SEED_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: client | warnings: | 64-bit block cipher 3DES vulnerable to SWEET32 attack | 64-bit block cipher IDEA vulnerable to SWEET32 attack | Broken cipher RC4 is deprecated by RFC 7465 | Ciphersuite uses MD5 for message integrity | Key exchange (dh 1024) of lower strength than certificate key |_ least strength: F 993/tcp open imaps | ssl-cert: Subject: commonName=Plesk/organizationName=Odin/stateOrProvinceName=Washington/countryName=US | Issuer: commonName=Plesk/organizationName=Odin/stateOrProvinceName=Washington/countryName=US | Public Key type: rsa | Public Key bits: 2048 | Signature Algorithm: sha256WithRSAEncryption | Not valid before: 2016-05-03T21:11:36 | Not valid after: 2017-05-03T21:11:36 | MD5: a6bd 9cdc 510e 115e 98b5 bca2 ff64 1af8 |_SHA-1: 47a4 68dd ce19 fa99 e4d2 b60e 94a5 0599 217d c1f9 | ssl-enum-ciphers: | TLSv1.0: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D | TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 1024) - A | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: client | warnings: | 64-bit block cipher 3DES vulnerable to SWEET32 attack | Key exchange (dh 1024) of lower strength than certificate key | TLSv1.1: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: client | warnings: | 64-bit block cipher 3DES vulnerable to SWEET32 attack | Key exchange (dh 1024) of lower strength than certificate key | TLSv1.2: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D | TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 1024) - A | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 1024) - A | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: client | warnings: | 64-bit block cipher 3DES vulnerable to SWEET32 attack | Key exchange (dh 1024) of lower strength than certificate key |_ least strength: D 995/tcp open pop3s | ssl-cert: Subject: commonName=Plesk/organizationName=Odin/stateOrProvinceName=Washington/countryName=US | Issuer: commonName=Plesk/organizationName=Odin/stateOrProvinceName=Washington/countryName=US | Public Key type: rsa | Public Key bits: 2048 | Signature Algorithm: sha256WithRSAEncryption | Not valid before: 2016-05-03T21:11:36 | Not valid after: 2017-05-03T21:11:36 | MD5: a6bd 9cdc 510e 115e 98b5 bca2 ff64 1af8 |_SHA-1: 47a4 68dd ce19 fa99 e4d2 b60e 94a5 0599 217d c1f9 | ssl-enum-ciphers: | TLSv1.0: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D | TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 1024) - A | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: client | warnings: | 64-bit block cipher 3DES vulnerable to SWEET32 attack | Key exchange (dh 1024) of lower strength than certificate key | TLSv1.1: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D | TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 1024) - A | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: client | warnings: | 64-bit block cipher 3DES vulnerable to SWEET32 attack | Key exchange (dh 1024) of lower strength than certificate key | TLSv1.2: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D | TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 1024) - A | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 1024) - A | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 1024) - A | TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 1024) - A | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: client | warnings: | 64-bit block cipher 3DES vulnerable to SWEET32 attack | Key exchange (dh 1024) of lower strength than certificate key |_ least strength: D Nmap done: 1 IP address (1 host up) scanned in 27.86 seconds Elliotts-iMac:~ elliottbrown$ The letter after the cipher is a letter from A-F, indicating grade of the cipher (A being best, F being worst), you'll notice there are a few RC4 ciphers under the 465, 993 and 995 ports (graded F appropriately), but all of the TLS ciphers are grade A. The lowest cipher strength (according to nmap) on https://www.testmy.net/ is a grade A, so Chrome should definitely not be flagging this site. (In fact, based on this information, testmy.net would refuse an RC4 cipher connection, period.) You definitely have a different issue going on, and I'm curious as to what that is. Thanks, EBrown

Hah, forgot to post this here. Yeah, they asked me about it on Twitter a week or so ago. It's an interesting topic, we're discussing things that should never have to be worried about, no one should fear that their ISP can censor what they can see based on the ISP's own political motives. (Hell, just look at the Comcast v. Netflix issue from a couple years ago: Netflix traffic was throttled to unbelievable slow speeds as a result of Comcast wanting to extort them for money.) Personally, I am anti-government regulation, but in this case it's a necessity. One of the arguments I have recently heard in favor of revocation of the net–neutrality law was: This is a false premise, if the ISP's customers want traffic from that source, the ISP should not be throttling it in either direction. If your customers want to watch Netflix all day, you don't get to make additional profit off of that. The customer already pays for a broadband connection, it is the ISP's job to deliver that broadband service in an unbiased manner. Thanks, EBrown

Using Kbps / kbps is misleading, as we're *actually* referring to KiBps. (One KiB = one kibibyte, which is 1024 bytes, one KB = one kilobyte, which is 1000 bytes.) The definitions of the prefixes are pretty lame, but the SI version is the following: Multiplier Abbr Prefix (Example) 1 NONE (bytes) 1000 k kilo (kilobytes) 1000^2 M mega (megabytes) 1000^3 G giga (gigabytes) 1000^4 T tera (terabytes) 1000^5 P peta (petabytes) 1000^6 E exa (exabytes) 1000^7 Z zetta (zettabytes) 1000^8 Y yotta (yottabytes) On the other hand, the version we typically refer to are the IEC ones, with JEDEC (SI) prefixes. Multiplier Abbr Prefix (Example) 1 NONE (bytes) 1024 Ki kibi (kibibytes) 1024^2 Mi mebi (mebibytes) 1024^3 Gi gibi (gibibytes) 1024^4 Ti tebi (tebibytes) 1024^5 Pi pebi (pebibytes) 1024^6 Ei exbi (exbibytes) 1024^7 Zi zebi (zebibytes) 1024^8 Yi yobi (yobibytes) The error between them can be calculated as 0.9765625^N, which can be multiplied by 100 for the percent, where N is the exponential power (kB/KiB is N = 1, MB/MiB is N = 2, etc.). (I.e. 1kB is actually 97.65625% the size of 1KiB, 1MB is 95.367432% of 1MiB, etc.) When doing these speed tests, I assume CA3LE measures the result as bytes per second divided to the smallest whole measurement, if he's dividing by 1000 then the SI/JEDEC prefix is appropriate, if it's 1024 then the IEC is most accurate, but in today's society the majority of end-users don't actually know the difference. If you want the actual IEC definitions, IEC 60027-2 (parts of which are succeeded by ISO/IEC 80000) has the exact specifications. You can find some information on these prefixes in NIST and Wikipedia, which both reference the IEC 60027-2 standard: Definitions of the SI units: The binary prefixes - NIST Binary prefix - Wikipedia IEC 60027 - Wikipedia When converting to bits, simply multiply whatever number by 8. The byte/bit distinction is made by a capital 'B' for 'bytes', and a small 'b' for 'bits', though as the OP pointed out the small 'b' for 'bits' is generally frowned upon in the lab view, I suggest that most of our users won't really be worried about that particular distinction, but it is still a technical inaccuracy. (So 1KiB = 8Kibit = 8.192kbit = 1.024kB = 1024B.) Thus, when writing speeds they *should* be kbit/s if the measurement is actual bits. If it's bytes, then kB/s or KiB/s depending on the division factor. If anyone wants I can demonstrate several conversion proofs that go into great detail (from the old university Calc 1-3 days) to describe exactly what happens and how, but I feel that's a bit overkill. Thanks, EBrown

It's funny because the router we use here has a "Self-healing" feature which causes it to reboot at a specific time on specific days, on it's own. Edit: just read and saw this: Right, all of them. Thanks, EBrown

I need to get a pfSense router setup here, so that I can replace this damn piece of garbage router that my dad bought. This thing is literally the worst router ever. If it loses (or thinks it lost) internet connection, it will redirect all HTTP requests to the router configuration page. Please tell me pfSense doesn't do that. Thanks, EBrown

So what exactly is the issue? If you're using the entire third byte as your subnet block, your new mask would be 255.255.255.0, or /24. Which means the first subnet is 182.168.0.0/24, then 182.168.1.0/24, 182.168.2.0/24, etc. They're probably asking you to use the entire third block so that it makes an easy beginner question. Otherwise you would be able to get away with a 255.255.255.248 (/29) instead. Which would give you exactly 5 host addresses, 1 gateway address, 1 network address, and 1 broadcast address. The problem with this is that it's not as easy of a beginner question. (Your first subnet is 182.168.0.0 to 182.168.0.7, then 182.168.0.8 to 182.168.0.15, etc.) Thanks, EBrown

With as involved as Canonical was for this whole issue, I would be willing to bet that it will be a fairly high quality implementation. Microsoft and Canonical are actually adding an entire Linux sub kernel into Windows. This is a really big achievement, and should go a long way to increasing cross-platformability (especially for someone like me). I'm actually really excited to see how everything comes together and integrates, it should be a really cool project. Thanks, EBrown

That may make an interesting idea to make Testmy.net better. Thanks, EBrown

My Windows 10 install has been really buggy lately. It needs a reboot almost every other day. Thanks, EBrown

New and used at Newegg are $270 and $170 respectively, so long as it's not horribly beaten or used that's a fine price for a fine device. Thanks, EBrown

This site has no such app, you can use the browser on any smart-mobile for it though. Chrome, Safari, Firefox, Opera. All of them work. Thanks, EBrown

Personally, I think the multi-stream test is very representative of server speeds as well. Typically, if a server has high traffic, the likelihood of all the traffic coming from one location is minimal. This also helps create a more real estimate of the performance of a server. Can it really handle multiple streams at once? About the only thing I can think of that would make it better is if it would test each stream separately (obviously an option) and then report the speeds of each stream. Thanks, EBrown