AOA Forums AOA Forums AOA Forums Folding For Team 45 AOA Files Home Front Page Become an AOA Subscriber! UserCP Calendar Memberlist FAQ Search Forum Home


Go Back   AOA Forums > Hardware > Mobile Devices and Networking


Reply
 
LinkBack Thread Tools Rate Thread
  #1 (permalink)  
Old 24th May, 2005, 07:24 PM
Chief Systems Administrator
 
Join Date: September 2001
Location: Europe
Posts: 13,075

Issues with XP and path MTU discovery

Come across an odd issue that I've not seen before, and I'm not sure why it's happening.

Basically, a friend bought a new machine, and added it to their network. Generally everything works as expected, except that trying to FTP files up to an FTP site tends to just hang. They come down just fine, but putting them up results in the transfer starting, and then hanging after a few hundred bytes have been sent.

Initially, they were blaming it on their new router (AKA NAT device). However, the fact that other machines can upload via FTP rules that out to a certain extent.

After doing a packet dump, I found that the machine was doing path MTU discovery (IE, sending packets with the DNF flag set), but totally ignoring the ICMP errors that were coming back indicating that the packet couldn't be fragmented.

Now, I've no idea why the machine is behaving this way. It's XP SP2 preinstalled by Mesh. For the time being, I've applied a workaround in the form of limiting the MTU. However, I'm concerned that the machine can't do path MTU discovery properly.

Suggestions?
__________________
Any views, thoughts and opinions are entirely my own. They don't necessarily represent those of my employer (BlackBerry).
Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #2 (permalink)  
Old 24th May, 2005, 07:35 PM
Member/Contributor/Resident Crystal Ball
 
Join Date: March 2004
Posts: 7,451

First thing would be signal strength to me, and the load on the NAT device. Could be something as stupid as a bad port. Make sure windows firewall service is off as well.
__________________
Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #3 (permalink)  
Old 24th May, 2005, 08:00 PM
Chief Systems Administrator
 
Join Date: September 2001
Location: Europe
Posts: 13,075

It's wired.

The NAT device isn't loaded. It's working correctly, as it's responding to the path MTU discovery correctly by replying with ICMP unreach messages indicating the packet needs fragmenting and the do not fragment flag is set.

Windows firewall service makes no difference if disabled or enabled.

From sniffing the wire, it's definately a Windows issues, but I cannot figure out why Win XP is attempting to do path MTU discovery, and then ignoring the messages indicating it needs to use a smaller MTU.
__________________
Any views, thoughts and opinions are entirely my own. They don't necessarily represent those of my employer (BlackBerry).
Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #4 (permalink)  
Old 24th May, 2005, 08:07 PM
Member/Contributor/Resident Crystal Ball
 
Join Date: March 2004
Posts: 7,451

Quote:

There is no ability to configure the maximum transmission unit (MTU) of the PPPoE connection from the properties of the connection. By default, a Windows XP PPPoE connection uses an MTU size that is 20 bytes less than the IP MTU of the LAN adapter over which the PPPoE packets are sent, which in most cases is 1480 bytes. The 20 bytes of overhead consist of the PPPoE header (6 bytes), the largest possible outer PPP header (4 bytes), the largest possible Multilink PPP header (4 bytes), the largest possible PPP header for compression and encryption (4 bytes), and the PPP header that identifies the actual packet being sent (2 bytes).


If a lower MTU is required, then do one of the following:


•Instruct your ISP to configure their access devices to negotiate a lower MTU using the PPP maximum receive unit (MRU) option. This the recommended solution.


•Or, manually change the MTU size for all non-VPN miniports by setting the following registry values on the computer running Windows XP. (This will change the MTU size for the Windows XP PPPoE miniport.) Change:


HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\NdisWan\Parameters\Protocols\0\ProtocolType to 0x0800.


HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\NdisWan\Parameters\Protocols\0\PPPProtocolType to 0x0021.


HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\NdisWan\Parameters\Protocols\0\ProtocolMTU to the required MTU size. PPPoE will use the lesser of this value and the default (the LAN adapter MTU less 20).
(The second solution is not recommended because it affects the MTU used by all miniports except the built-in VPN miniports.)

-http://www.microsoft.com/windowsxp/using/networking/learnmore/ppoe.mspx

Make sure that QOS packet scheduler is not associated with the lan or dial-up connections as well.

Just seems that XP is sometimes stupid when it comes to these issues, and hence the need for a network tech for larger networks...wonder why that is?

i've got a site that i regualrly use for netwrok issues, i'll have to dig up the scrap of paper, as i tend to not deal with issues like this very often.
__________________
Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #5 (permalink)  
Old 24th May, 2005, 08:10 PM
Chief Systems Administrator
 
Join Date: September 2001
Location: Europe
Posts: 13,075

It's an ATM link, so there's no issues with anything as ugly as PPPoE. PPPoE has some issues with MTU due to it's backwards design.

The issue is that XP is attempting to do path MTU discovery and then breaking, despite the fact that the router responds correctly. If the router didn't respond correctly, I'd chalk it up to black hole router syndrome, but I can see it's not that.
__________________
Any views, thoughts and opinions are entirely my own. They don't necessarily represent those of my employer (BlackBerry).
Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #6 (permalink)  
Old 24th May, 2005, 08:14 PM
Chief Systems Administrator
 
Join Date: September 2001
Location: Europe
Posts: 13,075

Also, the fact that the machine is failing to do path MTU discovery means that some sites on the internet will not be accessible. A machine running PPPoE cannot discover it's own maximum MTU, but can do path MTU discovery.
__________________
Any views, thoughts and opinions are entirely my own. They don't necessarily represent those of my employer (BlackBerry).
Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #7 (permalink)  
Old 24th May, 2005, 08:34 PM
Member/Contributor/Resident Crystal Ball
 
Join Date: March 2004
Posts: 7,451

DSL? If it is, this is just one of those things that happens. Some cisco router in the query route is not set up properly.

Quote:
Some network and system administrators view all ICMPs as risky and block them all, disabling path MTU discovery, usually without even realizing it. Of the several dozen ICMP types and subtypes, some do pose some risk, but the risk is mostly mild and is of the "denial of service" nature. That is, an attacker can use them to interfere with service on and from the network.

By blocking all ICMPs the administrator himself interferes with service on and from his own network. Unless he also turns off path MTU discovery on his network's servers, he makes his servers unusable by users with reduced-MTU links in their paths. Because service is affected only in relatively unusual cases, it can be difficult to convince the administrator that a problem exists. The prevalence of such "unusual" cases is growing rapidly though.
it was this that made me say turn off the xp firewall. i don't understand the why, but when there is some other sort of firewall in the local lan as well as the XP firewall, all sorts of weirdness pops up. I was getting an intermittent connection because of the same issue, and the same behavior, as you describe, because of this issue. And just in the same way, it was only one machine that was affected... i tried changing netwrok adapters, routers, reinstalling devices and sevices, even windows...and the same behavior would always come back within a few days. Turned off windows firewall, and bang, it works.
__________________
Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #8 (permalink)  
Old 24th May, 2005, 08:45 PM
Chief Systems Administrator
 
Join Date: September 2001
Location: Europe
Posts: 13,075

That would be nice, except that I can see the ICMP coming back, hence my comment about not being a black hole router. That's one of the reasons I used a packet sniffer to see what was happening at a layer 2 and 3 level. Applications rarely give you the information needed to troubleshoot this sort of problem.

At no point do I accept that, at a network level, it's "just one of those things that happens". DSL makes no odds, as it's just as valid as any other form of ATM connection. You can be sure that ATM works just fine, given the number of people using it.
__________________
Any views, thoughts and opinions are entirely my own. They don't necessarily represent those of my employer (BlackBerry).
Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #9 (permalink)  
Old 24th May, 2005, 08:58 PM
Member/Contributor/Resident Crystal Ball
 
Join Date: March 2004
Posts: 7,451

I understand what you are saying. Really. Check 4 spyware.

I dunno why, exactly, i had the issue. exact same symptoms as yours. the next machine, would work fine. switching ports made no difference. Could be the driver not allowing the MTU change.

Anyway, i don't have a definate answer...but i know i had the same issue, and got it sorted. Really was annoying, as i could not access one of the suppliers' i deal with website. i think i redid the netwrok set-up on the machine, after turning off windows firewall, and the issue disappeared.
__________________
Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #10 (permalink)  
Old 24th May, 2005, 09:05 PM
Chief Systems Administrator
 
Join Date: September 2001
Location: Europe
Posts: 13,075

It's specifically only applications that have large amounts of data to send that it affects. Normal web connectivity is just fine, so browsing and downloading works correctly. When large files need to be uploaded is when the issue appears.

FTP down works just fine, unsurprisingly.
__________________
Any views, thoughts and opinions are entirely my own. They don't necessarily represent those of my employer (BlackBerry).
Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #11 (permalink)  
Old 24th May, 2005, 09:15 PM
Member/Contributor/Resident Crystal Ball
 
Join Date: March 2004
Posts: 7,451

That's what made me think of the PPPoE problem...the server is set to 1460 max(1460, plus 40k header), but XP clent is set to 1500 + header. It keeps looking for the remaining fragment, and chaos ensues. Theere is a utility...checks this sort of thing, as it's an SP2 problem, i think.

http://alive.znep.com/~marcs/mtu/

http://www.eastserve.com/opencms/ope...pport/mtu.html

hope these may be of help.
__________________
Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #12 (permalink)  
Old 24th May, 2005, 09:22 PM
Chief Systems Administrator
 
Join Date: September 2001
Location: Europe
Posts: 13,075

There's a 40byte overhead for PPPoE, hence the problem with packets over 1460 bytes. This issue is caused by the fact that the local interface's maximum size is 1500 bytes, indicating that that would be a valid MTU. However, when the stack steps up to 1500 bytes packets, it never receives an ICMP unreachable back from any router, as the packets never actually left the interface as they couldn't be encapsulated with the PPP header. This is an issue with PPPoE generally. The fix is to reduce the MTU at the host, to ensure it never tries to send IP packets over 1460 bytes (which corresponds to 1500 byte ethernet frames). A server sending 1500 bytes packets shouldn't hit a problem, as the far end of the PPPoE tunnel should be able to generate the ICMP unreach messages.

The issue I am seeing is completely different, as there's no encapsulation going on. Additionally, a valid ICMP unreach message is being sent back in reply to the large packet with the DNF flag set, indicating that the machine is actually attempting to do path MTU discovery. These messages are seen going across the network, so we know that relatively normal IP over ethernet is occuring.
__________________
Any views, thoughts and opinions are entirely my own. They don't necessarily represent those of my employer (BlackBerry).
Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #13 (permalink)  
Old 24th May, 2005, 09:24 PM
Member/Contributor/Resident Crystal Ball
 
Join Date: March 2004
Posts: 7,451

Seems like you are able to trace the problem further and further. What did you have to limit the MTU to?
__________________
Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #14 (permalink)  
Old 24th May, 2005, 09:29 PM
Chief Systems Administrator
 
Join Date: September 2001
Location: Europe
Posts: 13,075

I just slapped it at 1400, and left the machine working. There's not a huge loss of throughput, but my concern is that the path MTU discovery isn't working properly. That will cause issues, as not all devices on the net are on the end of a path that supports 1400 byte packets.

In the case of PPPoE, it's not an issue, as a PPPoE machine's path MTU discovery works just fine once you get out of it's local interface.
__________________
Any views, thoughts and opinions are entirely my own. They don't necessarily represent those of my employer (BlackBerry).
Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
Reply



Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
having some ram issues bonesaw General Hardware Discussion 11 31st January, 2007 05:27 AM
The safe path... Daniel ~ Data Security 8 18th November, 2006 03:39 AM
Water Path? BobRoss Cooling & Temperature Monitoring 24 12th July, 2006 06:51 AM
ram issues Skiracing108 Graphics and Sound cards; Speakers and other Peripherals 4 28th May, 2005 04:58 AM
XP's path barneygumble742 OS, Software, Firmware, and BIOS 7 16th July, 2004 04:57 AM


All times are GMT +1. The time now is 01:53 PM.


Copyright ©2001 - 2010, AOA Forums
Don't Click Here Don't Click Here Either

Search Engine Friendly URLs by vBSEO 3.3.0