dropped connection

Ray · Sep 25, 2008, 11:39:48

Quote from: Rik on Sep 25, 2008, 11:35:02
See above, Ray. IDNet have identified the cause.

Oops missed that post, to quick on the reply button again,

anyway that's good to know, Rik, another problem soon to be solved.

Simon · Sep 25, 2008, 11:47:21

Some people are also very quick to blame IDNet for everything, Ann, when it's not always something they can control.

Sebby · Sep 25, 2008, 12:28:20

Quote from: Ann on Sep 25, 2008, 11:37:16
People here are often far too quick to blame BT and let IDNet off the hook. It doesn't help sort the problem. As we have seen here IDNet now know they have a problem but had it been left to some to downplay it, it wouldn't have got sorted at all.

Point taken. I guess that when it comes to sync, it is seen as something outside of IDNet's control, that's all.

Moonshine · Sep 25, 2008, 13:18:46

Glad to see it wasn't just me, then!!

Baz · Sep 25, 2008, 15:05:33

blimey I started something here didnt I

Rik · Sep 25, 2008, 15:06:11

Don't you always, Baz?

Baz · Sep 25, 2008, 15:06:51

please dont hurt me guys...........i didnt mean it

Sebby · Sep 25, 2008, 15:31:23

We've heard it all before!

Simon · Sep 25, 2008, 17:02:24

Bloody inmigrants from other ISP, they cause nothing but trouble!

Baz · Sep 25, 2008, 20:11:14

Quote from: Simon on Sep 25, 2008, 17:02:24
Bloody inmigrants from other ISP, they cause nothing but trouble!

first you try to tempt me here with amazing stats and praise then you want rid

Simon · Sep 25, 2008, 20:54:38

Far be it from me to deprive IDNet of a good paying customer!

esh · Sep 26, 2008, 12:18:37

Obviously it's all Cisco's fault.

if (std::rand() % 100 + 1 == 1) { _this->connection->drop("bye!"); }

Tsk, tsk.

Sebby · Sep 26, 2008, 15:06:46

That one's gone straight over my head.

Rik · Sep 26, 2008, 15:09:25

You shouldn't have ducked then, Seb.

Sebby · Sep 26, 2008, 15:35:51

I thought I must be going wrong somewhere.

davej99 · Sep 26, 2008, 16:33:15

I understand but a little of this technology, but I think that the Link Control Protocol establishes, configures and monitors the PPP link and if an LCP packet determines that the link is not functioning properly, it terminates it. Loss of sync will always cause termination but termination is not always caused by loss of sync. All my Netgear router logs is LCP down, not the cause. It is not true to say this is always a BT line problem, but I guess it almost always is. Any point along the connection can give rise to the failure, including both BT and IDNET equipment. Since many of us saw termination at the same time loss of sync was an unlikely cause. As it turns out a robust dialogue on this thread and Rik's follow up helped diagnose an IDNET problem. I do not expect a trouble-free service and I suggest most of the time connection issues are not IDNET's fault. To the Companies credit they investigated the problem and put their hand up. That is good enough for me.

Sebby · Sep 26, 2008, 16:45:33

IDNet are good like that; they do tend to admit when there is something wrong at their end.

Rik · Sep 26, 2008, 16:46:47

Older Netgears used to log the PPP drop separately, Dave, it's a shame that they dropped that functionality. I agree with you that LCP can go down in response to a PPP problem, but 99% (it's as valid as any stat

) of dropped connections are a local/BT issue. That this one wasn't is unusual, but as you say, once IDNet were aware of it, they found the cause pretty quickly.