[Isaac Wilcox <ethereal@xxxxxxxxxxxxx>]

Three things I've noticed in 0.8.12 of (t)ethereal...

1. Filtering for http.request sometimes incorrectly matches HTTP responses
as requests if the response packets have 'put', 'get' or 'post' as their
first 3/4 characters, e.g.

[snip]
29190 2866.816976 workstation.my.domain -> wwwcache.my.domain HTTP GET http://js1.hitbox.com/js?acct=WQ590821MDRD76EN0&m=w131.hit ...
29201 2867.322619 workstation.my.domain -> wwwcache.my.domain HTTP GET http://hg1.hitbox.com/HG?hc=w131&hb=WQ590821MDRD76EN0&n=Ma ...
29216 2875.181982 workstation.my.domain -> wwwcache.my.domain HTTP GET http://www.icewarez.net/top2.html
29221 2875.234332 workstation.my.domain -> wwwcache.my.domain HTTP GET http://www.top25mp3.com/enter/top25.cgi?mp3mp4 HTTP/1.0\r\n
29232 2875.979058 wwwcache.my.domain -> workstation.my.domain HTTP GET>\r\n

The HTML page generated when you access:

	http://www.top25mp3.com/enter/top25.cgi?mp3mp4

contains the line:

<form action=http://www.searchtraffic.com/search.php3 target="_blank" method=GET>

and I guess this was on a packet border. This has (rather surprisingly)
shown up several times in my logs.

Maybe the http.request matching code should be based more strongly on
the RFCs - section 5.1 of 2616 (http://www.ietf.org/rfc/rfc2616.txt)
says that after the request method there has to be a space:

	Request-Line   = Method SP Request-URI SP HTTP-Version CRLF

It also says that the request methods mentioned in 5.1.1 are
always uppercase. The older RFCs (1.1 draft, 1.0) say exactly the same
things. So I think you should be matching 'PUT ', 'GET ' etc.,
and doing it case-insensitively. I'm happy to be proven wrong though.
There's a patch at the end that does this. It also defines TRACE as a
request method, which it wasn't before for some reason.


2. Why are bxxp and smtp requests/responses called xxx.req/xxx.rsp when all
the others are xxx.request/xxx.response ?

Patch is attached, but I'm not sure whether you'd want to use it, because
it might break a few people's setups.


3. The mailing lists seem to be full of people asking why their capture
filters won't parse. I certainly got caught out by this. The way I see it,
the problem is threefold.

First and foremost, the buttons and dialogs are not clear enough.
Where Ethereal says "Filter", it should say what kind. And when it gives
an error message, it should say what kind of filter it though it was
parsing.

Secondly, display filters and capture filters share the same storage.
Seeing as they use very different syntax (at least ATM they do), this is
a really bad idea. The lists of filters should allow users to easily
distinguish between the two types.

Thirdly, the documentation isn't clear enough - the README doesn't
mention the User's Guide, and the link to the User's Guide on the website
is discreetly hidden away at the bottom of the page rather than being
linked to from the "Resources" box on the LHS. It's not even linked to
from the "Useful Links" page.

I've written this small section on troubleshooting filter problems
(read: filter misunderstandings) which you may or may not consider
suitable for any of the following places: the FAQ, the User's Guide
(in the Using Ethereal section), the user mailing lists. It's yours
to GPL/hack/release if you think it useful.

Isaac Wilcox

---

Troubleshooting Filter Parse Errors

If, after entering a *capture* filter in the "Capture Preferences" dialog
and clicking "OK", you're getting the following error message:

	Unable to parse filter string (parse error).

then this means one of three things:

	a) You've got the wrong idea and tried to enter a *display* filter
	   where Ethereal wanted a *capture* filter (but Ethereal didn't tell
	   you which kind it wanted, so don't blame yourself).

	b) You've got the right idea and entered a perfectly valid capture
	   filter, but you are falling foul of a bug in older versions of pcap.
	   The bug is that if you get a capture filter wrong *even once* during
	   an Ethereal session, you must restart Ethereal before you can get
	   a valid capture filter to work. So try restarting Ethereal and
	   entering your capture filter again. If it /still/ doesn't work,
	   chances are...

	c) You've entered an invalid capture filter. Check it very carefully
	   against the rules described in the tcpdump(1) man page. 
	   Try it out using tcpdump until you get it right.

If, after clicking the "Filter" button at the bottom of the main screen,
entering a *display* filter you're getting a message like this:

	Unable to parse filter string ("your-display-filter-here").

then this means one of two things:

	a) You've got the wrong idea and tried to enter a *capture* filter 
       where Ethereal wanted a *display* filter (but Ethereal didn't tell
       you which kind it wanted, so don't blame yourself).

	b) You've got the right idea and entered what you *think* is a
	   perfectly valid display filter, but you're wrong and it's invalid.
	   Check it very carefully against the rules described in the
	   ethereal(1) man page. If it still doesn't work, ask someone on the
	   mailing list for help.
	   
---


Here's dem patches:

a) Fixes HTTP request/response detection. Tested on my capture files,
and appears to do exactly what it should, but I recommend someone else
has a go too on other stuff that used to work, and checks for differences.

--- packet-http.c	Tue Sep 12 21:25:18 2000
+++ packet-http.c.new	Sun Oct  8 05:09:19 2000
@@ -222,47 +222,44 @@
 static int
 is_http_request_or_reply(const u_char *data, int linelen, http_type_t *type)
 {
-	if (linelen >= 3) {
-		if (strncasecmp(data, "GET", 3) == 0 ||
-		    strncasecmp(data, "PUT", 3) == 0) {
+	if (linelen >= 4) {
+		if (strncmp(data, "GET ", 4) == 0 ||
+		    strncmp(data, "PUT ", 4) == 0) {
 			if (*type == HTTP_OTHERS)
 				*type = HTTP_REQUEST;
 			return TRUE;
 		}
 	}
-	if (linelen >= 4) {
-		if (strncasecmp(data, "HEAD", 4) == 0 ||
-		    strncasecmp(data, "POST", 4) == 0) {
+	if (linelen >= 5) {
+		if (strncmp(data, "HEAD ", 5) == 0 ||
+		    strncmp(data, "POST ", 5) == 0) {
 			if (*type == HTTP_OTHERS)
 				*type = HTTP_REQUEST;
 			return TRUE;
 		}
-	}
-	if (linelen >= 5) {
-		if (strncasecmp(data, "TRACE", 5) == 0)
-			return TRUE;
-		if (strncasecmp(data, "HTTP/", 5) == 0) {
+		if (strncmp(data, "HTTP/", 5) == 0) {
 			if (*type == HTTP_OTHERS)
-				*type = HTTP_RESPONSE;
-			return TRUE;	/* response */
-		}
+                                *type = HTTP_RESPONSE;
+                        return TRUE;    /* response */
+                }
 	}
 	if (linelen >= 6) {
-		if (strncasecmp(data, "DELETE", 6) == 0) {
+		if (strncmp(data, "TRACE ", 6) == 0) {
 			if (*type == HTTP_OTHERS)
 				*type = HTTP_REQUEST;
 			return TRUE;
 		}
 	}
 	if (linelen >= 7) {
-		if (strncasecmp(data, "OPTIONS", 7) == 0) {
+		if (strncmp(data, "DELETE ", 7) == 0) {
 			if (*type == HTTP_OTHERS)
 				*type = HTTP_REQUEST;
 			return TRUE;
 		}
 	}
-	if (linelen >= 7) {
-		if (strncasecmp(data, "CONNECT", 7) == 0) {
+	if (linelen >= 8) {
+		if (strncmp(data, "OPTIONS ", 8) == 0 ||
+		    strncmp(data, "CONNECT ", 8) == 0) {
 			if (*type == HTTP_OTHERS)
 				*type = HTTP_REQUEST;
 			return TRUE;
---------

b) Fixes inconsistent protocol field names for smtp and bxxp.
Whoever designed the build system has it all under control - changing
these automatically updates the man pages. Sweet !

--- packet-smtp.c	Sun Oct  8 05:22:21 2000
+++ packet-smtp.c.new	Sun Oct  8 05:20:03 2000
@@ -453,10 +453,10 @@
 {
   static hf_register_info hf[] = {
     { &hf_smtp_req,
-      { "Request", "smtp.req", FT_BOOLEAN, BASE_NONE, NULL, 0x0, ""}},
+      { "Request", "smtp.request", FT_BOOLEAN, BASE_NONE, NULL, 0x0, ""}},
 
     { &hf_smtp_rsp,
-      { "Response", "smtp.rsp", FT_BOOLEAN, BASE_NONE, NULL, 0x0, ""}},
+      { "Response", "smtp.response", FT_BOOLEAN, BASE_NONE, NULL, 0x0, ""}},
   };
   static gint *ett[] = {
     &ett_smtp

--- packet-bxxp.c	Tue Sep 12 03:24:19 2000
+++ packet-bxxp.c.new	Sun Oct  8 05:23:44 2000
@@ -819,10 +819,10 @@
 {
   static hf_register_info hf[] = {
     { &hf_bxxp_req,
-      { "Request", "bxxp.req", FT_BOOLEAN, BASE_NONE, NULL, 0x0, "" }},
+      { "Request", "bxxp.request", FT_BOOLEAN, BASE_NONE, NULL, 0x0, "" }},
 
     { &hf_bxxp_rsp,
-      { "Response", "bxxp.rsp", FT_BOOLEAN, BASE_NONE, NULL, 0x0, "" }},
+      { "Response", "bxxp.response", FT_BOOLEAN, BASE_NONE, NULL, 0x0, "" }},
 
     { &hf_bxxp_seq,
       { "Sequence", "bxxp.seq", FT_BOOLEAN, BASE_NONE, NULL, 0x0, "" }},


---------