Re: problems with USB/CDC serial (umodem) - devices work with Linux, Mac OS X, and FreeBSD, but not NetBSD

[Rob Newberry <robthedude%mac.com@localhost>]

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 <mlelstv%serpens.de@localhost> wrote:
> 
> robthedude%mac.com@localhost (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: mlelstv%serpens.de@localhost
>                                "A potential Snark may lurk in every tree."