many packets => link dies
Brought to you by:
jaggy
Menu
▾
▴
#9 many packets => link dies
There are lots of packets being sent to the default
route (sl0) and diald initiates a connection. The
packets continue coming in as the PPP link comes up.
The link then dies in one of two ways:
1) we send a protocol-reject message for some random
id and the other side requests that we terminate the
link.
2) diald reports the HALF_DEAD state and PPP loses its
assigned address. in a few seconds the link goes down.
These both happen AFTER the IP Address is assigned.
By adding delays and commenting parts of the code it
looks like it is happening after the act_UP()
function. This problem is 100% reproduceable for me,
and any type of traffic is sufficient (udp, flood
pings, etc).
If I initiate PPPD manually (not using diald) this
problem NEVER happens.
This also only happens if traffic is incoming during
the connection phase. If traffic is sent a few
seconds later, after link is up everything is ok. But
nonetheless this represents a huge problem for me...
I would greatly appreciate any hints, etc.
bkuschak@yahoo.com
Logged In: YES
user_id=2123
Diald buffers the packets then sends them once the link
has come up. To get to HALF_DEAD we have to have brought
the link up successfully but then all the routes through
the ppp* interface disappear (implying that pppd deleted
them).
My best guess is that the burst of buffered packets being
forwarded after link up is overrunning the serial port
and your flow control isn't working - which would lead
to a blast of garbage and pppd abandons in disgust.
Which implies your flow control isn't working. Either
you don't have crtscts in your diald config or your
modem has hardware flow control turned off. Presumably
whatever you are using to start pppd manually sets
flow control correctly.
Logged In: NO
I have the same problem with HALF_DEAD and can reproduce it
as well. It HAPPENS when you just say "ping <somehost>", so
the DNS-lookup seems to be enough. It does NOT happen when
you start the ping, stop it at once, wait until the line is
up etc. and then restart the ping. Neither ping nor
DNS-lookup should produce so many packets that the modem is
overrun, and i have crtscts in diald.conf and i am pretty
sure that hw-flowcontrol is enabled in my modem (Blatzheim
BM 33k6/ISDN), but i will double-check that. If you like i
would volunteer as tester for this problem because it is
really disgusting...
Martin Trenz
Logged In: NO
iam using diald 1.0 and rh6.2 i got this in my log
i dont know what to do . i have try looking for solution
but failed.
please help me
Oct 27 16:23:59 restucc modprobe: modprobe: Can't locate
module tap0
Oct 27 16:23:59 restucc modprobe: modprobe: Can't locate
module tap1
Oct 27 16:23:59 restucc modprobe: modprobe: Can't locate
module tap2
Oct 27 16:23:59 restucc modprobe: modprobe: Can't locate
module tap3
Oct 27 16:23:59 restucc modprobe: modprobe: Can't locate
module tap4
Oct 27 16:23:59 restucc modprobe: modprobe: Can't locate
module tap5
Oct 27 16:23:59 restucc modprobe: modprobe: Can't locate
module tap6
Oct 27 16:23:59 restucc modprobe: modprobe: Can't locate
module tap7
Oct 27 16:24:00 restucc modprobe: modprobe: Can't locate
module tap8
Oct 27 16:24:00 restucc modprobe: modprobe: Can't locate
module tap9
Oct 27 16:24:00 restucc modprobe: modprobe: Can't locate
module tap10
Oct 27 16:24:00 restucc modprobe: modprobe: Can't locate
module tap11
Oct 27 16:24:00 restucc modprobe: modprobe: Can't locate
module tap12
Oct 27 16:24:00 restucc modprobe: modprobe: Can't locate
module tap13
Oct 27 16:24:00 restucc modprobe: modprobe: Can't locate
module tap14
Oct 27 16:24:00 restucc modprobe: modprobe: Can't locate
module tap15
Oct 27 16:24:00 restucc diald[2943]: start sl0:
SIOCSIFMETRIC: Operation not supported
Oct 27 16:24:29 restucc diald[2943]: Trigger: tcp
192.168.0.2/1563 216.148.218.195/80
Oct 27 16:24:29 restucc diald[2943]: Calling site 127.0.0.4
Oct 27 16:25:06 restucc diald[2943]: Connected to site
127.0.0.4
Oct 27 16:25:06 restucc diald[2943]: Running pppd (pid =
2971).
Oct 27 16:25:06 restucc pppd[2971]: pppd 2.3.11 started by
root, uid 0
Oct 27 16:25:06 restucc pppd[2971]: Using interface ppp0
Oct 27 16:25:06 restucc pppd[2971]: Connect: ppp0 <--
> /dev/ttyS1
Oct 27 16:25:13 restucc pppd[2971]: Hangup (SIGHUP)
Oct 27 16:25:13 restucc pppd[2971]: Modem hangup
Oct 27 16:25:13 restucc pppd[2971]: Connection terminated.
Oct 27 16:25:13 restucc pppd[2971]: Exit.
Oct 27 16:25:13 restucc diald[2943]: start sl0:
SIOCSIFMETRIC: Operation not supported
Oct 27 16:25:13 restucc diald[2943]: start sl0: SIOCADDRT:
File exists
Oct 27 16:25:13 restucc diald[2943]: start sl0: SIOCDELRT:
No such process
Oct 27 16:25:13 restucc diald[2943]: start sl0: SIOCADDRT:
File exists
Oct 27 16:25:13 restucc diald[2943]: stop ppp0: SIOCDELRT:
No such process
Oct 27 16:25:13 restucc kernel: ppp: ppp0 not active
Oct 27 16:25:13 restucc diald[2943]: stop ppp0:
SIOCSIFFLAGS: Device not configured
Oct 27 16:25:14 restucc diald[2943]: Delaying 30 seconds
before clear to dial.
Logged In: NO
The problem _seems_ to be gone for me after getting new
hardware (Asus A7V133, AMD Athlon 1200 etc.) and Kernel
2.4.13. I can not say what actually made the difference, sorry.
Maybe the serial ports on my old Asus P5A-B Board where
brocken in respect to crtscts, maybe the ppp-code of 2.4.13 is
better than 2.4.4. Maybe this may help someone :-)
Martin Trenz
Logged In: YES
user_id=603653
I found a problem with the slip proxy losing the last two
bytes of a packet.
The reports here all point to these bad packets being
buffered and then sent direct to pppd. I suspect that they
were the cause of the older pppd bailing out.
I've supplied a fix in the patches section "slip proxy".