"a tool designed to detect when your ISP is interfering with your net connection."
By interfering with your net connection.
Nice idea, but no thanks.
Researchers with the International Computer Science Institute in Berkeley, California have unveiled a completed version of their Netalyzr service, a tool designed to detect when your ISP is interfering with your net connection. The web-based service has been available as a beta since the middle of last year, but it's now set …
"""By interfering with your net connection."""
And by 'Interfering' you mean 'using.' It sounds like all it does is emulate a few applications, so it'd be no more interfering than just firing up your web browser or email client.
It'll be fun to run this guy on Comcast later today...
SMTP, POP, and IMAP connections "succeed, but do not receive the expected content".
I know orange.fr places a mandatory block on SMTP connections (see note below), but I find their problems with POP and IMAP to be suspicious given that Thunderbird can talk to one IMAP and three POP servers without problem!
The test reports I have a problem with buffering (Uplink 3700 ms, Downlink 690 ms). Is this an ISP issue or something I can fix? Is it the ISP? The Livebox? Windows?
The site explains, but only technically "what it means" and not "what to do about it".
Still, its a useful test.
Hint if travelling in France - if your SMTP is blocked and you are connecting through a Livebox (numerous café "free WiFi" uses it), set the SMTP to smtp.orange.fr - it will pass mail from anyone to anyone).
If you are using McDonald's WiFi, are you aware that it hijacks SMTP connections? I used telnet to try to connect to a server, to see what worked and what didn't, and the (horribly SLOW) McDonald's SMTP server responded in every single instance.
I understand McDo is aiming for the click'n'drool crowd so they don't want to explain how to reconfigure mail clients, however my mail client (still config'd to smtp.orange.fr) was under the impression that it had sent mail to there. It hadn't. McDo picked it up. This seems to me to be bordering on unethical.
...the provider whose SMTP service you normally use also offers a service on a port other than 25. Port 587 is quite common and so you just configure your client to use that rather than 25 and then when you're clicking and drooling :-) your mail will go out where you think it will and not via the hijack.
For me Virgin Media UK (cable modem)
Summary of Noteworthy Events – (the rest is green)
Major Abnormalities Your DNS resolver returns results even when no such server exists
Minor Aberrations Certain TCP protocols are blocked in outbound traffic
Direct TCP access to remote RPC servers (port 135) is blocked.
Direct TCP access to remote NetBIOS servers (port 139) is blocked.
Direct TCP access to remote SMB servers (port 445) is blocked.
Network packet buffering may be excessive
Network buffer measurements (?): Uplink 1200 ms, Downlink 290 ms
I just tried it, and it appears to work well. I would like the opportunity to add services to the test (e.g. some torrent tracker sites).
You need to disable firewalls, sypbot, etc to get proper results.
The report does make me question their motives ("potentially dangerous DNS replies for IMPORTANT names", actually means that my machine resolves ads.doubleclick,net to 127.0.0.1)
This could scare some people, and so I think they need to add a bit more logic (127.0.0.1 is obviously not redirecting to a spoof site, but may be a deliberate blocking tactic).
Also their definition of IMPORTANT sites includes the above (as well as googleservices) which makes me wonder who is sponsoring this - I understand that you do not want these being redirected but to class them as IMPORTANT is beyond me.
All in all, it seems OK, and will be a tool I use along side the xenobite.eu TOR test for my internet connections.
* The network path does not reply when it needs to fragment traffic
* Network bandwidth may be low
* Network packet buffering may be excessive
Interesting, guess that their backend systems are overloaded ATM- I can get a comfortable 1.8 megs/sec to various mirror sites stuffed with Linux ISOs, rather than the 500k/sec that they're reporting.
I should try my 3g conection too, see what evil 3 are doing.. :)
Direct TCP access to remote IMAP servers (port 143) is blocked.
Direct TCP access to remote POP3 servers (port 110) is blocked.
However, seems like a false positive...
$ telnet pop3.demon.co.uk 110
Connected to pop3.mail.demon.net.
Escape character is '^]'.
+OK demon POP3 server ready (demon.co.uk)
+OK maildrop unchanged
Connection closed by foreign host.
Network bandwidth measurements (?): Upload 900 Kbit/sec, Download 2.4 Mbit/sec
This was tested with my Linux-based netbook and a MIFI unit, nice results.
Mostly reported no problems as I expected but I disagree with the results for POP3, SMTP and IMAP.
"Direct TCP connections to remote POP3 servers (port 110) succeed, but do not receive the expected content.
The applet received an empty response instead of our normal banner. This suggests that a firewall, proxy, or filter initially allowed the connection and then terminated it, either because it did not understand our server's reply or decided to block the service. "
The results for SMTP were similar but I regularly use several POP3 + SMTP servers that are not part of my ISP's network.
Biting the hand that feeds IT © 1998–2018