B
Bo Berglund
Flightless Bird
On Wed, 17 Mar 2010 20:04:00 -0700, John Wunderlich
<jwunderlich@lycos.com> wrote:
>Bo Berglund <boberglund@myotherhome.sec> wrote in
>news:grk2q5haa82m2b0n109qnbru6l98iv6dop@4ax.com:
>
>> C
Program Files\Support Tools>browstat dn
>>
>> List of transports currently bound to the browser
>>
>> 1 \Device\NetBT_Tcpip_{741442F2-B450-42F7-967E-00AD8658A7F3}
>> 2 \Device\NetBT_Tcpip_{3DD7AF76-C9DB-47AB-AC09-5FD763FDFD61}
>>
>[...]
>>
>> Looks like it is not this issue either....
>> My best bet now seems to be to go wireless for good. The wired
>> network connection is 10% blackouts now....
>
>You're right. This doesn't seem to be the problem. But it does point
>out another issue. It appears you have 2 transports bound to the
>browser for the same domain (SYSTEM3R). It might be that only one of
>these is actually connected in an operational sense (probably #1) and
>if it picks the wrong binding, you may be waiting for a long timeout
>before trying the other binding. When working wireless or over VPN,
>you may only have one active binding -- eliminating your problem.
>
>To test this, try un-binding one of the connections. The following
>command will unbind connection #2 above, leaving only connection #1:
>
> browstat unbind 2
>
>Then test it with only one binding. This "unbinding" is temporary and
>will hold until your next reboot. If #2 is the wrong one, try #1.
>
>[As you might guess, "browstat" has more parameters than it advertises
>in "browstat /help"]
>
Interesting, is there perhaps a way to translate the GUID of the
"transports" into a network interface name so it can be positively
connected to the NIC?
A "hidden" command parameter perhaps?
--
Bo Berglund (Sweden)
<jwunderlich@lycos.com> wrote:
>Bo Berglund <boberglund@myotherhome.sec> wrote in
>news:grk2q5haa82m2b0n109qnbru6l98iv6dop@4ax.com:
>
>> C
Program Files\Support Tools>browstat dn>>
>> List of transports currently bound to the browser
>>
>> 1 \Device\NetBT_Tcpip_{741442F2-B450-42F7-967E-00AD8658A7F3}
>> 2 \Device\NetBT_Tcpip_{3DD7AF76-C9DB-47AB-AC09-5FD763FDFD61}
>>
>[...]
>>
>> Looks like it is not this issue either....
>> My best bet now seems to be to go wireless for good. The wired
>> network connection is 10% blackouts now....
>
>You're right. This doesn't seem to be the problem. But it does point
>out another issue. It appears you have 2 transports bound to the
>browser for the same domain (SYSTEM3R). It might be that only one of
>these is actually connected in an operational sense (probably #1) and
>if it picks the wrong binding, you may be waiting for a long timeout
>before trying the other binding. When working wireless or over VPN,
>you may only have one active binding -- eliminating your problem.
>
>To test this, try un-binding one of the connections. The following
>command will unbind connection #2 above, leaving only connection #1:
>
> browstat unbind 2
>
>Then test it with only one binding. This "unbinding" is temporary and
>will hold until your next reboot. If #2 is the wrong one, try #1.
>
>[As you might guess, "browstat" has more parameters than it advertises
>in "browstat /help"]
>
Interesting, is there perhaps a way to translate the GUID of the
"transports" into a network interface name so it can be positively
connected to the NIC?
A "hidden" command parameter perhaps?
--
Bo Berglund (Sweden)