On Apr 16, 2009, at 6:02 PM, Caleb Hearon wrote:
Thanks for the response. By HTTP text/plain packet I just mean that
to see this packet in Wireshark i use http.content_type == "text/
plain" && tcp.port == 80. The ASCII value is offset 32 bytes after
the beginning of the TCP headers according to Wireshark (here's the
packet I'm trying to filter: http://img15.imageshack.us/img15/7955/picture1xpp.png
).
I.e., what you mean is not "I have been working on a program that will
report when a HTTP text/plain packet is sent over the network.", but
"I have been working on a program that will report when a very
particular packet is sent over the network." - the program won't
report all HTTP replies with a text/plain body, it will all report TCP
segment packets with "for " at a particular offset in them.
Sorry, I wasn't clear in that last part. What I meant was, using
Wireshark I found that the packet coming to my Mac had the same format
as the packet coming to my Linux machine, so it should be filtering it
the same way. But my program was not doing so. So, to double check
the filter, I used tcpdump and sure enough, it passed on through,
confirming that I had the right filter string.
So this isn't an issue with Wireshark; the best list for discussing
programming with libpcap is tcpdump-workers@xxxxxxxxxxx - Wireshark
just happens to be one of the programs that uses libpcap, along with
tcpdump, snort, etc.. (The fact that the tcpdump list is also for
libpcap is historical - the same people developed tcpdump and libpcap,
and didn't bother setting up a separate list when they first split off
the low-level capture parts of tcpdump into a library.)
And, given that tcpdump sees the packet, the problem isn't with using
BPF filters, it's with some other aspect of your program.
Does your program capture that packet, along with other packets, if
you don't do any filtering?
