Unfortunately, this patch works on Win2000 (this an undocumented feature),
but does not work on NT4. Moreover I suppose this does not work on XP, since
the flag to be set (NDIS_FLAGS_SKIP_LOOPBACK on Win2k) is different.
Look at the winpcap-users archive, I posted some links to the ddk newsgroups
that explain the problem.
GV
----- Original Message -----
From: "George Powers" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, November 22, 2002 4:40 PM
Subject: RE: [WinPcap-users] ignore outbound packets? / winpcap dev faq
I'm using winpcap on Windows 2000 and had a similar problem, namely that
winpcap would loop back every packet it sent. I found a few tips in earlier
postings and found this change to driver/write.c fixes the loopback
behavior:
NTSTATUS
NPF_Write(
IN PDEVICE_OBJECT DeviceObject,
IN PIRP Irp
)
{
POPEN_INSTANCE Open;
PIO_STACK_LOCATION IrpSp;
PNDIS_PACKET pPacket;
UINT i;
NDIS_STATUS Status;
IF_LOUD(DbgPrint("NPF_Write\n");)
IrpSp = IoGetCurrentIrpStackLocation(Irp);
Open=IrpSp->FileObject->FsContext;
IF_LOUD(DbgPrint("Max frame size = %d\n", Open->MaxFrameSize);)
if(IrpSp->Parameters.Write.Length == 0 || // Check that the buffer provided
by the user is not empty
Open->MaxFrameSize == 0 || // Check that the MaxFrameSize is correctly
initialized
IrpSp->Parameters.Write.Length > Open->MaxFrameSize) // Check that the fame
size is smaller that the MTU
{
IF_LOUD(DbgPrint("frame size out of range, send aborted\n");)
Irp->IoStatus.Status = NDIS_STATUS_SUCCESS;
IoCompleteRequest (Irp, IO_NO_INCREMENT);
return NDIS_STATUS_SUCCESS;
}
IoMarkIrpPending(Irp);
Open->Multiple_Write_Counter=Open->Nwrites;
NdisResetEvent(&Open->WriteEvent);
for(i=0;i<Open->Nwrites;i++){
// Try to get a packet from our list of free ones
NdisAllocatePacket(
&Status,
&pPacket,
Open->PacketPool
);
if (Status != NDIS_STATUS_SUCCESS) {
// No free packets
Irp->IoStatus.Status = STATUS_INSUFFICIENT_RESOURCES;
IoCompleteRequest (Irp, IO_NO_INCREMENT);
return STATUS_INSUFFICIENT_RESOURCES;
}
// The packet has a buffer that needs not to be freed after every single
write
RESERVED(pPacket)->FreeBufAfterWrite = FALSE;
// Save the IRP associated with the packet
RESERVED(pPacket)->Irp=Irp;
// Attach the writes buffer to the packet
NdisChainBufferAtFront(pPacket,Irp->MdlAddress);
++ NdisSetPacketFlags(pPacket, NDIS_FLAGS_SKIP_LOOPBACK); // -GAP 10/14/02
// Call the MAC
NdisSend(
&Status,
Open->AdapterHandle,
pPacket);
if (Status != NDIS_STATUS_PENDING) {
// The send didn't pend so call the completion handler now
NPF_SendComplete(
Open,
pPacket,
Status
);
}
if(i%100==99){
NdisWaitEvent(&Open->WriteEvent,1000);
NdisResetEvent(&Open->WriteEvent);
}
}
return(STATUS_PENDING);
}
This fix may not work on other versions of Windows.
You'll have to install the Microsoft DDK (the older, free one works) and
rebuild the driver, npf.sys. Seems to me like this fix really ought to be
the default behavior or at least an option of the winpcap API.
> -----Original Message-----
> From: protocol 7 [mailto:[EMAIL PROTECTED]]
> Sent: Friday, November 22, 2002 1:31 AM
> To: [EMAIL PROTECTED]
> Subject: [WinPcap-users] ignore outbound packets? / winpcap dev faq
>
>
> Hello again everyone, I've run into a snag which I'm sure is
> pretty common.
> Here's exactly what I'm doing: I'm writing a UDP bridge tool
> which consists
> of two parts, which I'll describe. In the example, the
> 10.255.255.255
> network exists seperately at two locations, and the only
> point of contact
> between the networks are a machine 169.0.0.1 on one end, and
> a machine
> 170.0.0.1 on the other end. The intent of the tool is to
> bridge the two
> 10.255.255.255 networks.
>
> The server thread captures all UDP port 1234 traffic, which
> looks like:
> src ip: 10.0.0.1
> dst ip: 10.0.0.1 or 10.255.255.255
> src udp port: 1234
> dst udp port: 1234
>
> It then rewrites the packet, changing the following before sending:
> src ip: 169.0.0.1
> dst ip: 170.0.0.1
> src udp port: 4321
> dst udp port: 4321
>
> The listener thread captures all UDP port 4321 traffic, then
> rewrites it
> back to the original form (10.0.0.1 / 1234) and sends it to the local
> network. The problem is, when the listener sends the new
> packet to the
> local network, the server thread sees it and redelivers it to
> the source
> network. In effect, I'm ending up with two reflectors. Since I'm
> preserving the mac addresses in the packet, I can't filter
> out my own mac.
> Is there a flag of some kind that will mark already modified
> packets as
> such? i'm hoping for something that can be handled
> automagically by the
> packet filter built in to pcap.
>
> I've gone over the docs/faqs and haven't been able to find
> anything, so I
> hope this question is appropriate for the list. If not, a
> quick pointer to
> where in the docs I should be looking would be great.
>
> Thanks
> Jason
>
> _________________________________________________________________
> Add photos to your e-mail with MSN 8. Get 2 months FREE*.
> http://join.msn.com/?page=features/featuredemail
>
>
>
> ==================================================================
> This is the WinPcap users list. It is archived at
> http://www.mail-archive.com/winpcap-users@winpcap.polito.it/
>
> To unsubscribe use
> mailto: [EMAIL PROTECTED]?body=unsubscribe
> ==================================================================
>
======================
This is the WinPcap users list. It is archived at
http://www.mail-archive.com/winpcap-users@winpcap.polito.it/
To unsubscribe use
mailto: [EMAIL PROTECTED]?body=subscribe
======================
==================================================================
This is the WinPcap users list. It is archived at
http://www.mail-archive.com/winpcap-users@winpcap.polito.it/
To unsubscribe use
mailto: [EMAIL PROTECTED]?body=unsubscribe
==================================================================
