Blocking code for Windows Pipes.

[George S. Lockwood]

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!
>