Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 02 Jun 1997 16:51:26 -0400
From:      Brian McGovern <bmcgover@cisco.com>
To:        hackers@freebsd.org
Cc:        questions@freebsd.org
Subject:   Need help with O_NONBLOCK and pppd in FreeBSD....
Message-ID:  <199706022051.QAA00272@bmcgover-pc.cisco.com>

next in thread | raw e-mail | index | archive | help
I've been doing some code-searching as to why, whenever I try to run pppd
with my serial driver, that pppd suddenly starts spinning out of control. I
think I see where this is happening (in pppd), but I'm not sure if I'm 
confusing what I think is happening, and what really is happening. If someone
can comment on these code chunks, I'd greatly appreciate it:



>From /usr/src/usr.sbin/pppd/main.c, line 317:

	nonblock = (connector || !modem)? O_NONBLOCK: 0;

Now, in my test cases, connector will be 0/NULL (I am not dialing out), and
modem is 1 (I want to use modem control lines). Therefore,
        nonblock = (0 || !1)? O_NONBLOCK:0;
        nonblock = (0 || 0) ? O_NONBLOCK:0;
        nonblock = 0;

Then, on line 326:

	if (nonblock) {
	    initfdflags &= ~O_NONBLOCK;
	    fcntl(fd, F_SETFL, initfdflags);
	}

Which translates in to:
       if (0) {
       	   initfdflags &= ~O_NONBLOCK;
           fcntl(fd, F_SETFL, initfdflags);
       }

which will never get executed. This should turn OFF NON_BLOCKING operation,
which I'm assuming is what pppd really wants. Of course, due to the value of
nonblock, this code will never happen, so O_NONBLOCK is still in the default 
case, which appears to be OFF (unset).

However, then we look at line 396, which reads:
	if (fcntl(fd, F_SETFL, initfdflags | O_NONBLOCK) == -1) {
	    syslog(LOG_ERR, "Couldn't set device to non-blocking mode: %m");
	    die(1);
	}

Which seems to tell me to set O_NONBLOCK, reguardless of whether we want to
use modem control lines or not. Once in a non-blocking state, pppd is free
to spin completely out of control. This is the last invokation I've found that
effects the O_NONBLOCK attribute.

Now, in my opinion, this seems backwards. Wouldn't I potentially want to turn
O_NONBLOCK  _ON_ first, in order to dial out, then turn it _OFF_ 
unconditionally? Perhaps I'm missing something, but it seems strange. Please,
set me straight....

	-Brian



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706022051.QAA00272>