Keeping connection bettween hosts always alive

Discussion in 'Networking Issues' started by wonderwall, Jan 19, 2005.

  1. wonderwall

    wonderwall Network Guru Member

    Hi all; I do need some help on setting up MTU value in my WRT54G cause I need w98 SE desktop to print wirelessly.

    I´ve got a wireless print server I´d like to print trough it... via LPR printing
    cause this wireless print server has this topic.. I´m nearly to do it.... from a w98 Se desktop.
    I had to add LPR protocol on my w98 system.... I did it with ACITS LPR software from Texas University It works great.... but I cannot print text
    I mean.. text files bigger than 0,5 mb. I can print images bigger than that but not text files... It´s strange..., isn´t it?

    My wireless print server can´t see my router all the time while I´m printing... I guess is something about MTU on my router and my desktop
    When I do type in a command prompt...

    ping -t (wireless print server IP)

    I do recieve "Timeout ended" while I´m printing

    I have look at this.. to Know the right MTU value for my W98 se machine

    ping -f -l MTU_size packet Gateway_IP(my router)

    I discover it is 1472.

    Right now I´ve got my WRT54G configured "auto" (It works as a DHCP server and gateway).

    Note: I´ve got a wireless pci adapter on my desktop from Belkin... and
    I´ve seen this in microsoft´s website...

    It indicates:

    "When a Transmission Control Protocol (TCP) connection is established, the two hosts involved exchange their TCP maximum segment size (MSS) values. The smaller of the two MSS values is used for the connection.
    I don´t Know if that´s true in W98 se.

    My wireless print server is
    and I´ve got DHCP client enabled on it cause my router ( works as a DHCP server.
    So I guess I do need to change something on the registry of my w98 se desktop or in my WRT54G to keep connection bettween hosts alive...

    What should I do ?

    I mean how can I change MTU on my desktop. Any ideas apart from that.

  2. wonderwall

    wonderwall Network Guru Member

    That´s the way to optimize connection between hosts

    I hope all this should help to change MTU value!!! :lol: :lol: . Here it is:

    Due to network hardware malfunction, misconfiguration, or software defects, you might observe a condition where small TCP data transfers will work without problem, but large data transfers, ones with full-length packets, will hang and then time out. A workaround is to configure the sending nodes to do one or both of the following:
    · Disable PMTUD.
    · Reduce the maximum packet size by shrinking the TCP MSS and/or the IP MTU.
    Components Used
    This document is not restricted to specific software and hardware versions.
    Problem Description and Possible Causes
    Sometimes, over some IP paths, a TCP/IP node may send small amounts of data (typically less than 1500 bytes) with no difficulty, but transmission attempts with larger amounts of data hang, then time out. Often this is observed as a unidirectional problem: large data transfers succeed in one direction but fail in the other direction. This problem is likely caused by the TCP MSS value, PMTUD failure, different LAN media types, or defective links. These problems are described below:
    TCP MSS Value
    The TCP MSS value specifies the maximum amount of TCP data in a single IP datagram that the local system can accept (reassemble). The IP datagram may be fragmented into multiple packets when sent. Theoretically, this value could be as large as 65495, but such a large value is never used. Typically, an end system will use the "outgoing interface MTU" minus 40 as its reported MSS. For example, an Ethernet MSS value would be 1460 (1500 - 40 = 1460).
    PMTUD Failure
    PMTUD is an algorithm described in RFC 1191 and implemented in recent TCP/IP stacks. This algorithm attempts to discover the largest IP datagram that may be sent without fragmentation through an IP path and maximizes data transfer throughput.
    PMTUD is implemented by having an IP sender set the "Don't Fragment" (DF) flag in the IP header. If an IP packet with this flag set reaches a router whose next-hop link has too small an MTU to send the packet without fragmentation, that router discards that packet and sends an ICMP "Fragmentation needed but DF set" error to the IP sender. When the IP sender receives this Internet Control Message Protocol (ICMP) message, it should learn to use a smaller IP MTU for packets sent to this destination, and subsequent packets should be able to get through.
    Various problems can cause the PMTUD algorithm to fail, so that the IP sender will never learn the smaller path MTU but will continue unsuccessfully to retransmit the too-large packet, until the retransmissions time out. Some problems include the following:
    · The router with the too-small next hop path fails to generate the necessary ICMP error message.
    · Some router in the reverse path between the small-MTU router and the IP sender discards the ICMP error message before it can reach the IP sender.
    · Confusion in the IP sender's stack in which it ignores the received ICMP error message.
    With the above problems, a workaround is to configure the IP sender to disable PMTUD. This causes the IP sender to send their datagrams with the DF flag clear. When the large packets reach the small-MTU router, that router fragments the packets into multiple smaller ones. The smaller, fragmented data reaches the destination where it is reassembled into the original large packet.

    How to Disable PMTUD and Configure a Smaller MTU/MSS on an End Node
    The following examples set an IP MTU of 1500 or a TCP MSS of 1460 for Solaris 8 (and previous versions), HP-UX 9.x, 10.x, and 11.x, Windows 95/98/ME, Windows NT 3.1/3.51, Windows NT 4.0 and Windows 2000/XP. Setting an IP MTU value of 1500 and a TCP MSS value of 1460 generally produces the same effect because a TCP segment normally comes in 40 bytes of an IP/TCP header.
    Note: If you change the interface MTU (router or end node) then all systems connected to the same broadcast domain (wire and hub) must run the same MTU. If two systems on the same broadcast domain do not use the same MTU value, they will have trouble communicating when packets (larger than the small MTU but smaller than the big MTU) are sent from the system with the larger MTU to the system with the smaller MTU.

    Windows 95/98/ME
    Note: Modifying Windows 95's TCP/IP parameters involves editing the registry, which should only be attempted by experienced system administrators because mistakes can render the system unbootable. After making these registry changes, reboot to apply the changes.
    Disable PMTUD:
    Add the following registry value to the key:

    PMTUDiscovery = 0 or 1

    Data Type: DWORD
    The above specifies whether Microsoft TCP/IP will attempt to perform path MTU discovery as specified in RFC 1191 . A "1" enables discovery while a "0" disables it. The default is 1.
    Note: In Windows 98, the data type is a string value.
    Set Interface MTUs to 1500:
    The entries in this section must be added to the following registry key, where "n" represents the particular TCP/IP-to-network adapter binding.

    MaxMTU = 16-bit integer

    Data Type: String

    The above specifies the maximum size datagram IP that can pass to a media driver. Subnetwork Access Protocol (SNAP) and source routing headers (if used on the media) are not included in this value. For example, on an Ethernet network, MaxMTU will default to 1500. The actual value used will be the minimum of the value specified with this parameter and the size reported by the media driver. The default is the size reported by the media driver.
    Source: Knowledge Base article Q158474 from Microsoft
  3. Esquire

    Esquire Mesquire Staff Member Member

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice