[ previous ] [ next ] [ threads ]
 
 From:  "Fred Mol" <fredlist at xs4all dot nl>
 To:  <m0n0wall at lists dot m0n0 dot ch>
 Subject:  Re: pptp WAN link freezes [Analysis: packet loss]
 Date:  Wed, 14 Jul 2004 22:27:49 +0200
The problem:

> Hi,
> 
> I'm running m0nowall 1.1b15 with the following setup:
> 
> (10.0.0.138)              (10.0.0.100)
> [adsl modem] ---(pptp)----[m0n0wall]--- LAN:   192.168.1.1/24
>    WAN                              --- DMZ:   192.168.2.1/24
>                                     --- Guest: 192.168.3.1/24
> 
> The pptp link seems to work perfectly after a reboot, but after some
> time (varying from an hour to several days), the link almost freezes.
> The speed becomes so low that most operations (web browsing, mail
> checking) time out. Some traffic still comes through though: an ftp
> upload that normally takes 6 minutes finished in 2 hours.


I had another nearly-freeze of the pptp-wan link last night, so I took the
opportunity to explore the wonderful world of tcpdump and ethereal again.
I noticed that packets get lost somewhere between the the pptp interface (ng0)
and the ethernet interface that talks to the adsl modem (xl0).

Here's an excerpt from the dumps (as it comes out of ethereal). The data is
from a web browser at 'client.ip' accessing a web server in the DMZ behind
the m0n0wall. The m0n0wall has a public ip 'm0n0.w.ip':


ng0 trace:
----------
No. Time            Source    Dest      Pro Info
231 23:19:33.638163 client.ip m0n0.w.ip TCP 3059 > http [SYN] Seq=3532737625 Ack=0 Win=16384 Len=0
MSS=1360
    Client sends first part of 3-way handshake to set up a tcp connection
232 23:19:33.638391 m0n0.w.ip client.ip TCP http > 3059 [SYN, ACK] Seq=2527798562 Ack=3532737626
Win=17680 Len=0 MSS=1460
    Proper response from server
249 23:19:36.659041 client.ip m0n0.w.ip TCP 3059 > http [SYN] Seq=3532737625 Ack=0 Win=16384 Len=0
MSS=1360
    Client apparently didn't get segment #232 and resends #231
250 23:19:36.659198 m0n0.w.ip client.ip TCP http > 3059 [ACK] Seq=2527798563 Ack=3532737626
Win=17680 Len=0
    ??? Why is the server sending an ACK?
251 23:19:36.669397 m0n0.w.ip client.ip TCP http > 3059 [SYN, ACK] Seq=2527798562 Ack=3532737626
Win=17680 Len=0 MSS=1460
    A proper response to #249
263 23:19:42.674621 client.ip m0n0.w.ip TCP 3059 > http [SYN] Seq=3532737625 Ack=0 Win=16384 Len=0
MSS=1360
    Client apparently didn't get #251 and transmits #231 for the second time
264 23:19:42.674760 m0n0.w.ip client.ip TCP http > 3059 [ACK] Seq=2527798563 Ack=3532737626
Win=17680 Len=0
    ??? Another ACK from the server I don't understand
265 23:19:42.684865 m0n0.w.ip client.ip TCP http > 3059 [SYN, ACK] Seq=2527798562 Ack=3532737626
Win=17680 Len=0 MSS=1460
    A proper response to #263
...
    The client gives up here: no more connection attempts from port 3059

When we take a look at the corresponding packets at xl0 (extracted from the
PPP encapsulation by ethereal) it becomes clear why the client doesn't get
the [SYN,ACK] responses: they are not being sent through xl0. Apparently
they were lost somewhere between ng0 and xl0.

xl0 trace
---------
No. Time            Source    Dest      Pro Info
 88 23:19:33.638141 client.ip m0n0.w.ip TCP 3059 > http [SYN] Seq=3532737625 Ack=0 Win=16384 Len=0
MSS=1360
    Corresponds to ng0#231
???
    Where is the packet corresponding to ng0#232? Seems to be lost
106 23:19:36.658971 client.ip m0n0.w.ip TCP 3059 > http [SYN] Seq=3532737625 Ack=0 Win=16384 Len=0
MSS=1360
    Corresponds to ng0#249
107 23:19:36.659236 m0n0.w.ip client.ip TCP http > 3059 [ACK] Seq=2527798563 Ack=3532737626
Win=17680 Len=0
    ??? Strange ACK corresponding to ng0#250
???
    Packet corresponding to ng0#251 seems to be lost as well
118 23:19:42.674588 client.ip m0n0.w.ip TCP 3059 > http [SYN] Seq=3532737625 Ack=0 Win=16384 Len=0
MSS=1360
    Third attempt of client, corresponding to ng0#263
120 23:19:42.674782 m0n0.w.ip client.ip TCP http > 3059 [ACK] Seq=2527798563 Ack=3532737626
Win=17680 Len=0
    Another strange ACK, corresponding to ng0#264
???
    Packet corresponding to ng0#265 seems to be lost as well


Packets are not always lost however, as shown by the following lines:

at ng0:
-------
No. Time            Source    Dest      Pro Info
168 23:18:35.370961 client.ip m0n0.w.ip TCP 3058 > http [SYN] Seq=3519365821 Ack=0 Win=16384 Len=0
MSS=1360
169 23:18:35.371333 m0n0.w.ip client.ip TCP http > 3058 [SYN, ACK] Seq=1920437045 Ack=3519365822
Win=17680 Len=0 MSS=1460
171 23:18:35.388806 client.ip m0n0.w.ip TCP 3058 > http [ACK] Seq=3519365822 Ack=1920437046
Win=17680 Len=0
... a long http conversation follows

at xl0:
--------
No. Time            Source    Dest      Pro Info
 16 23:18:35.370937 client.ip m0n0.w.ip TCP 3058 > http [SYN] Seq=3519365821 Ack=0 Win=16384 Len=0
MSS=1360
 17 23:18:35.371368 m0n0.w.ip client.ip TCP http > 3058 [SYN, ACK] Seq=1920437045 Ack=3519365822
Win=17680 Len=0 MSS=1460
    Corresponds to ng0#169. Apparently _some_ [SYN,ACK] segment do get through
 20 23:18:35.388785 client.ip m0n0.w.ip TCP 3058 > http [ACK] Seq=3519365822 Ack=1920437046
Win=17680 Len=0
... a long http conversation follows


Anyway, the question remains: What could be causing this and how can I
diagnose this further? Any help would be appreciated.

Thanks,

--Fred Mol