I am looking for some suggestion/help in solving some packet driver problems.
We have a driver, roughly based on the NT Packet driver running on NT 4 SP6.
It has been performing OK with no particular problems until recently we turn
on the 803.1q VLAN tagging on the NIC.
Now it pauses after sending 3 packets. Looking into this problem I found out
that
after each third packet my Protocol Characteristic StatusHandler and
StatusCompleteHandler
callbacks are executed with status NDIS_STATUS_RESET_START and
NDIS_STATUS_RESET_END.
Is there anything that has to be done differently/added when VLAN tagging is
enabled?
Looking at the packets “on the wire” it seems that they are going out at the
normal speed until
the third packet is out, after which there is a pause for about 4 to 6 seconds.
The system has 2 NICs and if I turn off tagging on one of the NIC’s, packets are
still going at the
old fast speed on the NIC with no tagging, and slow as mentioned above for the
NIC with tagging.
Any suggestions on where I should look to solve this problem?
Thanks,
Satrio
AFAIK, there is no VLAN support in NT4, ie. NDIS4. Thus, if the NIC
and its driver supports VLAN, it is probably some proprietary
solution.
Does your driver support VLAN tagging? Or is it just the NIC driver?
In the latter case, go and ask the NIC vendor (which one is it?).
BTW, what is 803.1q??? => 802.1q!
Stephan
On Mon, 18 Mar 2002 18:35:19 -0700, “Satrio Mualim”
wrote:
>I am looking for some suggestion/help in solving some packet driver problems.
>
>We have a driver, roughly based on the NT Packet driver running on NT 4 SP6.
>It has been performing OK with no particular problems until recently we turn
>on the 803.1q VLAN tagging on the NIC.
>
>Now it pauses after sending 3 packets. Looking into this problem I found out
>that
>after each third packet my Protocol Characteristic StatusHandler and
>StatusCompleteHandler
>callbacks are executed with status NDIS_STATUS_RESET_START and
>NDIS_STATUS_RESET_END.
>
>Is there anything that has to be done differently/added when VLAN tagging is
>enabled?
>Looking at the packets “on the wire” it seems that they are going out at the
>normal speed until
>the third packet is out, after which there is a pause for about 4 to 6 seconds.
>The system has 2 NICs and if I turn off tagging on one of the NIC’s, packets are
>still going at the
>old fast speed on the NIC with no tagging, and slow as mentioned above for the
>NIC with tagging.
>
>Any suggestions on where I should look to solve this problem?
>
>Thanks,
>
>Satrio
Sorry, typo, 802.1q is what I meant
The NIC is the Intel Pro 100 (82558 chip).
I also found out that the packet driver will work properly if
I limit the packet size to about 200 bytes, i.e under the limit
it sends the packets the way it does before VLAN tagging is
enabled.
What I dont understand is the fact that it seems to be transparent
to TCP/IP which works the same way as before tagging was enabled.
I suspect that I must be missing some calls/settings that are required
to make it work with bigger packets
Thanks,
Satrio
Stephan Wolf wrote:
AFAIK, there is no VLAN support in NT4, ie. NDIS4. Thus, if the NIC
and its driver supports VLAN, it is probably some proprietary
solution.
Does your driver support VLAN tagging? Or is it just the NIC driver?
In the latter case, go and ask the NIC vendor (which one is it?).
BTW, what is 803.1q??? => 802.1q!
Stephan
On Mon, 18 Mar 2002 18:35:19 -0700, “Satrio Mualim”
> wrote:
>
> >I am looking for some suggestion/help in solving some packet driver problems.
> >
> >We have a driver, roughly based on the NT Packet driver running on NT 4 SP6.
> >It has been performing OK with no particular problems until recently we turn
> >on the 803.1q VLAN tagging on the NIC.
> >
> >Now it pauses after sending 3 packets. Looking into this problem I found out
> >that
> >after each third packet my Protocol Characteristic StatusHandler and
> >StatusCompleteHandler
> >callbacks are executed with status NDIS_STATUS_RESET_START and
> >NDIS_STATUS_RESET_END.
> >
> >Is there anything that has to be done differently/added when VLAN tagging is
> >enabled?
> >Looking at the packets “on the wire” it seems that they are going out at the
> >normal speed until
> >the third packet is out, after which there is a pause for about 4 to 6 seconds.
> >The system has 2 NICs and if I turn off tagging on one of the NIC’s, packets are
> >still going at the
> >old fast speed on the NIC with no tagging, and slow as mentioned above for the
> >NIC with tagging.
> >
> >Any suggestions on where I should look to solve this problem?
> >
> >Thanks,
> >
> >Satrio
>
> —
> You are currently subscribed to ntdev as: xxxxx@agcs.com
> To unsubscribe send a blank email to %%email.unsub%%
Hmm, actually, I was involved in a VLAN project for W2K. AFAIK,
built-in VLAN support is only in XP.
What needs to be done for VLAN tagging is that the VLAN header has to
be inserted for send packets and removed from receive packets at a
very low level, ie. “below” any protocol stack.
This can be done either in the NIC driver or in some intermediate
driver (“filter”). The VLAN header sits in (or after - depends on how
you look at it) the MAC header. Thus, a new *local* MAC header has to
be created in the NIC or IM driver.
I remember we also had problems with “large” frames.
I guess the problems go away if you set up the MAC header in a
separate NDIS_BUFFER in any frame that your protocol sends.
Stephan
On Wed, 20 Mar 2002 07:57:14 -0700, “Satrio Mualim”
wrote:
>Sorry, typo, 802.1q is what I meant
>The NIC is the Intel Pro 100 (82558 chip).
>I also found out that the packet driver will work properly if
>I limit the packet size to about 200 bytes, i.e under the limit
>it sends the packets the way it does before VLAN tagging is
>enabled.
>What I dont understand is the fact that it seems to be transparent
>to TCP/IP which works the same way as before tagging was enabled.
>I suspect that I must be missing some calls/settings that are required
>to make it work with bigger packets
>
>Thanks,
>
>Satrio
>
>Stephan Wolf wrote:
>
>> AFAIK, there is no VLAN support in NT4, ie. NDIS4. Thus, if the NIC
>> and its driver supports VLAN, it is probably some proprietary
>> solution.
>>
>> Does your driver support VLAN tagging? Or is it just the NIC driver?
>> In the latter case, go and ask the NIC vendor (which one is it?).
>>
>> BTW, what is 803.1q??? => 802.1q!
>>
>> Stephan
>> —
>> On Mon, 18 Mar 2002 18:35:19 -0700, “Satrio Mualim”
>> wrote:
>>
>> >I am looking for some suggestion/help in solving some packet driver problems.
>> >
>> >We have a driver, roughly based on the NT Packet driver running on NT 4 SP6.
>> >It has been performing OK with no particular problems until recently we turn
>> >on the 803.1q VLAN tagging on the NIC.
>> >
>> >Now it pauses after sending 3 packets. Looking into this problem I found out
>> >that
>> >after each third packet my Protocol Characteristic StatusHandler and
>> >StatusCompleteHandler
>> >callbacks are executed with status NDIS_STATUS_RESET_START and
>> >NDIS_STATUS_RESET_END.
>> >
>> >Is there anything that has to be done differently/added when VLAN tagging is
>> >enabled?
>> >Looking at the packets “on the wire” it seems that they are going out at the
>> >normal speed until
>> >the third packet is out, after which there is a pause for about 4 to 6 seconds.
>> >The system has 2 NICs and if I turn off tagging on one of the NIC’s, packets are
>> >still going at the
>> >old fast speed on the NIC with no tagging, and slow as mentioned above for the
>> >NIC with tagging.
>> >
>> >Any suggestions on where I should look to solve this problem?
>> >
>> >Thanks,
>> >
>> >Satrio
I was wondering about how the NIC driver inserts the VLAN tag and
found out the following:
- Creating the VLAN causes the original device name to be hidden/unavailable.
Instead there is a new device name /device/iVLAN…
- Using the existing packet driver, just opening the new device, will cause
packets on the wire to be <0x8100> …
where the 0x8100 and vlan tag are inserted by the NIC driver (as far as I can tell)
and vlan tag is the value specified during the setup of the NIC
- If I cheat and modify the registry to make the original device available,
and send packets using it, I get packets on the wire that have everything the way
they should be except the is 0x0000.
In either case I still have the problem where it resets the NIC every 3 packets.
I am interested in trying to do what you said in your last paragraph.
Why would the problem go away if I setup a different NDIS_BUFFER
for the MAC header and how do I make sure that the MAC header
buffer and the “payload” still go out as one packet on the wire?
Thanks,
Satrio
Stephan Wolf wrote:
> Hmm, actually, I was involved in a VLAN project for W2K. AFAIK,
> built-in VLAN support is only in XP.
>
> What needs to be done for VLAN tagging is that the VLAN header has to
> be inserted for send packets and removed from receive packets at a
> very low level, ie. “below” any protocol stack.
>
> This can be done either in the NIC driver or in some intermediate
> driver (“filter”). The VLAN header sits in (or after - depends on how
> you look at it) the MAC header. Thus, a new local MAC header has to
> be created in the NIC or IM driver.
>
> I remember we also had problems with “large” frames.
>
> I guess the problems go away if you set up the MAC header in a
> separate NDIS_BUFFER in any frame that your protocol sends.
>
> Stephan
> —
AFAIK, “iVLAN” is an intermediate driver.
The driver has to make a local copy of the MAC header in order to be
able to insert the VLAN tag. If the complete packet is just one
NDIS_BUFFER then the driver *might* get into trouble. I am not saying
this is so but it could be.
The lookahead size also plays a major role here. NDIS requires that
the first NDIS_BUFFER in a received (!) packet is at least the
lookahead size (or the complete packet, whichever is shorter).
Do you specify any specific lookahead size for your protocol?
Anyway, if you say TCP/IP works ok then maybe because it also uses a
separate NDIS_BUFFER for the header(s).
You can also try and run the NDIS Tester against the NIC driver with
VLAN tagging enabled. If that passes, it’s a problem of your protocol.
Otherwise, it’s a bug in the NIC driver, which I expect.
Download “ndt391.exe” here:
ftp://ftp.microsoft.com/services/whql/ndis/
Stephan
On Wed, 20 Mar 2002 10:28:22 -0700, “Satrio Mualim”
wrote:
>
>
>I was wondering about how the NIC driver inserts the VLAN tag and
>found out the following:
>- Creating the VLAN causes the original device name to be hidden/unavailable.
> Instead there is a new device name /device/iVLAN…
>- Using the existing packet driver, just opening the new device, will cause
> packets on the wire to be <0x8100> …
> where the 0x8100 and vlan tag are inserted by the NIC driver (as far as I can tell)
> and vlan tag is the value specified during the setup of the NIC
>- If I cheat and modify the registry to make the original device available,
> and send packets using it, I get packets on the wire that have everything the way
> they should be except the is 0x0000.
>In either case I still have the problem where it resets the NIC every 3 packets.
>
>
>I am interested in trying to do what you said in your last paragraph.
>Why would the problem go away if I setup a different NDIS_BUFFER
>for the MAC header and how do I make sure that the MAC header
>buffer and the “payload” still go out as one packet on the wire?
>
>Thanks,
>
>Satrio
>
>Stephan Wolf wrote:
>
>> Hmm, actually, I was involved in a VLAN project for W2K. AFAIK,
>> built-in VLAN support is only in XP.
>>
>> What needs to be done for VLAN tagging is that the VLAN header has to
>> be inserted for send packets and removed from receive packets at a
>> very low level, ie. “below” any protocol stack.
>>
>> This can be done either in the NIC driver or in some intermediate
>> driver (“filter”). The VLAN header sits in (or after - depends on how
>> you look at it) the MAC header. Thus, a new local MAC header has to
>> be created in the NIC or IM driver.
>>
>> I remember we also had problems with “large” frames.
>>
>> I guess the problems go away if you set up the MAC header in a
>> separate NDIS_BUFFER in any frame that your protocol sends.
>>
>> Stephan
>> —
Thanks for all the info and hints.
I tried to add another small NDIS_BUFFER and chained it to the packet descriptor.
And, at least from my first test run, it seems to behave the way it should.
No more pause after each 3 packets.
I still have to figure out what this means to existing application code, but at least it
can be made to work. And I agree that this maybe the same reason that TCP/IP
works with no problems.
I will check the lookahead size and see if this is another potential problem.
Satrio
Stephan Wolf wrote:
AFAIK, “iVLAN” is an intermediate driver.
The driver has to make a local copy of the MAC header in order to be
able to insert the VLAN tag. If the complete packet is just one
NDIS_BUFFER then the driver *might* get into trouble. I am not saying
this is so but it could be.
The lookahead size also plays a major role here. NDIS requires that
the first NDIS_BUFFER in a received (!) packet is at least the
lookahead size (or the complete packet, whichever is shorter).
Do you specify any specific lookahead size for your protocol?
Anyway, if you say TCP/IP works ok then maybe because it also uses a
separate NDIS_BUFFER for the header(s).
You can also try and run the NDIS Tester against the NIC driver with
VLAN tagging enabled. If that passes, it’s a problem of your protocol.
Otherwise, it’s a bug in the NIC driver, which I expect.
Download “ndt391.exe” here:
ftp://ftp.microsoft.com/services/whql/ndis/
Stephan