[Winpcap-users] Unable to send or receive some IP packets on WinXP
Loris Degioanni
loris.degioanni at gmail.com
Wed Aug 10 16:33:50 GMT 2005
Tom,
the relationship between the WinPcap driver and the OS is shown at
http://www.winpcap.org/docs/docs31/html/group__NPF.html.
The WinPcap driver is a protocol driver, and uses the standard NDIS
interface (NdisSend) to send packets to the network. NdisSend delivers
the packet to the NIC driver, that in turs transmits it on the wire.
I can see two reasons why your packets are not transmitted:
- the NIC driver does something strange with some kind of packets. This
is very remote, but could maybe happen if your network card has fancy
features like TCP offloading engines. In that case, you can try to
disable them.
- there is an intermediate driver between NPF and the NIC driver. This
is more probable. Typical NDIS intermediate drivers are personal
firewalls, packet schedulers, third party VPN clients, and so on. You
can try to disable all these softwares and see if it works better.
Loris
Heyligen Tom wrote:
> Dear WinPcap-users,
>
> So far I didn't receive any reply on below WinXP packet send/receive question, so I continued the investigation by linking my code with wpcap.lib from the new WinPcap v3.1.
> Unfortunately, the result is still the same: The packets don't appear on the wire while pcap_sendpacket() returns 0 (indicating success)...
>
> Any clues?
>
> Thanks again,
> Tom.
>
>
> -----Original Message-----
> From: winpcap-users-bounces at winpcap.org
> [mailto:winpcap-users-bounces at winpcap.org]On Behalf Of Heyligen Tom
> Sent: dinsdag 2 augustus 2005 15:47
> To: winpcap-users at winpcap.org
> Subject: [Winpcap-users] Unable to send or receive some IP packets on
> WinXP
>
>
> Dear WinPcap-users,
>
> WinPcap on my WinXP is unable to send (and receive, see later) some mangled or non-standard IGMP/ICMP/TCP/UDP packets. Please find below some specific sample packets, captured with libpcap/ethereal on Linux 2.6.9. Apparently, they all struggle with some length at some point?
>
> They never appear in Ethereal, nor on the wire. These packets can however be send when changing the Ethernet type from 0x08 0x00 (IP) to e.g. 0x09 0x00 (unknown) or changing the IP protocol to e.g. 0xFF. This happens on any Ethernet interface on that machine...making me believe it must be a "security feature/setting" hidden somewhere in Windows? Strangely, I am unable to reproduce this problem on similar WinXP machines with/without SP2 installed.
>
> I use the Win32 specific function pcap_sendpacket(pcap_t*,u_char*,int) to send the raw data. This function returns 0, so the packet should be succesfully sent...
>
>
> Additionally, when trying to receive such packets, below sample packets 1 and 3 were transferred to my pcap_handler callback (and seen in Ethereal), while packet 2 wasn't...
>
>
> Any ideas which part in WinPcap or WinXP is responsible for this unexpected and unwanted behavior?
> P.S. No problems seen on Linux when calling write() to send and using libpcap to receive.
>
> Thanks a lot,
> Tom.
>
>
>
> Environment:
> ------------
> (Although I played around with versions and OS hotfixes, in vain):
> MS WinXP SP2 (firewall and other security tools disabled)
> WinPcap v3.0
> Ethereal v0.10.10
>
>
> sample packet 1
> (IGMP part should be at least 8 bytes long?)
> --------------------------------------------
> Frame 1 (40 bytes on wire, 40 bytes captured)
> Ethernet II, Src: 00:01:02:03:04:05, Dst: 00:0d:56:c5:01:a5
> Internet Protocol, Src Addr: 192.168.1.123 (192.168.1.123), Dst Addr: 192.168.1.254 (192.168.1.254)
> Version: 4
> Header length: 20 bytes
> Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
> Total Length: 26
> Identification: 0x5456 (21590)
> Flags: 0x00
> Fragment offset: 0
> Time to live: 1
> Protocol: IGMP (0x02)
> Header checksum: 0xe0c2 (correct)
> Source: 192.168.1.123 (192.168.1.123)
> Destination: 192.168.1.254 (192.168.1.254)
> Internet Group Management Protocol
> Type: Unknown (0xaa)
> Data
>
> 0000 00 0d 56 c5 01 a5 00 01 02 03 04 05 08 00 45 00 ..V...........E.
> 0010 00 1a 54 56 00 00 01 02 e0 c2 c0 a8 01 7b c0 a8 ..TV.........{..
> 0020 01 fe aa bb cc dd ee ff ........
>
>
> sample packet 2
> (ip.hdr_len 0x06 should be 0x05?)
> ---------------------------------
> Frame 2 (74 bytes on wire, 74 bytes captured)
> Ethernet II, Src: 00:01:02:03:04:05, Dst: 00:0d:56:c5:01:a5
> Internet Protocol, Src Addr: 192.168.1.123 (192.168.1.123), Dst Addr: 192.168.1.254 (192.168.1.254)
> Version: 4
> Header length: 24 bytes
> Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
> Total Length: 60
> Identification: 0x0188 (392)
> Flags: 0x04 (Don't Fragment)
> Fragment offset: 0
> Time to live: 128
> Protocol: ICMP (0x01)
> Header checksum: 0x736f (incorrect, should be 0x2613)
> Source: 192.168.1.123 (192.168.1.123)
> Destination: 192.168.1.254 (192.168.1.254)
> Options: (4 bytes)
> Internet Control Message Protocol
> Type: 3 (Destination unreachable)
> Code: 0 (Network unreachable)
> Checksum: 0x0500 (incorrect, should be 0x525c)
> Internet Protocol, Src Addr: 113.114.115.116 (113.114.115.116), Dst Addr: 117.118.119.97 (117.118.119.97)
> Version: 6
> Header length: 20 bytes
> Differentiated Services Field: 0x66 (DSCP 0x19: Unknown DSCP; ECN: 0x02)
> Total Length: 26472
> Identification: 0x696a (26986)
> Flags: 0x06 (Don't Fragment) (More Fragments)
> Fragment offset: 23392
> Time to live: 109
> Protocol: Compaq Peer (0x6e)
> Header checksum: 0x6f70 (incorrect, should be 0x1f2d)
> Source: 113.114.115.116 (113.114.115.116)
> Destination: 117.118.119.97 (117.118.119.97)
> Data (8 bytes)
>
> 0000 00 0d 56 c5 01 a5 00 01 02 03 04 05 08 00 46 00 ..V...........F.
> 0010 00 3c 01 88 40 00 80 01 73 6f c0 a8 01 7b c0 a8 .<.. at ...so...{..
> 0020 01 fe 08 00 45 5c 03 00 05 00 61 62 63 64 65 66 ....E\....abcdef
> 0030 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 ghijklmnopqrstuv
> 0040 77 61 62 63 64 65 66 67 68 69 wabcdefghi
>
>
> sample packet 3
> (ip.len 0x00 0x3C is too long?)
> -------------------------------
> Frame 3 (41 bytes on wire, 41 bytes captured)
> Ethernet II, Src: 00:01:02:03:04:05, Dst: 00:0d:56:c5:01:a5
> Internet Protocol, Src Addr: 192.168.1.123 (192.168.1.123), Dst Addr: 192.168.1.254 (192.168.1.254)
> Version: 4
> Header length: 20 bytes
> Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
> Total Length: 60
> Identification: 0x0188 (392)
> Flags: 0x04 (Don't Fragment)
> Fragment offset: 0
> Time to live: 128
> Protocol: ICMP (0x01)
> Header checksum: 0x746f (correct)
> Source: 192.168.1.123 (192.168.1.123)
> Destination: 192.168.1.254 (192.168.1.254)
> Internet Control Message Protocol
> Type: 8 (Echo (ping) request)
> Code: 0
> Checksum: 0x455c (incorrect, should be 0xefff)
> Identifier: 0x0300
> [Malformed Packet: ICMP]
>
> 0000 00 0d 56 c5 01 a5 00 01 02 03 04 05 08 00 45 00 ..V...........E.
> 0010 00 3c 01 88 40 00 80 01 74 6f c0 a8 01 7b c0 a8 .<.. at ...to...{..
> 0020 01 fe 08 00 45 5c 03 00 05 ....E\...
>
> _______________________________________________
> Winpcap-users mailing list
> Winpcap-users at winpcap.org
> https://www.winpcap.org/mailman/listinfo/winpcap-users
>
> _______________________________________________
> Winpcap-users mailing list
> Winpcap-users at winpcap.org
> https://www.winpcap.org/mailman/listinfo/winpcap-users
>
More information about the Winpcap-users
mailing list