On 17 Feb, Greg Zornetzer wrote:
> On Thu, 18 Feb 1999, Anssi Sallinen wrote:
>
>> Feb 17 23:41:48 neutron diald[2226]: Running connector (pid = 2238).
>> Feb 17 23:42:13 neutron diald[2226]: child process 2238 terminated with signal
>> 11
>> Feb 17 23:42:13 neutron diald[2226]: Connect script failed.
>> Feb 17 23:42:13 neutron diald[2226]: Closing /dev/ttyS1
>
> Welcome to the club. I just upgraded to diald-0.98.2 and had much the
> same problem. After about an hour for screwing around, I think I've got
> it figured out. You compiled in TCP wrapper support, didn't you? That's
> what I did, and that's the problem. The short answer is to recompile
> without tcp wrapper support.
>
> Here's the slightly longer answer: In the process of debugging the
> problem, I was able to use gdb to connect to the child processes, and see
> what was going so terribly wrong in them. It turns out that you never
> even get to running the connection script - instead, the problem occurs
> after the fork of the child, and before the exec of the connect script.
> The problem is that libwrap.a has a function in it called setenv. Why
> someone chose to put a function with that name in, I have no clue.
> Anyway, when diald is compiled, instead of using the setenv command in
> libc, like we should, this other setenv from libwrap gets used. It goes
> into infinite recursion for some unknown reason, and bam!, a SIG11 when
> the process runs out of stack space.
> So, there are a couple of ways around this problem. As I mentioned
> above, compile without tcp wrapper support for now. Or, someone could go
> in and modify all of the setenv calls in diald to call putenv. Or,
> someone could fix libwrap so that it doesn't contain braindead-named
> functions. I may attempt the second option if I get some time (although
> probably not very soon).
> I'm rather curious why not all of the people running diald with
> tcp-wrapper support are seeing this problem <shrug>
>
I'm not sure you saw what you thought you saw. I had a similar problem
that I debugged. It turns out that diald will not work if the linkname
option is not set in the diald.conf file. In between the fork of the
child and the calling of the connect script is the following code
(located in fork_dialer in modem.c):
setenv("DIALD_DEVICE", current_dev, 1);
setenv("DIALD_LINK", link_name, 1);
link_name never gets initialized. Passing a NULL pointer into setenv
causes the core dump. I fixed this on my machine by checking link_name
for NULL and giving it a default value if it was not set. Patches
available on demand.
FYI,
The setenv in tcp_wrappers is simply an alternate implementation of
setenv. It does the same thing as the one in the C library.
--
----------------------
Todd J Martin
[EMAIL PROTECTED]
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]
