Hi Pierre:

I think I know what may be causing your problem, as
I had something similar happen to me, and I had to add
a fix for it.

See if you can run to fix it:

route -n flush
setup

Basically, it was caused by the route table filling
up in a newer tcpip stack, where the older versions had
a set expire to delete old entries, and I have to check
what I changed to fix it . . . {:-)

later,
lin Baden



In , rcpj@panix.com (Pierre Jelenc) writes:
>
>Oh well, every silver lining must have its cloud, doesn't it...
>
>The good news is that the DSL setup is running well. The bad news is that
>I seem to be having an http/https choke point somewhere.
>
>The symptoms: after a fresh boot, all is well for a while (I don't know
>yet whether this "while" is a time duration or an amount of usage) until
>suddenly some web sites (there will be a list below) simply do not load.
>
>Some of them do not load at all, some (about half; unfortunately I did not
>think of making a list) seem to load something because the proper title
>and favicon are displayed, and sometimes the background color changes, but
>no data actually come up, neither text nor graphics.
>
>Those sites that do load, seem to do so incompletely, although I don't see
>anything obviously missing: even after everything seems to have loaded,
>the loading indicators in SeaMonkey and FireFox continue to twirl.
>
>Once this phenomenon has started, it will not stop. I can close SM and FF,
>the blocked sites are still blocked later, until a reboot. Furthermore,
>the *same* sites also do not load in links, while those that are still
>accessible are also accessible by links (whether PM or text-mode).
>
>After a reboot, when the problem recurs after a while, it seems that the
>same sites that had been blocked before the reboot become blocked again,
>while those that had remained accessible do remain accessible.
>
>While this is happening in OS/2, my elderly Mac laptop (running 8.6)
>plugged into the same router (no wireless: Ethernet cables in both
>instances) will happily visit all the sites, whether accessible or not
>on the OS/2 machine.
>
>My take is that it's not the router (the Mac works), it's not the sites
>themselves (all the the blocked sites load without problem after a
>reboot), it's not the browse (SM, FF, links are equally affected), it's
>not PM (links is affected in both modes).
>
>Also, when I try to load a blocked site, there's a lot of activity
>(blinking lights) on the DSL and Ethernet lines, as though the entire HTML
>code is actually received, but not displayed. In some instances, I even
>have some evidence for that: the amazon.com home page displays title and
>favicon, and the backgound turns white, but nothing gets displayed.
>Nevertheless "View Page Source" shows the entire HTML for the page all the
>way to the final "".
>
>Finally, it happens on both http and https sites, and whether or not
>javascript is enabled.
>
>Stumped again!
>
>Pierre
>-----------------------------------
>appendix: test sites:
>
>Sites visited in the previous 2 weeks or so that
>remain accessible:
>http://www.banjojims.com/
>http://www.rockwoodmusichall.com/
>http://www.jr.com/
>http://www.nycbeer.org/
>http://www.sciencedaily.com/
>http://leopac.nypl.org/
>http://www.php.net/
>http://www.panix.com/
>
>Sites NOT visited in the previous 2 weeks or so that
>are accessible:
>http://www.columbia.edu/
>http://wnyu.nyu.edu/
>http://httpd.apache.org/
>http://newyork.craigslist.org/
>http://www.seaportmusicfestival.com/
>http://www.yahoo.com/
>http://www.camra.org.uk/
>http://www.wcbs880.com/
>http://www.independent.co.uk/
>
>
>Sites visited in the previous 2 weeks or so that
>are now inaccessible:
>http://www.google.com/
>http://news.google.com/
>https://login.yahoo.com/
>http://www.rodeobar.com/
>http://www.countrystandardtime.com/
>http://www.harrisradio.com/
>http://www.lefigaro.fr/
>http://www.drudgereport.com/
>http://www.nydailynews.com/
>http://www.nytimes.com/
>http://www.timesonline.co.uk/
>http://www.amazon.com/
>
>Sites NOT visited in the previous 2 weeks or so that
>are inaccessible:
>https://www.blogger.com/start
>http://www.livejournal.com/
>http://www.hbd.org/
>http://chowhound.chow.com/
>http://www.sxsw.com/
>http://www.cmj.com/
>http://www.live365.com/
>http://www.bestbuy.com/
>http://www.nypost.com/
>http://www.guardian.co.uk/
>http://www.lesoir.be/
>http://www.svd.se/
>http://www.dn.se/
>http://www.wfuv.org/
>-----------------------------------
>--
>Pierre Jelenc
> The Gigometer www.gigometer.com
> The NYC Beer Guide www.nycbeer.org



-----------------------------------------------------------
Let Ignorance and Intolerance Rule!

Baden Kudrenecky
baden@baden.nu
http://baden.nu/
-----------------------------------------------------------

Trevor Hemsley writes:
> On Tue, 19 Aug 2008 21:43:13 UTC in comp.os.os2.misc, rcpj@panix.com (Pierre
> Jelenc) wrote:
>
> > Once this phenomenon has started, it will not stop. I can close SM and FF,
> > the blocked sites are still blocked later, until a reboot. Furthermore,
> > the *same* sites also do not load in links, while those that are still
> > accessible are also accessible by links (whether PM or text-mode).
>
> Does the problem go away if you rerun \mptn\bin\setup.cmd

Well, I rebooted and applied ifconfig lan0 mtu 576

Since then there hasn't been any problem, so I haven't been able to test
your and Baden's suggestions.

Looking at \mptn\bin\setup.cmd however, it seems odd that its lan0
reference is REM'd out:

route -fh
arp -f
ifconfig lo 127.0.0.1
REM ifconfig lan0
REM ifconfig lan1
REM ifconfig lan2
REM ifconfig lan3
REM ifconfig lan4
REM ifconfig lan5
REM ifconfig lan6
REM ifconfig lan7
dhcpstrt -i lan0 -d 0
REM ifconfig sl0

Should I unREM it and place the "mtu 576" there rather than in
TCPEXIT.CMD?

Thanks,

Pierre
--
Pierre Jelenc
The Gigometer www.web-ho.com/gigs.html
The NYC Beer Guide www.nycbeer.org

Dave Yeo writes:
> On 08/19/08 05:14 pm, Pierre Jelenc wrote:
> > So it does not appear to be seeing errors.
> >
> >> > You can change it like
> >> > ifconfig lan0 mtu 576
> >> > 576 might be a good number.
> >
> > OK, I'll try that. Where should it go, though, if it proves beneficial:
> > tcpstart.cmd, b4tcp.cmd, or something else altogether?
>
> Probably tcpexit.cmd would be as good as anywhere.

Thanks, done. Maybe I'll move it to \mptn\bin\setup.cmd later if it turns
out to be better.

What is so magic about 576? So far it seems to be working perfectly, there
hasn't been any problem since last night.

Pierre


--
Pierre Jelenc
The Gigometer www.web-ho.com/gigs.html
The NYC Beer Guide www.nycbeer.org

On Wed, 20 Aug 2008 20:33:37 UTC in comp.os.os2.misc, rcpj@panix.com (Pierre
Jelenc) wrote:

> Looking at \mptn\bin\setup.cmd however, it seems odd that its lan0
> reference is REM'd out:

There is a dhcpstrt line for lan0 instead so leave it remmed out.

> route -fh
> arp -f
> ifconfig lo 127.0.0.1
> REM ifconfig lan0
> REM ifconfig lan1
> REM ifconfig lan2
> REM ifconfig lan3
> REM ifconfig lan4
> REM ifconfig lan5
> REM ifconfig lan6
> REM ifconfig lan7
> dhcpstrt -i lan0 -d 0
> REM ifconfig sl0
>
> Should I unREM it and place the "mtu 576" there rather than in
> TCPEXIT.CMD?

It's fine where it is.

Two possibilities spring to mind and both are bugs fixed in later releases -
there is a bug in one version of MPTS/TCPIP that fills up the routing table and
then things randomly stop working. Rerunning \mptn\bin\setup.cmd runs the 'route
-fh' command and flushes that table and everything springs back into life. This
was the theory I was getting you to test by running it when you had the problem.
I don't remember what version of MPTS and/or TCPIP was affected by this nor what
the fix was (other than upgrade!). The other thing is that the DHCP client had
bugs in it and was not able to refresh its lease on the IP address and then
weird things started to happen too. I'm pretty sure that this bug was in Warp 4
base version and again, the fix is to upgrade the networking with publicly
available fixes.

--
Trevor Hemsley, Brighton, UK
Trevor dot Hemsley at ntlworld dot com

On Wed, 20 Aug 2008 20:36:14 UTC, rcpj@panix.com (Pierre Jelenc) wrote:
> Dave Yeo writes:
> > On 08/19/08 05:14 pm, Pierre Jelenc wrote:

> > > So it does not appear to be seeing errors.
> > >
> > >> > You can change it like
> > >> > ifconfig lan0 mtu 576
> > >> > 576 might be a good number.
> > >
> > > OK, I'll try that. Where should it go, though, if it proves beneficial:
> > > tcpstart.cmd, b4tcp.cmd, or something else altogether?
> >
> > Probably tcpexit.cmd would be as good as anywhere.
>
> Thanks, done. Maybe I'll move it to \mptn\bin\setup.cmd later if it turns
> out to be better.
>
> What is so magic about 576? So far it seems to be working perfectly, there
> hasn't been any problem since last night.

I'm surprised MTU size was the problem but I can't argue with success.
However, the choice of 576 may not be optimal.

Formerly, you were using 1500 byte packets, now you're using 576 byte
packets. This means more overhead and a lower throughput - effectively,
a slower connection. You may find that setting MTU to 1492 or 1488
resolves the issue while giving you a "faster" connection. (If your
ISP's tech support seems to be fairly knowledgable, you may want to ask
them if 1492 doesn't work.)



--
== == almost usable email address: Rich AT E-vertise.Com == ==
__________________________________________________ _________________
|
| DragText v3.9 with NLS support
Rich Walsh | A Distinctly Different Desktop Enhancement
Ft Myers, FL | http://e-vertise.com/dragtext/
__________________________________________________ _________________

On 08/20/08 01:36 pm, Pierre Jelenc wrote:
> Dave Yeo writes:
>> On 08/19/08 05:14 pm, Pierre Jelenc wrote:
>>> So it does not appear to be seeing errors.
>>>
>>>>> You can change it like
>>>>> ifconfig lan0 mtu 576
>>>>> 576 might be a good number.
>>> OK, I'll try that. Where should it go, though, if it proves beneficial:
>>> tcpstart.cmd, b4tcp.cmd, or something else altogether?
>> Probably tcpexit.cmd would be as good as anywhere.
>
> Thanks, done. Maybe I'll move it to \mptn\bin\setup.cmd later if it turns
> out to be better.
>
> What is so magic about 576? So far it seems to be working perfectly, there
> hasn't been any problem since last night.
>

576 is/was the default, see rfc879
(http://www.faqs.org/rfcs/rfc879.html). Your problem is probably that a
router, perhaps yours, perhaps at your ISP has its mtu set smaller then
1500 so with your mtu set at 1500 you were getting fragmentation.
Larger numbers will give you better speed with a slight loss in
responsiveness.
Another number that you might try is 1492, which is the default for
PPPOE. 1500 is the default for ethernet.
Dave

Dave Yeo writes:
>
> 576 is/was the default, see rfc879
> (http://www.faqs.org/rfcs/rfc879.html). Your problem is probably that a
> router, perhaps yours, perhaps at your ISP has its mtu set smaller then
> 1500 so with your mtu set at 1500 you were getting fragmentation.
> Larger numbers will give you better speed with a slight loss in
> responsiveness.
> Another number that you might try is 1492, which is the default for
> PPPOE. 1500 is the default for ethernet.

Ah, since I do use PPPoE that could be it. I changed it and we'll see. The
router's docs do not mention anything about setting a different mtu, just
that it accepts 100 to 1500.

Pierre

--
Pierre Jelenc
The Gigometer www.web-ho.com/gigs.html
The NYC Beer Guide www.nycbeer.org

On 08/20/08 06:40 pm, Pierre Jelenc wrote:
> Dave Yeo writes:
>> 576 is/was the default, see rfc879
>> (http://www.faqs.org/rfcs/rfc879.html). Your problem is probably that a
>> router, perhaps yours, perhaps at your ISP has its mtu set smaller then
>> 1500 so with your mtu set at 1500 you were getting fragmentation.
>> Larger numbers will give you better speed with a slight loss in
>> responsiveness.
>> Another number that you might try is 1492, which is the default for
>> PPPOE. 1500 is the default for ethernet.
>
> Ah, since I do use PPPoE that could be it. I changed it and we'll see. The
> router's docs do not mention anything about setting a different mtu, just
> that it accepts 100 to 1500.
>
> Pierre
>

You can try entering different values on the cmd line and in between try
pinging something like google.com and watch the results. Not sure if
this will tell you anything or not but might be worth trying.
Dave

On Wed, 20 Aug 2008 21:15:11 UTC, "Trevor Hemsley"
wrote:

> Two possibilities spring to mind and both are bugs fixed in later releases
> - there is a bug in one version of MPTS/TCPIP that fills up the routing
> table and then things randomly stop working. Rerunning \mptn\bin\setup.cmd
> runs the 'route -fh' command and flushes that table and everything springs
> back into life. This was the theory I was getting you to test by running
> it when you had the problem. I don't remember what version of MPTS and/or
> TCPIP was affected by this nor what the fix was (other than upgrade!).

I'm not sure if it ever _was_ fixed. Wasn't it eventually discovered to be
sockets rather than the routing table? The fix for that was to change the
'keepalive' setting to something sane like 60 (which IIRC was the default in
Warp 4) from the later default of 7800. Most of us have made this change so
long ago we're not having the problem anymore (and eCS always sets it to
something smallish by default).

--
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00

Please take off hat when replying.

In , "Alex Taylor" writes:
>On Wed, 20 Aug 2008 21:15:11 UTC, "Trevor Hemsley"
> wrote:
>
>> Two possibilities spring to mind and both are bugs fixed in later releases
>> - there is a bug in one version of MPTS/TCPIP that fills up the routing
>> table and then things randomly stop working. Rerunning \mptn\bin\setup.cmd
>> runs the 'route -fh' command and flushes that table and everything springs
>> back into life. This was the theory I was getting you to test by running
>> it when you had the problem. I don't remember what version of MPTS and/or
>> TCPIP was affected by this nor what the fix was (other than upgrade!).
>
>I'm not sure if it ever _was_ fixed. Wasn't it eventually discovered to be
>sockets rather than the routing table? The fix for that was to change the
>'keepalive' setting to something sane like 60 (which IIRC was the default in
>Warp 4) from the later default of 7800. Most of us have made this change so
>long ago we're not having the problem anymore (and eCS always sets it to
>something smallish by default).

I am confused with this, as I thought you had a good
hint, but I just found:

========================================
#Inetcfg: CURRENT DEFAULT MINIMUM MAXIMUM

keepalive 7800 7800 0 7800 KeepAlive (sec)
multidefrt 1 1 0 1 Multiple Default Routes ON/OFF
========================================

and I don't have a full route table problem anymore,
but I know I used to.

I have unsuccessfully searched everything looking
for a configuration change. All I found was an old
setup.cmd with "inetcfg -s keepalive 180" added.

Version numbers of TCP/IP protocol drivers:
SOCKETS.SYS: 6.1002
AFOS2.SYS: 6.1000
AFINET.SYS: 6.1001

Also, I found this:
http://groups.google.com/group/comp....348360d8f7abcf

which is relevant, but I still don't know what
corrected the problem on my systems, unless a new stack
fixed it.

lin Baden



-----------------------------------------------------------
Let Ignorance and Intolerance Rule!

Baden Kudrenecky
baden@baden.nu
http://baden.nu/
-----------------------------------------------------------

Rich Walsh writes:
>
> I'm surprised MTU size was the problem but I can't argue with success.
> However, the choice of 576 may not be optimal.
>
> Formerly, you were using 1500 byte packets, now you're using 576 byte
> packets. This means more overhead and a lower throughput - effectively,
> a slower connection. You may find that setting MTU to 1492 or 1488
> resolves the issue while giving you a "faster" connection.

The situation so far: 576 is totally stable, over hours of active use and
left overnight with a couple of auto-refreshing news sites.

Various values in the 1400 range, including 1492, cause loss of web access
on the same tests sites as before, pretty much at the same rate (loading a
page or two after the switch.)

The various tips on how to recover after that do not work: "setup.cmd"
and/or "tcpstart.cmd" have no effect; "route -n flush" kills all tcp/ip
services and neither "setup.cmd" nor "tcpstart.cmd" have any effect. The
only solution is to reboot.

Is there a way to test the maximum mtu with ping or something similar, as
described in http://www.dslreports.com/faq/695 for instance? It looks like
OS/2 ping either does not fragment packets, or does so silently, even in
debug or verbose modes.

> If your ISP's tech support seems to be fairly knowledgable, you may want
> to ask them if 1492 doesn't work.)

I did and am awaiting the answer. They are very good, but have no
experience with OS/2.

Pierre
--
Pierre Jelenc
The Gigometer www.web-ho.com/gigs.html
The NYC Beer Guide www.nycbeer.org

In , rcpj@panix.com (Pierre Jelenc) writes:
>Rich Walsh writes:
>
>The various tips on how to recover after that do not work: "setup.cmd"
>and/or "tcpstart.cmd" have no effect; "route -n flush" kills all tcp/ip
>services and neither "setup.cmd" nor "tcpstart.cmd" have any effect. The
>only solution is to reboot.

I guess I could look back, but are you using DHCP?

If so, that could change several things, as it will
configure things the way it wants.

Also, if you are, then to restart services after a
"route -n flush", it may be expedient to run "dhcpmon",
and then select "Release lease" followed by "Request
lease".

later,
lin Baden


-----------------------------------------------------------
Let Ignorance and Intolerance Rule!

Baden Kudrenecky
baden@baden.nu
http://baden.nu/
-----------------------------------------------------------

On Fri, 22 Aug 2008 21:23:29 UTC, rcpj@panix.com (Pierre Jelenc) wrote:
> Rich Walsh writes:

> > If your ISP's tech support seems to be fairly knowledgable, you may want
> > to ask them if 1492 doesn't work.)
>
> I did and am awaiting the answer. They are very good, but have no
> experience with OS/2.

Your OS is wholly irrelevant when it comes to MTU size. If whomever you
spoke to didn't recognize that, then maybe they're not as knowledgable as
we might have hoped.

> The situation so far: 576 is totally stable, over hours of active use and
> left overnight with a couple of auto-refreshing news sites.
>
> Various values in the 1400 range, including 1492, cause loss of web access
> on the same tests sites as before, pretty much at the same rate (loading a
> page or two after the switch.)
>[snip]
> Is there a way to test the maximum mtu with ping or something similar, as
> described in http://www.dslreports.com/faq/695 for instance? It looks like
> OS/2 ping either does not fragment packets, or does so silently, even in
> debug or verbose modes.

Apparently, the OS/2 version doesn't let you set the "don't fragment" flag
that this test relies on. Perhaps someone has ported a GNU or BSD version
of ping that supports this parameter.

FWIW... I could be all wrong about this, but ISTR that MTU is set as part
of DHCP negotiation. If that's correct, then you may want to look for an
MTU setting in your modem/router and monkey around with that.


--
== == almost usable email address: Rich AT E-vertise.Com == ==
__________________________________________________ _________________
|
| DragText v3.9 with NLS support
Rich Walsh | A Distinctly Different Desktop Enhancement
Ft Myers, FL | http://e-vertise.com/dragtext/
__________________________________________________ _________________

On 08/22/08 09:13 pm, Rich Walsh wrote:
> Apparently, the OS/2 version doesn't let you set the "don't fragment" flag
> that this test relies on. Perhaps someone has ported a GNU or BSD version
> of ping that supports this parameter.
>

It's amazing how hard it is to find sources for a simple ping

> FWIW... I could be all wrong about this, but ISTR that MTU is set as part
> of DHCP negotiation. If that's correct, then you may want to look for an
> MTU setting in your modem/router and monkey around with that.

netstat -n after getting a new lease should show if the DHCP server sets
the MTU. (the one I have running here doesn't)
Dave

Rich Walsh writes:
> On Fri, 22 Aug 2008 21:23:29 UTC, rcpj@panix.com (Pierre Jelenc) wrote:
> > Rich Walsh writes:
>
> > > If your ISP's tech support seems to be fairly knowledgable, you may want
> > > to ask them if 1492 doesn't work.)
> >
> > I did and am awaiting the answer. They are very good, but have no
> > experience with OS/2.
>
> Your OS is wholly irrelevant when it comes to MTU size. If whomever you
> spoke to didn't recognize that, then maybe they're not as knowledgable as
> we might have hoped.

I didn't speak to anyone, I emailed them.

> FWIW... I could be all wrong about this, but ISTR that MTU is set as part
> of DHCP negotiation. If that's correct, then you may want to look for an
> MTU setting in your modem/router and monkey around with that.

There isn't anything in either the installation docs or the PDF manual as
far as I can tell. The manual merely mentions that it accepts values
between 1000 and 1500.

Pierre
--
Pierre Jelenc
The Gigometer www.web-ho.com/gigs.html
The NYC Beer Guide www.nycbeer.org

On 08/22/08 10:00 pm, Dave Yeo wrote:
> On 08/22/08 09:13 pm, Rich Walsh wrote:
>> Apparently, the OS/2 version doesn't let you set the "don't fragment"
>> flag
>> that this test relies on. Perhaps someone has ported a GNU or BSD
>> version
>> of ping that supports this parameter.
>>
>
> It's amazing how hard it is to find sources for a simple ping

I've tried to compile a couple of ping implementations. Unluckily for
most our stack is to old. Some depend on kernel features that we don't
have and most want getaddrinfo() which we also don't have, be nice to
have it though
example
checking for getaddrinfo... no
checking getaddrinfo again by including ... configure: error:
Missing mandatory function - echoping now uses the new network functions
(RFC 2133) which are mandatory for IPv6

Dave

On Sun, 24 Aug 2008 04:16:33 UTC, Dave Yeo
wrote:

> On 08/22/08 10:00 pm, Dave Yeo wrote:
> > On 08/22/08 09:13 pm, Rich Walsh wrote:
> >> Apparently, the OS/2 version doesn't let you set the "don't fragment"
> >> flag
> >> that this test relies on. Perhaps someone has ported a GNU or BSD
> >> version
> >> of ping that supports this parameter.
> >>
> >
> > It's amazing how hard it is to find sources for a simple ping
>
> I've tried to compile a couple of ping implementations. Unluckily for
> most our stack is to old. Some depend on kernel features that we don't
> have and most want getaddrinfo() which we also don't have, be nice to
> have it though
> example

I was thinking that somehow, we should find a way to move to IPv6, for
many reasons, included security and performances. How about BSD? IIRC,
the OS/2 TCP/IP stack was derived from AIX, and this went from BSD.

How big would be the costs to port a complete TCP/IP IPv6 stack on
OS/2 - eCS?

Mentore

On 08/24/08 12:40 pm, Mentore Siesto wrote:
> On Sun, 24 Aug 2008 04:16:33 UTC, Dave Yeo
> wrote:
>
>> On 08/22/08 10:00 pm, Dave Yeo wrote:
>>> On 08/22/08 09:13 pm, Rich Walsh wrote:
>>>> Apparently, the OS/2 version doesn't let you set the "don't fragment"
>>>> flag
>>>> that this test relies on. Perhaps someone has ported a GNU or BSD
>>>> version
>>>> of ping that supports this parameter.
>>>>
>>> It's amazing how hard it is to find sources for a simple ping
>> I've tried to compile a couple of ping implementations. Unluckily for
>> most our stack is to old. Some depend on kernel features that we don't
>> have and most want getaddrinfo() which we also don't have, be nice to
>> have it though
>> example
>
> I was thinking that somehow, we should find a way to move to IPv6, for
> many reasons, included security and performances. How about BSD? IIRC,
> the OS/2 TCP/IP stack was derived from AIX, and this went from BSD.
>
> How big would be the costs to port a complete TCP/IP IPv6 stack on
> OS/2 - eCS?
>

I'd guess that it would be a pretty large job. Look how long it took IBM
to get the 32 bit stack working right.
Dave

Hi,
> > Another number that you might try is 1492, which is the default for
> > PPPOE. 1500 is the default for ethernet.

1500 Ethernet default packet size. Typical setting for PPPoA and non-
VPN connections.
1492 recommended size for PPPoE
1478 optimal size for PPPoA (In Aus if running servers stick with 1500
on Telstra network).
1472 Max size to use for pinging (Bigger packets are fragmented.)
1468 size DHCP prefers
1454 optimal size for PPPoE
1430 VPN and PPTP prefer
576 dial-up ISPs


My personal recommendations are to set 1500 for PPPoA and 1454 for
PPPoE BUT your best bet would be to check with your ISP as this
really depends on how they have setup there DSLAM or bridge units.

Cheers
Ian Manners

Hi,

Alex is correct re setting KeepAlive to something like 60, the default
value in OS/2 leads to socket overload, especially when OS/2 is used
as a TCP/IP server.

Cheers
IBM