|author||Gerald Combs <firstname.lastname@example.org>||2009-05-20 15:50:40 +0000|
|committer||Gerald Combs <email@example.com>||2009-05-20 15:50:40 +0000|
From Jakub Zawadzki via bug 3421:
e_ip->ip_ttl is currently always set to 0, in attachment fix. I also (in same patch, sorry) submit cleanup to use ep_alloc() instead of static e_ip buffers, I didn't test it, but I hope it's ok. There's note about static buffers in doc/README.tapping, which should also be updated, but I don't feel so good with my English :) From me: Rename e_ip to ws_ip. Update the static buffers note in README.tapping. svn path=/trunk/; revision=28425
Diffstat (limited to 'doc/README.tapping')
1 files changed, 7 insertions, 10 deletions
diff --git a/doc/README.tapping b/doc/README.tapping
index 0833cd69d6..f437ed71e7 100644
@@ -173,16 +173,13 @@ same packet, you will have to make sure that each instance of
tap_queue_packet() is using its own instance of private struct variable
so they don't overwrite each other.
-See packet-ip.c which has a simple solution to the problem. It just
-uses a static struct of 4 instances of the ip header struct and
-cycles through them each time the dissector is called.
-4 is just a number taken out of the blue but it should be enough for most
-Of course, if someone would generate a capture with IP encapsulated
-over IP over IP over IP over IP, so that there would be more than 4 IP headers
-in the same packet, yes then this would fail. The likelihood of this
-happening in real life is probably very low. If it turns out to be a problem
-we can just increase the cycle length when that happens.
+See packet-ip.c which has a simple solution to the problem. It creates
+a unique instance of the IP header using ep_alloc().
+Previous versions used a static struct of 4 instances of the IP header
+struct and cycled through them each time the dissector was called. (4
+was just a number taken out of the blue but it should be enough for most
+cases.) This would fail if there were more than 4 IP headers in the same
+packet, but that was unlikely.