What's wrong with my Internet?
January 14, 2010 3:23 PM Subscribe
ICSI Netalyzr is a java applet that performs an impressive collection of tests on your Internet connection, and reports the results back to you (and to the ICSI) in an easily readable format.
Finally out of beta test, Netalyzr is useful for debugging weird connectivity issues and finding out what things your ISP might be doing to your connection intentionally that you don't know about.
It reports the results back to the International Computer Science Institute (a non-profit research institute associated with the University of California at Berkeley) to help them study the health of the network edge.
If you want to see what it does before you run it, they have an example report to look at.
Produced with financial support from the National Science Foundation.
Finally out of beta test, Netalyzr is useful for debugging weird connectivity issues and finding out what things your ISP might be doing to your connection intentionally that you don't know about.
It reports the results back to the International Computer Science Institute (a non-profit research institute associated with the University of California at Berkeley) to help them study the health of the network edge.
If you want to see what it does before you run it, they have an example report to look at.
Produced with financial support from the National Science Foundation.
I'm one of the authors of Netalyzr.
Many apologies for crashing Firefox, that is clearly a bug with the browser as we have no problem running on a huge variety of browsers.
However, version 3.0.8 is very out of date, and you should update immediately. There are many known and exploited vulnerabilities for that old a browser.
I will answer any questions people have about the service. And thanks to all those who check out Netalyzr.
posted by nweaver at 3:35 PM on January 14, 2010 [12 favorites]
Many apologies for crashing Firefox, that is clearly a bug with the browser as we have no problem running on a huge variety of browsers.
However, version 3.0.8 is very out of date, and you should update immediately. There are many known and exploited vulnerabilities for that old a browser.
I will answer any questions people have about the service. And thanks to all those who check out Netalyzr.
posted by nweaver at 3:35 PM on January 14, 2010 [12 favorites]
Nice little investigation tool! Took awhile to run, I thought it'd crashed. But then the report came through. Good, very detailed report that reflects what I know about my network. Only mystifying thing was it claims outgoing IMAP and POP is getting an empty response. I don't think anything on my network would be doing that. OTOH, I only use Gmail, so who knows?
PS: Welcome to MeFi, Nicholas!
posted by Nelson at 3:42 PM on January 14, 2010
PS: Welcome to MeFi, Nicholas!
posted by Nelson at 3:42 PM on January 14, 2010
I opened it in Chrome and I did not see the link that I think is supposed to be there to make it run.
Update-- worked in Firefox. Cool!
posted by cell divide at 3:44 PM on January 14, 2010
Update-- worked in Firefox. Cool!
posted by cell divide at 3:44 PM on January 14, 2010
Getting an empty response usually means some network process that looks for traffic didn't like what it saw. Our server is deliberately designed to cause such filters to object, because they don't actually follow any defined protocol, instead, its just the IP and port used to contact our server. So anything that goes "oh wait, that isn't to the protocol" will kill the connection and we see an empty response.
If its just POP and IMAP that are unexpectedly filtered, its probably your antivirus software, as some AV systems interprets mail messages as they are received through POP or IMAP by proxying all network traffic for these ports.
posted by nweaver at 3:47 PM on January 14, 2010
If its just POP and IMAP that are unexpectedly filtered, its probably your antivirus software, as some AV systems interprets mail messages as they are received through POP or IMAP by proxying all network traffic for these ports.
posted by nweaver at 3:47 PM on January 14, 2010
the link doesn't appear in chrome in osx but does in firefox...i'm being patient while it's running.
posted by ennui.bz at 3:55 PM on January 14, 2010
posted by ennui.bz at 3:55 PM on January 14, 2010
I'm curious what kinds of central analysis are planned for this data. Not curious in a suspicious way, I mean can you talk about what sort of stats or reports you have in mind to produce?
posted by FishBike at 3:57 PM on January 14, 2010
posted by FishBike at 3:57 PM on January 14, 2010
Chrome under OS-X doesn't support Java, unfortunately, and Netalyzr needs to do things that JavaScript can't do, like perform name lookups and communicate directly with our server.
posted by nweaver at 3:58 PM on January 14, 2010
posted by nweaver at 3:58 PM on January 14, 2010
It ran fine here, but Firefox 3.5 crashed shortly after finishing the tests.
The complaints I saw were all expected behavior from how I have my firewall configured, except for the errors on an invisible HTTP proxy. Is there any way to see if other users in my network are having the same problem, so I can figure out whether it's some kind of local issue? Invisible web proxies worry me a little.
posted by Malor at 4:00 PM on January 14, 2010
The complaints I saw were all expected behavior from how I have my firewall configured, except for the errors on an invisible HTTP proxy. Is there any way to see if other users in my network are having the same problem, so I can figure out whether it's some kind of local issue? Invisible web proxies worry me a little.
posted by Malor at 4:00 PM on January 14, 2010
Malor: Often the headers inserted by the HTTP proxy will tell you what it is, whether it is local or global. You can mail the Netalyzr help list (netalyzr-help@icsi.berkeley.edu ) with the session ID/link/results page and we can look at it in more detail.
posted by nweaver at 4:07 PM on January 14, 2010
posted by nweaver at 4:07 PM on January 14, 2010
This was surprisingly fascinating. Fun tool. The one "warning" it threw up it analyzed exactly right (unfortunately it's an annoying "feature" that Cox has which I can't do anything about since the house I live in has shared internet).
posted by Kattullus at 4:08 PM on January 14, 2010
posted by Kattullus at 4:08 PM on January 14, 2010
Malor: EG, on corporate networks, some of the censorware products are actually in-path web proxies. Likewise, the CISCO nat used here at ICSI actually acts as an HTTP proxy, changing headers and adding headers (eg, a -----: --------- header is added, as well as changing connections to "chunked")
posted by nweaver at 4:09 PM on January 14, 2010
posted by nweaver at 4:09 PM on January 14, 2010
Kattullus: If its the Cox DNS wildcarding, whoever pays for the network should be able to disable it, either by following the opt-out instructions or changing the DNS settings in the home router to a benign server.
posted by nweaver at 4:10 PM on January 14, 2010
posted by nweaver at 4:10 PM on January 14, 2010
Our goal is to create an overall picture of internet health: The list of things we want to analyze is very large, but this should give a feel of the sorts of things we are looking for (yes, this is just a start for us...):
EG, what problems affect a large number of users regardless of ISP (eg, due to NATs and other problems).
Are there specific ISP behaviors that are suspicious (eg, DNS wildcarding, port filtering, DNS Man-in-the-middle operations?). Has such behavior changed between last summer and today?
Another example is what we've already done for the DNS community: we've created an informal report into the IETF's DNS mailinglists on many problems DNSSEC (secure DNS) will face due to fragmentation and firewalls that don't handle EDNS or don't handle fragmented traffic, and used the results to suggest strategies DNS resolvers can use to cope with common network failures.
A third area is the striking prevelence of network overbuffering. This is a hardware flaw in the cable/DSL modems and other network equipment, and we hope to use Netalyzr's results as a guide to how vendors can better build their equipment.
Another example that we are looking forward to studying is MTU holes: Are there certain sizes of traffic that just don't work? Are there often network bottlenecks that don't respond correctly when packets are too big? These tests in particular are very new, which is why we're looking for publicity so we can get new data.
Finally we are really interested in hidden proxies. The hidden proxy tests have revealed proxies that network operators were unaware of!
posted by nweaver at 4:12 PM on January 14, 2010 [6 favorites]
Interesting stuff - showed me that my ISP is as nice as I thought they were (which is to say they aren't explicitly blocking anything. I have low expectations.) FTP, SMTP and POP all had some level of difficulty, but I've successfully used FTP over this connection and the other two are likely my antivirus, so no problems there.
What's a little more worrying is that presumably (and I'll admit I don't know a huge amount about this), any server that knows my IP (so that would be any site I connect to) could do this in reverse and find out all sorts of stuff about what traffic I accept. Anyone know whether that's the case, and whether it could be a problem?
posted by ZsigE at 4:17 PM on January 14, 2010
What's a little more worrying is that presumably (and I'll admit I don't know a huge amount about this), any server that knows my IP (so that would be any site I connect to) could do this in reverse and find out all sorts of stuff about what traffic I accept. Anyone know whether that's the case, and whether it could be a problem?
posted by ZsigE at 4:17 PM on January 14, 2010
Typo:
Also, there are various other network analysis tools at (Google-affiliated) M-Lab.
posted by Skorgu at 4:17 PM on January 14, 2010
DNS external proxy: OKThis is a great tool, I'm going to have to try it later when my connection isn't saturated.
Your host ignoress external DNS requests.
Also, there are various other network analysis tools at (Google-affiliated) M-Lab.
posted by Skorgu at 4:17 PM on January 14, 2010
ZsigE: Your IP address is revealed to every web server your visit. After all, how else is the server supposed to communicate with you?
But worse, there are tons of badguys which just check every IP address all the time for pretty much any vulnerability (a process known as "port scanning").
However, as long as you are behind a NAT or router, you really don't have to worry: most NATs just happily block any incoming requests, so having people know your IP address really doesn't tell them anything useful in that way.
posted by nweaver at 4:21 PM on January 14, 2010
But worse, there are tons of badguys which just check every IP address all the time for pretty much any vulnerability (a process known as "port scanning").
However, as long as you are behind a NAT or router, you really don't have to worry: most NATs just happily block any incoming requests, so having people know your IP address really doesn't tell them anything useful in that way.
posted by nweaver at 4:21 PM on January 14, 2010
Is there anything I can do about network overbuffering.
posted by diogenes at 4:21 PM on January 14, 2010 [3 favorites]
posted by diogenes at 4:21 PM on January 14, 2010 [3 favorites]
dogenes: Nothing really. Its a flaw in the cable modems and other devices. Basically, its a "be aware" situation:
Q: Netalyzr reports large buffers in my up/downlink. How can I fix that?
A: The first option is just to be aware of the issue. If you don't try to perform large file transfers or P2P applications while also websurfing, gaming, or using VoIP, you shouldn't notice a problem. Buffer sizing is only a problem if you try to perform both large transfers and interactive applications simultaneously.
The second is to pay for a higher bandwidth service, if it is important for you to be able to perform both large file transfers and interactive applications at the same time. The problem is due to the ratio between the buffer's capacity and the bandwidth of the connection, so if you pay for more bandwidth, the buffering problem is reduced.
Unfortunately the real solution, namely access devices which allow programmable buffer sizing or dynamically resize their buffer based on available bandwidth, is not generally available to the customer at this time.
posted by nweaver at 4:25 PM on January 14, 2010 [4 favorites]
Q: Netalyzr reports large buffers in my up/downlink. How can I fix that?
A: The first option is just to be aware of the issue. If you don't try to perform large file transfers or P2P applications while also websurfing, gaming, or using VoIP, you shouldn't notice a problem. Buffer sizing is only a problem if you try to perform both large transfers and interactive applications simultaneously.
The second is to pay for a higher bandwidth service, if it is important for you to be able to perform both large file transfers and interactive applications at the same time. The problem is due to the ratio between the buffer's capacity and the bandwidth of the connection, so if you pay for more bandwidth, the buffering problem is reduced.
Unfortunately the real solution, namely access devices which allow programmable buffer sizing or dynamically resize their buffer based on available bandwidth, is not generally available to the customer at this time.
posted by nweaver at 4:25 PM on January 14, 2010 [4 favorites]
My Time Warner Cable is blocking The Onion Router. Sinister.
posted by dunkadunc at 4:25 PM on January 14, 2010
posted by dunkadunc at 4:25 PM on January 14, 2010
Pretty cool analyser. Is there source code available?
posted by Blazecock Pileon at 4:26 PM on January 14, 2010
posted by Blazecock Pileon at 4:26 PM on January 14, 2010
dunkadunc: Thats odd. Can you please contact us at netalyzr-help@icsi.berkeley.edu to discuss this further and try to figure out what's going on? IT could be a "local" network problem (like AV software or your NAT)
posted by nweaver at 4:27 PM on January 14, 2010
posted by nweaver at 4:27 PM on January 14, 2010
Works on Chrome 4.0 on Windows. And it tells me that Comcast's DNS is sending many unresolvable host names to search.comcast.com instead of returning an error. Dicks.
posted by octothorpe at 4:28 PM on January 14, 2010 [3 favorites]
posted by octothorpe at 4:28 PM on January 14, 2010 [3 favorites]
Blazecok Pileon: Unfortunately not at this time. But since Netalyzr really isn't a standalone tool but a web service, sourcecode would be less useful anyway.
posted by nweaver at 4:28 PM on January 14, 2010
posted by nweaver at 4:28 PM on January 14, 2010
octothorpe: Fortunately, comcast actually has a usable opt-out unlike some other ISPs.
Type in sometihng random (eg, www.aoentuhaosentuhaonsetuhaosnetuh.com) into your web browser, the instructions should be in the upper right hand corner IIRC.
(As a comcast customer, this was one of the first things I did).
posted by nweaver at 4:30 PM on January 14, 2010
Type in sometihng random (eg, www.aoentuhaosentuhaonsetuhaosnetuh.com) into your web browser, the instructions should be in the upper right hand corner IIRC.
(As a comcast customer, this was one of the first things I did).
posted by nweaver at 4:30 PM on January 14, 2010
What an amazingly well thought tool.
My hat's off to you on this -- and I speak as a 20 year Sys/NetAdmin.
Well done. Bravo Zulu. Way to go, dude. Nice Jorb there subby.
posted by eriko at 4:35 PM on January 14, 2010 [1 favorite]
My hat's off to you on this -- and I speak as a 20 year Sys/NetAdmin.
Well done. Bravo Zulu. Way to go, dude. Nice Jorb there subby.
posted by eriko at 4:35 PM on January 14, 2010 [1 favorite]
nweaver: Kattullus: If its the Cox DNS wildcarding, whoever pays for the network should be able to disable it, either by following the opt-out instructions or changing the DNS settings in the home router to a benign server.
That is indeed it! Thanks for telling me there was an opt out. I have now opted out and no longer have to deal with that annoying page. I don't know if it's related but the uplink buffering is now considerably faster (from ~430 ms to 170 ms) but I have no idea if that's in any way related.
posted by Kattullus at 4:35 PM on January 14, 2010
That is indeed it! Thanks for telling me there was an opt out. I have now opted out and no longer have to deal with that annoying page. I don't know if it's related but the uplink buffering is now considerably faster (from ~430 ms to 170 ms) but I have no idea if that's in any way related.
posted by Kattullus at 4:35 PM on January 14, 2010
nweaver, it looks like I need to log in with a comcast email address to change those settings and I never setup an email address with them.
posted by octothorpe at 4:35 PM on January 14, 2010
posted by octothorpe at 4:35 PM on January 14, 2010
octothorpe: There's some way around it but I don't' remember what it is.
You can also manually set your DNS settings in your NAT to one of the comcast non-wildcarding servers: pick the appropriate ones from this list:
http://dns.comcast.net/dns-ip-addresses2.php
posted by nweaver at 4:38 PM on January 14, 2010
You can also manually set your DNS settings in your NAT to one of the comcast non-wildcarding servers: pick the appropriate ones from this list:
http://dns.comcast.net/dns-ip-addresses2.php
posted by nweaver at 4:38 PM on January 14, 2010
kattulus: The buffer settings weren't actualyl changed: that test tends to be noisy, sometimes its unable to fill the buffer completely.
posted by nweaver at 4:38 PM on January 14, 2010
posted by nweaver at 4:38 PM on January 14, 2010
This is pretty cool, but would most likely be much cooler if I knew what any of it meant, or what to do about it. Why would my DNS resolver return results even when no such server exists? And why would my 1100 msec of buffering? I am sadly clueless about this sort of thing.
posted by Aversion Therapy at 4:41 PM on January 14, 2010
posted by Aversion Therapy at 4:41 PM on January 14, 2010
>: Why would my DNS resolver return results even when no such server exists?
Basically, it means that your ISP is bypassing the real DNS servers (4.2.2.1) for their own, so when you mistype a URL it takes you to a "search" page which contains "sponsored" links.
posted by dunkadunc at 4:43 PM on January 14, 2010
Basically, it means that your ISP is bypassing the real DNS servers (4.2.2.1) for their own, so when you mistype a URL it takes you to a "search" page which contains "sponsored" links.
posted by dunkadunc at 4:43 PM on January 14, 2010
Click on each test name: it should open up an information page that should hopefully make that test clear. If it doesn't, feel free to ask me for a furtehr detailed explanation.
EG: http://netalyzr.icsi.berkeley.edu/info_dns_wildcarding.html
About this test: The DNS system is responsible for turning mnemonic names into Internet addresses. But what if the name does not exist, either because of a typo or other failure? In such case, the server is supposed to return a failure, which will tell the program that "this name currently does not exist".
Recently, however, several ISPs have started wildcarding these errors on their DNS servers by doing NXDOMAIN rewriting, thus instead of returning "no such name", they return the address of a server which suggests corrections as a way of generating profit for the ISP by serving advertisements.
Such behavior, although it attempts to be helpful, can cause other problems. For example, the web browser itself may have correction mechanisms which will be blocked by this. An example is where Firefox, if you type in a single word, will first attempt a DNS lookup, and, if it fails, perform a Google search. DNS NXDOMAIN rewriting will disrupt this functionality.
Similarly, web browsers are not the only application which performs DNS lookups, and which expect a failure when a name does not exist. This problem is exacerbated if the ISP also blocks access to third-party DNS resolvers.
What if this test reports a problem: Try typing a random address in your web browser, one composed of a large number of characters produced by just pounding on the keyboard. This will usually cause the ISP's advertisement page to appear, which should contain opt-out instructions to disable this feature. If there are no opt-out instructions, or if the opt-out instructions are unclear, we would suggest calling your ISP's customer service to complain about the lack of a clear and usable opt-out.
posted by nweaver at 4:44 PM on January 14, 2010 [2 favorites]
EG: http://netalyzr.icsi.berkeley.edu/info_dns_wildcarding.html
About this test: The DNS system is responsible for turning mnemonic names into Internet addresses. But what if the name does not exist, either because of a typo or other failure? In such case, the server is supposed to return a failure, which will tell the program that "this name currently does not exist".
Recently, however, several ISPs have started wildcarding these errors on their DNS servers by doing NXDOMAIN rewriting, thus instead of returning "no such name", they return the address of a server which suggests corrections as a way of generating profit for the ISP by serving advertisements.
Such behavior, although it attempts to be helpful, can cause other problems. For example, the web browser itself may have correction mechanisms which will be blocked by this. An example is where Firefox, if you type in a single word, will first attempt a DNS lookup, and, if it fails, perform a Google search. DNS NXDOMAIN rewriting will disrupt this functionality.
Similarly, web browsers are not the only application which performs DNS lookups, and which expect a failure when a name does not exist. This problem is exacerbated if the ISP also blocks access to third-party DNS resolvers.
What if this test reports a problem: Try typing a random address in your web browser, one composed of a large number of characters produced by just pounding on the keyboard. This will usually cause the ISP's advertisement page to appear, which should contain opt-out instructions to disable this feature. If there are no opt-out instructions, or if the opt-out instructions are unclear, we would suggest calling your ISP's customer service to complain about the lack of a clear and usable opt-out.
posted by nweaver at 4:44 PM on January 14, 2010 [2 favorites]
Oh dear! My computer's clock is seven seconds slow.
posted by Jumpin Jack Flash at 4:45 PM on January 14, 2010 [4 favorites]
posted by Jumpin Jack Flash at 4:45 PM on January 14, 2010 [4 favorites]
And they're doing that because they're the scum of the earth, I might add.
The buffering, as the dev mentioned upthread, is due to a flaw in network equipment and something you can't do much about.
posted by dunkadunc at 4:46 PM on January 14, 2010
The buffering, as the dev mentioned upthread, is due to a flaw in network equipment and something you can't do much about.
posted by dunkadunc at 4:46 PM on January 14, 2010
Ah, Time Warner/Road Runner, how I loathe thee.
posted by Aversion Therapy at 4:51 PM on January 14, 2010 [1 favorite]
posted by Aversion Therapy at 4:51 PM on January 14, 2010 [1 favorite]
JJFlash: Don't knock it. I've had problem with fileservers (generally, things like make that care about modification dates) when clocks were off by as little as 10 seconds....
Drove me batty until I figured it out. Which is why we check for it.
posted by nweaver at 4:52 PM on January 14, 2010 [2 favorites]
Drove me batty until I figured it out. Which is why we check for it.
posted by nweaver at 4:52 PM on January 14, 2010 [2 favorites]
nweaver: Well played, sir! Works perfectly on Safari 4.04/OS 10.6.2. It correctly discerned that my ISP was wildcarding to a telecom-sponsored ad site "search page."
posted by rdone at 4:55 PM on January 14, 2010
posted by rdone at 4:55 PM on January 14, 2010
Oh, and those with Digg or slashdot accounts, it would be a wonderful help to us if you could bump our story up! The more people who run Netalyzr, the better a picture we can construct of what works (and doesn't work) on the Internet.
thanks!
posted by nweaver at 4:58 PM on January 14, 2010
thanks!
posted by nweaver at 4:58 PM on January 14, 2010
Wow, Google DNS is fast. I didn't really care about my Time Warner provided DNS server, assuming it would be faster than Google, here are the results:
Pinging 24.28.193.9 with 32 bytes of data:
Reply from 24.28.193.9: bytes=32 time=62ms TTL=107
Reply from 24.28.193.9: bytes=32 time=61ms TTL=107
Reply from 24.28.193.9: bytes=32 time=61ms TTL=107
Reply from 24.28.193.9: bytes=32 time=69ms TTL=107
Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=38ms TTL=245
Reply from 8.8.8.8: bytes=32 time=39ms TTL=245
Reply from 8.8.8.8: bytes=32 time=33ms TTL=245
Reply from 8.8.8.8: bytes=32 time=39ms TTL=245
I ran it several times and Google's (8.8.8.8) DNS is consistently twice as fast. Looks like I will be switching.
posted by geoff. at 5:27 PM on January 14, 2010 [4 favorites]
Pinging 24.28.193.9 with 32 bytes of data:
Reply from 24.28.193.9: bytes=32 time=62ms TTL=107
Reply from 24.28.193.9: bytes=32 time=61ms TTL=107
Reply from 24.28.193.9: bytes=32 time=61ms TTL=107
Reply from 24.28.193.9: bytes=32 time=69ms TTL=107
Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=38ms TTL=245
Reply from 8.8.8.8: bytes=32 time=39ms TTL=245
Reply from 8.8.8.8: bytes=32 time=33ms TTL=245
Reply from 8.8.8.8: bytes=32 time=39ms TTL=245
I ran it several times and Google's (8.8.8.8) DNS is consistently twice as fast. Looks like I will be switching.
posted by geoff. at 5:27 PM on January 14, 2010 [4 favorites]
My upload buffering is 3.9 seconds. Do I win a prize? I'd like to win something for that, because it's a noticeable pain in the ass.
Verizon's doing the old redirect trick with me too. Unfixable though. Their opt-out page tells me that I need to change my settings in my operating system. I'm running Ubuntu, and they don't recognize the existence of Linux (I actually had to run Windows XP in Virtualbox just to set up the DSL modem). God I hate Verizon. I really wish I could get a non-evil ISP ---ArsTechnica occasionally runs stories on non-evil ISPs, albeit always in other countries.
posted by Humanzee at 5:28 PM on January 14, 2010
Verizon's doing the old redirect trick with me too. Unfixable though. Their opt-out page tells me that I need to change my settings in my operating system. I'm running Ubuntu, and they don't recognize the existence of Linux (I actually had to run Windows XP in Virtualbox just to set up the DSL modem). God I hate Verizon. I really wish I could get a non-evil ISP ---ArsTechnica occasionally runs stories on non-evil ISPs, albeit always in other countries.
posted by Humanzee at 5:28 PM on January 14, 2010
Well a slight hair below twice as fast, but considerably faster nonetheless.
posted by geoff. at 5:28 PM on January 14, 2010
posted by geoff. at 5:28 PM on January 14, 2010
But since Netalyzr really isn't a standalone tool but a web service, sourcecode would be less useful anyway.
What on earth does that mean? It is code running on my computer functioning as a tool that I'm using. Why would I find it non-useful/undesireable to view the source? It could also be a good educational resource on how to properly perform certain tests.
Another example: It'd be really neat to know how this Java applet killed my internet so hard I had to physically unplug the power to both the router AND the DSL modem to bring it back to life.
posted by DU at 5:31 PM on January 14, 2010
What on earth does that mean? It is code running on my computer functioning as a tool that I'm using. Why would I find it non-useful/undesireable to view the source? It could also be a good educational resource on how to properly perform certain tests.
Another example: It'd be really neat to know how this Java applet killed my internet so hard I had to physically unplug the power to both the router AND the DSL modem to bring it back to life.
posted by DU at 5:31 PM on January 14, 2010
comcast actually has a usable opt-out unlike some other ISPs.
I had no idea I could opt out. In time warner/road runner the opt out form is on the lower right, at the very bottom of the page - you will need to scroll down.
posted by shothotbot at 5:33 PM on January 14, 2010
I had no idea I could opt out. In time warner/road runner the opt out form is on the lower right, at the very bottom of the page - you will need to scroll down.
posted by shothotbot at 5:33 PM on January 14, 2010
So what does it mean if I have HTTP caching of strongly and weakly uncacheable data? Who is doing the cacheing and is there anything that should be done about it?
posted by JackFlash at 5:37 PM on January 14, 2010
posted by JackFlash at 5:37 PM on January 14, 2010
bypassing the real DNS servers (4.2.2.1)
That's not 'the real' DNS servers, that's a set of free DNS servers that Level3 has been running for many years. They've been making noises about trying to monetize them, so don't get too dependent. But they're great for testing.
DNS is a completely trivial protocol. A 386-20 could probably handle DNS for a normal household. I wish more routers included a full resolver.... typically they have just a 'slave' resolver that forwards local lookups to whatever your ISP provides.
Running a local DNS server detaches you from your ISP's DNS services, which insulates you from their vagaries, whether deliberate or inadvertent. It also makes you almost entirely immune to cache-poisoning attacks.... they have to be aimed specifically at YOU, not just your ISP. Local DNS means all you need to use the Internet is IP connectivity, with no additional configuration required.
It's kind of one of those tragedy-of-the-commons things... when everyone shares a DNS server, it cuts load on the root servers substantially. If everyone ran their own, their own networks would be more resilient and secure, but the root servers would be under a lot more load.
posted by Malor at 5:40 PM on January 14, 2010 [1 favorite]
That's not 'the real' DNS servers, that's a set of free DNS servers that Level3 has been running for many years. They've been making noises about trying to monetize them, so don't get too dependent. But they're great for testing.
DNS is a completely trivial protocol. A 386-20 could probably handle DNS for a normal household. I wish more routers included a full resolver.... typically they have just a 'slave' resolver that forwards local lookups to whatever your ISP provides.
Running a local DNS server detaches you from your ISP's DNS services, which insulates you from their vagaries, whether deliberate or inadvertent. It also makes you almost entirely immune to cache-poisoning attacks.... they have to be aimed specifically at YOU, not just your ISP. Local DNS means all you need to use the Internet is IP connectivity, with no additional configuration required.
It's kind of one of those tragedy-of-the-commons things... when everyone shares a DNS server, it cuts load on the root servers substantially. If everyone ran their own, their own networks would be more resilient and secure, but the root servers would be under a lot more load.
posted by Malor at 5:40 PM on January 14, 2010 [1 favorite]
DU: It'd be really neat to know how this Java applet killed my internet so hard I had to physically unplug the power to both the router AND the DSL modem to bring it back to life.
You probably have a crappy firmware in the router, one that chokes under any real load. What brand/model is it?
posted by Malor at 5:42 PM on January 14, 2010
You probably have a crappy firmware in the router, one that chokes under any real load. What brand/model is it?
posted by Malor at 5:42 PM on January 14, 2010
Humanzee: Nope, we've seen worse but not by much. It can only measure up to 5 seconds.
My suggestion would be to change the settings in your NAT/home-router, its a pain but that's the only opt-out they have!
DU: Netalyzr is not a standalone tool, a lot of the smarts are on the server side. It relies on a custom set of back-end servers we've written, including a custom web server, custom DNS server, and a bunch of others (much of Netalyzr's magic comes from traffic with a calculated disregard to application specifications), and has to be located at a "clean" place on the Internet with a lot of bandwidth. (for us, we use EC2).
You can't just run the servers anywhere, you have to host them well. In fact, we can't run the back-end servers here at ICSI, not because of the load (but that does matter) but simply because our network blocks stuff.
And it SHOULD NOT crash the router and DSL modem. PERIOD!
All but the last two tests (the bandwidth tests) are completely non-stressfull, and the last two tests just send UDP packets to our server as fast as possible for ten seconds, and then try to receive packets as fast as possible for ten seconds, with a max in both directions of ~20 Mbps.
The only traffic sent to the router itself (rather than passing through the network) is a couple of DNS queries, one from your computer and one from our server, to see if your router proxies DNS requests.
If any network equipment actually crashes due to this, the engineer who designed it should be fired: traffic load like that happens all the time. If you tried it one more time and it crashes again, something is seriously, SERIOUSLY wrong, and needs to be examined in much more detail (you can contact us through email at netalyzr-help@icsi.berkeley.edu )
And we haven't received any other complaints about Netalyzr crashing network hardware, so this is very peculiar.
posted by nweaver at 5:45 PM on January 14, 2010 [4 favorites]
My suggestion would be to change the settings in your NAT/home-router, its a pain but that's the only opt-out they have!
DU: Netalyzr is not a standalone tool, a lot of the smarts are on the server side. It relies on a custom set of back-end servers we've written, including a custom web server, custom DNS server, and a bunch of others (much of Netalyzr's magic comes from traffic with a calculated disregard to application specifications), and has to be located at a "clean" place on the Internet with a lot of bandwidth. (for us, we use EC2).
You can't just run the servers anywhere, you have to host them well. In fact, we can't run the back-end servers here at ICSI, not because of the load (but that does matter) but simply because our network blocks stuff.
And it SHOULD NOT crash the router and DSL modem. PERIOD!
All but the last two tests (the bandwidth tests) are completely non-stressfull, and the last two tests just send UDP packets to our server as fast as possible for ten seconds, and then try to receive packets as fast as possible for ten seconds, with a max in both directions of ~20 Mbps.
The only traffic sent to the router itself (rather than passing through the network) is a couple of DNS queries, one from your computer and one from our server, to see if your router proxies DNS requests.
If any network equipment actually crashes due to this, the engineer who designed it should be fired: traffic load like that happens all the time. If you tried it one more time and it crashes again, something is seriously, SERIOUSLY wrong, and needs to be examined in much more detail (you can contact us through email at netalyzr-help@icsi.berkeley.edu )
And we haven't received any other complaints about Netalyzr crashing network hardware, so this is very peculiar.
posted by nweaver at 5:45 PM on January 14, 2010 [4 favorites]
What brand/model is it?
Linksys but I don't remember the model, although I do know it's discontinued. But what is "real load" supposed to mean? I frequently max out my allotted bandwidth. Also doesn't explain the dead DSL modem.
posted by DU at 5:46 PM on January 14, 2010
Linksys but I don't remember the model, although I do know it's discontinued. But what is "real load" supposed to mean? I frequently max out my allotted bandwidth. Also doesn't explain the dead DSL modem.
posted by DU at 5:46 PM on January 14, 2010
malor: Don't forget one other thing: when you share a DNS server with a lot of people, your lookups happen faster because they are far more likely to be cached because someone else has looked it up.
Load on the servers isn't the real issue, its common caching why DNS caches are so important. The authorities could take so much more traffic than they do now. This is why Google Public DNS is so "fast" for lookups: they cache very agressively, including prefetching, and they are using a lot of users to get better cacheability.
posted by nweaver at 5:50 PM on January 14, 2010 [2 favorites]
Load on the servers isn't the real issue, its common caching why DNS caches are so important. The authorities could take so much more traffic than they do now. This is why Google Public DNS is so "fast" for lookups: they cache very agressively, including prefetching, and they are using a lot of users to get better cacheability.
posted by nweaver at 5:50 PM on January 14, 2010 [2 favorites]
You can't just run the servers anywhere...
This is not the only reason to have open source code.
posted by DU at 5:51 PM on January 14, 2010
This is not the only reason to have open source code.
posted by DU at 5:51 PM on January 14, 2010
DU: "Real load" is in a feedback loop that goes up to 20 Mbps max, but there's a feedback involved (it only sends out 2 packets for every one received) so it never tries to send more than 2x faster than the network is really capable of.
Did the modem die when you tried it one more time? Whats the manufacturer/provider of it? This could have been a coincidence of noise: what happens if you visit one of the TCP-based speedtest sites that are done in Flash?
posted by nweaver at 5:52 PM on January 14, 2010
Did the modem die when you tried it one more time? Whats the manufacturer/provider of it? This could have been a coincidence of noise: what happens if you visit one of the TCP-based speedtest sites that are done in Flash?
posted by nweaver at 5:52 PM on January 14, 2010
New opt-out plan: switched to google DNS, which I was previously unaware of. Thanks, geoff.
I'm toying with getting a Nexus One because it's conceivable that tethering it would yield a faster internet connection than my DSL, and canceling DSL service would save money long term. I think T-mobile might send assassins the first time I tried to use BitTorrent though.
posted by Humanzee at 5:53 PM on January 14, 2010
I'm toying with getting a Nexus One because it's conceivable that tethering it would yield a faster internet connection than my DSL, and canceling DSL service would save money long term. I think T-mobile might send assassins the first time I tried to use BitTorrent though.
posted by Humanzee at 5:53 PM on January 14, 2010
Two more comments.. 1: ICSI is cool, what a great Berkeley department. And 2: if you live in the Bay Area ditch your Comcast ISP and sign up on sonic.net. They don't hijack your DNS and they don't randomly reach in and RST your TCP streams.
posted by Nelson at 5:55 PM on January 14, 2010
posted by Nelson at 5:55 PM on January 14, 2010
Yes, it killed me a second time. No, I will not be handing out anymore free information to an unknown entity that isn't revealing any source code about the stuff it's harvesting from me.
posted by DU at 6:02 PM on January 14, 2010
posted by DU at 6:02 PM on January 14, 2010
Host Properties –
System clock accuracy: Warning
Your computer's clock is 16 seconds slow.
This explains everything.
posted by fixedgear at 6:10 PM on January 14, 2010
System clock accuracy: Warning
Your computer's clock is 16 seconds slow.
This explains everything.
posted by fixedgear at 6:10 PM on January 14, 2010
DU: But what is "real load" supposed to mean? I frequently max out my allotted bandwidth. Also doesn't explain the dead DSL modem.
Well, I don't know what this test actually does, but it was very common for a long time to see Linksys WRT54G and GS routers, post the 3.0 version, crash quite badly when asked to handle a lot of separate connections, like with Bittorrent, or with many connections quickly established and dropped, like scanning available matches for popular games with thousands of running servers.
In the v1 and v2 versions of those, they ran Linux, but starting with v3, they came with VxWorks, which is horribly unstable in comparison, at least when handling network traffic. Later versions have gotten more acceptable, but the Linux firmwares are always better. If you've got a WRT54, you'll probably be able to run DD-WRT or Tomato on it; both are excellent.
Probably 2/3 of the time I've had to troubleshoot someone having weird connection issues with a WRT54, putting DD-WRT on it fixed the problem right up. It's not a panacea, but it works often enough to be worth trying.
re: crashed DSL modem, I'm not sure what's up with that. I'd have needed to experiment with it before powercycling it. As is, I'm clueless.
posted by Malor at 6:11 PM on January 14, 2010 [2 favorites]
Well, I don't know what this test actually does, but it was very common for a long time to see Linksys WRT54G and GS routers, post the 3.0 version, crash quite badly when asked to handle a lot of separate connections, like with Bittorrent, or with many connections quickly established and dropped, like scanning available matches for popular games with thousands of running servers.
In the v1 and v2 versions of those, they ran Linux, but starting with v3, they came with VxWorks, which is horribly unstable in comparison, at least when handling network traffic. Later versions have gotten more acceptable, but the Linux firmwares are always better. If you've got a WRT54, you'll probably be able to run DD-WRT or Tomato on it; both are excellent.
Probably 2/3 of the time I've had to troubleshoot someone having weird connection issues with a WRT54, putting DD-WRT on it fixed the problem right up. It's not a panacea, but it works often enough to be worth trying.
re: crashed DSL modem, I'm not sure what's up with that. I'd have needed to experiment with it before powercycling it. As is, I'm clueless.
posted by Malor at 6:11 PM on January 14, 2010 [2 favorites]
Just running through the test results now, and overall it looks cool. It's reporting that SMTP is blocked by my ISP, but that's not true; I'm my own ISP (I have a T1 direct to a level 1 core provider, and the only filters are those that I've set on my own edge router). Looking into the transcript of the tests, the SMTP test tries to contact port 25 on n7.netalyzr.icsi.berkeley.edu, and that host is currently rejecting requests on port 25... so the test is currently not accurate, I'd assume.
posted by delfuego at 6:28 PM on January 14, 2010
posted by delfuego at 6:28 PM on January 14, 2010
Aaaaaand now would be the time that I admit that I forgot I was connected to my work VPN, which definitely does filter outbound traffic. So nevermind my last comment -- I'm an idjit.
posted by delfuego at 6:30 PM on January 14, 2010
posted by delfuego at 6:30 PM on January 14, 2010
Major Abnormalities
* Your DNS resolver returns results even when no such server exist.
Ah, Rogers High Speed. One of the many reasons you suck, but options are so limited.
posted by generichuman at 6:54 PM on January 14, 2010
This is brilliant. nweaver, thank you for this invaluable tool!
Network bandwidth measurements: Upload 490 Kbit/sec, Download 7.5 Mbit/sec
Your Uplink: We measured your uplink's sending bandwidth at 490 Kbit/sec. This level of bandwidth works well for many users.
Your Downlink: We measured your downlink's receiving bandwidth at 7.5 Mbit/sec. This level of bandwidth works well for many users.
Network buffer measurements: Uplink 3300 ms, Downlink 229 ms (Holy Crap!) We estimate your uplink as having 3300 msec of buffering. This is quite high, and you may experience substantial disruption to your network performance when performing interactive tasks such as web-surfing while simultaneously conducting large uploads. With such a buffer, real-time applications such as games or audio chat can work quite poorly when conducting large uploads at the same time.
...and there's nothing I can do about this? Is there no possible way that my wireless router (Netgear WPN311 Rangemax Wireless) could be reconfigured to decrease such a large uplink buffer? I'm on TWC's RoadRunner service.
posted by zarq at 6:55 PM on January 14, 2010
Network bandwidth measurements: Upload 490 Kbit/sec, Download 7.5 Mbit/sec
Your Uplink: We measured your uplink's sending bandwidth at 490 Kbit/sec. This level of bandwidth works well for many users.
Your Downlink: We measured your downlink's receiving bandwidth at 7.5 Mbit/sec. This level of bandwidth works well for many users.
Network buffer measurements: Uplink 3300 ms, Downlink 229 ms (Holy Crap!) We estimate your uplink as having 3300 msec of buffering. This is quite high, and you may experience substantial disruption to your network performance when performing interactive tasks such as web-surfing while simultaneously conducting large uploads. With such a buffer, real-time applications such as games or audio chat can work quite poorly when conducting large uploads at the same time.
...and there's nothing I can do about this? Is there no possible way that my wireless router (Netgear WPN311 Rangemax Wireless) could be reconfigured to decrease such a large uplink buffer? I'm on TWC's RoadRunner service.
posted by zarq at 6:55 PM on January 14, 2010
/me facepalms while reading delfuego isn't the only one who left the vpn to the office up...
posted by butterstick at 7:03 PM on January 14, 2010
posted by butterstick at 7:03 PM on January 14, 2010
Your computer's clock is 154 seconds slow.
The hell?
posted by griphus at 7:10 PM on January 14, 2010
The hell?
posted by griphus at 7:10 PM on January 14, 2010
I have two RED results:
TCP connection setup latency: 28000ms
Network buffer measurements: Uplink 1100 ms, Downlink 790 ms
This is on Verizon FIOS (Fiber Optic). Weird. Not sure what to do about it or the source or cause.
posted by stbalbach at 7:51 PM on January 14, 2010
TCP connection setup latency: 28000ms
Network buffer measurements: Uplink 1100 ms, Downlink 790 ms
This is on Verizon FIOS (Fiber Optic). Weird. Not sure what to do about it or the source or cause.
posted by stbalbach at 7:51 PM on January 14, 2010
zark: "...and there's nothing I can do about this? Is there no possible way that my wireless router (Netgear WPN311 Rangemax Wireless) could be reconfigured to decrease such a large uplink buffer? I'm on TWC's RoadRunner service."
Unfortunately no. There is a research project that came up with a scheme ("Remote Active Queue Management") which could work but I don't know of any wireless router that does it.
stbalbach: Try a second run. The high session latency may just be a transient glitch. The buffering is just stupid systems.
posted by nweaver at 8:06 PM on January 14, 2010
Unfortunately no. There is a research project that came up with a scheme ("Remote Active Queue Management") which could work but I don't know of any wireless router that does it.
stbalbach: Try a second run. The high session latency may just be a transient glitch. The buffering is just stupid systems.
posted by nweaver at 8:06 PM on January 14, 2010
We detected the presence of an in-network transparent HTTP cache that caches data which was directly requested by the applet.
What does this mean? I'm more technically adept than the average American, less so than the average Mefite. I'm connected through a Linksys wireless router to Comcast - does the router cache data?
posted by desjardins at 8:10 PM on January 14, 2010
What does this mean? I'm more technically adept than the average American, less so than the average Mefite. I'm connected through a Linksys wireless router to Comcast - does the router cache data?
posted by desjardins at 8:10 PM on January 14, 2010
zarq: if you run a local router with traffic shaping, and set its maximum upload speed to be a little less than your actual line upload speed, that should reduce the buffering problem a great deal. Most ISPs have it, but yours is really terrible.
posted by Malor at 8:11 PM on January 14, 2010
posted by Malor at 8:11 PM on January 14, 2010
desjardins: Thats really odd. Do you have something interesting on the wireless router or your end host itself?
This means that the applet tried twice to get the same special image (that our server switches between two versions) but got the same copy twice.
Comcast, to my knowledge (as a customer) does not do any caching, so it is likely something that either the router is doing or your system is doing.
If you send the results link to us (mail it to netalyzr-help@icsi.berkeley.edu ) I can probably diagnose in more detail.
posted by nweaver at 8:35 PM on January 14, 2010
This means that the applet tried twice to get the same special image (that our server switches between two versions) but got the same copy twice.
Comcast, to my knowledge (as a customer) does not do any caching, so it is likely something that either the router is doing or your system is doing.
If you send the results link to us (mail it to netalyzr-help@icsi.berkeley.edu ) I can probably diagnose in more detail.
posted by nweaver at 8:35 PM on January 14, 2010
I have been using Open DNS for my server for years now.
Not switching. Google has enough of my information.
posted by will wait 4 tanjents at 9:56 PM on January 14, 2010
Not switching. Google has enough of my information.
posted by will wait 4 tanjents at 9:56 PM on January 14, 2010
Very interesting info on OpenDNS in the test results. What other DNS servers can be recommended as alternatives?
posted by Mei's lost sandal at 10:38 PM on January 14, 2010
posted by Mei's lost sandal at 10:38 PM on January 14, 2010
[W]e've seen worse but not by much. It can only measure up to 5 seconds.
"We estimate your uplink as having 5500 msec of buffering."
posted by robtoo at 10:57 PM on January 14, 2010
"We estimate your uplink as having 5500 msec of buffering."
posted by robtoo at 10:57 PM on January 14, 2010
This was the only warning:
"Your ISP's DNS resolver follows CNAMEs regardless of their location. This is very unusual."
I'm using Google DNS. Is this something to worry about?
posted by al_fresco at 11:45 PM on January 14, 2010
"Your ISP's DNS resolver follows CNAMEs regardless of their location. This is very unusual."
I'm using Google DNS. Is this something to worry about?
posted by al_fresco at 11:45 PM on January 14, 2010
Quick question to nweaver as the info-box didn't help when it came to figuring out a particular result. For the adress-based HTTP proxy detection, I got this: "An I/O error occurred during the test. The test result code is 34." Could you explain this for me please?
posted by Inner Universe at 2:14 AM on January 15, 2010
posted by Inner Universe at 2:14 AM on January 15, 2010
Very cool indeed, thanks nweaver (for the awesome support here too!)
posted by Duug at 3:00 AM on January 15, 2010
posted by Duug at 3:00 AM on January 15, 2010
al_fresco: Yes, Goggle DNS is far more agressive chasing CNAMEs than any other. Its rpobably safe (possibly?), but VERY unusual.
inner universe: Probably just a transient error, if it reappears, please send the results link to netalyzr-help@icsi.berkeley.edu and we'll try to find out in more details.
will-wait: You can disable the wildcarding in the OpenDNS dashboard, and I think you can now disable the google MITM if they are still doing it. Do that and the opendns issues go away.
posted by nweaver at 5:10 AM on January 15, 2010
inner universe: Probably just a transient error, if it reappears, please send the results link to netalyzr-help@icsi.berkeley.edu and we'll try to find out in more details.
will-wait: You can disable the wildcarding in the OpenDNS dashboard, and I think you can now disable the google MITM if they are still doing it. Do that and the opendns issues go away.
posted by nweaver at 5:10 AM on January 15, 2010
Thanks nweaver; I've run the scan three times now and the results have remained the same, so I'm emailing them in now.
posted by Inner Universe at 6:43 AM on January 15, 2010
posted by Inner Universe at 6:43 AM on January 15, 2010
Inner Universe: Quick question, do you have any sort of software firewall that is bringing up prompts to allow outbound connections?
posted by nweaver at 7:34 AM on January 15, 2010
posted by nweaver at 7:34 AM on January 15, 2010
zarq: if you run a local router with traffic shaping, and set its maximum upload speed to be a little less than your actual line upload speed, that should reduce the buffering problem a great deal. Most ISPs have it, but yours is really terrible.
I don't believe the Netgear router has traffic shaping built in but will check, thank you.
TWC now offers wideband service (not in my area yet, of course) and I may just switch to that when it becomes available, if it's not outrageously expensive. (ha!)
posted by zarq at 9:17 AM on January 15, 2010
I don't believe the Netgear router has traffic shaping built in but will check, thank you.
TWC now offers wideband service (not in my area yet, of course) and I may just switch to that when it becomes available, if it's not outrageously expensive. (ha!)
posted by zarq at 9:17 AM on January 15, 2010
nweaver: Unfortunately no.
Thank you! Much appreciated.
posted by zarq at 9:18 AM on January 15, 2010
Thank you! Much appreciated.
posted by zarq at 9:18 AM on January 15, 2010
Is there a good paper / webpage that explains more about the network buffering issue in routers and what its impact is? I'm assuming this is a different problem than Nagling? Is Netalyzr blind to any QoS that the router might be doing to work around the buffering problem?
posted by Nelson at 9:51 AM on January 15, 2010
posted by Nelson at 9:51 AM on January 15, 2010
Yes, we are blind to QOS, but most of the problem devices are VERY dumb, and even WITH QOS, you really shouldn't allow the buffer that big.
We do have a FAQ and explanation on that test which should explain why this is a problem, if thats not sufficient, please tell me.
Thanks.
posted by nweaver at 10:02 AM on January 15, 2010
We do have a FAQ and explanation on that test which should explain why this is a problem, if thats not sufficient, please tell me.
Thanks.
posted by nweaver at 10:02 AM on January 15, 2010
zarq : TWC now offers wideband service
I think you're probably talking about Clearwire. I think it's going to get rolled out in my area this year and I'm actually pretty excited about it.
TWC tried a different wireless (phone) product a year or two ago and it went pretty badly, it seems like they are being a little bit more cautious this time.
[fwiw, I'm digging the Netalyzr tool. Thanks for the work nweaver]
posted by quin at 10:12 AM on January 15, 2010
I think you're probably talking about Clearwire. I think it's going to get rolled out in my area this year and I'm actually pretty excited about it.
TWC tried a different wireless (phone) product a year or two ago and it went pretty badly, it seems like they are being a little bit more cautious this time.
[fwiw, I'm digging the Netalyzr tool. Thanks for the work nweaver]
posted by quin at 10:12 AM on January 15, 2010
My connection had two minor issues. The first is the large buffer sizes which a lot of people experience. I understand what this is but as far as I know there is nothing I can do about it.
The second issue the program identifies is a possible "MTU hole". Can someone explain what the heck an MTU hole is and how I can troubleshoot the problem further?
posted by Justinian at 10:20 AM on January 15, 2010
The second issue the program identifies is a possible "MTU hole". Can someone explain what the heck an MTU hole is and how I can troubleshoot the problem further?
posted by Justinian at 10:20 AM on January 15, 2010
Jusinian: An "MTU hole" is where there is a size range which your computer can't send but should. Question, are you running Linux? It could be due to a stupid bug in the Linux "path MTU discovery" code.
posted by nweaver at 10:28 AM on January 15, 2010
posted by nweaver at 10:28 AM on January 15, 2010
yes, I am running linux. THANK YOU AND GOODNIGHT.
posted by Justinian at 10:33 AM on January 15, 2010
posted by Justinian at 10:33 AM on January 15, 2010
quin: I think you're probably talking about Clearwire. I think it's going to get rolled out in my area this year and I'm actually pretty excited about it.
It's DOCSIS 3.0. I don't believe that's the same thing? It doesn't look like a wireless product.
posted by zarq at 10:59 AM on January 15, 2010
It's DOCSIS 3.0. I don't believe that's the same thing? It doesn't look like a wireless product.
posted by zarq at 10:59 AM on January 15, 2010
My bad. I read your "wideband" as "WiMAX", and Clearwire is the option using that technology from TWC that is just coming out. Sorry to have conflated the two.
posted by quin at 11:42 AM on January 15, 2010
posted by quin at 11:42 AM on January 15, 2010
I'd be curious if you could elaborate on where the buffering takes place, in the DSLAM or in the DSL access equipment I own. I know a lot of people have several DSL 'modems' lying around, some of which could be swapped in. Are you capturing info on the DSL hardware? You might want to include that as a question on your feedback form if you can't auto-detect. Any chance of ISP ratings in the future?
posted by BrotherCaine at 12:19 PM on January 15, 2010
posted by BrotherCaine at 12:19 PM on January 15, 2010
The downlink is usually the DSLAM, the uplink is the DSL modem.
We don't have any way of fingerprinting the DSL or NAT, and we deliberately don't try.
Our plan is, among other things, an ISP report card on things like wildcarding, port filtering, any DNS abberations, etc.
posted by nweaver at 12:42 PM on January 15, 2010 [2 favorites]
We don't have any way of fingerprinting the DSL or NAT, and we deliberately don't try.
Our plan is, among other things, an ISP report card on things like wildcarding, port filtering, any DNS abberations, etc.
posted by nweaver at 12:42 PM on January 15, 2010 [2 favorites]
Our plan is, among other things, an ISP report card on things like wildcarding, port filtering, any DNS abberations, etc.
This I like.
I think a lot of these problems could be reduced through market forces if people understand which things are bad, why they are bad, and who is doing them.
posted by FishBike at 12:54 PM on January 15, 2010
This I like.
I think a lot of these problems could be reduced through market forces if people understand which things are bad, why they are bad, and who is doing them.
posted by FishBike at 12:54 PM on January 15, 2010
« Older Maybe you'll get some, maybe you won't! | Best Science Blog Posts of 2009 Newer »
This thread has been archived and is closed to new comments
posted by aquathug at 3:30 PM on January 14, 2010