Re: IM driver modifying packet content and task offload

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Sorry, I wrote inaccurate sentence...
Yes IM driver cannot modify packets,
I ment creating own packets with it's own chained buffers and copying
original data to it.
So my question in other words:

assumptions:
Only outgoing packets, task offload is switched on in network card,
IM driver MiniportQueryInformation() does not block
MiniportQueryInformation(...OID_TCP_TASK_OFFLOAD...) requests down to
miniport.

question:
Can it be checksum functional with outgoing packets created by IM driver ?

I tried it. When I set IP/TCP checksums zero, but on target machine I detect
bad checksum.
When I switch off task offload and let IM driver to calculate checksum then
all is ok,
but I 's like to create packets in IM driver and use task offload for
checksum, is it possible ? Or it is really how wrote Maxim: "task offload
means that only miniport can to create checksum..." (I am not sure if I good
understand it.)
I appear also that NDIS_TCP_IP_CHECKSUM_PACKET_INFO must have correct info
for checksums created by miniport, maybe I must to fill it with right values
and try it, if it has sense...

Thx!
Peter

"Anton Bassov" wrote:

Maxim,

or IM driver must return NDIS_STATUS_NOT_SUPPORTED on
MiniportQueryInformation(...OID_TCP_TASK_OFFLOAD...) request.

Why? If this is a received packet with task offload on, then the checksum was
already checked by the hardware. You can still indicate the new packet based on
this one up to TCPIP.

If this is an outgoing packet - then again you can reuse offload. For outgoing
packets, offload means - nobody except the hardware and its driver bother to
compute TCP/IP checksums. Your IM can also not bother.

Actually, the OP said a right thing - modifying IM should fail
OID_TCP_TASK_OFFLOAD request with NDIS_STATUS_NOT_SUPPORTED, rather than
passing it down to miniport. I think Thomas F.Divine was the first one who
discovered it - this info appeared on PCAUSA ages ago (MSDN had not mentioned
this problem at the time). This info subsequently made its way to WDK
documentation, so that these days it is MSFT guideline. Please check WDK
documentation for more info.

Anton Bassov


"Maxim S. Shatskih" wrote:

When IM driver modifies packet content (for example NAT implementation),
cheksum offload must be switched off in network card properties,

IM cannot modify the packet content. It can only assemble its own packet, and
modify it.

or IM driver must return NDIS_STATUS_NOT_SUPPORTED on
MiniportQueryInformation(...OID_TCP_TASK_OFFLOAD...) request.

Why? If this is a received packet with task offload on, then the checksum was
already checked by the hardware. You can still indicate the new packet based on
this one up to TCPIP.

If this is an outgoing packet - then again you can reuse offload. For outgoing
packets, offload means - nobody except the hardware and its driver bother to
compute TCP/IP checksums. Your IM can also not bother.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@xxxxxxxxxxxxxxxx
http://www.storagecraft.com


.

Relevant Pages

  • Re: Changes in the network interface queueing handoff model
    ... bouncing around for some time is a restructuring of the network interface packet transmission API to reduce the number of locking operations and allow network device drivers increased control of the queueing behavior. ... to "start" output by the driver. ... encapsulation and wrapping, and notifies the hardware. ... The ifnet layer send queue is becoming decreasingly useful over time. ...
    (freebsd-arch)
  • Re: Changes in the network interface queueing handoff model
    ... bouncing around for some time is a restructuring of the network interface packet transmission API to reduce the number of locking operations and allow network device drivers increased control of the queueing behavior. ... to "start" output by the driver. ... encapsulation and wrapping, and notifies the hardware. ... The ifnet layer send queue is becoming decreasingly useful over time. ...
    (freebsd-net)
  • PATCH: Remove file riowinif.h from rio driver (unused file)
    ... -/* The RUP (Remote Unit Port) structure relates to the Remote Terminal Adapters ... - CONFIG is sent from the driver to configure an already opened port. ... - Packet structure is same as OPEN. ... - of the specified port's RTA address space. ...
    (Linux-Kernel)
  • Re: Changes in the network interface queueing handoff model
    ... layer output routine via ifp->if_outputwith the ifnet pointer, packet, ... as ARP), and hands off to the ifnet driver via a call to IFQ_HANDOFF, ... encapsulation and wrapping, and notifies the hardware. ... The ifnet layer send queue is becoming decreasingly useful over time. ...
    (freebsd-arch)
  • Changes in the network interface queueing handoff model
    ... 5BOne of the ideas that I, Scott Long, and a few others have been bouncing around for some time is a restructuring of the network interface packet transmission API to reduce the number of locking operations and allow network device drivers increased control of the queueing behavior. ... to "start" output by the driver. ... encapsulation and wrapping, and notifies the hardware. ... The ifnet layer send queue is becoming decreasingly useful over time. ...
    (freebsd-net)