On Jan 11, 2008, at 4:33 PM, warlord wrote:
> a) I want to add my own protocol, on the same level as ethernet. So
> instead of "Ethernet" or "FDDI" or something similar, I want f.ex.
> "PROTO_WRL".
> In a pcap the protocol information of the packet is specified in an
> int.
> 0x1 is Ethernet, 0x6 is Token_Ring and so on. If I use a hexeditor and
> claim my packet in the pcap is of type 115(0x73), Wireshark tells me
> the
> protocol is unknown/unspecified. Great, so I found myself a free
> number
> I can (ab)use.
No, you haven't. You've found a DLT_ value that Wireshark doesn't
dissect. Just because it doesn't dissect Acorn Econet - the protocol
to which 115 is assigned - now doesn't mean it never will. (Unlikely,
perhaps, but not impossible - and, given that there are better ways of
finding a DLT_ value to use, "unlikely" isn't enough.)
The way you find a free number you can use *privately* is to look in /
usr/include/pcap-bpf.h (or, on older systems, /usr/include/net/bpf.h,
or, with the not-yet-released libpcap 1.0, /usr/include/pcap/bpf.h - /
usr/include/pcap-bpf.h includes the latter in 1.0), where, at least
with reasonably modern versions of libpcap, you'll find:
/*
* Reserved for private use. If you have some link-layer header type
* that you want to use within your organization, with the capture
files
* using that link-layer header type not ever be sent outside your
* organization, you can use these values.
*
* No libpcap release will use these for any purpose, nor will any
* tcpdump release use them, either.
*
* Do *NOT* use these in capture files that you expect anybody not
using
* your private versions of capture-file-reading tools to read; in
* particular, do *NOT* use them in products, otherwise you may find
that
* people won't be able to use tcpdump, or snort, or Ethereal, or... to
* read capture files from your firewall/intrusion detection/traffic
* monitoring/etc. appliance, or whatever product uses that DLT_ value,
* and you may also find that the developers of those applications will
* not accept patches to let them read those files.
*
* Also, do not use them if somebody might send you a capture using
them
* for *their* private type and tools using them for *your* private
type
* would have to read them.
*
* Instead, ask "[EMAIL PROTECTED]" for a new DLT_ value,
* as per the comment above, and use the type you're given.
*/
#define DLT_USER0 147
#define DLT_USER1 148
#define DLT_USER2 149
#define DLT_USER3 150
#define DLT_USER4 151
#define DLT_USER5 152
#define DLT_USER6 153
#define DLT_USER7 154
#define DLT_USER8 155
#define DLT_USER9 156
#define DLT_USER10 157
#define DLT_USER11 158
#define DLT_USER12 159
#define DLT_USER13 160
#define DLT_USER14 161
#define DLT_USER15 162
Use one of those values.
If you want a type you can use *publicly* - i.e., if you want libpcap
and some application such as Wireshark to officially include support
for it - you need to ask [EMAIL PROTECTED] for a DLT_ value.
> It seems wiretap/libpcap.c is responsible for number->protocol
> decoding.
> So I edit the file and add number 115 with a value of
> "WTAP_ENCAP_WRL".
> When trying to recompile wireshark I'm consequently told that this
> hasn't been assigned, so I edit wiretap/wtap.h and add WTAP_ENCAP_WRL
> with a value of 115.
Note that, in reasonably modern versions of Wireshark, wiretap/wtap.h
has:
#define WTAP_ENCAP_USER0 45
#define WTAP_ENCAP_USER1 46
#define WTAP_ENCAP_USER2 47
#define WTAP_ENCAP_USER3 48
#define WTAP_ENCAP_USER4 49
#define WTAP_ENCAP_USER5 50
#define WTAP_ENCAP_USER6 51
#define WTAP_ENCAP_USER7 52
#define WTAP_ENCAP_USER8 53
#define WTAP_ENCAP_USER9 54
#define WTAP_ENCAP_USER10 55
#define WTAP_ENCAP_USER11 56
#define WTAP_ENCAP_USER12 57
#define WTAP_ENCAP_USER13 58
#define WTAP_ENCAP_USER14 59
#define WTAP_ENCAP_USER15 60
The fact that they're named USER0 through USER15 is not a
coincidence. :-)
However, they're not mapped to DLT_USER0 through DLT_USER15, as
somebody might want them for some other purpose, e.g. to handle a
particular link layer header type in another capture file format.
Both sets are intended for that sort of private use.
> I recompile wshark and what do I get? Protocol 115 is not unknown
> anymore. But now it's "WTAP_ENCAP = 115". How do I get that right?
> All I
> want is my own protocol, instead of ethernet.
You have to have a dissector for your own protocol, *and* you have to
have it tell the core of Wireshark that it should be used with a
particular WTAP_ENCAP value. You do the latter by having your
dissector's "reg_handoff" routine call
dissector_add("wtap_encap", WTAP_ENCAP_{yours}, {your
dissector}_handle);
See, for example, epan/dissectors/packet-eth.c, which contains the
dissector for Ethernet.
> b) I don't need all those dissectors in epan/dissectors. I tried
> removing some from epan/dissectors/Makefile.common from the
> CLEAN_DISSECTOR_SRC section. Wireshark failed to compile, complaining
> about missing dependencies. Can I not easily remove unused
> dissectors(basically all of them)?
No.
> d) I'm on a Gentoo and have Wireshark installed from the packet
> manager.
> I created a new dir for my experimental dev wireshark, checked
> wireshark
> out into there and built it. The build worked fine, but I can't run
> it.
> It segfaults when I try to execute it.
>
> stat64("/home/warlord/some_dirs_here/wireshark2/gtkrc", 0xbf93c8fc)
> = -1
> ENOENT (No such file or directory)
> access("/home/warlord/some_dirs_here/wireshark2/gtkrc.en_EN", F_OK)
> = -1
> ENOENT (No such file or directory)
> access("/home/warlord/some_dirs_here/wireshark2/gtkrc.en", F_OK) = -1
> ENOENT (No such file or directory)
> lstat64("/home/warlord/.wireshark/gtkrc", 0xbf93c8fc) = -1 ENOENT (No
> such file or directory)
> access("/home/warlord/.wireshark/gtkrc.en_EN", F_OK) = -1 ENOENT (No
> such file or directory)
> access("/home/warlord/.wireshark/gtkrc.en", F_OK) = -1 ENOENT (No such
> file or directory)
> - --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> +++ killed by SIGSEGV +++
Run it under GDB, and see *where* it gets the segmentation fault.
_______________________________________________
Wireshark-dev mailing list
[email protected]
http://www.wireshark.org/mailman/listinfo/wireshark-dev
