NDIS MINIPORT MiniPortSend() not called after ASSOC
Mai Kee Reiss
in my own WLAN Miniport Driver, NDIS sometimes does not start
transmitting the 1st data packet (usually the 1st key of the WPA/PSK
EAPOL 4-way-handshake).
I have absolutely no idea, why
What I have is:
After getting the interrupt from WLAN Chip, which is reporting "okay
from 802.11 ASSOC", I send to NDIS:
NdisMIndicateStatus ( Adapter->MyAdapterHdl,
NDIS_STATUS_MEDIA_DISCONNECT,
NULL, 0 );
NdisMIndicateStatusComplete ( Adapter->MyAdapterHdl );
Is this _not_ enought to force NDIS the start of Tx/Rx?
The last status was _not_ NDIS_STATUS_RESSOURCES, so NdisMSendComplete()
could also not be the reason, right?
in fact, I get this problems right after rebooting the device, so the
Miniport can not be in NDIS_STATUS_RESSOURCES state, I assume...
BTW:
the driver is currently build for WinCE5.0, which is NDIS 5.1.
The port for WinXP is long time not maintained and the hardware is also
no longer avail for desktop. Thus, I cannot check if I have the same
problems under any WinNT.
Any help is highly appreciated!
--
Mai Kee Reiss
Pavel A.
wonder why you don't get any sends, right?
--PA
"Mai Kee Reiss" <MaiK_NOS...@yahoo.de> wrote in message
news:MPG.22e7165a6...@mail.home...
Peter
NDIS_STATUS_MEDIA_DISCONNECT) before you see your MiniportSendPackets
function get called.
"Mai Kee Reiss" <MaiK_NOS...@yahoo.de> wrote in message
news:MPG.22e7165a6...@mail.home...
Mai Kee Reiss
I'm sorry for the confusion - of course I am indicating "CONNECT", not
"DISCONNECT". It was a typo. My mistake. Please apologize for the
inconvinience!
What I _exactly_ do is:
1st)
after MiniportInitialize() is finished, I force the next call to
MiniportSetInformation() or MiniportQueryInformation() to call my so
called "Deferred Disconnect Indicator" once. Since NdisMIndicateStatus()
is forbidden in MiniportInitialize(), I shifted the Disconnect-
indication just into the next call. It looks mostly like:
if( Adapter->NotYetDeferredDSC ){
if( Adapter->NotYetReportedDSC )
{
NdisMIndicateStatus ( Adapter->MyAdapterHdl,
NDIS_STATUS_MEDIA_DISCONNECT,
NULL, 0 );
NdisMIndicateStatusComplete ( Adapter->MyAdapterHdl );
Adapter->NotYetReportedDSC = FALSE;
Adapter->NotYetDeferredDSC = FALSE;
}}
2nd)
when starting the Assoc - right after a "Specific Scan" which again
takes place because of a MiniportSetInformation( OID_802_11_SSID ) - I
start an episodic 10.000ms timer, which will also do this
if( Adapter->NotYetReportedDSC )
{
NdisMIndicateStatus ( Adapter->MyAdapterHdl,
NDIS_STATUS_MEDIA_DISCONNECT,
NULL, 0 );
NdisMIndicateStatusComplete ( Adapter->MyAdapterHdl );
Adapter->NotYetReportedDSC = FALSE;
}
but only, if I do not cancel the timer before that 10s.
3rd)
when getting positive ASSOC response (in my case, it's an interrupt with
a hardware specific response code), I cancel the timer and instead of
the timers DISCONNECT, I indicate
NdisMIndicateStatus ( Adapter->MyAdapterHdl,
NDIS_STATUS_MEDIA_CONNECT,
NULL, 0 );
NdisMIndicateStatusComplete ( Adapter->MyAdapterHdl );
Adapter->NotYetReportedDSC = TRUE;
(3b)
when _not_ getting positive ASSOC, the timer ist still running,
so I have time left to retry the scan and the assoc, multiple times.
Am I on the right way till here?
in normal cases (positive ASSOC response), the WZC supplicant will now
transmit the 1st EAPOL packet of the well known 4-way-handshake and the
rest runs fine.
But _very_ often, I don't get any call for MiniportSend().
this occurs:
- just after 1st soft-reset (in wince it is a little bit like ctrl-alt-
del), i need to do it to get my driver loaded
- then after each 2nd soft-reset
- or after each 2nd suspend/resume.
I tracked all cases where I use NdisMIndicateStatusXxxx() with
RETAILMSG, there is never a "stacked" DISCONNECT, but sometimes a
"stacked" CONNECT - later is specified to be required in the MSDN for
some roaming cases (in my eyes, the way I read the
<http://msdn.microsoft.com/en-us/library/aa913036.aspx> "Media Status
Indications for Infrastructure Networks" document).
or, is MicroSoft documentation wrong and the stacked CONNECT is a
failure?
Or does anything other control the TX too? Since I not returned
NDIS_STATUS_RESSOURCES until here, it cannot be
NdisMSendRessourcesAvailable(), right?
what the h*** is it?
Any idea?
--
Mai Kee Reiss
Pavel A.
> Hi Pavel, Peter,
>
> I'm sorry for the confusion - of course I am indicating "CONNECT", not
> "DISCONNECT". It was a typo. My mistake. Please apologize for the
> inconvinience!
ok...
> What I _exactly_ do is:
>
> 1st)
<snip>
> 2nd)
<snip>
> 3rd)
<snip>
> Am I on the right way till here?
Yes, all this looks ok more or less
> in normal cases (positive ASSOC response), the WZC supplicant will now
> transmit the 1st EAPOL packet of the well known 4-way-handshake and the
> rest runs fine.
> But _very_ often, I don't get any call for MiniportSend().
>
> this occurs:
> - just after 1st soft-reset (in wince it is a little bit like ctrl-alt-
> del), i need to do it to get my driver loaded
> - then after each 2nd soft-reset
> - or after each 2nd suspend/resume.
Hope your question applies now only to your WinXP port. Sorry I don't
exactly remember how it worked in WinCE.
> I tracked all cases where I use NdisMIndicateStatusXxxx() with
> RETAILMSG, there is never a "stacked" DISCONNECT, but sometimes a
> "stacked" CONNECT - later is specified to be required in the MSDN for
> some roaming cases (in my eyes, the way I read the
> <http://msdn.microsoft.com/en-us/library/aa913036.aspx> "Media Status
> Indications for Infrastructure Networks" document).
>
> or, is MicroSoft documentation wrong and the stacked CONNECT is a
> failure?
no, the documentation is correct.
> Or does anything other control the TX too? Since I not returned
> NDIS_STATUS_RESSOURCES until here, it cannot be
> NdisMSendRessourcesAvailable(), right?
>
> what the h*** is it?
>
> Any idea?
Yes there may be some other reasons why TX won't occur.
Does your driver work well in unsecure mode (without supplicant, 4 way, etc)
?
Regards,
Mai Kee Reiss
I have completely rewritten the CONNECT/DISCONNECT signalling, regarding
the MSDN papers. Now it works most times. Have still some problems unter
WinCE500, but /very/ rare now.
Thank you for your hints!
As far as I can see, other chipsets and other driver authors suffering
the same problems with the same frequency - so there may be a bug in the
WinCE CoreOS or in the MSDN Papers. It's a pitty to not having the NDIS
source code within WinCE600...
I still have some problems with the first ASSOC on the Marvel 88w8385.
But this is out of topic here.
B.T.W.:
does anybody know a good group/area/board/echo/list/net/blog/forum for
the Marvel chipset?
I can read all inclusive god old FidoNet here...
--
Mai Kee Reiss