Blocking code for Windows Pipes.
George S. Lockwood
gslockwood
Wed Aug 23 13:23:12 PDT 2006
I am also finding that the ReadPipe just goes off and never returns??
g
On 8/23/06, George S. Lockwood <gslockwood at gmail.com> wrote:
> Regarding my earlier Pipe blocking msg:
>
> I've noticed the following in the supplicant's console log. I believe
> the "1156357958.468750: CTRL: wpa_supplicant_global_iface_receive" msg
> occurs when my app does the following:
>
> if (m_szCtrl_ifname == NULL)
> {
> m_szCtrl_ifname = wpa_cli_get_default_ifname();
> }
>
> this is at initialzation the very first use.....is the ReadFileEx
> failed: 109 a problem?
>
> LOG:
>
> 1156357896.796875: Connected to ROOT\WMI.
> 1156357896.906250: NDIS: Set OID 0d010108 - hexdump(len=4): [REMOVED]
> 1156357896.906250: NDIS: WZCEnumInterfaces: 1 interfaces
> 1156357896.906250: NDIS: intfs 0 GUID '{556DEBC4-B686-4A77-A2D8-7F34F3A5708F}'
> 1156357896.906250: NDIS: Current interface found from WZC
> 1156357896.921875: NDIS: WZC interface flags 0x8000 dwCtlFlags 0x0
> 1156357896.921875: NDIS: WZC was not enabled for this interface
> 1156357896.921875: Driver interface replaced interface name with '{556DEBC4-B686
> -4A77-A2D8-7F34F3A5708F}'
> 1156357896.937500: Own MAC address: 00:16:6f:4e:02:c7
> 1156357896.937500: __func__ not defined: enabled=1
> 1156357896.937500: __func__ not defined: oid=0xd010101 len (6) failed
> 1156357896.937500: NDIS: Set OID 0d01011e - hexdump(len=16): [REMOVED]
> 1156357896.937500: NDIS: Set OID 0d010114 - hexdump(len=4): [REMOVED]
> 1156357896.937500: __func__ not defined: oid=0xd010101 len (6) failed
> 1156357896.937500: NDIS: Set OID 0d01011e - hexdump(len=16): [REMOVED]
> 1156357896.937500: NDIS: Set OID 0d010114 - hexdump(len=4): [REMOVED]
> 1156357896.937500: __func__ not defined: oid=0xd010101 len (6) failed
> 1156357896.953125: NDIS: Set OID 0d01011e - hexdump(len=16): [REMOVED]
> 1156357896.953125: NDIS: Set OID 0d010114 - hexdump(len=4): [REMOVED]
> 1156357896.953125: __func__ not defined: oid=0xd010101 len (6) failed
> 1156357896.953125: NDIS: Set OID 0d01011e - hexdump(len=16): [REMOVED]
> 1156357896.953125: NDIS: Set OID 0d010114 - hexdump(len=4): [REMOVED]
> 1156357896.953125: Setting scan request: 0 sec 100000 usec
> 1156357896.953125: CTRL: Open pipe 00B177E0
> 1156357896.953125: CTRL: ConnectNamedPipe: connection in progress
> 1156357896.953125: Added interface {556DEBC4-B686-4A77-A2D8-7F34F3A5708F}
> 1156357897.062500: State: DISCONNECTED -> SCANNING
> 1156357897.062500: Starting AP scan (broadcast SSID)
> 1156357897.062500: Trying to get current scan results first without requesting a
> new scan to speed up initial association
> 1156357897.062500: Scan results: 0
> 1156357897.062500: No suitable AP found.
> 1156357897.062500: Setting scan request: 0 sec 0 usec
> 1156357897.062500: No enabled networks - do not scan
> 1156357897.062500: State: SCANNING -> INACTIVE
> 1156357897.750000: __func__ not defined: oid=0xd010101 len (6) failed
> 1156357958.468750: CTRL: wpa_supplicant_global_iface_receive
> 1156357958.468750: CTRL: GetOverlappedResult: New client connected
> 1156357958.468750: CTRL: Open pipe 00B179D0
> 1156357958.468750: CTRL: ConnectNamedPipe: connection in progress
> 1156357958.468750: CTRL: Overlapped write completed: dst=00B13DC8 err=0 bytes=0
> 1156357958.468750: CTRL: Overlapped read started for 00B13DC8
> 1156357958.468750: CTRL: Overlapped read completed: dst=00B13DC8 err=0 bytes=10
> 1156357958.468750: RX global ctrl_iface - hexdump_ascii(len=10):
> 49 4e 54 45 52 46 41 43 45 53 INTERFACES
> 1156357958.484375: CTRL: Overlapped write started for 00B13DC8
> 1156357958.484375: CTRL: Overlapped write completed: dst=00B13DC8 err=0 bytes=39
>
> 1156357958.484375: CTRL: ReadFileEx failed: 109
> 1156357958.484375: CTRL: close pipe 00B13DC8
> 1156357958.484375: CTRL: Overlapped read started for 00B13DC8
>
>
> On 8/23/06, George S. Lockwood <gslockwood at gmail.com> wrote:
> > Hello, I have implemented the new s/w code for the windows named pipe
> > resource and it works fine for using the single wpa_ctrl (and
> > attached) to send msgs.
> >
> > However, when I implemented a second wpa_ctrl (and attached to it
> > instead of the first) to monitor the unsolicited msg and using the
> > same code I set up to create a thread and block for the msgs for when
> > the s/w code was using udp sockets, it seems to block that thread and
> > never receive a msg to process.
> >
> > Have you already tested this out? Perhaps I need to adjust my code in some way?
> >
> > What exactly should I block for?
> >
> > Here's my the code my thread starts as is today (I pass a pointer to
> > my object so I can access the wpa_ctrl member):
> >
> > LPTHREAD_START_ROUTINE receiveMsgs( LPVOID lpParam )
> > {
> > char buf[256];
> > size_t len;
> >
> > CPPCWPA* pThis = NULL;
> >
> > if (lpParam)
> > pThis = (CPPCWPA*)lpParam;
> >
> > while( TRUE )
> > {
> > cout << "inside true" << endl;
> >
> > DWORD dwResult = WaitForSingleObject( (HANDLE)wpa_ctrl_get_fd(
> > pThis->m_pWpa_ctrlMonitor ), INFINITE );//m_pWpa_ctrlMonitor
> >
> > DWORD dwError = GetLastError();
> >
> > if (dwResult == WAIT_OBJECT_0)
> > {
> > if (pThis)
> > {
> > // don't need wpa_ctrl_pending with the WaitForSingleObject
> > //while( wpa_ctrl_pending( pThis->m_pWpa_ctrlMonitor ) ) //monitor_conn
> > {
> > len = sizeof(buf) - 1;
> > if (wpa_ctrl_recv( pThis->m_pWpa_ctrlMonitor, buf, &len) == 0)
> > //monitor_conn
> > {
> > buf[len] = '\0';
> > pThis->EventMessageHandler( buf, len );
> > }
> > }// end while
> > }
> > }
> > }
> >
> > return 0;
> > }
> >
> > thanks!
> >
>
More information about the Hostap
mailing list