How do I debug this link - Win95 dialing RH9 Linux ppp server

I am not able to get Win95 dial-up to a RH9 dial-in server working for
http:// (web) transfers, altough other (ssh-based) transfers work.

When I use a web browser (I started with IE5.5, then shifted over to
Mozilla 1.7, and got the same outcome in each case) to access
Internet, http:// sessions appear to stall after a few hundred or a
few thousand bytes of data send/receive. It appears after a few data
packets are exchanged during a single http:// transfer sequence that
the transfers stall (it doesn't disconnect, data packets just cease
transfer.)

Even after this happens, I can use a ssh client to open a ssh session
over the same link (example right after a stalled http:// session) and
that works fine, and I can also transfer long files over a ssh
session.

When I use a linux (RH9) machine to dial into the same server, all
works fine.

This is my configuration:

A Windows 95 (B) laptop is dialing to a Redhat 9 Linux ppp server.

The linux machine has the following /etc/ppp/options file contents:

lock
asyncmap 0
crtscts
mru 576
mtu 576
ms-dns 192.168.0.1
ms-wins 192.168.0.1
netmask 255.255.255.0
passive
proxyarp
modem
usehostname

The Windows 95 machine has all dial-up options off except for
"TCP/IP", and TCP/IP settings have only "Use default gateway on remote
network" selected.

I've read the ppp "options" definitions a number of times, and I've
done quite a bit of trial-and-error, but no solution yet (some changes
completely break the connection, but nothing improves on the http://
problem above.) I have tried enabling "debug" on the server end hoping
to see a packet trace, but evidently I am not doing that properly,
hence perhaps someone could suggest if that's a useful path to take
(then, how?) or other approach to solving.

Very tnx,

Dave
(E-Mail Removed)

On 23 Aug 2004 13:28:09 -0700, wb0gaz <(E-Mail Removed)> wrote:
> I am not able to get Win95 dial-up to a RH9 dial-in server working for
> http:// (web) transfers, altough other (ssh-based) transfers work.
>
> When I use a web browser (I started with IE5.5, then shifted over to
> Mozilla 1.7, and got the same outcome in each case) to access
> Internet, http:// sessions appear to stall after a few hundred or a
> few thousand bytes of data send/receive. It appears after a few data
> packets are exchanged during a single http:// transfer sequence that
> the transfers stall (it doesn't disconnect, data packets just cease
> transfer.)
>
> Even after this happens, I can use a ssh client to open a ssh session
> over the same link (example right after a stalled http:// session) and
> that works fine, and I can also transfer long files over a ssh
> session.
>
> When I use a linux (RH9) machine to dial into the same server, all
> works fine.
>
> This is my configuration:
>
> A Windows 95 (B) laptop is dialing to a Redhat 9 Linux ppp server.
>
> The linux machine has the following /etc/ppp/options file contents:
>
> lock
> asyncmap 0
> crtscts
> mru 576
> mtu 576
> ms-dns 192.168.0.1
> ms-wins 192.168.0.1
> netmask 255.255.255.0
> passive
> proxyarp
> modem
> usehostname

What is the reason for such a low (ancient) MTU instead of default? Not
sure if that is the source of your problems (MTU path discovery blocked),
but I have never seen that on any PPP connection since I started using
dialup PPP in 1995. Typically default MTU for any PPP ISP I used was 1500
or 1524. Then incoming packets would not get fragmented (which masquerade
may be blocking).

The only time I had an MTU issue was with an smtp server on LAN that had
trouble receiving mail through a pppoe connection (max mtu 1492 due to
8-byte pppoe header). In that case I just set the LAN nick of the smtp
server to match pppoe's mtu 1492 and it worked.

But in your case, I think you just need your dialin PPP mtu at least as
high as your internet connection mtu. Otherwise if PMTU discovery is not
working, fragmented packets may get rejected. Maybe Linux to Linux is
more cooperative.

--
David Efflandt - All spam ignored http://www.de-srv.com/

The problem was tracked down - turns out the mtu/mru
entries were causing transmission errors during web browsing
(but for whatever reason not during ssh sessions.) Basic approach
was to eliminate each instruction in /etc/ppp/options that could
not be specifically justified (either by reading documentation
or other dialogs on c.o.l.n or trial-and-error.)

Anyway, the working /etc/ppp/options in the dial-in machine
in this case is just this:

lock
asyncmap 0
crtscts
ms-dns 192.168.0.1
passive
proxyarp
modem

###

(E-Mail Removed) (wb0gaz) wrote in message news:<(E-Mail Removed). com>...
> I am not able to get Win95 dial-up to a RH9 dial-in server working for
> http:// (web) transfers, altough other (ssh-based) transfers work.
>
> When I use a web browser (I started with IE5.5, then shifted over to
> Mozilla 1.7, and got the same outcome in each case) to access
> Internet, http:// sessions appear to stall after a few hundred or a
> few thousand bytes of data send/receive. It appears after a few data
> packets are exchanged during a single http:// transfer sequence that
> the transfers stall (it doesn't disconnect, data packets just cease
> transfer.)
>
> Even after this happens, I can use a ssh client to open a ssh session
> over the same link (example right after a stalled http:// session) and
> that works fine, and I can also transfer long files over a ssh
> session.
>
> When I use a linux (RH9) machine to dial into the same server, all
> works fine.
>
> This is my configuration:
>
> A Windows 95 (B) laptop is dialing to a Redhat 9 Linux ppp server.
>
> The linux machine has the following /etc/ppp/options file contents:
>
> lock
> asyncmap 0
> crtscts
> mru 576
> mtu 576
> ms-dns 192.168.0.1
> ms-wins 192.168.0.1
> netmask 255.255.255.0
> passive
> proxyarp
> modem
> usehostname
>
> The Windows 95 machine has all dial-up options off except for
> "TCP/IP", and TCP/IP settings have only "Use default gateway on remote
> network" selected.
>
> I've read the ppp "options" definitions a number of times, and I've
> done quite a bit of trial-and-error, but no solution yet (some changes
> completely break the connection, but nothing improves on the http://
> problem above.) I have tried enabling "debug" on the server end hoping
> to see a packet trace, but evidently I am not doing that properly,
> hence perhaps someone could suggest if that's a useful path to take
> (then, how?) or other approach to solving.
>
> Very tnx,
>
> Dave
> (E-Mail Removed)