[2139] in linux-net channel archive
Diald-0.13 woes with 1.3.75 and half-dynamic address
daemon@ATHENA.MIT.EDU (jam@mnsinc.com)
Mon Mar 18 17:00:57 1996
To: "Eric Schenk" <schenk@cs.toronto.edu>
cc: kev@primenet.com, linux-net@vger.rutgers.edu, linux-diald@vger.rutgers.edu
In-reply-to: ("Eric Schenk" Wed, 13 Mar 1996 01:10:31 -0500)
<96Mar13.011038edt.15371@dvp.cs.toronto.edu>
Date: Mon, 18 Mar 1996 15:41:13 -0500
From: jam@mnsinc.com
My diad-0.13 on kernel 1.3.75 seems to have the same problems with a
fixed local but dynamic remote address as reported for kernels
1.3.7[2,3] but the 'reroute' option seems to have no effect. 0.13
works fine on 1.3.70 without 'reroute' as this mail demonstrates. I
have not tried kernels 1.3.7[1-4] with diald-0.13.
>>>>> "Eric" == Eric Schenk "Re: Diald doesn't work with 1.3.72 "
>>>>> Wed, 13 Mar 1996 01:10:31 -0500
Eric> Kevin Buettner <kev@primenet.com> writes:
>>> These bugs together hose anyone who is using dynamic PPP or
>>> SLIP, and anyone who sets things like "remote 127.0.0.3" in
>>> their diald options. If you must have things working before I
>>> can figure out the necessary fixes for the last bug, make sure
>>> that you use the "reroute" option, and set your "remote"
>>> address correctly!
>> I can't set my "remote" address correctly because it is
>> dynamic. OTOH, my local address is static. Should I still
>> specify the dynamic option or not?
Eric> You don't need it, but the remote address won't show up in
Eric> your routing tables if you don't use it. For dynamic remote
Eric> addresses this is mostly an esthetic choice.
Eric> For the moment you must use the "reroute" option (which was
Eric> broken in diald-0.12) with kernel versions 1.3.7[2-3]. This
Eric> is fixed in 0.13, which I will try to release tomorrow. The
Eric> need for the reroute option may go away if I can figure out
Eric> why the 1.3.7[2-3] kernels don't allow SOCK_PACKET packets
Eric> to be forwarded on ppp devices. I suspect this will be a
Eric> kernel side patch though, so we'll probably have to wait for
Eric> the patch to appear in the kernel sources (once one of us
Eric> figures out what the patch should be!)