nexmon – Blame information for rev 1
?pathlinks?
Rev | Author | Line No. | Line |
---|---|---|---|
1 | office | 1 | Unfortunately, the closest thing to a design document is the |
2 | "README.developer" document in the "doc" directory of the Wireshark |
||
3 | source tree; however, although that's useful for people adding new |
||
4 | protocol dissectors to Wireshark, it doesn't describe the operations of |
||
5 | the "core" of Wireshark. |
||
6 | |||
7 | We have no document describing that; however, a quick summary of the |
||
8 | part of the code you'd probably be working with is: |
||
9 | |||
10 | for every capture file that Wireshark has open, there's a |
||
11 | "capture_file" structure - Wireshark currently supports only one |
||
12 | open capture file at a time, and that structure is named |
||
13 | "cfile" (see the "file.h" header file); |
||
14 | |||
15 | that structure has a member "plist", which points to a |
||
16 | "frame_data" structure - every link-layer frame that Wireshark |
||
17 | has read in has a "frame_data" structure (see the |
||
18 | "epan/packet.h" header file), the "plist" member of "cfile" |
||
19 | points to the first frame, and each frame has a "next" member |
||
20 | that points to the next frame in the capture (or is null for the |
||
21 | last frame); |
||
22 | |||
23 | each "frame_data" struct has: |
||
24 | |||
25 | a pointer to the next frame (null for the last frame); |
||
26 | |||
27 | a pointer to the previous frame (null for the first |
||
28 | frame); |
||
29 | |||
30 | information such as the ordinal number of the frame in |
||
31 | the capture, the time stamps for the capture, the size |
||
32 | of the packet data in bytes, the size of the frame in |
||
33 | bytes (which might not equal the size of the packet data |
||
34 | if, for example, the program capturing the packets |
||
35 | captured no more than the first N bytes of the capture, |
||
36 | for some value of N); |
||
37 | |||
38 | the byte offset in the capture file where the frame's |
||
39 | data is located. |
||
40 | |||
41 | See the "print_packets()" routine in "file.c" for an example of a |
||
42 | routine that goes through all the packets in the capture; the loop does |
||
43 | |||
44 | for (fdata = cf->plist; fdata != NULL; fdata = fdata->next) { |
||
45 | |||
46 | update a progress bar (because it could take a |
||
47 | significant period of time to process all packets); |
||
48 | |||
49 | read the packet data if the packet is to be printed; |
||
50 | |||
51 | print the packet; |
||
52 | |||
53 | } |
||
54 | |||
55 | The "wtap_seek_read()" call read the packet data into memory; the |
||
56 | "epan_dissect_new()" call "dissects" that data, building a tree |
||
57 | structure for the fields in the packet. |
||
58 |