Guys,
the documentation for OID_GEN_MAXIMUM_TOTAL_SIZE specifies that
The miniport driver must never indicate up to the bound protocol driver
packets received over the network that are longer than the packet size
specified by OID_GEN_MAXIMUM_TOTAL_SIZE.
I have at least two wi-fi network cards (with WHQL certified drivers) that
advertise that the total size is 1514 (the usual eth one), but then deliver
packets of 1572 bytes through the ProtocolReceivePacket handler.
Am I missing anything, or these two miniport drivers are violating the NDIS
specs?
Have a nice day
GV
Since ProtocolReceivePacket is a NDIS 5 callback and Native Wi-Fi miniports
are strictly NDIS 6, then perhaps this is a bug in the Vista NDIS 6-to-NDIS
5 shim.
I haven’t noticed this (yet) myself.
Thomas F. Divine
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-272360-
xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Friday, December 08, 2006 5:22 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] NDIS wi-fi miniport drivers - OID_GEN_MAXIMUM_TOTAL_SIZE
Guys,
the documentation for OID_GEN_MAXIMUM_TOTAL_SIZE specifies that
The miniport driver must never indicate up to the bound protocol driver
packets received over the network that are longer than the packet size
specified by OID_GEN_MAXIMUM_TOTAL_SIZE.
I have at least two wi-fi network cards (with WHQL certified drivers) that
advertise that the total size is 1514 (the usual eth one), but then
deliver
packets of 1572 bytes through the ProtocolReceivePacket handler.
Am I missing anything, or these two miniport drivers are violating the
NDIS
specs?
Have a nice day
GV
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
>> Native Wi-Fi miniports are strictly NDIS 6
I must be blind. I didn’t see in the OP where it said "Native WiFi’ or
ExtSTA Wifi.
AFAIK the OID_GEN_MAXIMUM_TOTAL_SIZE was one of those things that governed
the behavior of the the original ProtocolRecieve() ‘legacy’ miniport
handling. Since the NIC allocates the buffer(s) in the case of
ProtocolReceivePacket(), I suppose it is less important to remain within
that limit.
But the real curious thing is just what is in that 1572 octet packet?
Good Luck,
Dave Cattley
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Thomas F. Divine
Sent: Friday, December 08, 2006 6:07 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NDIS wi-fi miniport drivers -
OID_GEN_MAXIMUM_TOTAL_SIZE
Since ProtocolReceivePacket is a NDIS 5 callback and Native Wi-Fi miniports
are strictly NDIS 6, then perhaps this is a bug in the Vista NDIS 6-to-NDIS
5 shim.
I haven’t noticed this (yet) myself.
Thomas F. Divine
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-272360-
xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Friday, December 08, 2006 5:22 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] NDIS wi-fi miniport drivers -
OID_GEN_MAXIMUM_TOTAL_SIZE
Guys,
the documentation for OID_GEN_MAXIMUM_TOTAL_SIZE specifies that
The miniport driver must never indicate up to the bound protocol
driver packets received over the network that are longer than the
packet size specified by OID_GEN_MAXIMUM_TOTAL_SIZE.
I have at least two wi-fi network cards (with WHQL certified drivers)
that advertise that the total size is 1514 (the usual eth one), but
then deliver packets of 1572 bytes through the ProtocolReceivePacket
handler.
Am I missing anything, or these two miniport drivers are violating the
NDIS specs?
Have a nice day
GV
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
> -----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-272363-
xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Friday, December 08, 2006 6:29 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NDIS wi-fi miniport drivers -
OID_GEN_MAXIMUM_TOTAL_SIZE
>> Native Wi-Fi miniports are strictly NDIS 6
I must be blind. I didn’t see in the OP where it said "Native WiFi’ or
ExtSTA Wifi.
[PCAUSA] No, I must be seeing things…
Basically, NDIS 5.1 802.11 adapters have been around so long that my mind
couldn’t imagine that this could be a real issue - unless something new was
in the mix. Certainly someone would have hollered.
The only new thing that could be in the mix would be Vista.
I jumped to an unwarranted conclusion…
AFAIK the OID_GEN_MAXIMUM_TOTAL_SIZE was one of those things that governed
the behavior of the the original ProtocolRecieve() ‘legacy’ miniport
handling. Since the NIC allocates the buffer(s) in the case of
ProtocolReceivePacket(), I suppose it is less important to remain within
that limit.
[PCAUSA] The NDIS spec is still firm that that limit shouldn’t be exceeded.
Thomas F. Divine
But the real curious thing is just what is in that 1572 octet packet?
Good Luck,
Dave Cattley
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Thomas F. Divine
Sent: Friday, December 08, 2006 6:07 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NDIS wi-fi miniport drivers -
OID_GEN_MAXIMUM_TOTAL_SIZE
Since ProtocolReceivePacket is a NDIS 5 callback and Native Wi-Fi
miniports
are strictly NDIS 6, then perhaps this is a bug in the Vista NDIS 6-to-
NDIS
5 shim.
I haven’t noticed this (yet) myself.
Thomas F. Divine
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:bounce-272360-
> xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
> Sent: Friday, December 08, 2006 5:22 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] NDIS wi-fi miniport drivers -
> OID_GEN_MAXIMUM_TOTAL_SIZE
>
> Guys,
>
> the documentation for OID_GEN_MAXIMUM_TOTAL_SIZE specifies that
>
> The miniport driver must never indicate up to the bound protocol
> driver packets received over the network that are longer than the
> packet size specified by OID_GEN_MAXIMUM_TOTAL_SIZE.
>
> I have at least two wi-fi network cards (with WHQL certified drivers)
> that advertise that the total size is 1514 (the usual eth one), but
> then deliver packets of 1572 bytes through the ProtocolReceivePacket
> handler.
>
> Am I missing anything, or these two miniport drivers are violating the
> NDIS specs?
>
> Have a nice day
> GV
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Thomas, is of course, right that the OID_GEN_MAXIMUM_TOTAL_SIZE is *speced*
to govern both ProtocolReceive() and ProtocolReceivePacket(). I was just
musing that perhaps NDISTest does not really check for this possiblity
(especially on WiFi -how?) and that it could easily slip through WHQL.
I still come back to wondering what is in the packet 'cause it?s a touch too
big for an 802.3 packet, right?
Good Luck,
Dave Cattley
I forgot… I saw that on Win XP, so no NDIS6 frills…
GV
----- Original Message -----
From: “Thomas F. Divine”
To: “Windows System Software Devs Interest List”
Sent: Friday, December 08, 2006 3:07 PM
Subject: RE: [ntdev] NDIS wi-fi miniport drivers -
OID_GEN_MAXIMUM_TOTAL_SIZE
> Since ProtocolReceivePacket is a NDIS 5 callback and Native Wi-Fi
> miniports
> are strictly NDIS 6, then perhaps this is a bug in the Vista NDIS
> 6-to-NDIS
> 5 shim.
>
> I haven’t noticed this (yet) myself.
>
> Thomas F. Divine
>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com [mailto:bounce-272360-
>> xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
>> Sent: Friday, December 08, 2006 5:22 PM
>> To: Windows System Software Devs Interest List
>> Subject: [ntdev] NDIS wi-fi miniport drivers - OID_GEN_MAXIMUM_TOTAL_SIZE
>>
>> Guys,
>>
>> the documentation for OID_GEN_MAXIMUM_TOTAL_SIZE specifies that
>>
>> The miniport driver must never indicate up to the bound protocol driver
>> packets received over the network that are longer than the packet size
>> specified by OID_GEN_MAXIMUM_TOTAL_SIZE.
>>
>> I have at least two wi-fi network cards (with WHQL certified drivers)
>> that
>> advertise that the total size is 1514 (the usual eth one), but then
>> deliver
>> packets of 1572 bytes through the ProtocolReceivePacket handler.
>>
>> Am I missing anything, or these two miniport drivers are violating the
>> NDIS
>> specs?
>>
>> Have a nice day
>> GV
>>
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
----- Original Message -----
From: “David R. Cattley”
To: “Windows System Software Devs Interest List”
Sent: Friday, December 08, 2006 3:28 PM
Subject: RE: [ntdev] NDIS wi-fi miniport drivers -
OID_GEN_MAXIMUM_TOTAL_SIZE
>
> >> Native Wi-Fi miniports are strictly NDIS 6
>
> I must be blind. I didn’t see in the OP where it said "Native WiFi’ or
> ExtSTA Wifi.
>
> AFAIK the OID_GEN_MAXIMUM_TOTAL_SIZE was one of those things that governed
> the behavior of the the original ProtocolRecieve() ‘legacy’ miniport
> handling. Since the NIC allocates the buffer(s) in the case of
> ProtocolReceivePacket(), I suppose it is less important to remain within
> that limit.
>
> But the real curious thing is just what is in that 1572 octet packet?
Some APs support bigger packets. In this case it was a tunnel, but the
802.11 standard allows packets bigger than 1514. In any case, you can have
such bigger packets with GigaEthernet and jumbo frames…
GV
>
> Good Luck,
> Dave Cattley
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Thomas F. Divine
> Sent: Friday, December 08, 2006 6:07 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] NDIS wi-fi miniport drivers -
> OID_GEN_MAXIMUM_TOTAL_SIZE
>
> Since ProtocolReceivePacket is a NDIS 5 callback and Native Wi-Fi
> miniports
> are strictly NDIS 6, then perhaps this is a bug in the Vista NDIS
> 6-to-NDIS
> 5 shim.
>
> I haven’t noticed this (yet) myself.
>
> Thomas F. Divine
>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com [mailto:bounce-272360-
>> xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
>> Sent: Friday, December 08, 2006 5:22 PM
>> To: Windows System Software Devs Interest List
>> Subject: [ntdev] NDIS wi-fi miniport drivers -
>> OID_GEN_MAXIMUM_TOTAL_SIZE
>>
>> Guys,
>>
>> the documentation for OID_GEN_MAXIMUM_TOTAL_SIZE specifies that
>>
>> The miniport driver must never indicate up to the bound protocol
>> driver packets received over the network that are longer than the
>> packet size specified by OID_GEN_MAXIMUM_TOTAL_SIZE.
>>
>> I have at least two wi-fi network cards (with WHQL certified drivers)
>> that advertise that the total size is 1514 (the usual eth one), but
>> then deliver packets of 1572 bytes through the ProtocolReceivePacket
>> handler.
>>
>> Am I missing anything, or these two miniport drivers are violating the
>> NDIS specs?
>>
>> Have a nice day
>> GV
>>
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
The problem is that probably almost no APs support big packets like the ones
I’m seeing.
That’s why Ndistest doesn’t spot them. In any case you can have jumbo frames
with gigabit ethernet…
GV
----- Original Message -----
From: “David R. Cattley”
To: “Windows System Software Devs Interest List”
Sent: Friday, December 08, 2006 3:50 PM
Subject: RE: [ntdev] NDIS wi-fi miniport drivers -
OID_GEN_MAXIMUM_TOTAL_SIZE
Thomas, is of course, right that the OID_GEN_MAXIMUM_TOTAL_SIZE is speced
to govern both ProtocolReceive() and ProtocolReceivePacket(). I was just
musing that perhaps NDISTest does not really check for this possiblity
(especially on WiFi -how?) and that it could easily slip through WHQL.
I still come back to wondering what is in the packet 'cause it’s a touch too
big for an 802.3 packet, right?
Good Luck,
Dave Cattley
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
What adapters?
Any other filters in the stack?
Thomas F. Divine
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-272368-
xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Friday, December 08, 2006 7:34 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] NDIS wi-fi miniport drivers -
OID_GEN_MAXIMUM_TOTAL_SIZE
I forgot… I saw that on Win XP, so no NDIS6 frills…
GV
----- Original Message -----
From: “Thomas F. Divine”
> To: “Windows System Software Devs Interest List”
> Sent: Friday, December 08, 2006 3:07 PM
> Subject: RE: [ntdev] NDIS wi-fi miniport drivers -
> OID_GEN_MAXIMUM_TOTAL_SIZE
>
>
> > Since ProtocolReceivePacket is a NDIS 5 callback and Native Wi-Fi
> > miniports
> > are strictly NDIS 6, then perhaps this is a bug in the Vista NDIS
> > 6-to-NDIS
> > 5 shim.
> >
> > I haven’t noticed this (yet) myself.
> >
> > Thomas F. Divine
> >
> >> -----Original Message-----
> >> From: xxxxx@lists.osr.com [mailto:bounce-272360-
> >> xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
> >> Sent: Friday, December 08, 2006 5:22 PM
> >> To: Windows System Software Devs Interest List
> >> Subject: [ntdev] NDIS wi-fi miniport drivers -
> OID_GEN_MAXIMUM_TOTAL_SIZE
> >>
> >> Guys,
> >>
> >> the documentation for OID_GEN_MAXIMUM_TOTAL_SIZE specifies that
> >>
> >> The miniport driver must never indicate up to the bound protocol driver
> >> packets received over the network that are longer than the packet size
> >> specified by OID_GEN_MAXIMUM_TOTAL_SIZE.
> >>
> >> I have at least two wi-fi network cards (with WHQL certified drivers)
> >> that
> >> advertise that the total size is 1514 (the usual eth one), but then
> >> deliver
> >> packets of 1572 bytes through the ProtocolReceivePacket handler.
> >>
> >> Am I missing anything, or these two miniport drivers are violating the
> >> NDIS
> >> specs?
> >>
> >> Have a nice day
> >> GV
> >>
> >>
> >>
> >> —
> >> Questions? First check the Kernel Driver FAQ at
> >> http://www.osronline.com/article.cfm?id=256
> >>
> >> To unsubscribe, visit the List Server section of OSR Online at
> >> http://www.osronline.com/page.cfm?name=ListServer
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
“Thomas F. Divine” wrote in message news:xxxxx@ntdev…
> What adapters?
One is a Dell 1450 USB one, another is a D-Link DWL-G122.
>
> Any other filters in the stack?
The MS QoS packet scheduler was in the stack. I removed it from the adapter,
and nothing changed…
…just interesting…
I’ll play a bit more on this.
Have a nice day
GV
>
> Thomas F. Divine
>
>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com [mailto:bounce-272368-
>> xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
>> Sent: Friday, December 08, 2006 7:34 PM
>> To: Windows System Software Devs Interest List
>> Subject: Re: [ntdev] NDIS wi-fi miniport drivers -
>> OID_GEN_MAXIMUM_TOTAL_SIZE
>>
>> I forgot… I saw that on Win XP, so no NDIS6 frills…
>>
>> GV
>>
>>
>> ----- Original Message -----
>> From: “Thomas F. Divine”
>> To: “Windows System Software Devs Interest List”
>> Sent: Friday, December 08, 2006 3:07 PM
>> Subject: RE: [ntdev] NDIS wi-fi miniport drivers -
>> OID_GEN_MAXIMUM_TOTAL_SIZE
>>
>>
>> > Since ProtocolReceivePacket is a NDIS 5 callback and Native Wi-Fi
>> > miniports
>> > are strictly NDIS 6, then perhaps this is a bug in the Vista NDIS
>> > 6-to-NDIS
>> > 5 shim.
>> >
>> > I haven’t noticed this (yet) myself.
>> >
>> > Thomas F. Divine
>> >
>> >> -----Original Message-----
>> >> From: xxxxx@lists.osr.com [mailto:bounce-272360-
>> >> xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
>> >> Sent: Friday, December 08, 2006 5:22 PM
>> >> To: Windows System Software Devs Interest List
>> >> Subject: [ntdev] NDIS wi-fi miniport drivers -
>> OID_GEN_MAXIMUM_TOTAL_SIZE
>> >>
>> >> Guys,
>> >>
>> >> the documentation for OID_GEN_MAXIMUM_TOTAL_SIZE specifies that
>> >>
>> >> The miniport driver must never indicate up to the bound protocol
>> >> driver
>> >> packets received over the network that are longer than the packet size
>> >> specified by OID_GEN_MAXIMUM_TOTAL_SIZE.
>> >>
>> >> I have at least two wi-fi network cards (with WHQL certified drivers)
>> >> that
>> >> advertise that the total size is 1514 (the usual eth one), but then
>> >> deliver
>> >> packets of 1572 bytes through the ProtocolReceivePacket handler.
>> >>
>> >> Am I missing anything, or these two miniport drivers are violating the
>> >> NDIS
>> >> specs?
>> >>
>> >> Have a nice day
>> >> GV
>> >>
>> >>
>> >>
>> >> —
>> >> Questions? First check the Kernel Driver FAQ at
>> >> http://www.osronline.com/article.cfm?id=256
>> >>
>> >> To unsubscribe, visit the List Server section of OSR Online at
>> >> http://www.osronline.com/page.cfm?name=ListServer
>> >
>> >
>> > —
>> > Questions? First check the Kernel Driver FAQ at
>> > http://www.osronline.com/article.cfm?id=256
>> >
>> > To unsubscribe, visit the List Server section of OSR Online at
>> > http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>
>
> -----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-272369-
xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Friday, December 08, 2006 7:36 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] NDIS wi-fi miniport drivers -
OID_GEN_MAXIMUM_TOTAL_SIZE
----- Original Message -----
From: “David R. Cattley”
> To: “Windows System Software Devs Interest List”
> Sent: Friday, December 08, 2006 3:28 PM
> Subject: RE: [ntdev] NDIS wi-fi miniport drivers -
> OID_GEN_MAXIMUM_TOTAL_SIZE
>
>
> >
> > >> Native Wi-Fi miniports are strictly NDIS 6
> >
> > I must be blind. I didn’t see in the OP where it said "Native WiFi’ or
> > ExtSTA Wifi.
> >
> > AFAIK the OID_GEN_MAXIMUM_TOTAL_SIZE was one of those things that
> governed
> > the behavior of the the original ProtocolRecieve() ‘legacy’ miniport
> > handling. Since the NIC allocates the buffer(s) in the case of
> > ProtocolReceivePacket(), I suppose it is less important to remain within
> > that limit.
> >
> > But the real curious thing is just what is in that 1572 octet packet?
>
> Some APs support bigger packets. In this case it was a tunnel, but the
> 802.11 standard allows packets bigger than 1514. In any case, you can have
> such bigger packets with GigaEthernet and jumbo frames…
[PCAUSA] Sure you can have packets larger than 1514.
BUT in those cases OID_GEN_MAXIMUM_XYZ returns larger sizes as well.
I have never seen a packet total size larger than that reported by
OID_GEN_MAXIMUM_TOTAL_SIZE even when working with Jumbo frames…
Thomas F. Divine
>
> GV
>
>
> >
> > Good Luck,
> > Dave Cattley
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Thomas F. Divine
> > Sent: Friday, December 08, 2006 6:07 PM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] NDIS wi-fi miniport drivers -
> > OID_GEN_MAXIMUM_TOTAL_SIZE
> >
> > Since ProtocolReceivePacket is a NDIS 5 callback and Native Wi-Fi
> > miniports
> > are strictly NDIS 6, then perhaps this is a bug in the Vista NDIS
> > 6-to-NDIS
> > 5 shim.
> >
> > I haven’t noticed this (yet) myself.
> >
> > Thomas F. Divine
> >
> >> -----Original Message-----
> >> From: xxxxx@lists.osr.com [mailto:bounce-272360-
> >> xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
> >> Sent: Friday, December 08, 2006 5:22 PM
> >> To: Windows System Software Devs Interest List
> >> Subject: [ntdev] NDIS wi-fi miniport drivers -
> >> OID_GEN_MAXIMUM_TOTAL_SIZE
> >>
> >> Guys,
> >>
> >> the documentation for OID_GEN_MAXIMUM_TOTAL_SIZE specifies that
> >>
> >> The miniport driver must never indicate up to the bound protocol
> >> driver packets received over the network that are longer than the
> >> packet size specified by OID_GEN_MAXIMUM_TOTAL_SIZE.
> >>
> >> I have at least two wi-fi network cards (with WHQL certified drivers)
> >> that advertise that the total size is 1514 (the usual eth one), but
> >> then deliver packets of 1572 bytes through the ProtocolReceivePacket
> >> handler.
> >>
> >> Am I missing anything, or these two miniport drivers are violating the
> >> NDIS specs?
> >>
> >> Have a nice day
> >> GV
> >>
> >>
> >>
> >> —
> >> Questions? First check the Kernel Driver FAQ at
> >> http://www.osronline.com/article.cfm?id=256
> >>
> >> To unsubscribe, visit the List Server section of OSR Online at
> >> http://www.osronline.com/page.cfm?name=ListServer
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
“David R. Cattley” wrote in message news:xxxxx@ntdev…
> I still come back to wondering what is in the packet 'cause it’s a touch too
> big for an 802.3 packet, right?
This could occur when an emulation driver (that normally reports 1514)
starts working in some proprietary “wireless sniffer” mode.
Then, it will send up raw 802.11 frames.
[no specific driver or product in mind… just an assumption]
There seems to be no way for connectionless NDIS5 driver to indicate change
in the max. packet size, so the protocol that invokes such a mode must be
able to handle larger packets correctly.
Regards,
–PA
----- Original Message -----
From: “Thomas F. Divine”
To: “Windows System Software Devs Interest List”
Sent: Friday, December 08, 2006 5:30 PM
Subject: RE: [ntdev] NDIS wi-fi miniport drivers -
OID_GEN_MAXIMUM_TOTAL_SIZE
>
>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com [mailto:bounce-272369-
>> xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
>> Sent: Friday, December 08, 2006 7:36 PM
>> To: Windows System Software Devs Interest List
>> Subject: Re: [ntdev] NDIS wi-fi miniport drivers -
>> OID_GEN_MAXIMUM_TOTAL_SIZE
>>
>>
>> ----- Original Message -----
>> From: “David R. Cattley”
>> To: “Windows System Software Devs Interest List”
>> Sent: Friday, December 08, 2006 3:28 PM
>> Subject: RE: [ntdev] NDIS wi-fi miniport drivers -
>> OID_GEN_MAXIMUM_TOTAL_SIZE
>>
>>
>> >
>> > >> Native Wi-Fi miniports are strictly NDIS 6
>> >
>> > I must be blind. I didn’t see in the OP where it said "Native WiFi’ or
>> > ExtSTA Wifi.
>> >
>> > AFAIK the OID_GEN_MAXIMUM_TOTAL_SIZE was one of those things that
>> governed
>> > the behavior of the the original ProtocolRecieve() ‘legacy’ miniport
>> > handling. Since the NIC allocates the buffer(s) in the case of
>> > ProtocolReceivePacket(), I suppose it is less important to remain
>> > within
>> > that limit.
>> >
>> > But the real curious thing is just what is in that 1572 octet packet?
>>
>> Some APs support bigger packets. In this case it was a tunnel, but the
>> 802.11 standard allows packets bigger than 1514. In any case, you can
>> have
>> such bigger packets with GigaEthernet and jumbo frames…
> [PCAUSA] Sure you can have packets larger than 1514.
>
> BUT in those cases OID_GEN_MAXIMUM_XYZ returns larger sizes as well.
>
> I have never seen a packet total size larger than that reported by
> OID_GEN_MAXIMUM_TOTAL_SIZE even when working with Jumbo frames…
>
FWIW, the Intel Pro/wireless 2200BG shows the same…
GV
> Thomas F. Divine
>
>>
>> GV
>>
>>
>> >
>> > Good Luck,
>> > Dave Cattley
>> >
>> > -----Original Message-----
>> > From: xxxxx@lists.osr.com
>> > [mailto:xxxxx@lists.osr.com] On Behalf Of Thomas F. Divine
>> > Sent: Friday, December 08, 2006 6:07 PM
>> > To: Windows System Software Devs Interest List
>> > Subject: RE: [ntdev] NDIS wi-fi miniport drivers -
>> > OID_GEN_MAXIMUM_TOTAL_SIZE
>> >
>> > Since ProtocolReceivePacket is a NDIS 5 callback and Native Wi-Fi
>> > miniports
>> > are strictly NDIS 6, then perhaps this is a bug in the Vista NDIS
>> > 6-to-NDIS
>> > 5 shim.
>> >
>> > I haven’t noticed this (yet) myself.
>> >
>> > Thomas F. Divine
>> >
>> >> -----Original Message-----
>> >> From: xxxxx@lists.osr.com [mailto:bounce-272360-
>> >> xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
>> >> Sent: Friday, December 08, 2006 5:22 PM
>> >> To: Windows System Software Devs Interest List
>> >> Subject: [ntdev] NDIS wi-fi miniport drivers -
>> >> OID_GEN_MAXIMUM_TOTAL_SIZE
>> >>
>> >> Guys,
>> >>
>> >> the documentation for OID_GEN_MAXIMUM_TOTAL_SIZE specifies that
>> >>
>> >> The miniport driver must never indicate up to the bound protocol
>> >> driver packets received over the network that are longer than the
>> >> packet size specified by OID_GEN_MAXIMUM_TOTAL_SIZE.
>> >>
>> >> I have at least two wi-fi network cards (with WHQL certified drivers)
>> >> that advertise that the total size is 1514 (the usual eth one), but
>> >> then deliver packets of 1572 bytes through the ProtocolReceivePacket
>> >> handler.
>> >>
>> >> Am I missing anything, or these two miniport drivers are violating the
>> >> NDIS specs?
>> >>
>> >> Have a nice day
>> >> GV
>> >>
>> >>
>> >>
>> >> —
>> >> Questions? First check the Kernel Driver FAQ at
>> >> http://www.osronline.com/article.cfm?id=256
>> >>
>> >> To unsubscribe, visit the List Server section of OSR Online at
>> >> http://www.osronline.com/page.cfm?name=ListServer
>> >
>> >
>> > —
>> > Questions? First check the Kernel Driver FAQ at
>> > http://www.osronline.com/article.cfm?id=256
>> >
>> > To unsubscribe, visit the List Server section of OSR Online at
>> > http://www.osronline.com/page.cfm?name=ListServer
>> >
>> >
>> > —
>> > Questions? First check the Kernel Driver FAQ at
>> > http://www.osronline.com/article.cfm?id=256
>> >
>> > To unsubscribe, visit the List Server section of OSR Online at
>> > http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
> -----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-272384-
xxxxx@lists.osr.com] On Behalf Of Pavel A.
Sent: Friday, December 08, 2006 8:27 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] NDIS wi-fi miniport drivers -
OID_GEN_MAXIMUM_TOTAL_SIZE
“David R. Cattley” wrote in message news:xxxxx@ntdev…
> > I still come back to wondering what is in the packet 'cause it’s a touch
> too
> > big for an 802.3 packet, right?
>
> This could occur when an emulation driver (that normally reports 1514)
> starts working in some proprietary “wireless sniffer” mode.
> Then, it will send up raw 802.11 frames.
> [no specific driver or product in mind… just an assumption]
>
> There seems to be no way for connectionless NDIS5 driver to indicate
> change
> in the max. packet size, so the protocol that invokes such a mode must be
> able to handle larger packets correctly.
>
[PCAUSA] Yes, but perhaps not filter drivers below the protocol and above
the miniport.
I would call the driver “broken” if it indicates more than
OID_GEN_MAXIMUM_TOTAL_SIZE except on embedded systems running proprietary
software.
BUT, I see your point about the inability to change the MTU when a path with
a larger MTU is identified.
Thomas F. Divine
> Regards,
> --PA
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
In my case, the driver is not in monitor mode or similar. I have an IM
driver, and I receive pure ethernet frames. I think that 99% of the APs on
the market cannot transmit bigger frames, but the ones that I’m using can. I
was also thinking that you could probably force the transmission of bigger
frames in at least two other ways
- using one of those APs that run Linux, and generate the packets directly
from the shell of AP.
- ad-hoc mode (I have no idea what the maximum frame size is for 802.11 in
ad-hoc mode)
GV
“Pavel A.” wrote in message news:xxxxx@ntdev…
> “David R. Cattley” wrote in message news:xxxxx@ntdev…
>> I still come back to wondering what is in the packet 'cause it’s a touch
>> too
>> big for an 802.3 packet, right?
>
> This could occur when an emulation driver (that normally reports 1514)
> starts working in some proprietary “wireless sniffer” mode.
> Then, it will send up raw 802.11 frames.
> [no specific driver or product in mind… just an assumption]
>
> There seems to be no way for connectionless NDIS5 driver to indicate
> change
> in the max. packet size, so the protocol that invokes such a mode must be
> able to handle larger packets correctly.
>
> Regards,
> --PA
>
>
>
Pavel,
Of course any of those schemes would work. I was only wondering how one
would have expected NDISTest to have done so during the (self-sign)
procedures of a WHQL submission for a WiFi NDIS Miniport. None of the
NDISTest infrastructure for WiFi is nominally capable of generating such a
packet for the purposes of validating the behavior of the NIC (DUT).
Perhaps this is the kind of thing that can now be caught by the DTK with the
SoftAP used for driving the WiFi tests.
I am still curious, however, to know if the frame actually (as you suggest)
came from the network as a jumbo. In other words, do you have any evidence
to suggest that indeed a jumbo frame was transmitted on the LAN (either
wireless or wired) and the AP bridged that to the WiFi station as a jumbe?
I ask only because this scenario would be the one you could really do
nothing about. An alternate scenario is that the on-air frame was perfectly
reasonable and the NIC, Miniport, or some other intervening entity messed up
the packet length or the frame itself. That would be a serious issue in my
opinion.
Best Regards,
Dave Cattley
Consulting Engineer
Systems Software Development
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Monday, December 11, 2006 11:47 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] NDIS wi-fi miniport drivers - OID_GEN_MAXIMUM_TOTAL_SIZE
In my case, the driver is not in monitor mode or similar. I have an IM
driver, and I receive pure ethernet frames. I think that 99% of the APs on
the market cannot transmit bigger frames, but the ones that I’m using can. I
was also thinking that you could probably force the transmission of bigger
frames in at least two other ways
- using one of those APs that run Linux, and generate the packets directly
from the shell of AP.
- ad-hoc mode (I have no idea what the maximum frame size is for 802.11 in
ad-hoc mode)
GV
“Pavel A.” wrote in message news:xxxxx@ntdev…
> “David R. Cattley” wrote in message news:xxxxx@ntdev…
>> I still come back to wondering what is in the packet 'cause it’s a
>> touch too big for an 802.3 packet, right?
>
> This could occur when an emulation driver (that normally reports 1514)
> starts working in some proprietary “wireless sniffer” mode.
> Then, it will send up raw 802.11 frames.
> [no specific driver or product in mind… just an assumption]
>
> There seems to be no way for connectionless NDIS5 driver to indicate
> change in the max. packet size, so the protocol that invokes such a
> mode must be able to handle larger packets correctly.
>
> Regards,
> --PA
>
>
>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
----- Original Message -----
From: “David R. Cattley”
To: “Windows System Software Devs Interest List”
Sent: Monday, December 11, 2006 10:35 AM
Subject: RE: [ntdev] NDIS wi-fi miniport drivers -
OID_GEN_MAXIMUM_TOTAL_SIZE
> Pavel,
>
> Of course any of those schemes would work. I was only wondering how one
> would have expected NDISTest to have done so during the (self-sign)
> procedures of a WHQL submission for a WiFi NDIS Miniport. None of the
> NDISTest infrastructure for WiFi is nominally capable of generating such a
> packet for the purposes of validating the behavior of the NIC (DUT).
>
> Perhaps this is the kind of thing that can now be caught by the DTK with
> the
> SoftAP used for driving the WiFi tests.
>
> I am still curious, however, to know if the frame actually (as you
> suggest)
> came from the network as a jumbo. In other words, do you have any
> evidence
> to suggest that indeed a jumbo frame was transmitted on the LAN (either
> wireless or wired) and the AP bridged that to the WiFi station as a jumbe?
The packet was really in the air with that size (i use a wireless sniffer
for this purpose). The AP generates such “big” frames. I cannot reveal any
specific detail, just consider that it’s not a “standard” 50$ AP just
bridging packets from ethernet…
> I ask only because this scenario would be the one you could really do
> nothing about.
Yeah. This is the scenario. As you said, it’s just something that none of
the NDIStests covers, as it’s a quite “naive” scenario…
Maybe the new DTM softAP stuff already covers such scenario…
Have a nice day
GV
An alternate scenario is that the on-air frame was perfectly
> reasonable and the NIC, Miniport, or some other intervening entity messed
> up
> the packet length or the frame itself. That would be a serious issue in
> my
> opinion.
>
> Best Regards,
> Dave Cattley
> Consulting Engineer
> Systems Software Development
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
> Sent: Monday, December 11, 2006 11:47 AM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] NDIS wi-fi miniport drivers -
> OID_GEN_MAXIMUM_TOTAL_SIZE
>
> In my case, the driver is not in monitor mode or similar. I have an IM
> driver, and I receive pure ethernet frames. I think that 99% of the APs on
> the market cannot transmit bigger frames, but the ones that I’m using can.
> I
> was also thinking that you could probably force the transmission of bigger
> frames in at least two other ways
> - using one of those APs that run Linux, and generate the packets directly
> from the shell of AP.
> - ad-hoc mode (I have no idea what the maximum frame size is for 802.11 in
> ad-hoc mode)
>
> GV
>
> “Pavel A.” wrote in message news:xxxxx@ntdev…
>> “David R. Cattley” wrote in message
>> news:xxxxx@ntdev…
>>> I still come back to wondering what is in the packet 'cause it’s a
>>> touch too big for an 802.3 packet, right?
>>
>> This could occur when an emulation driver (that normally reports 1514)
>> starts working in some proprietary “wireless sniffer” mode.
>> Then, it will send up raw 802.11 frames.
>> [no specific driver or product in mind… just an assumption]
>>
>> There seems to be no way for connectionless NDIS5 driver to indicate
>> change in the max. packet size, so the protocol that invokes such a
>> mode must be able to handle larger packets correctly.
>>
>> Regards,
>> --PA
>>
>>
>>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
> -----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-272580-
xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Monday, December 11, 2006 1:36 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NDIS wi-fi miniport drivers -
OID_GEN_MAXIMUM_TOTAL_SIZE
Pavel,
Of course any of those schemes would work. I was only wondering how one
would have expected NDISTest to have done so during the (self-sign)
procedures of a WHQL submission for a WiFi NDIS Miniport. None of the
NDISTest infrastructure for WiFi is nominally capable of generating such a
packet for the purposes of validating the behavior of the NIC (DUT).
Perhaps this is the kind of thing that can now be caught by the DTK with
the
SoftAP used for driving the WiFi tests.
I am still curious, however, to know if the frame actually (as you
suggest)
came from the network as a jumbo. In other words, do you have any
evidence
to suggest that indeed a jumbo frame was transmitted on the LAN (either
wireless or wired) and the AP bridged that to the WiFi station as a jumbe?
I ask only because this scenario would be the one you could really do
nothing about. An alternate scenario is that the on-air frame was
perfectly
reasonable and the NIC, Miniport, or some other intervening entity messed
up
the packet length or the frame itself. That would be a serious issue in
my
opinion.
[PCAUSA] That is a good guess. The OP has a NDIS IM filter. Perhaps it is
somehow installed below another filter whose job it is to modify the packet
for proper presentation to higher levels.
This observation is perplexing. Shouldn’t happen, IMHO.
Thomas F. Divine
http://www.rawether.net
Best Regards,
Dave Cattley
Consulting Engineer
Systems Software Development
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Monday, December 11, 2006 11:47 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] NDIS wi-fi miniport drivers -
OID_GEN_MAXIMUM_TOTAL_SIZE
In my case, the driver is not in monitor mode or similar. I have an IM
driver, and I receive pure ethernet frames. I think that 99% of the APs on
the market cannot transmit bigger frames, but the ones that I’m using can.
I
was also thinking that you could probably force the transmission of bigger
frames in at least two other ways
- using one of those APs that run Linux, and generate the packets directly
from the shell of AP.
- ad-hoc mode (I have no idea what the maximum frame size is for 802.11 in
ad-hoc mode)
GV
“Pavel A.” wrote in message news:xxxxx@ntdev…
> > “David R. Cattley” wrote in message
> news:xxxxx@ntdev…
> >> I still come back to wondering what is in the packet 'cause it’s a
> >> touch too big for an 802.3 packet, right?
> >
> > This could occur when an emulation driver (that normally reports 1514)
> > starts working in some proprietary “wireless sniffer” mode.
> > Then, it will send up raw 802.11 frames.
> > [no specific driver or product in mind… just an assumption]
> >
> > There seems to be no way for connectionless NDIS5 driver to indicate
> > change in the max. packet size, so the protocol that invokes such a
> > mode must be able to handle larger packets correctly.
> >
> > Regards,
> > --PA
> >
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer