Data in "verifying username and password" phase of Dial up

Podun_Yu · September 14, 2010, 2:16am

I am developing a driver for usb to serial , when I plug in the device into PC, In device management ,It appear a com port for communication.

It runs fine in Hyper Terminal and normal Read/Write . But I block in Dail up to Internet with this driver.

So I intercept the request of the “usbser.sys” which is provided by Microsoft by contrast .
I added the upper filter driver and lower filter driver to usbser. and use the driver to dial up to internet .Here are the logs ,and “LowFlter :” section is the log from lower filter driver.otherwise from upper filter driver.

When I sending “ATDT*99#” command , the Modem driver reply me the “CONNECT” and raise the DCD , that means Modem will switch command mode to data mode . and PC will communicate with the PPP module.

what I am puzzled is that after “CONNECT” phase ,there is a read 3114 bytes Request . and It was complete by usbser driver but sending down to the lower driver .
what data in this request ? (This Request was Reuse several times . same data ?)

This is the phase “verifying username and password” of PC dial up to Internet ,Does it means that data in request is the username and password ?

Should my driver implement any communication protocol ?( Besides I start a continuous reader in BulkIN and InterruptIN pipes In my new usb2serial driver,I didn’t catch any data In this phase.)

LOG :
IRP_MJ_CREATE
IRP_MJ_CLEANUP
IOCTL_MODEM_CHECK_FOR_MODEM
IOCTL_SERIAL_SET_DTR

LowFlter : URB_FUNCTION_CLASS_INTERFACE
IOCTL_SERIAL_INTERNAL_CANCEL_WAIT_WAKE
IOCTL_SERIAL_GET_PROPERTIES
IOCTL_SERIAL_GET_BAUD_RATE
LowFlter : URB_FUNCTION_CLASS_INTERFACE
IOCTL_SERIAL_GET_LINE_CONTROL
LowFlter : URB_FUNCTION_CLASS_INTERFACE
IOCTL_SERIAL_GET_CHARS
IOCTL_SERIAL_GET_HANDFLOW
IOCTL_SERIAL_SET_BAUD_RATE
LowFlter : URB_FUNCTION_CLASS_INTERFACE
LowFlter : URB_FUNCTION_CLASS_INTERFACE
IOCTL_SERIAL_SET_DTR
LowFlter : URB_FUNCTION_CLASS_INTERFACE
IOCTL_SERIAL_SET_LINE_CONTROL
LowFlter : URB_FUNCTION_CLASS_INTERFACE
LowFlter : URB_FUNCTION_CLASS_INTERFACE
IOCTL_SERIAL_SET_CHARS
IOCTL_SERIAL_SET_HANDFLOW
IOCTL_SERIAL_PURGE (03)
IOCTL_SERIAL_CLEAR_STATS
IOCTL_SERIAL_PURGE (02)
IOCTL_SERIAL_SET_TIMEOUTS(RI=20,WC= 2000,WM=10)
IOCTL_SERIAL_GET_COMMSTATUS
IOCTL_SERIAL_GET_BAUD_RATE
LowFlter : URB_FUNCTION_CLASS_INTERFACE
IOCTL_SERIAL_GET_LINE_CONTROL
LowFlter : URB_FUNCTION_CLASS_INTERFACE
IOCTL_SERIAL_GET_CHARS
IOCTL_SERIAL_GET_HANDFLOW
IOCTL_SERIAL_SET_BAUD_RATE
LowFlter : URB_FUNCTION_CLASS_INTERFACE
IOCTL_SERIAL_SET_DTR
LowFlter : URB_FUNCTION_CLASS_INTERFACE
IOCTL_SERIAL_SET_LINE_CONTROL
LowFlter : URB_FUNCTION_CLASS_INTERFACE
LowFlter : URB_FUNCTION_CLASS_INTERFACE
IOCTL_SERIAL_SET_CHARS
IOCTL_SERIAL_SET_HANDFLOW
IOCTL_SERIAL_SET_DTR
LowFlter : URB_FUNCTION_CLASS_INTERFACE
IOCTL_SERIAL_GET_MODEMSTATUS

Write 3 bytes (AT.)
LowFlter : URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
IOCTL_SERIAL_GET_COMMSTATUS(in = 0x05 ,out = 0x00)
Read : .OK…
IOCTL_SERIAL_GET_COMMSTATUS(in = 0x00 ,out = 0x00)

Write 7 Bytes (ATE0V1.)
LowFlter : URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
IOCTL_SERIAL_GET_COMMSTATUS(in = 0x05 ,out = 0x00)
Read : .OK…
IOCTL_SERIAL_GET_COMMSTATUS(in = 0x00 ,out = 0x00)

Write 3 bytes (AT.)
LowFlter : URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
IOCTL_SERIAL_GET_COMMSTATUS(in = 0x05 ,out = 0x00)
Read : .OK…
IOCTL_SERIAL_GET_COMMSTATUS(in = 0x00 ,out = 0x00)

Write 7 Bytes (ATS0=0.)
LowFlter : URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
IOCTL_SERIAL_GET_COMMSTATUS(in = 0x05 ,out = 0x00)
Read : .OK…
IOCTL_SERIAL_GET_COMMSTATUS(in = 0x00 ,out = 0x00)

Write 3 bytes (AT.)
LowFlter : URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
IOCTL_SERIAL_GET_COMMSTATUS(in = 0x05 ,out = 0x00)
Read : .OK…
IOCTL_SERIAL_GET_COMMSTATUS(in = 0x00 ,out = 0x00)

IOCTL_SERIAL_SET_WAIT_MASK (0x10)
IOCTL_SERIAL_WAIT_ON_MASK (0x00)
IOCTL_SERIAL_CLEAR_STATS
IOCTL_SERIAL_GET_BAUD_RATE
LowFlter : URB_FUNCTION_CLASS_INTERFACE
IOCTL_SERIAL_GET_LINE_CONTROL
LowFlter : URB_FUNCTION_CLASS_INTERFACE
IOCTL_SERIAL_GET_CHARS
IOCTL_SERIAL_GET_HANDFLOW
IOCTL_SERIAL_SET_BAUD_RATE
LowFlter : URB_FUNCTION_CLASS_INTERFACE
LowFlter : URB_FUNCTION_CLASS_INTERFACE
IOCTL_SERIAL_SET_DTR
LowFlter : URB_FUNCTION_CLASS_INTERFACE
IOCTL_SERIAL_SET_LINE_CONTROL
LowFlter : URB_FUNCTION_CLASS_INTERFACE
LowFlter : URB_FUNCTION_CLASS_INTERFACE
IOCTL_SERIAL_SET_CHARS
IOCTL_SERIAL_SET_HANDFLOW
IOCTL_SERIAL_SET_DTR
LowFlter : URB_FUNCTION_CLASS_INTERFACE

IOCTL_SERIAL_GET_MODEMSTATUS
Write 3 bytes (AT.)
LowFlter : URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
IOCTL_SERIAL_GET_COMMSTATUS(in = 0x05 ,out = 0x00)
Read : .OK…
IOCTL_SERIAL_GET_COMMSTATUS(in = 0x00 ,out = 0x00)

Write 7 Bytes (ATE0V1.)
LowFlter : URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
IOCTL_SERIAL_GET_COMMSTATUS(in = 0x05 ,out = 0x00)
Read : .OK…
IOCTL_SERIAL_GET_COMMSTATUS(in = 0x00 ,out = 0x00)

Write 3 bytes (AT.)
LowFlter : URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
IOCTL_SERIAL_GET_COMMSTATUS(in = 0x05 ,out = 0x00)
Read : .OK…
IOCTL_SERIAL_GET_COMMSTATUS(in = 0x00 ,out = 0x00)

Write 9 Bytes (ATDT*99#)
LowFlter : URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
IOCTL_SERIAL_GET_COMMSTATUS(in = 0x0a ,out = 0x00)
Read : CONNECT
IOCTL_SERIAL_GET_COMMSTATUS(in = 0x00 ,out = 0x00)

Interrupt IN (Raise DCD)

IOCTL_SERIAL_GET_MODEMSTATUS (0x00)
IOCTL_SERIAL_GET_MODEMSTATUS (0x90)
IOCTL_SERIAL_SET_WAIT_MASK(0x00)
IOCTL_SERIAL_SET_WAIT_MASK(0x30)
IOCTL_SERIAL_WAIT_ON_MASK (0x00)
IOCTL_SERIAL_SET_WAIT_MASK(0x00)
IOCTL_SERIAL_WAIT_ON_MASK (0x00)
IOCTL_SERIAL_SET_WAIT_MASK(0x30)

IOCTL_SERIAL_GET_BAUD_RATE
LowFlter : URB_FUNCTION_CLASS_INTERFACE
IOCTL_SERIAL_GET_LINE_CONTROL
LowFlter : URB_FUNCTION_CLASS_INTERFACE
IOCTL_SERIAL_GET_CHARS
IOCTL_SERIAL_GET_HANDFLOW
IOCTL_SERIAL_GET_BAUD_RATE
LowFlter : URB_FUNCTION_CLASS_INTERFACE
IOCTL_SERIAL_GET_LINE_CONTROL
LowFlter : URB_FUNCTION_CLASS_INTERFACE
IOCTL_SERIAL_GET_CHARS
IOCTL_SERIAL_GET_HANDFLOW
IOCTL_SERIAL_GET_STATS
IOCTL_SERIAL_SET_QUEUE_SIZE(1514,1514)
IOCTL_SERIAL_PURGE(0xE)
IOCTL_SERIAL_GET_BAUD_RATE
LowFlter : URB_FUNCTION_CLASS_INTERFACE
IOCTL_SERIAL_GET_LINE_CONTROL
LowFlter : URB_FUNCTION_CLASS_INTERFACE
IOCTL_SERIAL_SET_BAUD_RATE
LowFlter : URB_FUNCTION_CLASS_INTERFACE
LowFlter : URB_FUNCTION_CLASS_INTERFACE
IOCTL_SERIAL_SET_DTR
LowFlter : URB_FUNCTION_CLASS_INTERFACE
IOCTL_SERIAL_SET_LINE_CONTROL
LowFlter : URB_FUNCTION_CLASS_INTERFACE
LowFlter : URB_FUNCTION_CLASS_INTERFACE
IOCTL_SERIAL_SET_QUEUE_SIZE(4096,4096)
IOCTL_SERIAL_SET_TIMEOUTS(RI=-1,RC=0,RM=0,WC=4000,WM=4)
IOCTL_SERIAL_GET_CHARS(Eof=0,err=0,break=0,event=0,x0n=17,xoff=19)
IOCTL_SERIAL_SET_CHARS(Eof=0,err=0,break=0,event=126,x0n=17,xoff=19)
IOCTL_SERIAL_SET_WAIT_MASK(0x4b2)
IOCTL_SERIAL_WAIT_ON_MASK (0x000)
Read 3114 Bytes (IRP:0x88F2CE48)
Read Complete 3114 Bytes(IRP:0x88F2CE48)
Write 53 Bytes
LowFlter : URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER

Complete IOCTL_SERIAL_WAIT_ON_MASK with 0x407
IOCTL_SERIAL_WAIT_ON_MASK(0x407)

Read 3114 Bytes (IRP:0x88F2CE48)
Read Complete 3114 Bytes(IRP:0x88F2CE48)

Write 43 Bytes
LowFlter : URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER

Complete IOCTL_SERIAL_WAIT_ON_MASK with 0x403
IOCTL_SERIAL_WAIT_ON_MASK(0x403)

Read 3113 Bytes (IRP:0x88F2CE48)
Read Complete 3113 Bytes(IRP:0x88F2CE48)

Write 47 Bytes
LowFlter : URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER

Complete IOCTL_SERIAL_WAIT_ON_MASK with 0x407
IOCTL_SERIAL_WAIT_ON_MASK(0x407)

Read 3113 Bytes (IRP:0x88F2CE48)
Read Complete 3113 Bytes(IRP:0x88F2CE48)

Podun_Yu · September 14, 2010, 9:01am

I check the data of the usbser,where it read 3114 Bytes :

the data sequence:

Does it means that usbser driver read something privately/independent file ?

Chris_Aseltine · September 14, 2010, 11:20am

Podun Yu wrote:

what I am puzzled is that after “CONNECT” phase ,there is a
read 3114 bytes Request . and It was complete by usbser driver
but sending down to the lower driver . what data in this request ?
(This Request was Reuse several times . same data ?)

I’m having a little trouble parsing your grammar so let me just give you some general information here:

DUN is issuing the 3,114 byte reads to your driver. There is not necessarily any “data” in that “request”, it’s a read request which may be pended, completed partially, or completed completely according to the rules and regulations of the serial spec.
The activity between the modem driver and the “lower driver” (the USB PDO) is independent of the activity between DUN and your modem driver. Serial is a buffered interface so there is not necessarily connection (although there can be) between any I/O that you are seeing coming into the upper edge or going out of the lower edge.
You asked, “should my driver implement any communication protocol?” Answer: yes, it should fully and completely implement all the serial IOCTLs correctly as well as properly implement all their associated timeout semantics (don’t miss any!), otherwise your driver will never really work. If you can’t connect a PPP session using DUN, your driver’s implementation is complete. Why aren’t you using usbser in the first place?
Your post about the beginning of an HTML document – that’s just what was transmitted over the wire, did you surf to a web page once you were connected? There is no “private or independent file”.

Podun_Yu · September 14, 2010, 9:36pm

Thanks for your advance!

DUN is issuing the 3,114 byte reads to your driver. There is not
necessarily any “data” in that “request”, it’s a read request which may be
pended, completed partially, or completed completely according to the rules and
regulations of the serial spec.
At that time I didn’t have any ‘data’ , And with the timeout reason ,I should complete
this read request with length = 0 immediately .
so how can it complete the wait mask ,and issue the next Mask?
Log :Complete IOCTL_SERIAL_WAIT_ON_MASK with 0x407
IOCTL_SERIAL_WAIT_ON_MASK(0x407)

The activity between the modem driver and the “lower driver” (the USB PDO)
is independent of the activity between DUN and your modem driver. Serial is a
buffered interface so there is not necessarily connection (although there can
be) between any I/O that you are seeing coming into the upper edge or going out
of the lower edge.

So the usb to serial driver just doing the transmission ?

You asked, “should my driver implement any communication protocol?” Answer:
yes, it should fully and completely implement all the serial IOCTLs correctly
as well as properly implement all their associated timeout semantics (don’t miss
any!), otherwise your driver will never really work. If you can’t connect a PPP
session using DUN, your driver’s implementation is complete. Why aren’t you
using usbser in the first place?

Sorry ,Maybe my words misleading you . I means that should complete any protocol ,like TCP/IP
UDP or other networking protocol .
Yes ,I know I should Implement all the IOCTL_SERIAL_XXX set of IOCTLS,and implement the timeout semantics , It may be some mistake about the waitmask with the read right,I will check it .
At least It works well in Hyper Terminal.

Your post about the beginning of an HTML document – that’s just what was
transmitted over the wire, did you surf to a web page once you were connected?
There is no “private or independent file”.

It is nice to hearing that There is no “private or independent file”.
It doesn’t connect to network yet ,I did not surf to a web page . are the DUN will attach to a Web before connected?

Chris_Aseltine · September 14, 2010, 10:44pm

Podun Yu wrote:

At that time I didn’t have any ‘data’ , And with the
timeout reason ,I should complete this read request
with length = 0 immediately . so how can it complete
the wait mask ,and issue the next Mask?

Well, let’s see. 0x407 is the combination of received-any-character, received-certain-character, transmit-queue-empty, and 80%-full. Are any of those conditions occuring?

So the usb to serial driver just doing the transmission ?

It’s making the device side, which in the end is just two pipes of data, behave as if it were a serial port. It’s not really “just” doing transmission, except on the write path I suppose.

I means that should complete any protocol ,like TCP/IP UDP
or other networking protocol .

No, those would be layered on top of PPP … which in turn would just go over the serial interface.

At least It works well in Hyper Terminal.

Ha, right. A bit premature to declare victory, trust me.

It doesn’t connect to network yet ,I did not surf to a web page
. are the DUN will attach to a Web before connected?

Well, consider that any number of these things may occur when the system detects a live connection:

Windows Update (and its related ilk) may start pulling down stuff.
Installed malware will phone home.
A bunch of UPnP, NetBIOS, etc. broadcasts will start going out.

In other words you shouldn’t expect the connection to be “idle” in lieu of any user-generated activity.

Podun_Yu · September 14, 2010, 11:31pm

>Well, let’s see. 0x407 is the combination of received-any-character,

received-certain-character, transmit-queue-empty, and 80%-full. Are any of
those conditions occuring?
I did not get any char in the Bulk IN continuous reader .so Just the transmit-queue-empty May be happen , I didn’t think that I can complete the WAIT_ON mask with 0x407 . the driver is USB ,not real com port ,can the received-certain-character be happened ?

No, those would be layered on top of PPP … which in turn would just go over
the serial interface.

ok , I will give up the idea.

Ha, right. A bit premature to declare victory, trust me.
Yeath ,i Know it still has a long way to go.

Windows Update (and its related ilk) may start pulling down stuff.

Installed malware will phone home.

A bunch of UPnP, NetBIOS, etc. broadcasts will start going out.

I will check these things ,and I don’t care the data , So any one of things happened will no influence the Dial-up flow ,right?

In other words you shouldn’t expect the connection to be “idle” in lieu of any
user-generated activity.
I don’t really catch you . that means the connection always be busy in processing activity?

Chris_Aseltine · September 15, 2010, 9:24am

Podun Yu wrote:

I did not get any char in the Bulk IN continuous reader .

I find that hard to believe. You issued ATD*99# (or whatever) and heard only utter silence from the other side? Come on.

the driver is USB ,not real com port ,can the
received-certain-character be happened ?

I guess my question back to you would be, why do you think the nature of the physical transport has anything to do with whether a certain character can be received?

I will check these things ,and I don’t care the data , So any
one of things happened will no influence the Dial-up flow ,
right?

I’m not sure what you’re asking. If you’re asking if they can interfere with successfully establishing a dial-up connection, then generally speaking, no, they cannot. If you’re asking if they can “influence” the connection, well, of course they can. Once it’s up, of course.

I don’t really catch you . that means the connection always
be busy in processing activity?

Not “always”, but some of the time, especially immediately after the connection is established. What I’m really saying is, don’t jump to any conclusions about your driver working (or not) because of what data you see going across the wire.

Podun_Yu · September 15, 2010, 10:05am

>I find that hard to believe. You issued ATD*99# (or whatever) and heard only

utter silence from the other side? Come on.

It sets timeouts (RI = -1 ,RC = 0,RM=0, WC= 4000,WM =4).and with timeouts semantics ,I should return immediately with what I had . before this read request time out ,I got 43 Bytes data from PPP module (ha begin with 0x7e ,and end with 0x7e).

I guess my question back to you would be, why do you think the nature of the
physical transport has anything to do with whether a certain character can be
received?

I had got the answer.haha .It set event char = ‘~’ ,so when PPP send any data ,and “wait on request” has the mask = SERIAL_EV_RXFLAG, the wait on mask would be completed.

I’m not sure what you’re asking. If you’re asking if they can interfere with
successfully establishing a dial-up connection, then generally speaking, no,
they cannot. If you’re asking if they can “influence” the connection, well, of
course they can. Once it’s up, of course.

this one :If you’re asking if they can interfere with successfully establishing a dial-up connection.

Thank you so much !
Wish you have a good day !

Chris_Aseltine · September 15, 2010, 11:35am

Podun Yu wrote:

It sets timeouts (RI = -1 ,RC = 0,RM=0, WC= 4000,WM =4).
and with timeouts semantics ,I should return immediately
with what I had .

I think you’re correct here and are taking the appropriate action. I looked at some old DUN logs from my modem driver and I see the same thing.

I had got the answer.haha .It set event char = ‘~’ ,so when
PPP send any data ,and “wait on request” has the mask =
SERIAL_EV_RXFLAG, the wait on mask would be completed.

Ahh … now you’re getting it …