OS/2 eZine - http://www.os2ezine.com
Spacer
February 16, 2002
 
Gili Tzabari is studying toward his Bachelor of Software Engineering in Concordia University, Quebec, Canada. Constantly in the persuit of a great programming project he constantly shifts from one idea to the another... This week's project: Java for the People!

If you have a comment about the content of this article, please feel free to vent in the OS/2 eZine discussion forums.

There is also a Printer Friendly version of this page.



Spacer
Previous Article
Home
Next Article


Buy the CD 'This Space for Rent' by Pete Grubbs


Can't Get There From Here?

Ever notice how sometimes your OS/2 network applications are quirky while their Windows counterparts work just fine? Think you're being paranoid? Maybe not...

After two years of suffering random network failures across my OS/2 box I finally managed to locate the problem: MTU. That's right.. my MTU (Maximum Transmision Unit) was misconfigured and as a result network packets were being dropped randomily.


Common symptoms:

  • Web pages which work just fine under Windows have problems under OS/2
  • The inability to submit web-forms if they're too big (you click on submit and the website hangs on "waiting for reply...")
  • Network packets magically getting corrupted or dropped. One tell-tale indication on my box was how Weasel's packets were being dropped because they were too short (smaller than the minimum packet size).

So what's the big deal you ask? Well, the problem with MTU misconfiguration is that you can't just fix the problem in one place and make it go away. I remember modifying my MTU value at least 20 times with no effect. The problem was that I was modifying the MTU in all the wrong places. There are plenty of ways to modify the MTU, many of which won't solve your problem. The Injoy documentation was both a blessing and a curse on this issue. It was a curse because it down-played the importance of MTU misconfiguration (stating that MTU problems are quite easy to diagnose). It was a blessing because it (eventually) helped me fix the problem. Besides, Bjarne (the author) was a lot of help. Many thanks go out to him and William L. Hartzell who pointed me in the right direction.

MTU misconfiguration probably isn't a problem to those of you using dial-up modems or cable connections, but for those unfortunate souls stuck using PPPoE the maximum MTU value is reduced to 1492, below the default value of 1500. Novice users often get confused.

Lets do it right!

Ok, so you've decided you need to change your MTU configuration. What do you do? In this article I will assume you're using Injoy Firewall and PPPoE (so your ideal MTU value is 1492).

First thing's first, lets take care of Injoy Firewall. The documentation reads:

Edit the ASCII file:

GATEWAY.CF

Locate the following section, and edit

[hardware]
fragmented packets prior to
up again (using the MTU), as
is enabled per default, which
rules to operate on full packets.
on the performance.

Remove the ';' in front of 'MTU' and change to 1492

Next, modify the MTU associated with your LAN adapter, loopback interface and ppp interface. The last two are optional but I'd do them "just in case" (I'm paranoid that way).

  • Edit \mptn\bin\setup.cmd
  • Replace:
    • ifconfig lan1 nil metric 1 mtu 1500 by
    • ifconfig lan1 192.168.0.2 netmask 255.255.255.0 metric 1 mtu 1492
  • This modifies your LAN adapter MTU
  • WARNING: On older versions of the TCP/IP stack ifconfig lan1 mtu 1492 must appear on a different line than ifconfig lan1 192.168.0.2 netmask 255.255.255.0 metric 1; just separate them into two lines.
  • Add (optional):
    • ifconfig lo 127.0.0.1 mtu 1492
    • This modifies your loopback interface MTU
  • Run (optional):
    • ifconfig ppp0 mtu 1492
    • Execute this after gateway.exe has connected to your service provider.
Also, I've found the following settings yielded better TCP/IP throughput and the timestmp flag prevents TCP/IP-related TRAPs. Simply create \tcpip\bin\b4tcp.cmd with the following contents:

inetcfg -s tcpswinsize 65536
inetcfg -s mtudiscover 0
inetcfg -s synattack 1
inetcfg -s syncookie 1
inetcfg -s timestmp 1

Don't make the same mistake I did: modifying the MTU of ppp0 is not enough. You must modify your adapter's MTU value as well.

Good hunting!

Previous Article
Home
Next Article

Copyright (C) 2002. All Rights Reserved.