wireless regular loses connectivity

On Tue, 13 Mar 2007 12:27:12 -0400, Chris F Clark wrote in :

Make sure your own SSID is _unique_ (different from anyone else in the world, especially your neighbors).

They may nonetheless cause problems! Likewise the many other sources of

2.4 GHz interference (e.g., microwave ovens).

What are the _exact_ symptoms? Does the icon in the System Tray change? I have no idea what you mean by "gets lost" and "lose connectivity".

Sounds like weak signal and/or interference. You may need better (directional) antennas -- wireless signals have trouble penetrating walls, floors and ceilings.

I believe my ssid is unique in the world, given that it is a rather odd one. The ssid's I see for my neighbors are distinct both from mine and each other.

I'm pretty certain that no one was using neither the microwave nor the phones in our house at the times I was experiencing problems. Now, would the phones, even when not in use, send out some sort of broadcast message. The regularity of the lossages suggest some sort of automatic and timed event. Like someone sending out a "I'm here" (icmp) packet.

The exact symptoms are a loss of VPN connectivity. I don't recall any icons in the system tray changing. However, some percentage of time, when the problem "fixes itself", I get one of those "balloon boxes" in the system tray that says, "Connected to , strength: excellent".

I doubt weak signal, since I was within 1-3 meters from the router (i.e. in the same 9x12 room, close enough for a medium length cat5 cable to reach) the last time I was experiencing the problem, and after reconnecting, the stats show: signal strength excellent (and the maximum "4 bars").

Interference I can't rule out. I have no idea the source though, nor how to track it down. I also feel like it could be some kind of collision/packet overload problem. That seems real likely to me. However, I have no clue how to track that down either.

Thanks for response,

-Chris

On Wed, 14 Mar 2007 09:57:18 -0400, Chris F Clark wrote in :

How about your neighbors? How about other sources of interference?

Certain cordless phones do indeed chatter periodically when not in use.

It would be really helpful to get the exact symptoms when you experience a loss of VPN connectivity. Try pinging one of your DNS servers outside the VPN tunnel. Try running "IPCONFIG /ALL" in a command window. Post the exact output from both here.

Then something else is probably going on; e.g., DHCP lease renewal problem.

I seriously doubt that. Check your router log for errors.

I'm not sure of an IP address of a DNS server outside the VPN tunnel. The only addresses outside the tunnel I know it allows me to access are 192.168 (e.g. my local lan) and from what I've seen all the (wireless) devices hang up together. I guess I could ping the hardwired desktop machine. Presuming I have it turned on, as I recently have not by powering it on at all, living solely on laptops.

The ipconfig output should be easier to get. Do I need to anonymize any of it? Are there any addresses that posting will help promote a security breach?

Ok, I'll have to investigate how to do that. I essentially run the router in configure and forget mode. I know I used a web interface to initially configure the router, but haven't used that in some time (e.g. possibly weeks or months).

Is interference likely to show up in the log in some fashion?

Again, thanks.

-Chris

On Wed, 14 Mar 2007 11:35:41 -0400, Chris F Clark wrote in :

IPCONFIG/ALL would have given you the DNS servers, not to mention giving me more to go on. Please do that before posting anything more.

There should be no real security issue. (The only possible issue would be your IP address if it's static and not otherwise disclosed, but even that isn't a significant issue if you are properly firewalled, especially since you are using VPN.) Here's my current output:

| >IPCONFIG /ALL | | Windows IP Configuration | | Host Name . . . . . . . . . . . . : JTPT41 | Primary Dns Suffix . . . . . . . : navasgroup.com | Node Type . . . . . . . . . . . . : Hybrid | IP Routing Enabled. . . . . . . . : No | WINS Proxy Enabled. . . . . . . . : No | DNS Suffix Search List. . . . . . : navasgroup.com | | Ethernet adapter Wireless Network Connection: | | Connection-specific DNS Suffix . : | Description . . . . . . . . . . . : 11b/g Wireless LAN Mini PCI Adapter | Physical Address. . . . . . . . . : 00-0E-9B-A3-7B-51 | Dhcp Enabled. . . . . . . . . . . : Yes | Autoconfiguration Enabled . . . . : Yes | IP Address. . . . . . . . . . . . : 10.193.0.129 | Subnet Mask . . . . . . . . . . . : 255.255.255.0 | Default Gateway . . . . . . . . . : 10.193.0.1 | DHCP Server . . . . . . . . . . . : 10.193.0.1 | DNS Servers . . . . . . . . . . . : 207.77.152.2 | 168.215.210.50 | Lease Obtained. . . . . . . . . . : Wednesday, March 14, 2007 11:35:21 | Lease Expires . . . . . . . . . . : Wednesday, March 14, 2007 12:35:21 | | Ethernet adapter Local Area Connection: | | Media State . . . . . . . . . . . : Media disconnected | Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Mobile Connection | Physical Address. . . . . . . . . : 00-0D-60-11-B6-FA

Note the DNS server addresses.

You're now in troubleshooting mode.

The _problem_ is likely to show up in the log.

Well, this is interesting. I've seen the output of ipconfig before and I know this is NOT the expected output. And, it's particularly surprising, since at the moment I am NOT having a problem with my wireless connection. I then called up the wireless access connections and it gives the information below.

ipconfig /all

Windows IP Configuration

An internal error occurred: A device attached to the system is not functioning. Please contact Microsoft Product Support Services for further help.

Additional information: Unknown media status code.

========================================================================

Wireless Access Connections brings up a screen that reports:

Connection status: Associated with access point

Signal Strength: 91%

Signal quality: Excellent

Transmit rate: 54.0 Mbps

Associated MAC address: 00:13:10:73:92:F6

Current channel: 0

Current location profile: home

Network name (SSID): chris.net

Network type: Access point (Infrastructure)

Security encription: Configured by Windows

Description: 11a/b/g Wireless LAN Mini PCI Adapter

MAC Address: 00:05:4E:51:16:9D

Firmware version: N/A

Driver version: 4.1.0

========================================================================

I'm not certain what information to get next.

On Wed, 14 Mar 2007 21:59:02 -0400, Chris F Clark wrote in :

This is a known problem to which I've posted work-arounds -- see

The workarounds are problematic. I work for Intel and this laptop (and the software on it) is managed by Intel's IT department. The corporate security policy is that we need to use Thinkpad access connections (and Intel PROSet) on our laptops. In fact, they take a very dim view of us reinstalling or rolling-back any drivers on our systems. They don't even let us use Windows Update, since it might introduce patches that "they" (the corporate IT department) haven't "verified".

Thus, you've just turned a technical problem into a political one for me--how to "fix" my machine without breaking my conditions of employment.

Are there any "current" drivers which work? If not, what is the "most current" driver that works? I will need to call IT and get permission to install them, but there is a chance for that to be allowed, particularly if it is a current driver (and not an older one).

The machine in question is a thinkpad T42p (and the wireless card, is that standard one that IBM built into such units).

However, if the problem is just ipconfig not working (e.g. not displaying the information). Is there another workaround possible? Can I get the relevant information another way?

As I said, using access connections I get a connection and within that program I can see the various addresses (well, I didn't find the DNS server addresses, but I did find the addresses I previously displayed). Moreover, I *always* use access connections, someone (IBM? the IT department?) built turning it on into the laptop boot procedure--access conections (and perhaps a new driver) was part of a recent patch applied to the machine (automatically, by the IT program that keeps our machines "in spec").

Therefore, I don't care very much if ipconfig is broken, except as it relates to tracking down the mysterious problem of sometimes losing connectivity, which if I recall correctly predates ipconfig being broken (as I knew it worked at one time, since I used to use a perl script that ran ipconfig and grepped the address to determine whether my laptop was at home or at work).

On a related note, if there is some problem with the drivers, and you have information that I should pass along, I can see if I can do that--I don't know if I will be able to find the right people to pass it along to, but I will try. We do try to "eat our own dog food" and thus force ourselves to fix the problems that we have created.

Thanks,

-Chris

Note: Nothing is this email should be construed as coming from Intel or as any kind of official announcement or committment. They are simply the private opinions of the author.

Then make it their problem. Your employer is paying these clowns to solve problems.

Um... how bout engaging that IT department whose responsibility it is for ensuring you have a functioning laptop?

John's a helpful kinda guy. If you think he's holding onto alternate workaround info and nost posting it to the FAQ just to spite Intel employees, well...

Suddenly you sound like an immense pain in the ass that I'm personally not that interested in helping.

Open an helpdesk ticket with your IT department. If their policies prevent you from working around the issue, then a fix needs to come from them. If your it department is as clueful as the one I have to use on similar issues, I bid you good luck.

Best Regards,

On Thu, 15 Mar 2007 11:29:16 -0400, Chris F Clark wrote in :

This is covered in the thread I referred you to. My work-arounds (as distinct from my fix) _don't_ require messing with the driver. Among other things, you can simply disable and re-enable the device in hardware manager to run IPCONFIG -- just do it before the auto-disable kicks back in.

How about encouraging the folks in your company to fix their driver problem? Trying to get them to take notice of this issue has been futile and frustrating for me -- your company seems uninterested in bug reports to the point of making it very difficult to submit them (reminding me of former arrogance I thought it had put behind it).

This is also covered in the thread I referred you to. The problem seems to have been introduced in Version 8 drivers, so any prior Version should do.

The IPCONFIG problem comes from the _wired_ adapter. This is also covered in the thread I referred you to.

Again, this is covered in the thread I referred you to. Use one of my work-arounds.

And that's the point.

Once you've got IPCONFIG working, also try the script at .

I'd be happy to do that myself if you can give me some idea of who to contact or otherwise how to go about it. Try to find out who is responsible for (cares about) your wired Ethernet chipset drivers.

Ok, sorry, maybe I didn't read enough of the thread. When I used google to view the thread, it only showed me three postings, and they seemded all to be about rolling back the driver. I will go and look again.

Yes, this seems like the right solution long term. I will try to find you the right people to get the bug report noticed. I don't know if I will have any better luck getting them to notice, but I will try.

-Chris

snipped-for-privacy@toddh.net (Todd H.) writes

Agreed. John is a helpful guy. And apparently, there was more to the referenced thread than I found on Google by following the link. I don't think he was intentionally hiding something from me (or Intel employees or anyone else for that matter--doing so makes little sense). However, I didn't see that additional information and wrongly assumed that it wasn't there. That was my error. I will look again.

I would love to make it IT's problem. However, the reality of big company politics is that these guys aren't getting paid to solve problems, they're paid to enforce rules, rules that they write for their own convenience.

Thus, whether my home network is convenient for me to work at home is not something they care very much about (as a group--I can often find sympathetic members of the group that are helpful). As a comparative example, it took six weeks (and numerous interventions by my management) to get a version of vtune (an Intel developed product) installed on a linux system, so that I could do measurements of performance of a specific application I was tasked by my management to investigate (for a "high priority" project), because the request was not a "standard" one and the IT guy who was assigned that responsibility hid behind the regulations rather than simply running the script (which took me all of 5 minutes to do on my home linux system--it didn't take him significantly longer than that). Thus, you might excuse the fact, that I don't think making it IT's problem is going to get my issue resolved.

I don't expect any of the IP guys to come out and diagnose my home network and its interference problem. Nor, do I expect John or you to do so either. However, I don't know how to diagnose interference problems. Moreover, if this problem is an interference problem, as John suggested, then whether my laptop runs ipconfig or not, may or may not be relevant to the interference. I presume the interference isn't coming from ipconfg, which is why I asked if there was another way to get the relevant information, so that I wouldn't be stuck waiting for ipconfig to get fixed. However, it appears that I simply missed some of the thread which would have contained relevant information, and that is my fault.

Therefore, I am going to try to figure out who needs to be prodded to get the wired ethernet drivers fixed. I'm going to do that, because it is the right thing to do.

In the meantime, I have investigated and I am running version 8.0.57.0 of the wired ethernet adapters. Moreover, ipconfig does work when I first boot the machine, which all matches John's description. I will see if I can roll back the wired driver or use one of the other workarounds in the thread that I missed. (Reporting what it is currently saying is not relevant though, as my laptop and I are at work and not home and I know the addresses are different, and I'm not using wireless while sitting at my desk at work.)

I don't mean to be a pain-in-the-ass. I'm simply an individual who is trying to solve his own problem, and doing so with the little knowledge he possesses, augmented by what info he can cajole out of other sources. However, thank you for the insight, as being perceived as a p-i-a is not useful for me getting further help.

In any case, if you have further problems with my attitude, perhaps we should take them to email (last I checked my address was not obfuscated), as I don't see that airing our dirty laundry is that useful to the rest of the group...

Ok, here are annotated listings of the information I could get back.

First, before applying the workaround:

==>Microsoft Windows XP [Version 5.1.2600] ==>(C) Copyright 1985-2001 Microsoft Corp. ==>

==>C:\\Documents and Settings\\cfclark>ipconfig /all ==>

==>Windows IP Configuration ==>

==>An internal error occurred: A device attached to the system is not functioning. ==>

==>Please contact Microsoft Product Support Services for further help. ==>

==>Additional information: Unknown media status code. ==>

After applying the workaround where I disabled the wired connection in the device manager, and before I turned the vpn connection on.

Note: I couldn't find the "routing and remote access service" so I couldn't try that workaround. However, this workaround worked.

==>C:\\Documents and Settings\\cfclark>ipconfig /all ==>

==>Windows IP Configuration ==>

==> Host Name . . . . . . . . . . . . : hdxpl1030 ==> Primary Dns Suffix . . . . . . . : amr.corp.intel.com ==> Node Type . . . . . . . . . . . . : Peer-Peer ==> IP Routing Enabled. . . . . . . . : No ==> WINS Proxy Enabled. . . . . . . . : No ==> DNS Suffix Search List. . . . . . : amr.corp.intel.com ==> corp.intel.com ==> intel.com ==>

==>Ethernet adapter Wireless Network Connection 5: ==>

==> Connection-specific DNS Suffix . : ==> Description . . . . . . . . . . . : 11a/b/g Wireless LAN Mini PCI Adapte ==>r ==> Physical Address. . . . . . . . . : 00-05-4E-51-16-9D ==> Dhcp Enabled. . . . . . . . . . . : Yes ==> Autoconfiguration Enabled . . . . : No ==> IP Address. . . . . . . . . . . . : 192.168.1.105 ==> Subnet Mask . . . . . . . . . . . : 255.255.255.0 ==> Default Gateway . . . . . . . . . : 192.168.1.1 ==> DHCP Server . . . . . . . . . . . : 192.168.1.1 ==> DNS Servers . . . . . . . . . . . : 66.189.0.29 ==> 66.189.0.30 ==> 66.189.0.5 ==> Lease Obtained. . . . . . . . . . : Thursday, March 15, 2007 5:08:12 PM ==> Lease Expires . . . . . . . . . . : Friday, March 16, 2007 5:08:12 PM ==>

==>Ethernet adapter Local Area Connection 2: ==>

==> Connection-specific DNS Suffix . : ==> Description . . . . . . . . . . . : VPN Client Virtual Adapter ==> Physical Address. . . . . . . . . : 00-C0-45-00-00-01 ==> Dhcp Enabled. . . . . . . . . . . : Yes ==> Autoconfiguration Enabled . . . . : No ==> IP Address. . . . . . . . . . . . : 0.0.0.0 ==> Subnet Mask . . . . . . . . . . . : 0.0.0.0 ==> Default Gateway . . . . . . . . . : ==> DHCP Server . . . . . . . . . . . : 255.255.255.255 ==>

Next, after I turned VPN on: Note at this point, I still had no problem.

==>C:\\Documents and Settings\\cfclark>ipconfig /all ==>

==>Windows IP Configuration ==>

==> Host Name . . . . . . . . . . . . : hdxpl1030 ==> Primary Dns Suffix . . . . . . . : amr.corp.intel.com ==> Node Type . . . . . . . . . . . . : Peer-Peer ==> IP Routing Enabled. . . . . . . . : No ==> WINS Proxy Enabled. . . . . . . . : No ==> DNS Suffix Search List. . . . . . : amr.corp.intel.com ==> hd.intel.com ==> corp.intel.com ==> intel.com ==>

==>Ethernet adapter Wireless Network Connection 5: ==>

==> Connection-specific DNS Suffix . : ==> Description . . . . . . . . . . . : 11a/b/g Wireless LAN Mini PCI Adapte ==>r ==> Physical Address. . . . . . . . . : 00-05-4E-51-16-9D ==> Dhcp Enabled. . . . . . . . . . . : Yes ==> Autoconfiguration Enabled . . . . : No ==> IP Address. . . . . . . . . . . . : 192.168.1.105 ==> Subnet Mask . . . . . . . . . . . : 255.255.255.0 ==> Default Gateway . . . . . . . . . : 192.168.1.1 ==> DHCP Server . . . . . . . . . . . : 192.168.1.1 ==> DNS Servers . . . . . . . . . . . : 66.189.0.29 ==> 66.189.0.30 ==> 66.189.0.5 ==> Lease Obtained. . . . . . . . . . : Thursday, March 15, 2007 5:08:12 PM ==> Lease Expires . . . . . . . . . . : Friday, March 16, 2007 5:08:12 PM ==>

==>Ethernet adapter Local Area Connection 2: ==>

==> Connection-specific DNS Suffix . : hd.intel.com ==> Description . . . . . . . . . . . : VPN Client Virtual Adapter ==> Physical Address. . . . . . . . . : 00-C0-45-00-00-01 ==> Dhcp Enabled. . . . . . . . . . . : Yes ==> Autoconfiguration Enabled . . . . : No ==> IP Address. . . . . . . . . . . . : 10.127.52.101 ==> Subnet Mask . . . . . . . . . . . : 255.255.252.0 ==> Default Gateway . . . . . . . . . : 10.127.52.101 ==> DHCP Server . . . . . . . . . . . : 10.127.52.15 ==> DNS Servers . . . . . . . . . . . : 10.127.1.11 ==> 146.152.3.1 ==> Primary WINS Server . . . . . . . : 143.182.250.105 ==> Secondary WINS Server . . . . . . : 134.134.128.37 ==> Lease Obtained. . . . . . . . . . : Thursday, March 15, 2007 5:11:49 PM ==> Lease Expires . . . . . . . . . . : Friday, March 14, 2008 5:11:49 PM ==>

Now, I took the laptop up to the office and put it in its docking station and the connection "broke". Notice, how the ipconfig is now dead.

==>C:\\Documents and Settings\\cfclark>ipconfig /all ==>

==>Windows IP Configuration ==>

==>An internal error occurred: The handle is invalid. ==>

==>Please contact Microsoft Product Support Services for further help. ==>

==>Additional information: Unknown media status code. ==>

However, I'm not certain if this is an example of the problem, or simply an artifact of going from undocked to docked. Therefore, I did some more snooping. (Subsequent passage of time with no more problems, suggest this is NOT the repetitive connection loss problem, and in fact perhaps simply a docking issue.)

So, I looked at the devices, and now the wireless card was disabled and the wired card was enabled. (I don't know how to capture that.) I didn't do that. I presume something with docking caused it. I then tried all the permutations of enabling and disabling the cards to see if that would "fix" the problem, but to no avail.

==>C:\\Documents and Settings\\cfclark>ipconfig /all ==>

==>Windows IP Configuration ==>

==>An internal error occurred: The handle is invalid. ==>

==>Please contact Microsoft Product Support Services for further help. ==>

==>Additional information: Unknown media status code. ==>

==>C:\\Documents and Settings\\cfclark>ipconfig /all ==>

==>Windows IP Configuration ==>

==>An internal error occurred: The handle is invalid. ==>

==>Please contact Microsoft Product Support Services for further help. ==>

==>Additional information: Unknown media status code. ==>

==>C:\\Documents and Settings\\cfclark>ipconfig /all ==>

==>Windows IP Configuration ==>

==>An internal error occurred: The handle is invalid. ==>

==>Please contact Microsoft Product Support Services for further help. ==>

==>Additional information: Unknown media status code. ==>

==>C:\\Documents and Settings\\cfclark>ipconfig /all ==>

==>Windows IP Configuration ==>

==>An internal error occurred: The handle is invalid. ==>

==>Please contact Microsoft Product Support Services for further help. ==>

==>Additional information: Unknown media status code. ==>

==>C:\\Documents and Settings\\cfclark>ipconfig /all ==>

==>Windows IP Configuration ==>

==>An internal error occurred: The handle is invalid. ==>

==>Please contact Microsoft Product Support Services for further help. ==>

==>Additional information: Unknown media status code. ==>

I then reconnected VPN, and reread your posting. I don't surf or read news or mail from my laptop. I only surf from my desktop. Thus, I needed to fix the connection to see what other info to gather.

I saw you wanted to see the results of pinging a DNS server outside the VPN connection. Note, these pings occurred after I fixed the VPN connection.

==>C:\\Documents and Settings\\cfclark>ping 66.189.0.29 ==>

==>Pinging 66.189.0.29 with 32 bytes of data: ==>

==>Request timed out. ==>Request timed out. ==>Request timed out. ==>Request timed out. ==>

==>Ping statistics for 66.189.0.29: ==> Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), ==>

As, you can see, I can't see anything outside the VPN network from the laptop. I then tried one of the DNS servers within the VPN. That worked, as I would have expected.

==>C:\\Documents and Settings\\cfclark>ping 10.127.1.11 ==>

==>Pinging 10.127.1.11 with 32 bytes of data: ==>

==>Reply from 10.127.1.11: bytes=32 time=42ms TTL=60 ==>Reply from 10.127.1.11: bytes=32 time=36ms TTL=60 ==>Reply from 10.127.1.11: bytes=32 time=29ms TTL=60 ==>Reply from 10.127.1.11: bytes=32 time=28ms TTL=60 ==>

==>Ping statistics for 10.127.1.11: ==> Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), ==>Approximate round trip times in milli-seconds: ==> Minimum = 28ms, Maximum = 42ms, Average = 33ms ==>

==>C:\\Documents and Settings\\cfclark>

I don't know if this provides any useful information to you. I hope it does. I next have to figure out how to get the error logs off my router....

Thanks,

-Chris

On Thu, 15 Mar 2007 18:55:51 -0400, Chris F Clark wrote in :

What we need is comparative IPCONFIG information when you lose connectivity.

Here is an anotated seesion before and during the problem occurring. (In fact the problem is occuring right now, although obvilously I can "work through" the problem by simply keeping opening and closing the RDP window. Closing the RDP window, waiting a bit and reopening it, seems to correct the problem.)

Ok, here is the setting right after I booted the computer.

==>C:\\Documents and Settings\\cfclark>ipconfig /all ==> ==>Windows IP Configuration ==>

==> Host Name . . . . . . . . . . . . : hdxpl1030 ==> Primary Dns Suffix . . . . . . . : amr.corp.intel.com ==> Node Type . . . . . . . . . . . . : Peer-Peer ==> IP Routing Enabled. . . . . . . . : No ==> WINS Proxy Enabled. . . . . . . . : No ==> DNS Suffix Search List. . . . . . : amr.corp.intel.com ==> hd.intel.com ==> corp.intel.com ==> intel.com ==>

==>Ethernet adapter Local Area Connection 6: ==>

==> Connection-specific DNS Suffix . : ==> Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Mobile Connecti ==>on ==> Physical Address. . . . . . . . . : 00-D0-59-33-EB-75 ==> Dhcp Enabled. . . . . . . . . . . : Yes ==> Autoconfiguration Enabled . . . . : No ==> IP Address. . . . . . . . . . . . : 192.168.1.106 ==> Subnet Mask . . . . . . . . . . . : 255.255.255.0 ==> Default Gateway . . . . . . . . . : 192.168.1.1 ==> DHCP Server . . . . . . . . . . . : 192.168.1.1 ==> DNS Servers . . . . . . . . . . . : 66.189.0.29 ==> 66.189.0.30 ==> 66.189.0.5 ==> Lease Obtained. . . . . . . . . . : Friday, March 16, 2007 6:03:10 PM ==> Lease Expires . . . . . . . . . . : Saturday, March 17, 2007 6:03:10 PM ==>

==>Ethernet adapter Local Area Connection 2: ==>

==> Connection-specific DNS Suffix . : hd.intel.com ==> Description . . . . . . . . . . . : VPN Client Virtual Adapter ==> Physical Address. . . . . . . . . : 00-C0-45-00-00-01 ==> Dhcp Enabled. . . . . . . . . . . : Yes ==> Autoconfiguration Enabled . . . . : No ==> IP Address. . . . . . . . . . . . : 10.127.56.148 ==> Subnet Mask . . . . . . . . . . . : 255.255.252.0 ==> Default Gateway . . . . . . . . . : 10.127.56.148 ==> DHCP Server . . . . . . . . . . . : 10.127.56.16 ==> DNS Servers . . . . . . . . . . . : 10.127.1.11 ==> 146.152.3.1 ==> Primary WINS Server . . . . . . . : 134.134.128.37 ==> Secondary WINS Server . . . . . . : 143.182.250.105 ==> Lease Obtained. . . . . . . . . . : Friday, March 16, 2007 6:05:43 PM ==> Lease Expires . . . . . . . . . . : Saturday, March 15, 2008 6:05:43 PM ==>

I then tried pinging the various DNS servers listed. First the ones outside VPN, which were inaaccessible.

==>C:\\Documents and Settings\\cfclark>ping 66.189.0.29 ==>

==>Pinging 66.189.0.29 with 32 bytes of data: ==>

==>Request timed out. ==>Request timed out. ==>Request timed out. ==>Request timed out. ==>

==>Ping statistics for 66.189.0.29: ==> Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), ==>

==>C:\\Documents and Settings\\cfclark>ping 66.189.0.30 ==>

==>Pinging 66.189.0.30 with 32 bytes of data: ==>

==>Request timed out. ==>Request timed out. ==>Request timed out. ==>Request timed out. ==>

==>Ping statistics for 66.189.0.30: ==> Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), ==>

==>C:\\Documents and Settings\\cfclark>ping 66.189.0.05 ==>

==>Pinging 66.189.0.5 with 32 bytes of data: ==>

==>Request timed out. ==>Request timed out. ==>Request timed out. ==>Request timed out. ==>

==>Ping statistics for 66.189.0.5: ==> Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), ==>

Now, nmy local router. It's not a DNS server, but I would expect it to be accessible.

==>C:\\Documents and Settings\\cfclark>ping 192.168.1.100 ==>

==>Pinging 192.168.1.100 with 32 bytes of data: ==>

==>Reply from 192.168.1.100: bytes=32 time=37ms TTL=64 ==>Reply from 192.168.1.100: bytes=32 time=2ms TTL=64 ==>Reply from 192.168.1.100: bytes=32 time=2ms TTL=64 ==>Reply from 192.168.1.100: bytes=32 time=3ms TTL=64 ==>

==>Ping statistics for 192.168.1.100: ==> Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), ==>Approximate round trip times in milli-seconds: ==> Minimum = 2ms, Maximum = 37ms, Average = 11ms ==>

Now, the DNS servers inside VPN. They are accessible.

==>C:\\Documents and Settings\\cfclark>ping 10.127.1.11 ==>

==>Pinging 10.127.1.11 with 32 bytes of data: ==>

==>Reply from 10.127.1.11: bytes=32 time=37ms TTL=60 ==>Reply from 10.127.1.11: bytes=32 time=35ms TTL=60 ==>Reply from 10.127.1.11: bytes=32 time=32ms TTL=60 ==>Reply from 10.127.1.11: bytes=32 time=34ms TTL=60 ==>

==>Ping statistics for 10.127.1.11: ==> Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), ==>Approximate round trip times in milli-seconds: ==> Minimum = 32ms, Maximum = 37ms, Average = 34ms ==>

==>C:\\Documents and Settings\\cfclark>ping 146.152.3.1 ==>

==>Pinging 146.152.3.1 with 32 bytes of data: ==>

==>Reply from 146.152.3.1: bytes=32 time=63ms TTL=58 ==>Reply from 146.152.3.1: bytes=32 time=49ms TTL=58 ==>Request timed out. ==>Reply from 146.152.3.1: bytes=32 time=35ms TTL=58 ==>

==>Ping statistics for 146.152.3.1: ==> Packets: Sent = 4, Received = 3, Lost = 1 (25% loss), ==>Approximate round trip times in milli-seconds: ==> Minimum = 35ms, Maximum = 63ms, Average = 49ms ==>

Now, here I am having trouble. However, I don't see anything different in the ipconfig information.

==>C:\\Documents and Settings\\cfclark>ipconfig /all ==>

==>Windows IP Configuration ==>

==> Host Name . . . . . . . . . . . . : hdxpl1030 ==> Primary Dns Suffix . . . . . . . : amr.corp.intel.com ==> Node Type . . . . . . . . . . . . : Peer-Peer ==> IP Routing Enabled. . . . . . . . : No ==> WINS Proxy Enabled. . . . . . . . : No ==> DNS Suffix Search List. . . . . . : amr.corp.intel.com ==> hd.intel.com ==> corp.intel.com ==> intel.com ==>

==>Ethernet adapter Local Area Connection 6: ==>

==> Connection-specific DNS Suffix . : ==> Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Mobile Connecti ==>on ==> Physical Address. . . . . . . . . : 00-D0-59-33-EB-75 ==> Dhcp Enabled. . . . . . . . . . . : Yes ==> Autoconfiguration Enabled . . . . : No ==> IP Address. . . . . . . . . . . . : 192.168.1.106 ==> Subnet Mask . . . . . . . . . . . : 255.255.255.0 ==> Default Gateway . . . . . . . . . : 192.168.1.1 ==> DHCP Server . . . . . . . . . . . : 192.168.1.1 ==> DNS Servers . . . . . . . . . . . : 66.189.0.29 ==> 66.189.0.30 ==> 66.189.0.5 ==> Lease Obtained. . . . . . . . . . : Saturday, March 17, 2007 6:03:10 PM ==> Lease Expires . . . . . . . . . . : Sunday, March 18, 2007 6:03:10 PM ==>

==>Ethernet adapter Local Area Connection 2: ==>

==> Connection-specific DNS Suffix . : hd.intel.com ==> Description . . . . . . . . . . . : VPN Client Virtual Adapter ==> Physical Address. . . . . . . . . : 00-C0-45-00-00-01 ==> Dhcp Enabled. . . . . . . . . . . : Yes ==> Autoconfiguration Enabled . . . . : No ==> IP Address. . . . . . . . . . . . : 10.127.56.148 ==> Subnet Mask . . . . . . . . . . . : 255.255.252.0 ==> Default Gateway . . . . . . . . . : 10.127.56.148 ==> DHCP Server . . . . . . . . . . . : 10.127.56.16 ==> DNS Servers . . . . . . . . . . . : 10.127.1.11 ==> 146.152.3.1 ==> Primary WINS Server . . . . . . . : 143.182.250.105 ==> Secondary WINS Server . . . . . . : 134.134.128.37 ==> Lease Obtained. . . . . . . . . . : Friday, March 16, 2007 6:05:43 PM ==> Lease Expires . . . . . . . . . . : Saturday, March 15, 2008 6:05:43 PM ==>

==>C:\\Documents and Settings\\cfclark>ping 66.189.0.29 ==>

==>Pinging 66.189.0.29 with 32 bytes of data: ==>

==>Request timed out. ==>Request timed out. ==>Request timed out. ==>Request timed out. ==>

==>Ping statistics for 66.189.0.29: ==> Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), ==>

==>C:\\Documents and Settings\\cfclark>ping 66.189.0.05 ==>

==>Pinging 66.189.0.5 with 32 bytes of data: ==>

==>Request timed out. ==>Request timed out. ==>Request timed out. ==>Request timed out. ==>

==>Ping statistics for 66.189.0.5: ==> Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), ==>

==>C:\\Documents and Settings\\cfclark>ping 192.168.1.100 ==>

==>Pinging 192.168.1.100 with 32 bytes of data: ==>

==>Reply from 192.168.1.100: bytes=32 time=56ms TTL=64 ==>Reply from 192.168.1.100: bytes=32 time=4ms TTL=64 ==>Reply from 192.168.1.100: bytes=32 time=2ms TTL=64 ==>Reply from 192.168.1.100: bytes=32 time=3ms TTL=64 ==>

==>Ping statistics for 192.168.1.100: ==> Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), ==>Approximate round trip times in milli-seconds: ==> Minimum = 2ms, Maximum = 56ms, Average = 16ms ==>

==>C:\\Documents and Settings\\cfclark>ping 10.127.1.11 ==>

==>Pinging 10.127.1.11 with 32 bytes of data: ==>

==>Reply from 10.127.1.11: bytes=32 time=29ms TTL=60 ==>Reply from 10.127.1.11: bytes=32 time=28ms TTL=60 ==>Reply from 10.127.1.11: bytes=32 time=31ms TTL=60 ==>Reply from 10.127.1.11: bytes=32 time=31ms TTL=60 ==>

==>Ping statistics for 10.127.1.11: ==> Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), ==>Approximate round trip times in milli-seconds: ==> Minimum = 28ms, Maximum = 31ms, Average = 29ms ==>

==>Ping statistics for 147.152.3.1: ==> Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), ==>

==>C:\\Documents and Settings\\cfclark>ping 146.152.3.1 ==>

==>Pinging 146.152.3.1 with 32 bytes of data: ==>

==>Reply from 146.152.3.1: bytes=32 time=34ms TTL=58 ==>Reply from 146.152.3.1: bytes=32 time=35ms TTL=58 ==>Reply from 146.152.3.1: bytes=32 time=49ms TTL=58 ==>Request timed out. ==>

==>Ping statistics for 146.152.3.1: ==> Packets: Sent = 4, Received = 3, Lost = 1 (25% loss), ==>Approximate round trip times in milli-seconds: ==> Minimum = 34ms, Maximum = 49ms, Average = 39ms ==>

==>C:\\Documents and Settings\\cfclark>

The trouble has continued overnight. Again, the prmary visible symptom is there is this "icon" that pops up in the RDP window that means that the RDP connection is "lost". If I close, the window, let it sit for a few seconds, and reopen it, it will generally come back. If I don't close and reopen the window, but let it stay "diswconnected" the VPN connection will eventually time out, say after about 5 minuntes, and I'll have to reconnect VPN (and reenter the security information).

Often when this occurs, if my wife is on the internet on her laptop also, she'll say that her internet connection (e.g. to hotmail) will get dropped at the same time.

The distinctive feature of this problem is its "regularity". Once, it starts, it appears to repeat on regular intervals. For example, if I'm down with my laptop, but watching TV, it appears that this problem will occur between each and every station break.

I still don't know what I'm looking for as a cause.

Thanks,

-Chris

On the problem with the latest Intel PRO wired ethernet drivers not disabling themselves properly and breaking "ipconfig all":

I have gotten some support from the Intel IT department (one of the techs who I know cares--I've dealt with him before), and I have explained the problem. From him I have some patches to try (always try the canned solutions first), because I can't connect wirelessly at work at all (and the ipconfig problem doesn't manifest itself if one is connecting using only the wired connection). I don't know yet if those patches will end up rolling back my wired driver or not.

If they do not roll back the driver and I can demonstrate the problem, then he will try to help me determine how to get it fixed. However, he said that he did not know how to find which group in Intel is responsible for the wired ethernet drivers. Hopefully, if we can escalate the problem appropriately, we will find the right group to fix it.

Thus, I still cannot promise that the wired drivers will ever get fixed, but I am trying to make that happen.

(And then hopefully, we can get back to my problem of the mysterious repeating "interference".)

Chris

On Fri, 23 Mar 2007 18:03:14 -0400, Chris F Clark wrote in :

Sounds like you are making some progress. It's just unfortunate, sad and frustrating that it's so hard to get companies like Intel to take notice of problems in their products. It inevitably makes me less likely to use and recommend them.

Of course, it isn't a problem unique to Intel (or large companies in general). However, large companies often develop bureaucracies where such problems proliferate, since often it isn't "locally" optimum to be accountable and responsible. I don't have a good solution to that problem, and even if I thought I did, it wouldn't be on topic in this group. It is still frustrating....

On Thu, 29 Mar 2007 12:23:18 -0400, Chris F Clark wrote in :

True, but Intel is the only company I know of that has this particular issue, and it has so much presence in the market that the issue is significant. It's not only a matter of respect for the customer, it's a matter of corporate responsibility.