Ethernet drivers? - OS2

This is a discussion on Ethernet drivers? - OS2 ; 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 ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 41

Thread: Ethernet drivers?

  1. Re: http grief (was: Ethernet drivers)

    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/
    -----------------------------------------------------------



  2. Re: http grief (was: Ethernet drivers)

    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

  3. Re: http grief

    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

  4. Re: http grief (was: Ethernet drivers)

    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

  5. Re: http grief

    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/
    __________________________________________________ _________________


  6. Re: http grief

    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

  7. Re: http grief

    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

  8. Re: http grief

    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

  9. Re: http grief (was: Ethernet drivers)

    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.

  10. Re: http grief (was: Ethernet drivers)

    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/
    -----------------------------------------------------------



  11. Re: http grief

    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

  12. Re: http grief

    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/
    -----------------------------------------------------------



  13. Re: http grief

    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/
    __________________________________________________ _________________


  14. Re: http grief

    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

  15. Re: http grief

    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

  16. Re: http grief

    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

  17. Re: http grief

    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

  18. Re: http grief

    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


  19. Re: http grief

    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

  20. Re: http grief (was: Ethernet drivers)

    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

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast