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

From: wb0gaz (wb0gaz_at_hotmail.com)
Date: 08/27/04


Date: 27 Aug 2004 09:04:35 -0700

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

###

wb0gaz@hotmail.com (wb0gaz) wrote in message news:<7670fd52.0408231228.1f17be2c@posting.google.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
> wb0gaz@hotmail.com



Relevant Pages

  • Re: IP Spoofing
    ... That would be enough if the purpose of the request was e.g. to delete a database by SQL injection. ... You would not need to keep it in 7 packets, merely to send in a TCP window - pretty large these days, BUT you would also need to cut in on an existing ESTABLISHED session. ... it is quite possible to send packets to the server without anything. ...
    (comp.lang.php)
  • Re: just an idea for packet protocol using ECB
    ... >> packets may be lost. ... the system would never shutdown if attackers kept ... The damage an attacker ... So each file transmission gets a session number. ...
    (sci.crypt)
  • Re: IP Spoofing
    ... That would be enough if the purpose of the request was e.g. to delete a database by SQL injection. ... You would not need to keep it in 7 packets, merely to send in a TCP window - pretty large these days, BUT you would also need to cut in on an existing ESTABLISHED session. ... it is quite possible to send packets to the server without anything. ...
    (comp.lang.php)
  • Re: Remote desktop deadlock on XP SP2
    ... I'm going to move all packet processing out of usermode. ... forward packets from our NDIS IM to usermode via an inverted call ... TermSrv.dll creates a new session for the purpose of displaying the logon ... lives on a DPC routine for the network miniport ...
    (microsoft.public.win32.programmer.kernel)
  • Re: IP Spoofing
    ... That would be enough if the purpose of the request was e.g. to delete a database by SQL injection. ... You would not need to keep it in 7 packets, merely to send in a TCP window - pretty large these days, BUT you would also need to cut in on an existing ESTABLISHED session. ... You need to know all about the TCP session as well as the senders IP address AND current sender port number, or the packet will be discarded as not part of any TCP session the server knows about. ...
    (comp.lang.php)