WEBWISE again

[#1]

Clicking through to ADOBE the dreaded BT WEBWISE page came up; I connect on RIN, and
BT have assured +Net this would never happen again, after their last incursion
Note URL where BTWEBWISE seems to have taken over the routing to adobe.com
I had clicked on my Adobe programmes help button, which takes you to their www;
URL that came up, as not clear on image: clearly shows the hijacking
http://webwise.bt.com/consumer/invitation.php?orig-url=http://www.adobe.com/support/techdocs/330714.html&request-id=2A7BAFAC&srv=a.webwise.net
All 2 lines above were the URL,  not the hypalink this post creates.

[#2]

Hiya,
Was it you that this happened to last time?
I'm going to have someone look into this asap.

[#3]

Yes was moi

[#4]

Gel, could you post the results of a tracet to any website please.
Also see https://nodpi.org/forum/index.php/topic,449.0.html - I've posted again to the end of the topic.

[#5]

Done
BT are my phone provider incidentally, if that's pertinent?

[#6]

And here's same TRACERT route but NOT via RIN which I assume
is not such a good routing[flash=200,200]http://community.plus.net/forum/index.php?[/flash]

[#7]

Gel, as we said before this shouldn't be happening. Did you change your router/modem settings to <username>@plusdsl.net and come off the RIN network?

[#8]

Thanks for that - it shows something I was looking for - the 192.168.*.* IP addresses near the beginning.
This is what my RIN tracert looks like:

C:\Documents and Settings\John>tracert www.bbc.co.uk
Tracing route to www.bbc.net.uk [212.58.251.195]
over a maximum of 30 hops:
  1     3 ms    <1 ms    <1 ms  dg834 [192.168.0.1]
  2    21 ms    19 ms    14 ms  217.47.89.122
  3     9 ms     9 ms     9 ms  217.47.89.161
  4    21 ms    17 ms    16 ms  217.47.88.10
  5    15 ms    15 ms    30 ms  217.41.171.21
  6    11 ms    11 ms     9 ms  217.41.171.65
  7    11 ms     9 ms     9 ms  217.41.171.122
  8    22 ms    22 ms    19 ms  217.41.171.50
  9    32 ms    31 ms    28 ms  217.47.88.114
 10    12 ms    10 ms    10 ms  core1-pos6-1.kingston.ukcore.bt.net [62.6.40.74]
 11    13 ms    10 ms    11 ms  core1-pos0-0-0-8.ealing.ukcore.bt.net [62.6.201.69]
 12    13 ms    10 ms    10 ms  core1-pos1-0-0.telehouse.ukcore.bt.net [62.6.201.82]
 13    11 ms    16 ms    17 ms  194.74.65.42
 14    11 ms    11 ms    10 ms  212.58.238.129
 15    12 ms    11 ms    11 ms  212.58.239.58
 16     *        *        *     Request timed out.
 17     *        *        *     Request timed out.

(Incidentally, if you right click the icon in the top left hand corner of the Cmd window you can mark the text and then copy it)

[#9]

Peter, I came off the RIN temporarily to show the alternative TRACERT on the +Net servers;
I assume it performed worse than the RIN did judging by data generated.
Moderator can see altered IP addresses.

[#10]

Hi Gel,
Your traceroute looked okay
I think the timeouts are just caused by a webserver which rejects ICMP traffic.

[#11]

I'm sticking to RIN because it performs better. I've just tried watching BBC 2 streaming. On the Plusnet network it was really jittery, on RIN it was fine.

[#12]

To me the non-RIN looks miles better. You're hitting BBC routers on the third hop.  Where you start getting timeouts is where the routers are set up to filter out ICMP traffic.. they will of course let through port 80 (http).

[#13]

Oh dear! I would of expected far better knowledge of how things work than that from a Plusnet employee.
The number of hops a a BT connection always appears more because on RIN the connection is not tunnelled through to a Gateway - all the IP addresses along the way are shown. On the Plusnet connection we will be going through many of the same boxes, it's just that because it's tunnelled the hops are invisible.

[#14]

Quote from: jelv

The number of hops a a BT connection always appears more because on RIN the connection is not tunnelled through to a Gateway - all the IP addresses along the way are shown. On the Plusnet connection we will be going through many of the same boxes, it's just that because it's tunnelled the hops are invisible.

Actually that is not correct. RIN is tunneled through to a gateway (slightly closer to the edge) and there is only 1 extra 'hop' hidden by the tunnels to PN. The reality is hop count  is largely irrelevant anyway assuming both networks are uncontended as the routers along the way do not really add latency. Of course the fewer hops the less that can go wrong along the way.
I'm surprised that you find streaming worse on the PN network as it's in the Gold queue which right now has no latency and no packet drops.
Phil

[#15]

Crown Prosecution Service posting on PHORM
http://groups.google.com/group/uk.telecom.broadband/browse_thread/thread/36075d581b1f1f9b?hl=en-GB#