ok i follow the thread so his problem is the terminal server browser may i know if your terminal server is working properly or maybe your internet browser had proxy configuration again check if correct if you had a firewall maybe the problem is there, one more thing if you can ping your gateway which is your router IP there is no other reason why you could not browse to internet other than virus
yes sort off
internet-----(202.61.x.x)firewall/router(exchange,192.168.0.2)----(192.168.0.3)Terminal Server
Last edited by pvclink; July 18th, 2007 at 08:34 AM.
I went back out onsite to test an alternate NIC, 2nd Onboard NIC is disabled and not needed. Copy over IP Configuration and connect - exact same issue.
Sticking with my gut feeling and still focusing on the NICs i went into the adapter properties and checked the advanced tab and i found a couple of interesting values.
NIC (x2) - INTEL(R) Pro 1000 EB Network Connection with I/O Acceleration. Under the advanced tab i found these;
Offload Recieve IP Checksum
Offload Recieve TCP Checksum
Offload Transmit IP Checksum
Offload Transmit TCP Checksum
Offload TCP Segmentation
Each of these has a value of either ON|OFF and each was set to ON. I switched all of these options to OFF and hey presto. Web browsing clockwork and lights all started happening . Works with and without a public proxy server and uses the original configuration as wanted. Also, once these options were off the ethereal does not display any errors at all.
I have replicated this so it is definitely the problem. I will still post the ethereal logs shortly in both before and after.
Thanks for all your help with this guys, could not have done it without you
Ethereal logs attached in a zip file. 2x files one is with options ON and the other with options OFF. File name says it all. Extention is .txt but you know what you need to do to read it.
Anyway i would be interested for someone to elaborate on what actually is happening if anyone will look at it and can see the forest through the trees, as it were.
Again, thanks for all your help with this guys! Look forward to seeing you around the forums.
Anyway i would be interested for someone to elaborate on what actually is happening if anyone will look at it and can see the forest through the trees, as it were.
Well, I was waiting for someone else's interpretation of those dumps, but since some time has past and no replies .... I am going to go way out there and give my gut impression.
From the dumps it appears you ran Ethereal on the Terminal Server.
As I see it, it is going to be hard to diagnose the exact cause because of where the packets were captured from. My guess is a packet capture off a span port on a switch would have been a little more useful.
The checksum errors were merely a normal consequence of running Ethereal on the same machine with Offload Checksum enabled on the NIC. Ethereal is capturing the packets before the NIC establishes the checksum. This appears to be a known issue. ( Until now we did not know you were using a gigabyte NIC. )
So I am not sure that turning the checksum offloading had anything to do with the fix.
I think your main problem was what was eluded to earlier by morganlefay , namely MTU, et al, which is affected by your changing the setting for Offload TCP Segmentation to off.
My guess is the problem may have been incompatibility between the way the Terminal Server NIC handles TCP Segmentation and the way your switch ( apparently a Netgear ) and/or the Exchange Server NIC does.
I could be way off, I am no expert on this stuff.
Any any other ideas?
" And maddest of all, to see life as it is and not as it should be" --Miguel Cervantes
The checksum errors were merely a normal consequence of running Ethereal on the same machine with Offload Checksum enabled on the NIC. Ethereal is capturing the packets before the NIC establishes the checksum.
That makes sense.
I think your main problem was what was eluded to earlier by morganlefay , namely MTU, et al, which is affected by your changing the setting for Offload TCP Segmentation to off.
Ok.... so lets run with this. Firstly, there is no denying that the aforementioned NIC values were the cause of the problem. So, why is the NIC causing such an issue, and if indeed it is an MTU Setting, at what point is the problem occuring (where along the traffic route) and how can i modify the MTU settings.
It seems anyone guess at this stage, however i am happy to replicate problems and do some more diagnostics to figure it out - otherwise the old saying if it aint broke dont fix it comes to mind
Network load balancing, dynamic routing, or both are used. In this scenario, there are several possible routes to a destination that has MTUs that differ from the MTU of the sending subnet and that differ from each other. Therefore, changing the route of IP packets over time can produce several MTU updates for the destination address.
WORKAROUND
To work around this problem, set the default MTU size to the largest size that the routers can process. The actual MTU value that is required to work around this problem depends on the network configuration. However, an MTU value of 576 should help reduce the effect of the problem because routers on the Internet should be able to handle such packets without fragmentation. You must restart the computer for this registry change to take effect. For more information about how to change the MTU registry settings, click the following article numbers to view the articles in the Microsoft Knowledge Base:
120642 (http://support.microsoft.com/kb/120642/) TCP/IP and NBT configuration parameters for Windows 2000 or Windows NT
314053 (http://support.microsoft.com/kb/314053/) TCP/IP and NBT configuration parameters for Windows XP
Important Depending on the network configuration and typical networking applications used, setting a low default MTU value can cause the network performance to decrease.
however i am happy to replicate problems and do some more diagnostics to figure it out -
The only thing I can think of ( other then contacting the vendors ) is setting up four simultaneous packet captures, one on each server machine, one on each side of the switch. Then compare for discrepancies.
A Lot of trouble for something that is now working!
Just a couple of links I came across that may or may not help:
All equipment on the network must also support the larger frame size. When setting up Jumbo Frames on other network devices, be aware that different network devices calculate Jumbo Frame size differently. Some devices include the header information in the frame size while others do not. Intel adapters do not include header information in the frame size. When configuring Jumbo Frames on a switch, set the frame size four bytes higher for CRC, plus four bytes if you are using VLANs or QoS packet tagging.
" And maddest of all, to see life as it is and not as it should be" --Miguel Cervantes
Reply With Quote
. Works with and without a public proxy server and uses the original configuration as wanted. Also, once these options were off the ethereal does not display any errors at all. 
