Kitz Forum
Broadband Related => Broadband Hardware => Topic started by: ClownBoy on November 02, 2007, 09:37:39 PM
-
Hello,
Hope you can help me and I apologise in advance if the solution is posted somewhere else, but I did search.
I'm having a problem with my connection to the internet (Pipex).
My connection stops working for a few seconds a couple of times a minute (pauses), then starts again. Never enough to completely disconnect.
My best analogy would be that my foot is on the accelerator of my car, steady at 60 MPH. My foot does not move, yet every now and again, the car loses speed steadily, then kicks back in and back up to 60 MPH.
I have checked with various speedtest sites and they all confirm this.
Voip calls drop for this length of time.
Online games throw me into wherever I would have been when the connection bucks it's ideas up.
I am running Vista Ultimate, but I had the same problem with XP pro SP2.
I have tried with 2 different PCs and with 2 different routers and connected via ethernet, wireless and even via a modem.
All same result.
BT have come out, said I can get my expected speed (which I can, but they don't test for these drops) and said that the line is fine.
I'm really at my wits end now.
Any advice would be great.
Thanks in advance.
-
Hello ClownBoy
Welcome to the forum. As you are a Pipex customer I wondered whether you had been "unbundled" ie connected to Pipex exchange equipment. I have some doubt because you say that BT came out to check your line.
If you are not sure you can use this checker http://www.kitz.co.uk/adsl/adslchecker.php to see whose equipment you are connected to. Please report back the result.
-
Hi and welcome :)
One thing that occurs to me, that could perhaps be causing the problem is that although your router isnt physically dropping the connection and loosing sync... There is the possibility that you could have low SNR and be experiencing lots of errors which cause data packets to be dropped. Your router would have to re-request these packets and the symptoms are similar to what you describe (ie loss of acceleration).
Can you provide us with your line stats (http://www.kitz.co.uk/adsl/frogstats.htm) - depending on which modem/router you use it should also record any errors. Look for HEC/CRC errors or errored seconds etc.
-
Thank you for the replies.
Astral: I have been with Pipex for almost a year, so that shouldn't be a problem. Also this is a now and then problem I get.
Kitz: I am sorry but I need more info. I need to know what SNR means.
The link given (and the replies therein do not conform with my routers stats. (i.e. I can't find HEC or CRC errors).
Sorry for being a noob.
Your patience is greatly appreciated.
Thanks folks.
-
SNR = signal to noise ratio.
Is your router/modem not listed on the frog stats page? If not, let us know what it is; it may be the same as one on the list but differently badged.
-
I think this is the info you want.
I think.
Statistics Downstream Upstream
Line Rate 8000 Kbps 448 Kbps
Attainable Line Rate 8032 Kbps 1168 Kbps
Noise Margin 8.4 dB 25.0 dB
Line Attenuation 34.0 dB 18.0 dB
Output Power 19.7 dBm 11.9 dBm
K (number of bytes in DMT frame) 251 15
R (number of check bytes in RS code word) 0 0
S (RS code word size in DMT frame) 1 1
D (interleave depth) 1 1
Super Frames 1121825 1121823
Super Frame Errors 45 8
RS Words 0 0
RS Correctable Errors 0 0
RS Uncorrectable Errors 0 0
HEC Errors 22 0
OCD Errors 0 0
LCD Errors 0 0
Total Cells 359831255 0
Data Cells 473941 0
Bit Errors 0 0
Total ES 41 4
Total SES 0 0
Total UAS 15 0
-
There are hardly any errors there, so nothing to explain the stuttering. You appear to have a pretty reasonable line, with performance figures to match. I'm rather inclined to suspect a problem at the Pipex end, but I'm really not sure.
-
Hi thanks for those :)
Although you have a few errors theres nothing in there that would really point to slow downs due to dropped packets/errors (I'd expect there to be 100s/1000s if it was this).
However it also depends on how long your router has been up for.
Your line rate looks a bit weird - interleaved depth of 1 indicates no interleaving.
But a sync of 8000 isnt a standard BT sync rate for a non-interleaved line. Indicating possible LLU.
Your stats look ok - one thing to check when the slow down occur is if the following figures suddenly start increasing.
>> Super Frame Errors 45 8
>> HEC Errors 22 0
---
The other thing that can cause similar problems is if your router has too many IP sessions open.
One of my old routers did this if say I was using a p2p. Theres sometimes a setting in the router which will allow you to configure the maximum IP sessions.
P2P applications can be a major culprit.
Another area to check for elimination purposes only is that your router hasnt got an idle timeout set.... however I notice that you say youve already tried another router/modem :/
Other than that Im out of ideas Im afraid, and looks like it could be a pipex problem.
-
Thanks for your help.
Much appreciated.
-
clownboy
do you know whether this problem is with your isp/line or on your home network???
if you have another machine on your network, transfer a large file from one to another to see if the pauses happen.
if it does then you'll have to swap test the nics/router with another (from a friend maybe??)
-
Hmm,
Back again problem persists.
Could electrical interference be causing this?
Just a thought because I (not pipex) have ruled everything else out, having replaced everything from filters to modems/routers to PCs.
For the record, Pipex couldn't have been less helpful if they had tried.
Thanks again. ;)
-
>> Could electrical interference be causing this?
Theres numerous things that can cause problems with your connection - flourescent lighting, external lighting, treadmills, faulty emersion heater switches, microwaves.
However - this type of thing would cause the SNR Margin to drop - and youd loose sync at the exchange... or at least see lots of errors.
Electrical interference would affect your connection on the link between your router and the exchange.
However since you arent actually dropping sync - then Id be inclined to say something with the router or the ISP.
Which router do you use?
Is it possible to borrow another router off someone to try that?
-
>> Could electrical interference be causing this?
Theres numerous things that can cause problems with your connection - flourescent lighting, external lighting, treadmills, faulty emersion heater switches, microwaves.
However - this type of thing would cause the SNR Margin to drop - and youd loose sync at the exchange... or at least see lots of errors.
Electrical interference would affect your connection on the link between your router and the exchange.
However since you arent actually dropping sync - then Id be inclined to say something with the router or the ISP.
Which router do you use?
Is it possible to borrow another router off someone to try that?
I have tried 2 routers (a bt 2091-I think and an edimax) I have also tried a modem.
Hmm, thought it may have been the electric thingy. :(
The hunt goes on.
Thanks for trying.
-
Just a thought..I have heard not-so-good reports of Pipex running on high contention ratio backhauls..this may be nothing more than other people on your exchange downloading the 'Encyclopaedia Galactica'.
You have a damn fast connection there. It's highly vulnerable to other traffic getting in its way.
-
I'm sorry to keep dragging this up, but potential solutions keep popping into my head.
Last winter, I had a similar problem whilst with BT.
They sent engineers out and said the line was "capable" of 6-7 Meg.
But the problem persisted until about March.
Could this be weather related? Or have I just gone possible solution mad?
-
Weather - well storms or water on the line can cause problems - as can oxydisation of the joints.
But again I would expect to see a lot of errors on the line if this were the case. The fact that it is still retaining sync and doesnt actually drop the connection is whats puzzling me.
Im trying to think of a way to explain this - the following isnt strictly true but Im trying to put it into simple terms rather than technical terms for you.
Your line can either "hear" the adsl signal or it cant.
When it cant hear the signal thats when you loose sync with the exchange.
Your router would then reconnect and negiotiate a lower speed.
During this phase sometimes just as the line starts to become "fuzzy", then there may be times when it cant quite "hear" the signal rather than loosing a whole data packet your router goes "sorry didnt quite catch that- can you repeat it please" and the data gets retransmitted.
This causes slow downs (stutters) - BUT when this happens your router will record it in the form of HEC and CRC errors in its log and there would be 100s/1000s.
Youre not getting loss of sync
Youre not getting tons of HEC/CRC errors
You are still getting a very good sync speed at the exchange.
Those 3 factors would indicate that the problem isnt between your home and the exchange.
Your line stats look good and whilst youre obviously not next door to the exchange - youre not a long line.
Youve tried different routers... Youve tried the master socket/filters and even makes no difference on a machine with another operating system.
The other thing to perhaps check you had a weird sync speed of 8000 which isnt usual for a non-interleaved maxed line.
Have you checked your line config settings? They should be:-
Protocol/Encapsulation :- PPPoA (PPP over ATM)
Multiplexing method: VC-BASED or VC-Mux
(On some routers the above 2 settings may be combined as "PPPoA VC-Mux".)
VPI = 0
VCI = 38
DSL Standard: G.dmt
Security Protocol: CHAP
Something else you could perhaps try is changing your DNS server - although it shouldnt cause general stuttering if there is a problem with your ISPs DNS servers then it would cause stuttering and slowness whilst trying to load web-pages.
Try
OpenDNS http://www.opendns.com/
208.67.220.220
208.67.222.222
Okay now Im really going to scrap the barrel and suggest a few other things just for the sake of elimination
Did you check to see if your router has a maximum session size that can be increased? (max IPsession (http://www.kitz.co.uk/tute/errors.htm)).
Try another browser such as firefox . (IE behaves really badly on one of my machines but is fine on others.)
Try changing your MTU settings http://www.kitz.co.uk/adsl/tweak2.htm or for vista http://www.kitz.co.uk/adsl/vistaMTU.htm
-
Just thought of perhaps something else to try to see if we can perhaps pinpoint a location.
Download WinMTR - http://www.kitz.co.uk/links/network_tools.htm
Set it up to ping somewhere like www.bbc.co.uk and leave it running for a while (sufficient for it to have covered a period when youd see the stuttering) then post the results back.
Important if you browse anything or do anything whilst winMTR is running it will affect the results.
-
Before I go any further, led me state how grateful I am to kitz (and others) how they would take time out of their own lives to try to help.
I REALLY do appreciate this.
Thank you.
WinMTR results:
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| No response from host - 100 | 101 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 101 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 101 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 100 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 100 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 100 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 100 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 100 | 0 | 0 | 0 | 0 | 0 |
| www.bbc.co.uk - 1 | 100 | 99 | 25 | 64 | 1651 | 30 |
|________________________________________________|______|______|______|______|______|______|
WinMTR - 0.8. Copyleft @2000-2002 Vasile Laurentiu Stanimir ( stanimir@cr.nivis.com )
Kitz, I haven't done the switch DNS thing, but everything else was correct with regards the wireless settings.
-
hmmmmmmm - interesting !
No response from host - youre not picking up the BBC site for some reason... in fact no hops at all are showing up
If youre not getting anything with the winmtr test could either be that you have a firewall blocking traffic.. or your DNS is b0rked.
Try doing the Win MTR test again using the IP address 212.58.251.201 rather than bbc.co.uk
-
IF the router is staying up and connected at high speeds and is showing a decent error rate,its NOTHING TO DO with anything between the router and the exchange.
It MIGHT be something on the local network, something on the backhaul to Pipex, or inside Pipex itself.
It might be BT'S ATM network flapping..but BT generally sort stuff like that out in a few days.
It might be that an error has your BRAS profile above your actual download speed and data os being lost at the DSLAM, but thats very unlikely.
That leaves congestion - which generally gives you slower speeds - no jerkiness - or a Pipex issue.
I'd say it's a Pipex issue. I haven't been taking an interest in ISP's very long, but one name keep coming up in the 'its so ghastly' stakes, and that is Pipex.
Chances are its not something support there can sort either. Only their accountants: they need more bandwidth. Or it an internal routing issue..
If it stays bad, change ISP's.
-
hmmmmmmm - interesting !
No response from host - youre not picking up the BBC site for some reason... in fact no hops at all are showing up
If youre not getting anything with the winmtr test could either be that you have a firewall blocking traffic.. or your DNS is b0rked.
Try doing the Win MTR test again using the IP address 212.58.251.201 rather than bbc.co.uk
Kitz, I am getting a response, any site I ping gives me 7 or 8 no responses and then a ping reponse from the site at the bottom of the list, like the list I posted. I assumed that was to be expected, no?
TNP, thanks. I am going to ditch Pipex as soon as my contract expires with them, but until then I'm stuck with this problem.
-
Was expecting something more like this
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.7.100 - 0 | 105 | 105 | 0 | 0 | 16 | 0 |
| Juniper_1 - 0 | 105 | 105 | 15 | 28 | 63 | 16 |
| ge0-0-0-303.ptn-gw01.plus.net - 0 | 105 | 105 | 15 | 25 | 47 | 31 |
| 54.core.plus.net - 0 | 105 | 105 | 15 | 29 | 203 | 31 |
| vl22.thn-gw2.plus.net - 0 | 104 | 104 | 15 | 32 | 235 | 15 |
| rt0.thdo.bbc.co.uk - 0 | 104 | 104 | 15 | 27 | 141 | 16 |
| 212.58.238.133 - 0 | 104 | 104 | 15 | 25 | 156 | 32 |
| fe0-0.rt0-frontpost.prodgw.bbc.co.uk - 0 | 104 | 104 | 15 | 27 | 63 | 31 |
| www2.cwwtf.bbc.co.uk - 0 | 104 | 104 | 15 | 26 | 47 | 31 |
|________________________________________________|______|______|______|______|______|______|
WinMTR - 0.8. Copyleft @2000-2002 Vasile Laurentiu Stanimir ( stanimir@cr.nivis.com )
Sorry I just saw all the 0's and no transit hops which didnt show any indication of where things may be slowing down when I looked last night
Try again using the IP address to see if theres anything glaringly obvious that shows up.
Although now I look at yours again I see the summary at the bottom which does show you were actually getting somewhere.
-
Ran the MTR test using the IP address. Results below.
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| No response from host - 100 | 121 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 121 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 121 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 121 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 121 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 121 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 121 | 0 | 0 | 0 | 0 | 0 |
| www1.telhc.bbc.co.uk - 3 | 120 | 117 | 26 | 54 | 1523 | 27 |
|________________________________________________|______|______|______|______|______|______|
WinMTR - 0.8. Copyleft @2000-2002 Vasile Laurentiu Stanimir ( stanimir@cr.nivis.com )
-
Theres still a hop(s) somewhere in there which isnt responding which is strange
(I dont get that), but the final hop at the beeb is responding ok
Just out of curiousity what happens if you do a tracert (http://www.kitz.co.uk/tech/tracert.htm) to 212.58.251.201
C:\Documents and Settings\kitz>tracert 212.58.251.201
Tracing route to www1.telhc.bbc.co.uk [212.58.251.201]
over a maximum of 30 hops:
1 1 ms <1 ms 1 ms 192.168.7.100
2 16 ms 16 ms 16 ms Juniper_1 [195.166.128.123]
3 17 ms 15 ms 17 ms ge0-0-0-303.ptn-gw01.plus.net [84.92.3.9]
4 16 ms 15 ms 15 ms 54.core.plus.net [212.159.1.54]
5 15 ms 15 ms 15 ms vl23.thn-gw2.plus.net [212.159.4.20]
6 15 ms 16 ms 16 ms rt0.thdo.bbc.co.uk [212.58.239.25]
7 15 ms 16 ms 16 ms 212.58.238.133
8 15 ms 15 ms 16 ms 212.58.239.58
9 16 ms 16 ms 16 ms www1.telhc.bbc.co.uk [212.58.251.201]Trace complete.
-
C:\Users\Sam>tracert 212.58.251.201
Tracing route to www1.telhc.bbc.co.uk [212.58.251.201]
over a maximum of 30 hops:
1 30 ms 30 ms 30 ms www1.telhc.bbc.co.uk [212.58.251.201]
Trace complete.
-
Are you in the BBC IT department? :)
-
lol - Im glad its not just me thats puzzled as hell by both the winMTR results and the tracert.
WTH arent the hops showing.
From the looks of that it does indeed seem to suggest that hes sat inside the BBC :lol:
... but the time would seem to indicate that data is perhaps tunnelled.
ok - humour me here - try a tracert to " newyork.com " please
-
C:\Users\Sam>tracert www.newyork.com
Tracing route to www.newyork.com [72.167.45.13]
over a maximum of 30 hops:
1 165 ms 154 ms 153 ms www.newyork.com [72.167.45.13]
Trace complete.
-
OMG youre now in New York :lol:
Your traffic must be being "tunnelled" or you/your ISP are using a proxy (http://www.broadband-help.com/articles/networking/web_proxies_fail/).
... and after a quick google I just found found this
http://www.dial.pipex.com/support/faq/web/cache.shtml.
and this which says the adsl one is
webcache.dsl.pipex.com 3128"
http://www.the.caretaker.dsl.pipex.com/pipex.htm
Does that ring any bells?
The proxy could very well be causing the stuttering if their network and equipment is busy.
-
Hmmm. No, this is news to me.
So, basically there's nothing I can do about it? >:(
-
Are you using their proxy?
It certainly looks like you are - the fact that all your hops are hidden does seem to imply some sort of proxy
According to the link you can turn it off.
Alternatively is there any other (security) proxy that you could be using?
If the proxy server is busy it can and does cause stuttering.
-
Sorry Kitz,
I don't know how to check whether or not I am using their proxy.
Also don't know anything about using another proxy.
Can you enlighten me please?
Your continuing help is really appreciated.
Thanks.
-
Try this
http://www.lagado.com/proxy-test
-
Not using a proxy according to those 2 tests.
???
-
did you also try the cache test?
Details how to do this http://www.lagado.com/tools/cache-test
-
Yes, tried both of the tests.
The number on the second test (cache) changed I ran the test twice.
-
ok sorry damn really thought it may have been that for a short while then :/
Anyone else got any ideas what else could be causing the non-hops.. and why 1st hop is location?
-
I'm baffled, I'm afraid.
-
Im not sure tbh if it could or not. The hosts file can alter the hop names (as in fact you can see on one of my traces that I have it set so that it shows "Juniper 1" rather than the router IP - something I did a long time ago to easily be able to see which gateway I was connected to. You can also redirect.
It is worth checking the host file just to see if there is anything in there.
http://www.kitz.co.uk/security/hostsfile.htm
Something else perhaps worth trying is a reverse tracert.
Try the visualroute one http://visualroute.visualware.com/
Let it trace to your IP - click start
Let it run for a min.
Then go to the "table" tab to see the output.
Next click on the "page" button at top right and it will open another windwo
Copy the results
If you want the forum software to keep any formatting spaces wrap the output with code[] tags which you can easily do by using the (https://forum.kitz.co.uk/Themes/KitzTheme/images/bbc/code.gif) button just above the row of smilies.
- for comparison
VisualRoute Connection Test to 81.174.xxx.xxx
Performed on 26 Nov 2007 11:09:24 GMT
--------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| Hop | %loss | IP Address | Node Name | Location | ms | Graph | Network |
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 0 | 0 | 205.234.111.204 | DTG311.visualware.com | Ashburn, VA, USA? | - | | Defender Technologies Group LLC DEFENDER-1 |
| 1 | 0 | 205.234.111.129 | r03-8.iad.defenderhosting.com | Washington, DC, USA | 0 | + | Defender Technologies Group LLC DEFENDER-1 |
| 2 | 0 | 69.65.112.25 | r01.iad.defenderhosting.com | Washington, DC, USA | 0 | + | Defender Technologies Group LLC DEFENDER-1 |
| 3 | 0 | 69.65.112.77 | unknown77.112.65.69.defenderhosting.com | Ashburn, VA, USA? | 0 | + | Defender Technologies Group LLC DEFENDER-1 |
| 4 | 0 | 205.234.224.81 | v960.ar1.iad1.us.scnet.net | Washington, DC, USA | 0 | + | Server Central Network SCN-4 |
| 5 | 20 | 216.246.102.97 | 52.ae0.cr1.iad1.us.scnet.net | Washington, DC, USA | 0 | + | Server Central Network SCN-5 |
| 6 | 20 | 216.246.36.201 | 102.xe-1-2-0.cr1.iad1.us.scnet.net | Washington, DC, USA | 0 | + | Server Central Network SCN-5 |
| 7 | 0 | 69.31.31.154 | xe-2-1-0.cr2.iad1.us.nlayer.net | Dulles, VA, USA | 2 | +- | nLayer Communications Internal/Backbone NLYR-69-31-31-0-1 |
| 8 | 10 | 69.22.142.38 | xe-1-3-0.cr2.nyc3.us.nlayer.net | New York, NY, USA | 5 | + | nLayer Communications Internal/Backbone NLYR-69-22-141-0-1 |
| 9 | 0 | 213.200.73.117 | xe-2-0-0.nyc22.ip.tiscali.net | New York, NY, USA | 83 | + | Tiscali International Network B.V. |
| 10 | 0 | 89.149.186.81 | xe-1-0-0.lon20.ip.tiscali.net | London, UK | 87 | +-- | Tiscali International Network B.V. |
| 11 | 0 | 213.200.79.234 | plusnet-gw.ip.tiscali.net | (Germany)? | 115 | -+------ | Tiscali International Network B.V. |
| 12 | 0 | 212.159.0.186 | te2-2.pte-gw1.plus.net | London, UK? | 74 | + | Access LAN |
| 13 | 0 | 212.159.4.19 | vl23.thn-gw1.plus.net | (United Kingdom)? | 74 | + | Dial Cluster |
| 14 | 0 | 212.159.1.53 | ae0-102.ptn-gw01.plus.net | London, UK? | 75 | + | Access LAN |
| 15 | 0 | 84.92.3.10 | gi9-0-303.ptn-ag1.plus.net | (United Kingdom)? | 75 | + | PlusNet Core Network Infrastructure |
| 16 | 0 | 81.174.xxx.xx | 81-174-1xx-xx.plus.com | (United Kingdom)? | 90 | +- | Dial-up and ADSL pool |
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-
The only explanation that I can come up with is that when you perform a traceroute, *something* e.g. your router, or a piece of firewall software, is re-writing the "TTL" part of the IP header that traceroute sends out. (traceroute explanation below if anyone's interested)
Do these weird traceroutes happen with both of your routers? If so, I'd look towards something installed on your PC.
Do you have any firewall software on there? If so, what is it, and does it work better when you disable the firewall.
I'm tempted to ask you to download and run HiJack This (http://www.spywareinfo.com/~merijn/programs.php#hijackthis) - Do a scan and save a logfile, then please attach it to a post on here, you might have something weird that needs getting rid of.
It can't be a proxy because proxy servers will only intercept HTTP requests, and a traceroute sends out ICMPs, so there's no real point investigating the proxy route further.
Other than that, I'm stumped as well, I've never seen this kind of behaviour before!
-
Explanation: How does Traceroute work?
When you send out a packet destined for a particular location on a routed IP network (e.g. the Internet), there is a field in the header called "Time-To-Live" or TTL. This is initially set to a value e.g. 255.
Each time the packet goes through a router, the router decreases the TTL field by one. If the TTL reaches zero, the packet is killed and the router sends a "TTL expired in transit" response back to the source. This prevents an endless bottleneck when routers are misconfigured resulting in a routing loop (where 2 routers are forwarding traffic to each other creating a loop, which I'm sure a few people will remember happening a few times from BT Internet dialup days!).
Traceroute uses this TTL functionality to find out the address of each hop on the network. It creates an ICMP packet destined for the destination IP address and sets the TTL to 1, which means the first hop will expire the packet and send an "expired in transit" response back. Traceroute intercepts this response and displays the first hop.
It then sets the TTL to 2 and sends the packet out again, this time the first router will decrease TTL to 1, and pass the packet on. The second router will decrease TTL to zero, and then send the "expired in transit" response back. Traceroute intercepts this response and displays it as the second hop.
And so on. Quite clever but simple really, and actually I see it as a bit of a 'hack' utility because of how it works!
-
--------------------------------------------------------------------------------------------
VisualRoute Connection Test to 85.210.174.237
Performed on 26 Nov 2007 19:42:31 GMT
--------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
| Hop | %loss | IP Address | Node Name | Location | ms | Graph | Network |
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 0 | 0 | 205.234.111.204 | DTG311.visualware.com | Ashburn, VA, USA? | - | | Defender Technologies Group LLC DEFENDER-1 |
| 1 | 0 | 205.234.111.129 | r03-8.iad.defenderhosting.com | Washington, DC, USA | 0 | + | Defender Technologies Group LLC DEFENDER-1 |
| 2 | 0 | 69.65.112.25 | r01.iad.defenderhosting.com | Washington, DC, USA | 11 | +-------- | Defender Technologies Group LLC DEFENDER-1 |
| 3 | 0 | 69.65.112.77 | unknown77.112.65.69.defenderhosting.com | Ashburn, VA, USA? | 10 | +-------- | Defender Technologies Group LLC DEFENDER-1 |
| 4 | 0 | 205.234.224.81 | v960.ar1.iad1.us.scnet.net | Washington, DC, USA | 0 | +- | Server Central Network SCN-4 |
| 5 | 0 | 216.246.102.97 | 52.ae0.cr1.iad1.us.scnet.net | Washington, DC, USA | 0 | +- | Server Central Network SCN-5 |
| 6 | 0 | 216.246.102.150 | xe-1-2-0.cr1.ams2.nl.scnet.net | Amsterdam, Netherlands | 86 | +-- | Server Central Network SCN-5 |
| 7 | 0 | 195.69.144.95 | te1-3.cr01.nik.bb.pipex.net | (Netherlands)? | 82 | + | AMS-IX peering LANs |
| 8 | 0 | 62.72.137.249 | te2-4.cr05.tn5.bb.pipex.net | (United Kingdom)? | 84 | +- | Core Link-1 |
| 9 | 0 | 62.72.137.10 | v3952.cr05.hx2.bb.pipex.net | (United Kingdom)? | 88 | +--- | Core Link-1 |
| 10 | 0 | 62.72.139.26 | ae0-104.cr02.hx4.dsl.pipex.net | (United Kingdom)? | 82 | + | PIPEX Communications UK Limited |
| 11 | 0 | 62.241.161.182 | g4-0.ar04.hx4.dsl.pipex.net | (United Kingdom)? | 83 | + | PIPEX Network Addresses |
| ... | - | - | - | - | - | | - |
| ? | - | 85.210.174.237 | 85-210-174-237.dsl.pipex.com | (United Kingdom)? | - | | ADSL Dynamic IP address pool |
-
The only explanation that I can come up with is that when you perform a traceroute, *something* e.g. your router, or a piece of firewall software, is re-writing the "TTL" part of the IP header that traceroute sends out. (traceroute explanation below if anyone's interested)
Do these weird traceroutes happen with both of your routers? If so, I'd look towards something installed on your PC. Yes
Do you have any firewall software on there? If so, what is it, and does it work better when you disable the firewall. Zonealarm, makes no difference if on or off
I'm tempted to ask you to download and run HiJack This (http://www.spywareinfo.com/~merijn/programs.php#hijackthis) - Do a scan and save a logfile, then please attach it to a post on here, you might have something weird that needs getting rid of. Can do if it will help
It can't be a proxy because proxy servers will only intercept HTTP requests, and a traceroute sends out ICMPs, so there's no real point investigating the proxy route further.
Other than that, I'm stumped as well, I've never seen this kind of behaviour before!
-
Would be interested in that hijack this logfile to be honest :)
Also could you download and run LSP Fix (http://www.cexx.org/lspfix.htm) and let us know what LSP providers are listed - maybe post a screenshot of the program before actually doing anything?
LSP's (layered service providers) are basically hooks into Windows networking, and are used by certain programs to intercept network / Internet traffic. Normally for good purposes if the proggy is legit (for example some antivirus programs use them to intercept mail traffic in order to transparently scan mail), but equally they are used by malware too to redirect search results etc.
It's just to try and eliminate something else, I guess :)
-
Initially......
Error
---------------------------
Winsock 2 Registry key (HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Winsock2\Parameters) is missing or could not be accessed.
If using Windows NT/2000/XP, please make sure you are logged in as Administrator and try again.
If you are still receiving this message as Administrator, it may be necessary to re-install Winsock 2.
---------------------------
OK
---------------------------
Then run in compatibility with XP, sorry couldn't copy and paste.............
NLAapi.dll
Mswsock.dll
Winrnr.dll
napinsp.dll
pnrpnsp.dll
In the keep side.
No problems found.
Will post the Hijack log very soon.
-
Hijack This log
Deleted.
-
Hijack This log
Deleted.
Havent been around the past couple of days - so didnt get to have a look see if there was anything odd on there.
-
Unfortunately I haven't been around much either, from what I remember it didn't look like there was anything nasty on there, but I didn't get a proper look, and was going to reply when I had more time.
Oh well