Thanks for you quick answer.
Gilles Espinasse wrote:
>It could be a mru/mtu problem (maybe only the primary problem, not the
>reconnection after)
>But it should not make die your connection and only let you unable to
>receive some too big packets.
>
>Reconnection problem may be a 'ghost session' : a pppoe session not properly
>closed that will only die after a certain timeout.
>
>
The scripts I use should take care of these ghosts, they're killed (if
can you possibly kill the ghost :) ) and there are
some sleep statements. Besides, I tried to reconnect manually and double
checked if there are any pppd or pppoe left running.
>Did you use clamp mss, something like this in your firewall rules
> /sbin/iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j
>TCPMSS --clamp-mss-to-pmtu
>
>
I did not have that "clamp mss" line in my firewall rules (now I do)
but the pppoe also has similar parameter set to 1412.
>Could you add debug in your ppp options and show the LCP negociation between
>pppd and your ISP?
>We should not need IPCP part just after, or you can mask confidential info :
>login, your IP if fix.
>
>Wich mtu size is your ppp0 interface set by lcp negociation?
>ifconfig ppp0 should display MTU:1492
>If it is not the cas, you may try to add to your ppp options
>mtu 1492
>mru 1492
>
It appears that my mtu/mru are set correctly. I set mtu/mru to 1492 in
ppp options but my provider lowers them to 1460 during negotiation
(which shouldn't be a problem, I assume):
Sep 19 20:24:15 pentium-133 pppoe[1078]: PADS: Service-Name: ''
Sep 19 20:24:16 pentium-133 pppd[1077]: sent [LCP ConfReq id=0x1 <mru
1492> <magic 0x9bd345ba>]
Sep 19 20:24:16 pentium-133 pppd[1077]: rcvd [LCP ConfAck id=0x1 <mru
1492> <magic 0x9bd345ba>]
Sep 19 20:24:18 pentium-133 pppd[1077]: rcvd [LCP ConfReq id=0x20 <mru
1492> <auth pap> <magic 0x7fd604e9>]
Sep 19 20:24:18 pentium-133 pppd[1077]: sent [LCP ConfAck id=0x20 <mru
1492> <auth pap> <magic 0x7fd604e9>]
Sep 19 20:24:18 pentium-133 pppd[1077]: sent [LCP EchoReq id=0x0
magic=0x9bd345ba]
Sep 19 20:24:18 pentium-133 pppd[1077]: sent [PAP AuthReq id=0x1
user="[EMAIL PROTECTED]" password=<hidden>]
Sep 19 20:24:18 pentium-133 pppd[1077]: rcvd [LCP EchoRep id=0x0
magic=0x7fd604e9]
Sep 19 20:24:18 pentium-133 pppd[1077]: rcvd [LCP ConfReq id=0x1 <mru
1460> <auth pap> <magic 0x41d149fb>]
Sep 19 20:24:18 pentium-133 pppd[1077]: sent [LCP ConfReq id=0x2 <mru
1492> <magic 0x507e85a>]
Sep 19 20:24:18 pentium-133 pppd[1077]: sent [LCP ConfAck id=0x1 <mru
1460> <auth pap> <magic 0x41d149fb>]
Sep 19 20:24:20 pentium-133 pppd[1077]: rcvd [LCP ConfReq id=0x2 <mru
1460> <auth pap> <magic 0x41d149fb>]
Sep 19 20:24:20 pentium-133 pppd[1077]: sent [LCP ConfAck id=0x2 <mru
1460> <auth pap> <magic 0x41d149fb>]
Sep 19 20:24:21 pentium-133 pppd[1077]: sent [LCP ConfReq id=0x2 <mru
1492> <magic 0x507e85a>]
Sep 19 20:24:21 pentium-133 pppd[1077]: rcvd [LCP ConfAck id=0x2 <mru
1492> <magic 0x507e85a>]
Sep 19 20:24:21 pentium-133 pppd[1077]: sent [LCP EchoReq id=0x0
magic=0x507e85a]
Sep 19 20:24:21 pentium-133 pppd[1077]: sent [PAP AuthReq id=0x2
user="[EMAIL PROTECTED]" password=<hidden>]
Sep 19 20:24:21 pentium-133 pppd[1077]: rcvd [LCP EchoRep id=0x0
magic=0x41d149fb]
Sep 19 20:24:22 pentium-133 pppd[1077]: rcvd [PAP AuthAck id=0x2 ""]
Sep 19 20:24:22 pentium-133 pppd[1077]: sent [IPCP ConfReq id=0x1 <addr
0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Sep 19 20:24:22 pentium-133 pppd[1077]: rcvd [IPCP ConfReq id=0x1
<compress VJ 0f 00> <addr x.x.x.x>]
Sep 19 20:24:22 pentium-133 pppd[1077]: sent [IPCP ConfRej id=0x1
<compress VJ 0f 00>]
Sep 19 20:24:22 pentium-133 pppd[1077]: rcvd [IPCP ConfNak id=0x1 <addr
x.x.x.x> <ms-dns1 x.x.x.x> <ms-dns3 x.x.x.x>]
Sep 19 20:24:22 pentium-133 pppd[1077]: sent [IPCP ConfReq id=0x2 <addr
x.x.x.x> <ms-dns1 x.x.x.x> <ms-dns3 x.x.x.x>]
Sep 19 20:24:22 pentium-133 pppd[1077]: rcvd [IPCP ConfReq id=0x2 <addr
x.x.x.x>]
Sep 19 20:24:22 pentium-133 pppd[1077]: sent [IPCP ConfAck id=0x2 <addr
x.x.x.x>]
Sep 19 20:24:22 pentium-133 pppd[1077]: rcvd [IPCP ConfAck id=0x2 <addr
x.x.x.x> <ms-dns1 x.x.x.x><ms-dns3 x.x.x.x>]
>>Alcatel SpeedTouch USB modem: revision: 000a (this is weird, never saw
>>this one in previous posts)
>>
>>
>This is cat /proc/bus/usb/devices | grep 06b9 that show this '000a'?
>
>
Oops, sorry I missed one line from modem_run output it said:
Sep 19 20:35:22 pentium-133 modem_run[1300]: Modem revision: 0001
Sep 19 20:35:22 pentium-133 modem_run[1300]: Unexpected modem revision
000a, assuming Rev 0200 modem.
That unexpected modem revision confused me. Sure the revision of modem
is 0001 (same shows procfs)
Nevertheless, the problems still prevail. Connection dies from time to
time and I can still deliberately kick it down by downloading one file
from microsoft.com (I hope its not a sabotage of my Linux gateway :) ).
I have run out of ideas, I tried almost everything to keept the
connection stable, even setting overkill parameters for send/receive buffers
for the driver. Is there any way how to find out whether are any packets
comming through driver or USB interface? I just want to find the root
cause of this problem. If packets arrive to ATM AAL5 layer (as shown
using atmdiag) does that mean, they passed through driver yet ?
Any more suggestions ?
Thanks a lot
Andrej
Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]
