NdisMIndicateReceivePackets problem

I’m working on a virtual NDIS miniport and I’m having trouble getting
packets of greater than 1500 bytes total (Ethernet header plus payload)
to be recognized by NDIS when I indicate them up. Basically, pings of
1458 bytes work, but at 1459 bytes, they seem to be silently dropped by
NDIS. 1458 bytes payload + 8 bytes ICMP + 20 bytes IP + 14 bytes
Ethernet is 1500 even. The way i see it, I should get 1500 bytes of
*payload*, plus 14 for the header, before I need to frag.

Stuff I’ve tried:

  • splitting the data into two NDIS_BUFFERs, with a current lookahead
    worth of data in the first buffer;
  • switching to NdisMEthIndicateReceive;
  • using one big buffer

Any ideas?

Thanks,

-sd

Your assumption is correct AFAIK.

Make sure that you are responding to OID’s related to lengths correctly
(header, max total size, etc) correctly.

Using one big flat buffer is the safest for testing this - until you get it
figured out. For absolute certain, make sure that:

MAC header PLUS required Lookahead size

is in the first buffer.

You might see if QoS Packet Scheduler is bound to your adapter. See if
disabling it has any effect on the problem you are seeing.

Thomas

“Steve Dispensa” wrote in message
news:xxxxx@ntdev…
>
> I’m working on a virtual NDIS miniport and I’m having trouble getting
> packets of greater than 1500 bytes total (Ethernet header plus payload)
> to be recognized by NDIS when I indicate them up. Basically, pings of
> 1458 bytes work, but at 1459 bytes, they seem to be silently dropped by
> NDIS. 1458 bytes payload + 8 bytes ICMP + 20 bytes IP + 14 bytes
> Ethernet is 1500 even. The way i see it, I should get 1500 bytes of
> payload, plus 14 for the header, before I need to frag.
>
> Stuff I’ve tried:
> - splitting the data into two NDIS_BUFFERs, with a current lookahead
> worth of data in the first buffer;
> - switching to NdisMEthIndicateReceive;
> - using one big buffer
>
> Any ideas?
>
> Thanks,
>
> -sd
>
>
>
>
>

Thanks for the response.

Make sure that you are responding to OID’s related to lengths correctly
(header, max total size, etc) correctly.

I’ve tried this several ways. Currently I’m setting:
OID_GEN_MAXIMUM_FRAME_SIZE = 1500
OID_GEN_MAXIMUM_LOOKAHEAD = 1500
OID_GEN_TRANSMIT_BUFFER_SPACE = 1514
OID_GEN_RECEIVE_BUFFER_SPACE = 1514
OID_GEN_TRANSMIT_BLOCK_SIZE = 1514
OID_GEN_RECEIVE_BLOCK_SIZE = 1514
OID_GEN_MAXIMUM_TOTAL_SIZE = 1514

Does anyone see any that I’m missing?

Using one big flat buffer is the safest for testing this - until you get it
figured out. For absolute certain, make sure that:

MAC header PLUS required Lookahead size

is in the first buffer.

This is the way I have my code set.

You might see if QoS Packet Scheduler is bound to your adapter. See if
disabling it has any effect on the problem you are seeing.

I’m testing on a really barebones win2k, but I do have passthru bound
above it. I’ll try with that unbound.

Thanks for the help.

-sd

Thomas

“Steve Dispensa” wrote in message
> news:xxxxx@ntdev…
> >
> > I’m working on a virtual NDIS miniport and I’m having trouble getting
> > packets of greater than 1500 bytes total (Ethernet header plus payload)
> > to be recognized by NDIS when I indicate them up. Basically, pings of
> > 1458 bytes work, but at 1459 bytes, they seem to be silently dropped by
> > NDIS. 1458 bytes payload + 8 bytes ICMP + 20 bytes IP + 14 bytes
> > Ethernet is 1500 even. The way i see it, I should get 1500 bytes of
> > payload, plus 14 for the header, before I need to frag.
> >
> > Stuff I’ve tried:
> > - splitting the data into two NDIS_BUFFERs, with a current lookahead
> > worth of data in the first buffer;
> > - switching to NdisMEthIndicateReceive;
> > - using one big buffer
> >
> > Any ideas?