Yes, that’s what it turned out to be (I figured it out late yesterday but forgot to send a note).
Any idea why Linux, Mac OS X, and FreeBSD all behave differently? I peeked at the FreeBSD code, and it appears to have handling for VMIN/VTIME similar to NetBSD — but the behavior for this application (configured the same way) is not like NetBSDs. I haven’t looked at the Mac OS X or Linux kernels. Anyway, thank you for pushing me in the right direction. I’ve got it working, and am now on to dealing with differences in the tun driver behavior — the application has some assumptions based on how Linux behaves. Rob > On Feb 22, 2019, at 10:07 PM, Michael van Elst <[email protected]> wrote: > > [email protected] (Rob Newberry) writes: > >> But the âreadâ call takes 25 seconds or more! > > That's your application. > > If configured with ",default" it sets all control characters to > _POSIX_VDISABLE, including the 'VMIN' and 'VTIME' characters. > > socket-utils.c:889 > > FETCH_TERMIOS(); > for (i=0; i < NCCS; i++) { > tios.c_cc[i] = _POSIX_VDISABLE; > } > > but > > If the value of one of the changeable special control characters (see > Special Characters) is {_POSIX_VDISABLE}, that function is disabled; that > is, no input data is recognized as the disabled special character. If > ICANON is not set, the value of {_POSIX_VDISABLE} has no special meaning > for the VMIN and VTIME entries of the c_cc array. > > _POSIX_VDISABLE is '\377', so your read waits for 255 chars and times > out after 255 tenth of a second. > > > Greetings, > -- > -- > Michael van Elst > Internet: [email protected] > "A potential Snark may lurk in every tree."
