Re: DTR Flow Control

[Mike McCormack]

Original message from: [email protected]
> On Mon, 25 Feb 2002, Michael Cardenas wrote:
> > Attached is the output of +relay,+file,+comm.

..
> May we see a
>
> wine --version, please?

Michael,

How about showing us the source you are using, so we can help you
debug it?

thanks in advance ;-)

Mike

------------------------------------------
mailto:[email protected]
ph [phone]

__________________________________________________________________
Get your free Australian email account at http://www.Looksmart.com.au

DTR Flow Control

[Michael Cardenas]

The parts of the source I'm using are not very different from yours.

I picked up the latest source and tried the app and it still has the same
behavior. It can talk to the modem enough to get it to connect to the ppp
server, but it cannot communicate over the network.

I've attached a trace using my app with the latest source. The application
seems to be stuck waiting for data and using ClearCommError to check the
number of bytes received. It calls GetOverlappedResult along with
GetLastError to check when the pending io operation has completed.

Maybe there's something wrong with the way overlapped io is implemented when
it interacts with a serial port. The documentation calls for the user to
manually set the file pointer when using overlappedio, which doesn't seem
like it would work on a serial port. The set_file_pointer function in
server.c doesn't check for serial ports, but I'm not familiar enough with
serial communications under linux to know if it matters. I tried to disable
set_file_pointer for serial ports, but this didn't seem to have any effect.

michael

----- Original Message -----
From: "Mike McCormack" [email protected]
To: [email protected]; [email protected]
Cc: [email protected]
Sent: Monday, February 25, 2002 6:37 PM
Subject: Re: DTR Flow Control
> How about showing us the source you are using, so we can help you
> debug it?

DTR Flow Control

[Andreas Mohr]

On Thu, Feb 28, 2002 at 06:42:28AM -0800, Michael Cardenas wrote:
> The parts of the source I'm using are not very different from yours.
>
> I picked up the latest source and tried the app and it still has the same
> behavior. It can talk to the modem enough to get it to connect to the ppp
> server, but it cannot communicate over the network.
>
> I've attached a trace using my app with the latest source. The application
> seems to be stuck waiting for data and using ClearCommError to check the
> number of bytes received. It calls GetOverlappedResult along with
> GetLastError to check when the pending io operation has completed.
>
> Maybe there's something wrong with the way overlapped io is implemented when
> it interacts with a serial port. The documentation calls for the user to
> manually set the file pointer when using overlappedio, which doesn't seem
> like it would work on a serial port. The set_file_pointer function in
> server.c doesn't check for serial ports, but I'm not familiar enough with
> serial communications under linux to know if it matters. I tried to disable
> set_file_pointer for serial ports, but this didn't seem to have any effect.

Just for the record:
I've also got some program which uses overlapped transmission and which
also doesn't work (some NEC 78K uController demo kit).

DTR Flow Control

On Thu, 28 Feb 2002, Michael Cardenas wrote:
> The parts of the source I'm using are not very different from yours.
>
> I picked up the latest source and tried the app and it still has the same
> behavior. It can talk to the modem enough to get it to connect to the ppp
> server, but it cannot communicate over the network.
>
> I've attached a trace using my app with the latest source. The application
> seems to be stuck waiting for data and using ClearCommError to check the
> number of bytes received. It calls GetOverlappedResult along with
> GetLastError to check when the pending io operation has completed.
>
> Maybe there's something wrong with the way overlapped io is implemented when
> it interacts with a serial port. The documentation calls for the user to
> manually set the file pointer when using overlappedio, which doesn't seem
> like it would work on a serial port. The set_file_pointer function in
> server.c doesn't check for serial ports, but I'm not familiar enough with
> serial communications under linux to know if it matters. I tried to disable
> set_file_pointer for serial ports, but this didn't seem to have any effect.

That doesn't make much sense to me.  I can't see why a comm port should
be lseekable, if that is what you mean.  I don't much trust Microsoft
doco either.  The app doesn't seem to be doing set_file_pointer on the
modem either.
> michael

I don't know about that yet, but it seems to me that GetCommState is
incorrectly creating lpdcb with fParity - if that is indeed what it is
and the structure and names are correct, and then the dumb app is just
using it.  Could you try it this helps?

diff -ur was/dlls/kernel/comm.c is/dlls/kernel/comm.c
--- was/dlls/kernel/comm.c	Fri Mar  1 15:19:45 2002
+++ is/dlls/kernel/comm.c	Sat Mar  2 23:22:09 2002
@@ -1235,19 +1235,17 @@
            default:
    	        ERR("unknown size %x \n",port.c_cflag & CSIZE);
    }	
-	
-        if(port.c_iflag & INPCK)
-            lpdcb->fParity = TRUE;
-        else
-            lpdcb->fParity = FALSE;
+
 #ifdef CMSPAR
    switch (port.c_cflag & (PARENB | PARODD | CMSPAR))
 #else
    switch (port.c_cflag & (PARENB | PARODD))
 #endif
    {
+                lpdcb->fParity = TRUE;
    	case 0:
    		lpdcb->Parity = NOPARITY;
+                        lpdcb->fParity = FALSE;
    		break;
    	case PARENB:
    		lpdcb->Parity = EVENPARITY;

________________________________________________________________
GET INTERNET ACCESS FROM JUNO!
Juno offers FREE or PREMIUM Internet access for less!
Join Juno today!  For your FREE software, visit:
http://dl.www.juno.com/get/web/.

DTR Flow Control

On Thu, 28 Feb 2002, Michael Cardenas wrote:
> The parts of the source I'm using are not very different from yours.
>
> I picked up the latest source and tried the app and it still has the same
> behavior. It can talk to the modem enough to get it to connect to the ppp
> server, but it cannot communicate over the network.
>
> I've attached a trace using my app with the latest source. The application
> seems to be stuck waiting for data and using ClearCommError to check the
> number of bytes received. It calls GetOverlappedResult along with
> GetLastError to check when the pending io operation has completed.
>
> Maybe there's something wrong with the way overlapped io is implemented when
> it interacts with a serial port. The documentation calls for the user to
> manually set the file pointer when using overlappedio, which doesn't seem
> like it would work on a serial port. The set_file_pointer function in
> server.c doesn't check for serial ports, but I'm not familiar enough with
> serial communications under linux to know if it matters. I tried to disable
> set_file_pointer for serial ports, but this didn't seem to have any effect.
>
> michael

Oops, I guess that was not the way to do it.  Could you try this
instead:

diff -ur was/dlls/kernel/comm.c is/dlls/kernel/comm.c
--- was/dlls/kernel/comm.c	Fri Mar  1 15:19:45 2002
+++ is/dlls/kernel/comm.c	Sun Mar  3 00:37:11 2002
@@ -1248,6 +1248,7 @@
    {
    	case 0:
    		lpdcb->Parity = NOPARITY;
+			lpdcb->fParity = FALSE;
    		break;
    	case PARENB:
    		lpdcb->Parity = EVENPARITY;

________________________________________________________________
GET INTERNET ACCESS FROM JUNO!
Juno offers FREE or PREMIUM Internet access for less!
Join Juno today!  For your FREE software, visit:
http://dl.www.juno.com/get/web/.

DTR Flow Control

[Rein Klazes]

On Sun, 3 Mar 2002 00:42:39 -0500 (EST), you wrote:
> Oops, I guess that was not the way to do it.  Could you try this
> instead:
>
> diff -ur was/dlls/kernel/comm.c is/dlls/kernel/comm.c
> --- was/dlls/kernel/comm.c	Fri Mar  1 15:19:45 2002
> +++ is/dlls/kernel/comm.c	Sun Mar  3 00:37:11 2002
> @@ -1248,6 +1248,7 @@
>    {
>    	case 0:
>    		lpdcb->Parity = NOPARITY;
> -
> 	lpdcb->fParity = FALSE;
> break;
> case PARENB:
> 	lpdcb->Parity = EVENPARITY;

Beware, it is possible for serial communication to have parity in one
direction only. My banking program uses parity when it sends data, but
there is no parity on the received characters. It is the opposite of
the case that is handled here, but the (il)logic is the same.

Rein.