Hi!
echo 1 > /proc/sys/net/ipv4/ip_dynaddr
put it somewhere in your system startup scripts so it is set after
booting.
If you have the kernel sources, see
/usr/src/linux/Documentation/networking/ip_dynaddr.txt.
Briefly, it enables the kernel to reset the dummy source IP address to
the real address after the connection is established. Look in your
logs, you will see that the hung socket (192.168.0.1,1078) keeps using
the dummy address while sockets created after the link is up use the
correct (63.196.173.43) address.
Regards,
Mark.
Kenward Vaughan wrote:
>
> Hi!
>
> I've been struggling to get diald working on my system (not having a
> computer science background, much less Linux... :). I use Debian, and
> finally got a connection to work under pap authentication by setting the
> name option for pppd and toying with the pap-secrets file.
>
> The problem I have at this point is figuring out why diald does not properly
> forward the original signal which triggers it in the first place. I've been
> using fetchmail with a regular account to test things. Whenever this is
> done, it simply sits forever after the connection has been established. If
> I cancel it with a ^C then resend, it works as expected.
>
> My ipchains rules are 1) completely open on the internal net prior to
> connection (i.e. input, forward, and output are all ACCEPT), then 2) are
> changed using Ian Hall-Beyer's script (can forward if desired) from ip-up.
>
> A "complete" syslog with debugging set in diald and pppd is attached. Does
> anyone see what the issue is? Would appreciate any help!
>
> TIA,
>
> Kenward Vaughan
> --
> Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
> --
>
> ------------------------------------------------------------------------
>
> dialdLogName: dialdLog
> Type: Plain Text (text/plain)
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]
