SG TCP Optimizer Beta 6a

Get help and discuss anything related to tweaking your internet connection, as well as the different tools and registry patches on the site. TCP Optimizer settings and Analyzer results should be posted here.
User avatar
Philip
SG VIP
Posts: 11762
Joined: Sat May 08, 1999 5:00 am
Location: Jacksonville, Florida

SG TCP Optimizer Beta 6a

Post by Philip »

SG TCP Optimizer BETA 6 with multiple bug fixes and improvements has been released for testing, here is a direct link:

SG TCP Optimizer BETA 6a (executable last updated 02/15/02)

Please keep in mind this is BETA software, and only test it if you are confident you know what you are doing.

Report all bugs you encounter and please include your Operating System and the settings you applied ( Optimal, Custom, Cable / DSL / PPPoE, etc. ). Make sure you are running the newest realease of the program as well :)

Thanks in advance for any suggestions and feedback.

-----------------------------------------------------

All known bugs have been fixed.

The MaxMTU and Latency TABs have been rewritten completely because of compatability issues (I'd especially like to hear about any new bugs or successes ;) with those), "LAN Browsing Speedup" has been enabled for Windows 9x.


All previous issues have been reset, if you find a problem with the current version please report it to this thread.
adamonebox

MaxMTU

Post by adamonebox »

I just downloaded beta6 of the Optimizer, and as a newbie had the following question:

When I ping my DSL gateway, the highest packet size at which I get no packet loss is 1464. Above that, up to 1473, I get time outs, and above that fragmentation. Should I manually config the Optimizer app for a MaxMTU of 1464, then an MSS of 1424 (MTU-40) and an RWIN of 250624 (1424*44*4)?????

I have PacBell DSL and WinXP Pro. My ave. latency is around 130.

Any help would be appreciated.

-Adam
User avatar
Philip
SG VIP
Posts: 11762
Joined: Sat May 08, 1999 5:00 am
Location: Jacksonville, Florida

Re: MaxMTU

Post by Philip »

Originally posted by adamonebox
I just downloaded beta6 of the Optimizer, and as a newbie had the following question:

When I ping my DSL gateway, the highest packet size at which I get no packet loss is 1464. Above that, up to 1473, I get time outs, and above that fragmentation. Should I manually config the Optimizer app for a MaxMTU of 1464, then an MSS of 1424 (MTU-40) and an RWIN of 250624 (1424*44*4)?????

I have PacBell DSL and WinXP Pro. My ave. latency is around 130.

Any help would be appreciated.

-Adam
The MaxMTU TAB accounts for headers ( ICMP=8 and IP=20, since it is an ICMP ping, not TCP/IP) so you'd add 28 t the result of that tab, then subtract 40 for TCP/IP headers (IP=20 & TCP=20) to get the correct MSS...

Your calculations are right, however timeouts are not equal to fragmentation, you can't assume that if a ping times out it would've been fragmented.

Do yu always get timeouts pinging with a packet size between 1464 & 1473 ? Have you tried changing the URL ? What OS ? Are you getting timeouts in both MaxMTU and Latency tabs ?
User avatar
rmrucker
Posts: 896
Joined: Sun Sep 17, 2000 12:00 pm
Location: Long Beach, CA, USA

Post by rmrucker »

Sorry, Philip - I have been very busy. Some quick things:

1) I tried the MaxMTU tab thrice and here are the results:


Pinging [192.150.14.120] with 32 bytes ->bytes=32 time=50ms TTL=239
Pinging [192.150.14.120] with 750 bytes ->bytes=750 time=208ms TTL=239
Pinging [192.150.14.120] with 1125 bytes ->bytes=1125 time=295ms TTL=239
Pinging [192.150.14.120] with 1312 bytes ->bytes=1312 time=337ms TTL=239
Pinging [192.150.14.120] with 1406 bytes ->bytes=1406 time=360ms TTL=239
Pinging [192.150.14.120] with 1453 bytes ->bytes=1453 time=370ms TTL=239
Pinging [192.150.14.120] with 1476 bytes -> ..fragmented
Pinging [192.150.14.120] with 1465 bytes ->bytes=1465 time=372ms TTL=239
Pinging [192.150.14.120] with 1470 bytes ->bytes=1470 time=372ms TTL=239
Pinging [192.150.14.120] with 1473 bytes -> ..fragmented
Pinging [192.150.14.120] with 1472 bytes ->IcmpSendEcho(): 11010

This last line caused the ping test to freeze -- even the globe stops spinning.

So, I tried again:

Pinging [192.150.14.120] with 32 bytes ->bytes=32 time=44ms TTL=239
Pinging [192.150.14.120] with 750 bytes ->bytes=750 time=207ms TTL=239
Pinging [192.150.14.120] with 1125 bytes ->bytes=1125 time=293ms TTL=239
Pinging [192.150.14.120] with 1312 bytes ->IcmpSendEcho(): 11010

Again, that last line freezes the test -- and the globe.

I ran the test a third time -- and it worked fine... MTU = 1500.


2) The good news -- this is obviously accessing the Internet. ZoneAlarm pops up a screen before the test begins and asks me if I want to allow SG TCP Optimizer to access the Internet. Of course I said 'yes'.

ALSO, the Latency (Ping) tab worked FLAWLESSLY.


3) I hate to say this, but are still a few funky things with the MaxMTU settings. I had made up a Spread Sheet with some information about this, and one of my employees just 'accidently' closed the file and did not save it.... :( I will recreate it and fill you in on what it showed.

4) Speaking of funky, it appears to me that the TCP1323Opts section of the Optimizer still shows the "default" setting (i.e., no TCP1323Opts string value) with the Scaling and TimeStamps boxes checked. Obviously, they should be unchecked by default.

5) Something still does not sit right with me about the "Empty" entries and the discrepancy with the PMTUD, PMTUBHD, and SACKS Text boxes. How about dumping the word "Empty" and using the word "Default" instead? The boxes for PMTUD, PMTUBHD, and SACKS are too small for the whole word, but perhaps just "Def" would be sufficient?? Just food for thought.

6) Optimal settings is with the LAN Browsing Tweak OFF -- how about ON?

More to follow...
adamonebox

Timeouts

Post by adamonebox »

Phillip,

In answer to your questions:

1. I am using DOS to ping my DSL gateway IP addy in the form:
ping [Gateway] -f -l 1464

Using this method, I get good packet throughput at up to 1464, timouts from 1465 thru 1472, and fragmentation at 1473 and above. It seems this is reproducible with other URLs (e.g. CyberNet).

2. When I use the optimizer MaxMTU tab, I get a similar situation to what the post before me described - good throughput until it goes to 1475, then fragmentation, then when it drops down to 1465 it times out and just stops.

GIven this data, what vlaues would you assign to MaxMTU, etc. to maximize my ADSL? Any other thoughts?

Thanks,

-Adam
adamonebox

Addendum

Post by adamonebox »

Phillip,

To completely answer your questions, I'm running WinXP/Pro, I don't get timeouts on the Latency tab, and the exact results from the MaxMTU tab are:

Pinging [192.150.14.120] with 32 bytes ->bytes=32 time=23ms TTL=238
Pinging [192.150.14.120] with 750 bytes ->bytes=750 time=81ms TTL=238
Pinging [192.150.10.120] with 1125 bytes ->bytes=1125 time=113ms TTL=238
Pinging [192.150.10.120] with 1312 bytes ->bytes=1312 time=126ms TTL=238
Pinging [192.150.10.120] with 1406 bytes ->bytes=1406 time=136ms TTL=238
Pinging [192.150.14.120] with 1453 bytes ->bytes=1453 time=135ms TTL=238
Pinging [192.150.10.120] with 1476 bytes -> ..fragmented
Pinging [192.150.14.120] with 1465 bytes ->IcmpSendEcho(): 11010

My latency data is:


Pinging [193.10.252.19] with 32 bytes ->bytes=32 time=190ms TTL=230
Pinging [193.10.252.19] with 32 bytes ->bytes=32 time=191ms TTL=230
Pinging [193.10.252.19] with 32 bytes ->bytes=32 time=190ms TTL=230
Pinging [199.249.20.30] with 32 bytes ->bytes=32 time=98ms TTL=238
Pinging [199.249.20.30] with 32 bytes ->bytes=32 time=96ms TTL=238
Pinging [199.249.20.30] with 32 bytes ->bytes=32 time=100ms TTL=238
Pinging [204.127.135.135] with 32 bytes ->bytes=32 time=87ms TTL=47
Pinging [204.127.166.135] with 32 bytes ->bytes=32 time=69ms TTL=50
Pinging [204.127.135.135] with 32 bytes ->bytes=32 time=87ms TTL=47
Pinging [207.155.184.74] with 32 bytes ->bytes=32 time=79ms TTL=242
Pinging [207.155.184.74] with 32 bytes ->bytes=32 time=80ms TTL=242
Pinging [207.155.184.74] with 32 bytes ->bytes=32 time=80ms TTL=242
Pinging [210.103.175.103] with 32 bytes ->bytes=32 time=205ms TTL=240
Pinging [210.103.175.103] with 32 bytes ->bytes=32 time=205ms TTL=240
Pinging [210.103.175.103] with 32 bytes ->bytes=32 time=205ms TTL=240
Ping statistics for above hosts:
Packets: Sent = 15, Received = 15, Lost = 0 (0% loss)
Approximate round trip times (RTT) in milli-seconds:
Minimum = 69ms, Maximum = 205ms, Average = 130ms

-Adam
User avatar
Lobo
SG VIP
Posts: 17660
Joined: Thu Nov 23, 2000 2:32 pm
Location: Panama City, FL and a FAN of Dale Earnhardt Jr. Bud Chevy & NASCAR , and the Atlanta Braves

Post by Lobo »

Mine works fine on XP :)
User avatar
HalfLifer
Posts: 7086
Joined: Tue Jul 11, 2000 12:00 am
Location: Detroit, Michigan Internet: Comcast Narrowband

Post by HalfLifer »

Question, what did you use for LAN Browsing speedup?

Usually I delete a reg key (the way I do it) but this doesnt..
Work: DQ
Comp: AXP 1600+, MSI K7T266a Pro2 RU, 512MB PC2100, GF3 Ti200 128MB
User avatar
Lobo
SG VIP
Posts: 17660
Joined: Thu Nov 23, 2000 2:32 pm
Location: Panama City, FL and a FAN of Dale Earnhardt Jr. Bud Chevy & NASCAR , and the Atlanta Braves

Post by Lobo »

I delete key too before Optimizer, Optimizer is supposed to remove that key if you say yes to LAN speedup :)
adamonebox

Custom Values

Post by adamonebox »

In addition, in Beta 6 custom values entered for the MTU aren't showing up when I use the TCP Analyzer - it says MTU is set to 1500 no matter what value is entered prior to reboot . . .

Also, I get the same IcmpSendEcho(): 11010 issue no matter how many times I run the MaxMTU tag . . . and at different points depending on URL, mostly around 1465,

-Adam
User avatar
Lobo
SG VIP
Posts: 17660
Joined: Thu Nov 23, 2000 2:32 pm
Location: Panama City, FL and a FAN of Dale Earnhardt Jr. Bud Chevy & NASCAR , and the Atlanta Braves

Post by Lobo »

adamonebox, that is because you have MTU Discovery =yes, select custom settings, MTU Discovery=no, set MTU and REBOOT
:) :)
User avatar
rmrucker
Posts: 896
Joined: Sun Sep 17, 2000 12:00 pm
Location: Long Beach, CA, USA

Post by rmrucker »

adamonebox - you have the same problem that I had. It is a problem that is displayed in the last line:

Pinging [192.150.14.120] with 1465 bytes ->IcmpSendEcho(): 11010

That line should not be that way.
________________


Philip, my Adapter stuff is a little complicated because I am using an "ExtraNet" set up now (Nortel Networks VPN connection to work).

First off, let me just show you what I see. The sub-keys here:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\Net
... hold the Adapter "names" that are displayed in the Optimizer. They are under string values called "Driver Desc".

My ...\Net sub-keys are as follows:

0000 Dial-Up Adapter
0001 Extranet Access Client Adapter
0003 This is a bogus adapter.
0004 Network Everywhere Fast Ethernet Adapter

Note: I entered the 0003 sub-key with only ONE value -- DriverDesc = "This is a bogus adapter." It show up perfectly as an adapter with that name in the Optimizer.

The Protocol - Adapter pairs are listed as sub-keys here:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\NetTrans

The ones we are interested in are the TCP/IP - Adapter pairs, however, you cannot tell these simply from the sub-key numerical names (i.e., 0002). This is a complete list of the Protocol-Adapter pairs on this computer:

0000 None (?Old TCP/IP -> Dial-up Adapter?)
0001 Extranet Access Client Protocol -> Extranet Access Client Adapter
0002 Extranet Access Client Protocol -> Dial-Up Adapter
0003 Extranet Access Client Protocol -> Network Everywhere Fast Ethernet Adapter
0004 NetBEUI -> Network Everywhere Fast Ethernet Adapter
0005 TCP/IP -> Network Everywhere Fast Ethernet Adapter
0006 TCP/IP -> Extranet Access Client Adapter

Note: the 0000 sub-key exists in the registry -- but it does not appear in the Network Properties box. I suspect it is a vestigial TCP/IP -> Dial-Up Adapter pair that I partially removed. It should be inactive.

Now, the ones that count (for this computer) would be 0005 and 0006 -- since those are the TCP/IP - Adapter pairs. This can be determined by examining (querying) the sub-keys in this key:

HKEY_LOCAL_MACHINE\Enum\Network\MSTCP

On this machine, there are two sub-keys here: 0000 and 0003. These are ALMOST exactly the same except for the "MasterCopy" value -- which points back to itself -- and the "Driver" value. This value is "NetTrans\0006" and "NetTrans\0005" respectively.

Now, here is the problem. If I set the MaxMTU and IP Addresses in the various TCP/IP - Adapter pairs, the Optimizer reads these incorrectly.

For example, if I set NetTrans\0000 to MTU=1357 and IP Address = 1.3.5.7, NetTrans\0005 to MTU=1444 and IP Address = (Actual IP Address), and NetTrans\0006 to MTU=1234 and IP Address = 1.2.3.4, the Optimizer shows these results:

Dial-Up Adapter: MTU=1234 and IP Address=1.2.3.4
Extranet Access Client Adapter: MTU=1444 and IP Address=Actual IP Address
This is a bogus adapter.: MTU=1444 and IP Address=Actual IP Address
Network Everywhere Fast Ethernet Adapter: MTU=1500 and IP Address=(blank)

So, something is still not quite reading correctly. Got to run home. Bye.
User avatar
Philip
SG VIP
Posts: 11762
Joined: Sat May 08, 1999 5:00 am
Location: Jacksonville, Florida

Post by Philip »

Thanks for the feedback guys.

1. The "IcmpSendEcho(): 11010" simply means a timeout... We'll set it to retry and eventually give a more informative message.

2. About the MaxMTU being assigned to the correct adapter... I'll work some more on that. It's just that I've went over it so many times I'm probably blind to something obvious:
How do you tell which HKLM....\NetTrans subkeys correspond to a specific adapter in HKLM...\Net ? The info under HKLM...Enum\... seems useless to me in showing the relation.

3. I'm not sure I follow this, are you saying that on a system where there are no Tcp1323Opts values it shows both checked ?? :
"Speaking of funky, it appears to me that the TCP1323Opts section of the Optimizer still shows the "default" setting (i.e., no TCP1323Opts string value) with the Scaling and TimeStamps boxes checked. Obviously, they should be unchecked by default. "

The others in the first/second tabs rmrucker mentions will be fixed as well, I must've forgotten about them while we were rewriting the ping 3 times.
User avatar
rmrucker
Posts: 896
Joined: Sun Sep 17, 2000 12:00 pm
Location: Long Beach, CA, USA

Post by rmrucker »

I wish I had all the answers for the MaxMTU keys. I will keep looking at them. Perhaps it would help if I knew how you are determining the 'correct' 000n sub-key? I have not looked at the binary code yet -- and I realize that may not be complete. My source gave me the Enum key and I suspected it was correct. Perhaps it is not -- I don't know. My time is very constricted and I am doing the best I can to look into this...

I think it is weird that my "bogus" adapter shows the correct MTU and IP Address, yet my actual NIC does not. And my functionally non-existant TCP/IP -> Dial-Up Adapter pair shows the MTU and IP Address for my TCP/IP -> Extranet Access Client Adapter pair. How did it get those numbers?? Something is missing -- I don't know what -- yet.

I know my set up is especially atypical -- due to the ExtraNet Protocol and Adapter. This will likely make the Optimizer's job more difficult. But it will also be a good test of the design...

YES, if I remove the TCP1323Opts value completely, the Optimizer shows that both Scaling and TimeStamps are checked. As you know, the default (no Tcp1323Opts value) is for both of these to be Off.

Got to run again. More as I can.
User avatar
Philip
SG VIP
Posts: 11762
Joined: Sat May 08, 1999 5:00 am
Location: Jacksonville, Florida

Post by Philip »

From our tests the keys under ENUM don't always correspond to the right NetTrans subkey, and we're looking directly in the Net key instead, then finding the right 000n by simply incremental pattern. It usually works (seems to be very similar to the way Windows assigns them), but not always as it seems with your setup. I'll have to check into it again.

The others are mostly trivial bugs it seems, more question of interpretation and error handling, they will be fixed soon.
User avatar
rmrucker
Posts: 896
Joined: Sun Sep 17, 2000 12:00 pm
Location: Long Beach, CA, USA

Post by rmrucker »

The Enum\Network\MSTCP subkeys definitely point to which NetTrans sub-keys have TCP-IP bound to an adapter -- but they do not seem to specify which adapter -- the subkeys are exactly alike (except for the two differences I pointed out above).

As you are aware, the Net and NetTrans subkeys are not directly related in a linear or numerical fashion. But somehow the Network Properties box is able to link them -- and obviously they are functionally linked. It is difficult to tell exactly how. :(

There must be something in the registry that ties these together. It should be simple, but it is certainly not obvious. I will try to spend some time today to get to the bottom of this....
User avatar
Lobo
SG VIP
Posts: 17660
Joined: Thu Nov 23, 2000 2:32 pm
Location: Panama City, FL and a FAN of Dale Earnhardt Jr. Bud Chevy & NASCAR , and the Atlanta Braves

Post by Lobo »

Set MTU discovery to no, MTU to 1472 in XP, took analyzer MTU=1472 :) :) :)
User avatar
Philip
SG VIP
Posts: 11762
Joined: Sat May 08, 1999 5:00 am
Location: Jacksonville, Florida

Post by Philip »

Originally posted by Lobo
Set MTU discovery to no, MTU to 1472 in XP, took analyzer MTU=1472 :) :) :)
Can you elaborate on that a bit ?
User avatar
Lobo
SG VIP
Posts: 17660
Joined: Thu Nov 23, 2000 2:32 pm
Location: Panama City, FL and a FAN of Dale Earnhardt Jr. Bud Chevy & NASCAR , and the Atlanta Braves

Post by Lobo »

Well with MTU discovery set to yes would detect 1500, so I set it to no and entered 1472, really haven't had time to play with it :) :)



You also left out about the 3rd party tweaks remaining
User avatar
Lobo
SG VIP
Posts: 17660
Joined: Thu Nov 23, 2000 2:32 pm
Location: Panama City, FL and a FAN of Dale Earnhardt Jr. Bud Chevy & NASCAR , and the Atlanta Braves

Post by Lobo »

I was wrong, with MTU discovery set to yes it changed MTU to 1472, sorry :) :) :)
User avatar
rmrucker
Posts: 896
Joined: Sun Sep 17, 2000 12:00 pm
Location: Long Beach, CA, USA

Post by rmrucker »

Philip-

I just shut down all my TSR's and ran RegMon (Registry Monitor from SysInternals). In case you have not used it, this program watches in real time what process accesses the registry and tells you what it does in there.

I then opened the Network Properties box and saved the real time RegMon output. The Network Properties box always seems to clearly link the correct Net and NetTrans keys (i.e., it links the Adapters and the Adapter-Protocol pairs that are listed in the the Net and NetTrans keys).

The only activity that I could find in the registry related to these entries were in the HKLM\Enum\Network keys. The Net and NetTrans keys themselves are not accessed by the Network Properties box. Also of note, my bogus adapter does not show up in Network Properties.

If I look specifically at the ...\MSTCP entries, I do find an interesting difference that I need to investigate further. I am not sure of the source, but the print out looks like this:

EnumKey HKLM\Enum\Network SUCCESS MSTCP
OpenKey HKLM\Enum\Network\MSTCP SUCCESS hKey: 0xC29B1BD0
EnumKey HKLM\Enum\Network\MSTCP SUCCESS 0003
OpenKey HKLM\Enum\Network\MSTCP\0003 SUCCESS hKey: 0xC29BB180
QueryValueEx HKLM\Enum\Network\MSTCP\0003\Class SUCCESS 4E 65 74 54 72 61 6E 73 ...
CloseKey HKLM\Enum\Network\MSTCP\0003 SUCCESS
EnumKey HKLM\Enum\Network\MSTCP SUCCESS 0000
OpenKey HKLM\Enum\Network\MSTCP\0000 SUCCESS hKey: 0xC29DF6A0
QueryValueEx HKLM\Enum\Network\MSTCP\0000\Class SUCCESS 4E 65 74 54 72 61 6E 73 ...
CloseKey HKLM\Enum\Network\MSTCP\0000 SUCCESS
EnumKey HKLM\Enum\Network\MSTCP NOMORE
_______________________________

As in my earlier post you will see that my registry in this section is as follows:

HKLM\Enum\Network\MSTCP\0003
Driver="NetTrans\0005"

HKLM\Enum\Network\MSTCP\0000
Driver="NetTrans\0006"

And NetTrans\0005 is for: TCP/IP -> Network Everywhere Fast Ethernet Adapter
While NetTrans\0006 is for: TCP/IP -> Extranet Access Client Adapter
________________________________

The correct one for the Optimizer to find is the NetTrans\0005 -- but presently it is using \0006.

The ONLY differences I see in the registry access from the Network Properties box is these:

OpenKey HKLM\Enum\Network\MSTCP\0003 SUCCESS hKey: 0xC29BB180
OpenKey HKLM\Enum\Network\MSTCP\0000 SUCCESS hKey: 0xC29DF6A0

All other EnumKey and OpenKey commands look the same for the 0003 and 0000 subkeys. So where the hell do those "hKey: 0x" numbers come from?? Are they important -- they seem to be? How else is the Network Properties box deciding which Adapter is tied to which Protocol?

I may be barking up the wrong tree -- it wouldn't be the first time. But I'll keep barking for awhile and see what falls out! Cheers.
adamonebox

PPPoE

Post by adamonebox »

Philip et. al.,

Hi, it's me, the newbie again.

The MaxMTU test is still timing out for me at 1465 - just like my own pings to my gateway.

I realized that when you add the 28 accounted for to 1464 - voila you get 1492 which suggests I am on a PPoE connection.

I have ADSL and a fixed IP address and have never had to run any type of special PPoE software (I've been sharing the connection through a broadband router using WinXP Pro and Mac OS 9 on a few different machines). Am I definitely on PPoE by this data, and should I set MaxMTU to 1492 accordingly?

Thanks!

-Adam
User avatar
Philip
SG VIP
Posts: 11762
Joined: Sat May 08, 1999 5:00 am
Location: Jacksonville, Florida

Post by Philip »

Interesting find Rick, I haven't used Regmon before but I'll certainly play with it as well to get to the bottom of this.

As far as the MaxMTU/Latency/etc. do they work ok on your end with the 6a update ?
User avatar
Philip
SG VIP
Posts: 11762
Joined: Sat May 08, 1999 5:00 am
Location: Jacksonville, Florida

Re: PPPoE

Post by Philip »

Originally posted by adamonebox
Philip et. al.,

Hi, it's me, the newbie again.

The MaxMTU test is still timing out for me at 1465 - just like my own pings to my gateway.

I realized that when you add the 28 accounted for to 1464 - voila you get 1492 which suggests I am on a PPoE connection.

I have ADSL and a fixed IP address and have never had to run any type of special PPoE software (I've been sharing the connection through a broadband router using WinXP Pro and Mac OS 9 on a few different machines). Am I definitely on PPoE by this data, and should I set MaxMTU to 1492 accordingly?

Thanks!

-Adam
can you please post the result of the MaxMTU tab again using the 6a version of Optimizer (I just updated it today).

If dos pings over 1464 get fragmented yes, your MaxMTU shoud be 1464+28=1492 ... However if they simly timeout I don't have a definite answer for you, I'd still stay within 1492 to be on the safe side.
adamonebox

Now it works

Post by adamonebox »

Philip,

Now that I set the MTU to 1492 and the other settings to PPoE optimized, I get the MaxMTU to work. Before I reset my RWIN and MaxMTU, I was getting time-outs at 1465:

Pinging [192.150.14.120] with 32 bytes ->bytes=32 time=22ms TTL=239
Pinging [192.150.14.120] with 750 bytes ->bytes=750 time=81ms TTL=239
Pinging [192.150.14.120] with 1125 bytes ->bytes=1125 time=111ms TTL=239
Pinging [192.150.14.120] with 1312 bytes ->bytes=1312 time=126ms TTL=239
Pinging [192.150.14.120] with 1406 bytes ->bytes=1406 time=133ms TTL=239
Pinging [192.150.10.120] with 1453 bytes ->bytes=1453 time=138ms TTL=239
Pinging [192.150.10.120] with 1476 bytes -> ..fragmented
Pinging [192.150.10.120] with 1465 bytes -> ..fragmented
Pinging [192.150.14.120] with 1459 bytes ->bytes=1459 time=136ms TTL=239
Pinging [192.150.14.120] with 1462 bytes ->bytes=1462 time=138ms TTL=239
Pinging [192.150.14.120] with 1463 bytes ->bytes=1463 time=137ms TTL=239
Pinging [192.150.14.120] with 1464 bytes ->bytes=1464 time=136ms TTL=239
The largest possible non-fragmented packet is 1464 (1492 - 28 ICMP & IP headers).
You can set your MTU to 1492
User avatar
Philip
SG VIP
Posts: 11762
Joined: Sat May 08, 1999 5:00 am
Location: Jacksonville, Florida

Post by Philip »

From what I see in your result you're getting fragmented packets over 1464, not timeouts...In that case your MaxMTU would be 1492 for sure. How did you come up with the timeouts ? Pinging from DOS ?
adamonebox

Philip

Post by adamonebox »

Philip,

When my settings were optimized for DSL (e.g. MTU at 1500) the MaxMTU program would fragment at 1475, then timeout at 1465, repeatedly and consistently. Pinging would yield the same results (timeouts above 1464, fragments above 1472).

Once I switched the PPoE optimized, with the MTU set to 1492, and the corresponding RWIN multiple, the MaxMTU test ran perfectly - i.e. fragmenting over 1464 as it should.

The test warned that good results would only happen if the MTU was set to 1500 - which makes sense. The test isn't as much help if you have to set the MTU and other settings to PPoE optimized before you run the test to figure out what is going on . . .

Does that help?

-Adam
User avatar
Lobo
SG VIP
Posts: 17660
Joined: Thu Nov 23, 2000 2:32 pm
Location: Panama City, FL and a FAN of Dale Earnhardt Jr. Bud Chevy & NASCAR , and the Atlanta Braves

Post by Lobo »

Call ISP and see if you are PPPoE




PPPoE you have to log on to the internet with username and password. (Not log on to Windows)
PPPoE ( Point-to-Point Protocol over Ethernet ) is a method for building PPP sessions and encapsulating packets, as described in RFC2516. Although it is not a standard, PPPoE is already being used by a number of DSL providers. It requires either routers that have built-in PPPoE support, or PPPoE software to "dial up" and establish the session. You have to log on with name and password everytime you access net with PPPoE.

:)
User avatar
Philip
SG VIP
Posts: 11762
Joined: Sat May 08, 1999 5:00 am
Location: Jacksonville, Florida

Re: Philip

Post by Philip »

Originally posted by adamonebox
Philip,

When my settings were optimized for DSL (e.g. MTU at 1500) the MaxMTU program would fragment at 1475, then timeout at 1465, repeatedly and consistently. Pinging would yield the same results (timeouts above 1464, fragments above 1472).

Once I switched the PPoE optimized, with the MTU set to 1492, and the corresponding RWIN multiple, the MaxMTU test ran perfectly - i.e. fragmenting over 1464 as it should.

The test warned that good results would only happen if the MTU was set to 1500 - which makes sense. The test isn't as much help if you have to set the MTU and other settings to PPoE optimized before you run the test to figure out what is going on . . .

Does that help?

-Adam
Yes, thanks. Just that I changed the MaxMTU routine a bit in the 6a version, and it should give a more informative result if your MTU is 1500 and it is timing out on lower values, that's why I was asking.
User avatar
rmrucker
Posts: 896
Joined: Sun Sep 17, 2000 12:00 pm
Location: Long Beach, CA, USA

Post by rmrucker »

I haven't had as much free time as I would have liked, so I haven't delved the registry as much as I had hoped.

However, I did run the MaxMTU and Latency tabs several times -- with absolutely NO problems!!! :)

I like the choices you made for the Latency tab -- let's see, that's Sweden, Colorado Springs, New Jersery, San Jose (I think??), and Seoul -- right? That should cover the gambit for most of your users.

I will keep playing around with the Optimizer and the registry and let you know what I find. Oh, I did try to remove my old NetTrans\0000 key (in case it was interfering), and it did not make any difference...
_____________________________

I looked into the Optimizer code and I noticed you still have this line:

"The number of hops (or *rime* in seconds) a packet travels before being discarded"

It is very challenging looking at the program this way as the various OS's seem to be intermingled and it is hard to tell where the Win98 stuff is at. But it does appear that you are making at least some use of the "Emun" keys. I find these lines:

System\CurrentControlSet\Services\Class\%s
Driver
Enum\Network\MSTCP\00%02d

Otherwise, I really cannot make heads or tails out of the exact mechanism you are using to get these adapter settings. If I have time, I'll run RegMon and see what it shows me! :)
_________________

One more interesting note (maybe). The Optimizer displays all of my adapters in the drop down list -- even those that are not bound to TCP-IP. This includes my Dial-up Adapter and my "bogus" adapter.

A competitive (but much more limited) program only shows the two adapters that are bound to TCP-IP. This includes my NIC and the ExtraNet adapter. I believe this is because the program begins in the Enum keys and sees that there are only two adapters bound to TCP-IP. It then finds those two adapters and correctly reports their associated MTU entries.

Perhaps using RegMon to observe it's use of the registry would be enlightening as well. These are all on my "To Do" list. Time to run...
adamonebox

Lobo and PPoE

Post by adamonebox »

Lobo, Philip, et. al.:

I know about PPoE - that's why I was puzzled.

I do NOT use a username/password to log onto the DSL service. I have a static IP and that's it - no authentication procedure at all.

Nonetheless, my gateway behaves as if the MTU is 1492 - timing out over 1464 on the MTU test.

Any idea what this means? Is it something that WinXP pro is doing?

-Adam
User avatar
Lobo
SG VIP
Posts: 17660
Joined: Thu Nov 23, 2000 2:32 pm
Location: Panama City, FL and a FAN of Dale Earnhardt Jr. Bud Chevy & NASCAR , and the Atlanta Braves

Post by Lobo »

MTU for PPPoE on XP is 148:)
User avatar
rmrucker
Posts: 896
Joined: Sun Sep 17, 2000 12:00 pm
Location: Long Beach, CA, USA

Post by rmrucker »

Here is the RegMon output of the Optimizer -- limited to the sections of the registry in question:

OpenKey HKLM\System\CurrentControlSet\Services
\Class\Net\0000 - SUCCESS hKey: 0xC19D2E30
QueryValueEx HKLM\System\CurrentControlSet\Services
\Class\Net\0000\DriverDesc - SUCCESS 44 69 61 6C 2D 55 70 20 ...
OpenKey HKLM\Enum\Network\MSTCP\0000 - SUCCESS hKey: 0xC29AA0D0
QueryValueEx HKLM\Enum\Network\MSTCP\0000\Driver -
SUCCESS 4E 65 74 54 72 61 6E 73 ...
OpenKey HKLM\System\CurrentControlSet\Services
\Class\NetTrans\0001 - SUCCESS hKey: 0xC19C22F0
QueryValueEx HKLM\System\CurrentControlSet\Services
\Class\NetTrans\0001\MaxMTU - NOTFOUND
QueryValueEx HKLM\System\CurrentControlSet\Services
\Class\NetTrans\0001\IPAddress - SUCCESS 30 2E 30 2E 30 2E 30 0
CloseKey HKLM\System\CurrentControlSet\Services
\Class\NetTrans\0001 - SUCCESS
OpenKey HKLM\System\CurrentControlSet\Services
\Class\Net\0001 - SUCCESS hKey: 0xC182B310
QueryValueEx HKLM\System\CurrentControlSet\Services
\Class\Net\0001\DriverDesc - SUCCESS 45 78 74 72 61 6E 65 74 ...
OpenKey HKLM\Enum\Network\MSTCP\0001 - SUCCESS hKey: 0xC19CC560
QueryValueEx HKLM\Enum\Network\MSTCP\0001\Driver -
SUCCESS 4E 65 74 54 72 61 6E 73 ...
OpenKey HKLM\System\CurrentControlSet\Services
\Class\NetTrans\0003 - SUCCESS hKey: 0xC19C22F0
QueryValueEx HKLM\System\CurrentControlSet\Services
\Class\NetTrans\0003\MaxMTU - SUCCESS 31 35 30 30 0
QueryValueEx HKLM\System\CurrentControlSet\Services
\Class\NetTrans\0003\IPAddress - SUCCESS 30 2E 30 2E 30 2E 30 0
CloseKey HKLM\System\CurrentControlSet\Services
\Class\NetTrans\0003 - SUCCESS
OpenKey HKLM\System\CurrentControlSet\Services
\Class\Net\0002 - SUCCESS hKey: 0xC19D2ED0
QueryValueEx HKLM\System\CurrentControlSet\Services
\Class\Net\0002\DriverDesc - SUCCESS 4E 65 74 77 6F 72 6B 20 ...
OpenKey HKLM\Enum\Network\MSTCP\0002 - NOTFOUND
CloseKey HKLM\Enum\Network\MSTCP\0001 - SUCCESS
OpenKey HKLM\Enum\Network\MSTCP\0003 - SUCCESS hKey: 0xC29A9B20
QueryValueEx HKLM\Enum\Network\MSTCP\0003\Driver -
SUCCESS 4E 65 74 54 72 61 6E 73 ...
OpenKey HKLM\System\CurrentControlSet\Services
\Class\NetTrans\0012 - SUCCESS hKey: 0xC19C22F0
QueryValueEx HKLM\System\CurrentControlSet\Services
\Class\NetTrans\0012\MaxMTU - NOTFOUND
QueryValueEx HKLM\System\CurrentControlSet\Services
\Class\NetTrans\0012\IPAddress - SUCCESS 30 2E 30 2E 30 2E 30 0
CloseKey HKLM\System\CurrentControlSet\Services
\Class\NetTrans\0012 - SUCCESS
OpenKey HKLM\System\CurrentControlSet\Services
\Class\Net\0003 - NOTFOUND
OpenKey HKLM\System\CurrentControlSet\Services
\Class\Net\0004 - NOTFOUND
OpenKey HKLM\System\CurrentControlSet\Services
\Class\Net\0005 - NOTFOUND
OpenKey HKLM\System\CurrentControlSet\Services
\Class\Net\0006 - NOTFOUND
OpenKey HKLM\System\CurrentControlSet\Services
\Class\Net\0007 - NOTFOUND
OpenKey HKLM\System\CurrentControlSet\Services
\Class\Net\0008 - NOTFOUND
OpenKey HKLM\System\CurrentControlSet\Services
\Class\Net\0009 - NOTFOUND
OpenKey HKLM\System\CurrentControlSet\Services
\Class\Net\00010 - NOTFOUND
OpenKey HKLM\System\CurrentControlSet\Services
\Class\Net\00011 - NOTFOUND
OpenKey HKLM\System\CurrentControlSet\Services
\Class\Net\00012 - NOTFOUND
OpenKey HKLM\System\CurrentControlSet\Services
\Class\Net\00013 - NOTFOUND
OpenKey HKLM\System\CurrentControlSet\Services
\Class\Net\00014 - NOTFOUND
OpenKey HKLM\System\CurrentControlSet\Services
\Class\Net\00015 - NOTFOUND
OpenKey HKLM\System\CurrentControlSet\Services
\Class\Net\00016 - NOTFOUND
OpenKey HKLM\System\CurrentControlSet\Services
\Class\Net\00017 - NOTFOUND
OpenKey HKLM\System\CurrentControlSet\Services
\Class\Net\00018 - NOTFOUND
OpenKey HKLM\System\CurrentControlSet\Services
\Class\Net\00019 - NOTFOUND
_______________________

Now, this is a different computer, so the subkeys are not the same. What is the Optimizer doing?

1) It looks into the ...\Class\Net\0000 subkey and grabs the data in the "DrvierDesc" value. This is the "Adapter Name" that appears in the "Network Adapter selection" drop-down box in the Optimizer. In the case of this computer, it is "Dial-Up Adapter". The Optimizer does NOT first check to see if this Adapter is actually bound to TCP-IP -- which it may not be. So I think the Optimizer is starting off incorrectly -- because it assumes this Adapter is bound to TCP-IP and it therefore has an IP address and a MaxMTU entry -- it may not.

2) It goes back to the ...\Enum\Network\MSTCP key and finds the first subkey -- 0000. It grabs data in the "Driver" value there -- in this case it is NetTrans\0001. It appears that the Optimizer assumes the first Net subkey (0000) should be directly related to the first Enum\...\MSTCP key (0000) -- this is a not necessarily a true assumption.

3) It takes this data (NetTrans\0001) and tries to extract the MaxMTU data and the IP address data. In this case, there is not MaxMTU data -- so the result is "NOTFOUND", but the IP Address value is there -- and it is 0.0.0.0 (or 30 2E 30 2E, etc.).

4) It moves to the ...\Class\Net\0001 subkey and grabs the "DriverDesc" there. This will appear in the drop-down box entitled "Network Adapter selection" in the Optimizer -- regardless of whether or not TCP-IP is bound to this adapter. For this computer, the result there is "Extranet Access Client Adapter".

5) It returns to the ...Enum\Network\MSTCP key and goes to the next subkey. In this case it is 0001. It finds the "Driver" value there to be "NetTrans\0003", so it assumes a direct relationship and goes to that that subkey next.

6) There it extracts a MaxMTU and an IP Address. These should be displayed whenever this Adapter is chosen. There lies the problem -- the NetTrans\0003 subkey is NOT the correct one for this adapter. The NetTrans\0003 subkey is for TCP-IP bound to my NIC.

7) The process continues as above -- assuming a direct relationship between the ...\Class\Net entries and the ...\Enum\Network\MSTCP entries.
______________________________

The problems are several-fold. First, the Optimizer is not verifying that the Adapter in question even is bound to TCP-IP. If the Adapter is not bound to TCP-IP, then there is no reason to list it in the drop-down box. Second, and more importantly, the Optimizer assumes a direct, linear relationship between the Net and the Enum registry entries -- and this cannot be assumed.
User avatar
rmrucker
Posts: 896
Joined: Sun Sep 17, 2000 12:00 pm
Location: Long Beach, CA, USA

Post by rmrucker »

OK, how about the examination of another program? This is what I found:

1) First, this section of the registry is examined:
HKEY_LOCAL_MACHINE\Enum\Root\Net

There happens to be two subkeys there on this computer, 0000 and 0001. Each is opened sequentially. The results for the first subkey are are follows: First the "Class" value is queried -- the result is "Net". Then the "Driver" value is queried -- result is "Net\0000". Last, the "Driver Description" is queried -- result is "Dial-Up Adapter".

Next the 0000\Bindings sub-subkey is opened and "Enum"erated. The desired result is a string value: "MSTCP/0000".

2) Next, the HKEY_LOCAL_MACHINE\Enum\Network\MSTCP\0000 key is opened. The "Driver" value is queried -- the result is "NetTrans\0001".
__________________________

OK, stop for a second. We now have determined EXACTLY what we need to know. We have the Adapter name ("Dial-Up Adapter") and its ...\Class\Net subkey ("Net\0000"). Most importantly, we have the correct ...Class\NetTrans subkey for the TCP-IP binding to this adapter ("NetTrans\0001").

But it is not that simple. There are only TWO subkeys in HKEY_LOCAL_MACHINE\Enum\Root\Net, yet I have three Adapters... let me go on.
__________________________

3) The opened keys are all closed. Then this key is opened:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\Net\0000
This is the key that was specified in the ...Root\Net\0000 key.

4) This key is opened next:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\Net\0000\Ndi\params\IPMTU, followed by a query in the ABOVE key (...\Class\Net\0000) for a value entitled "IPMTU". After that, both of the ...Class\Net subkeys are closed.

[That reminds me, for Dial-Up Adapters, you cannot set the MTU by using a "MaxMTU" value in the NetTrans subkey -- instead it must be an "IPMTU" value in the Net subkey. This is very different than for the NIC's.]

5) It then returns to HKLM\Enum\Root\Net and opens the next subkey - 0001. It extracts the Class, Driver, and DeviceDesc as above. In this case, the results are Net, Net/0001, and Extranet Access Client Adapter.

6) The Bindings subkey is opened and Enumerated -- the result in question is a string value named "MSTCP\0003". Not surprisingly, the next key opened is HKLM\Enum\Network\MSTCP\0003, and the "Driver" value is queried. The result this time is "NetTrans\0012". Again we have the Adapter name, the corresponding ...Class\Net subkey, and the ...Class\NetTrans subkey that binds TCP-IP to this adapter. This time it is Extranet Access Client Adapter, Net\0001, and NetTrans\0012.

7) The ...Net\0001 key is opened and an attempt is made to open an IPMTU subkey. Since this is not a Dial-Up Adapter, this is not found and the Net\0001 key is closed.

8) The NetTrans\0012 key is opened and a queried is made for a "MaxMTU" value. In the case of my ExtraNet adapter, none is found.

9) It goes back to my ...Enum\Root\Net key and finds no more subkeys. This is the weird part -- it has not yet found my actual NIC. There must be more to the story.

10) It runs through all of the Root subkeys -- always querying for "Class" -- and assumedly looking for "Net" -- but not finding it. Then it moves through *ALL* the ...Enum subkeys and keeps querying for "Class" -- but apparently not having success. Eh, until it gets to this key:

HKLM\Enum\PCI\VEN_1317&DEV_0985&SUBSYS_05701317&REV_11\BUS_00&DEV_0F&FUNC_00

That is exactly the key! There is a "Class" value there that has "Net" as its data.

11) The program found what it was looking for, so it extracts the Driver and the DeviceDesc values -- in this case, they are "Net\0002" and "Network Everywhere Fast Ethernet Adapter(NC100 v2)".

12) Next, it checks the Bindings subkey there -- that is:
HKLM\Enum\PCI\VEN_1317&DEV_0985&SUBSYS_05701317&REV_11\BUS_00&DEV_0F&FUNC_00\Bindings.
Lo and behold, this has a string value named "MSTCP\0001".

13) It should now come as little surprise that the next key opened is: HKLM\Enum\Network\MSTCP\0001. Also of little surprise, the "Driver" value is queried and found to be "NetTrans\0003". We now have the final piece to the puzzle -- my NIC (Network Everywhere Ethernet Adapter) is in the Net/0002 subkey and bound to TCP-IP in the NetTrans\0003 subkey.

14) The process is repeated, HKLM\System\CurrentControlSet\Services\Class\Net\0002 is opened and the IPMTU subkey is looked for but not found, so the HKLM\System\CurrentControlSet\Services\Class\NetTrans\0003 key is opened and the "MaxMTU" value is queried.
______________________________

I realize this is HUGE, but this is exactly what occurs. The *entire* Enum key is queried looking for any Class="Net" value. If it is found, then the Driver and DeviceDesc values are noted, and the Binding subkey is opened and queried for a Driver value. Once you have these, you have all the information you need to link a given Adapter to the correct NetTrans Protocol-Adapter pair.

If you think you wish this was more simple, imagine how I feel!! :) Good night.
User avatar
Philip
SG VIP
Posts: 11762
Joined: Sat May 08, 1999 5:00 am
Location: Jacksonville, Florida

Post by Philip »

Thanks Rick, that was a great help...
You're right, the Optimizer was using the \Net kew and some obscure algorithm to find the correct NIC, which did not work in all cases.

With all the info you have provided, I'm trying to design a bit better optimized algorithm now... Here are the steps as I see them, the below should work... (someone double-check it):

1. Search HKLM\Enum\ (PCI, USB, ISAPNP, Root, ACPI?) for setting "Class" with value = "Net".
a) When/if found, extract the "Driver"="Net\00xx", "DeviceDesc"="Name of Adapter". Also, search subkeys recursively for a key "Bindings" and find in it a setting named "MSTCP\00xx" with no value. (if there is no sybkey Bindings, discard. That will only take the Dial-up adapter from the \Root\Net subkey then... ? )

2. Go to HKLM\Enum\Network\MSTCP\00xx (where 00xx is the same as in the above "Bindings" subkey ) and extract the "Driver"="NetTrans\00xx"

3. Go through the right "HKLM\system\CurrentControlSet\Sevices\Class\NetTrans\00xx\MaxMTU" for NICs, and to the right "HKLM\system\CurrentControlSet\Sevices\Class\Net\00xx\IPMTU" for "Dial-Up Adapter"

The end... Hopefully.

Thanks for all the time you've spend on this Rick, it is appreciated as always.
Disclaimer: Please use caution when opening messages, my grasp on reality may have shaken loose during transmission (going on rusty memory circuits), even though my tin foil hat is regularly audited for potential supply chain tampering. I also eat whatever crayons are put in front of me.
๑۩۞۩๑
User avatar
rmrucker
Posts: 896
Joined: Sun Sep 17, 2000 12:00 pm
Location: Long Beach, CA, USA

Post by rmrucker »

I was fairly surprised how difficult it was to find my NIC -- I would have liked to see all the Adapters in the ...\Root\Net key -- but then it would have been too easy, eh? :)

The entire "Enum" key was scanned for anything containing the Class="Net" value. As was said, this is not necessarily an 'elegant' method, but it does work. Although a lot of keys are scanned, in practice the whole thing occurs in the blink of an eye.

Your list looks to be correct. If I have time this weekend, I will look for alternatives.

The bottom line is that the 000n sukeys in Enum\Network\MSTCP contain *all* of the Adapters (no more and no less) that should be included in the "Network Adapter selection" drop down box. Although these keys indicate the correct NetTrans key that binds the Adapter to TCP-IP, sadly, these subkeys do NOT indicatate the ...Class\Net\000n subkey that corresponds to the specified Adapter -- or even the name of the Adapter. :(

This can apparently only be identified by locating the appropriate key containing a 'Class="Net"' value. This key will contain the name of the Apapter (DeviceDesc) and it will point to the correct ...Class\Net\000n subkey. Most importantly, this key MUST contain a "Bindings" subkey that ties everything together.

A string value (with no data) in the Bindings subkey points to the correct ...\Enum\Network\MSTCP\000n subkey. This is the important piece of the puzzle that we did not have before -- and certainly was not given to us freely! :)

I will look for a more 'elegant' method -- but I am not sure there is one that can be easily discovered. If this 'Class="Net"' key is the only way to determine the bindings, then this may be all we can do...

Good luck.
User avatar
Philip
SG VIP
Posts: 11762
Joined: Sat May 08, 1999 5:00 am
Location: Jacksonville, Florida

Post by Philip »

Actually I don't think we have to go through the entire Enum key...

HKLM\Enum\PCI has all the PCI adapters, if any,

USB <-- self explanatory

ISAPNP <-- ISA PnP NICs, if any

Root <-- Dial-Up ?

The only subkey of Enum I'm not sure about is for non-PnP ISA NICs... I don't know if it's going to change much, but it looks we only have to look in the above subkeys rather than the entire HKLM\Enum.
User avatar
rmrucker
Posts: 896
Joined: Sun Sep 17, 2000 12:00 pm
Location: Long Beach, CA, USA

Post by rmrucker »

That sounds logical. I will be using a few other Win98 machines today (I am working) :( , so I will peak into the registry of these boxes and see if any thing else pops up.

On my home box, the ISAPNP key does list my Modem -- however, the Class="Modem" and the Driver="Modem\0000". So, it is the "Hardware" or ?Physical Layer? listing of the "adapter", but functionally this does us no good (correct?).

My Scanner (Class="SCSIApdapter") and something called "ReadDataPort" (Class="System") are also listed in there. Can you find a case where the Class="Net" appears in there?

If going through these keys only takes a few milliseconds, then it really is not a big deal. But it would be nice to limit the process to just the logical keys. To be more specific even, the Root\Net subkey is the one that holds the Dial-Up Adapters, but again fine tuning too much isn't likely going to buy you enough time to make it worth while.

I look forward to your next release. :)
User avatar
Philip
SG VIP
Posts: 11762
Joined: Sat May 08, 1999 5:00 am
Location: Jacksonville, Florida

Post by Philip »

...Enum\ISAPNP should hold only ISA PnP adapters... In your case the modem, however if you have a PnP ISA (rather than PCI) NIC, it should be listed there as well IMHO.
User avatar
rmrucker
Posts: 896
Joined: Sun Sep 17, 2000 12:00 pm
Location: Long Beach, CA, USA

Post by rmrucker »

OK. Again, I think scanning through a few extra keys is no big deal. I would rather have it scan too many keys than not enough.

So far, two other machines. Both have the Dial-Up Adapter in \Root\Net and the NIC in \PCI keys. I suspect the rest will be set up similarly. If I find anything different, I'll let you know.
Post Reply