====================================================== DETAILED README/HOWTO for MOTE NETWORK VISUALIZATION ====================================================== | | The home of this project is: | http://www.isi.edu/ilense/software/mnv/ | | Visit this site for the latest versions | and for links to source code not included | with this distribution. This is a suite of software (3 host side modules, plus mote code) for Linux which allows the user to capture packets from a live sensor network. During and after the capture, the user is able to view the contents of the packets in human-readable format, as well as to view the flow of packets as a whole in an intuitive and customizable manner. Additionally, certain kinds of aggregate data can be generated automatically. Sections of this document: 0. Licensing & Copyright 1. Status 2. Installation a) Kernel driver & helper app b) Ethereal c) Mote 3. Setup a) Kernel driver & helper app b) Ethereal c) Mote 4. Use a) Basic use of Ethereal b) Viewing aggregate data c) Application-level protocols d) Using tethereal 5. Troubleshooting a) Known bugs b) Common problems c) Common questions 6. Plans for Future Development 7. Writing your own expansions a) Mote-side b) Ethereal 8. Contact information 9. Acknowledgments == [0] LICENSING AND COPYRIGHT ======================================= All code in this distribution (with the exception of the redistributed code from Ethereal) is: (C) Copyright 2005 Information Sciences Institute University of Southern California The copyright(s) for the unmodified Ethereal code is described in the Ethereal READMEs and source. All code in this suite is licensed for use under the GNU General Public License (GPL). See LICENSE for details and COPYING for a copy of the GPL. == [1] STATUS ======================================================== This suite works with the S-MAC, B-MAC, and SCP-MAC MAC-layer protocols. There is not yet any significant application-level support. Support exists for the SMACTest and BMACTest applications only. All other application-level data is displayed only as a block of "data" in Hex and ASCII. If there is a particular application or MAC you would like to see supported, please see section 8 (Contact information) for information about contacting the developer, or see section 9 (Writing your own applications) to look into doing it yourself. Mote-side code is particularly easy. This suite should be treated as an in-development (or "beta") release. See section 5a (Known bugs) for a listing of flaws in the current version of this software. == [2] INSTALLATION ================================================== Overall, there are four parts to this suite: 1. Kernel driver, called "moteradio" 2. Helper app for the driver, called "mrattach" 3. Ethereal (or tethereal) 4. Mote-side code, one of: "S-MAC Snooper", "S-MAC New Snooper", "B-MAC Snooper", or "SCP-MAC Snooper". -- <2a> Kernel Driver & helper app ----------------------------------- The kernel driver, called "moteradio", is now provided only as source. However, the compilation process is straightforward. The kernel driver sources are in moteradio/module. First, if you are building for a 2.4 series kernel, note that this module is primarily intended for the 2.6 series, but should work for most later 2.4 series kernels. Then, open Makefile-2.4 and change the KERNELDIR variable to point to your kernel sources. In either case, please first open the appropriate Makefile and read through the available options to ensure that your driver has the correct options. For 2.6 series, type: make For 2.4 series, type: make -f Makefile-2.4 This should generate moteradio.ko (for 2.6) or moteradio.o (for 2.4). The helper app, called "mrattach" is provided as a Linux binary and as source. The binary *should* work on all platforms, but if it does not you can build it for your system by typing "make" in the source directory. The helper binary is in moteradio/binaries. The helper sources are in moteradio/mrattach. -- <2b> Ethereal ----------------------------------------------------- Ethereal with MNV modifications is provided as: - two i386 RPMs (Ethereal core and Ethereal GTK GUI) - one SRPM - a patch against Ethereal (version 0.10.11, a link to download unmodified source of Ethereal 0.10.11 can be found on the website - see the top of this document). - raw sources to be merged into Ethereal (version 0.10.11). This is primarily for developers. Instructions for RPM and patch installation follow. Installation from RPM: The Ethereal RPMs are located in ethereal/rpms. The ethereal-0.10.11-4mnv0.3.i386 RPM is the base libraries and a terminal interface for Ethereal called "tethereal". The ethereal-0.10.11-4mnv0.3.i386-gnome RPM is a GTK-based GUI for Ethereal. Unless you have a compelling reason to use the terminal version, it is advisable to install the GUI for ease of use. To install each of these, as root, type: rpm -ivh .rpm. Note that even if you are installing the GUI, you must still install the base rpm first. Installation from patches: The diff for Ethereal is located in ethereal/patches. Visit the project website (see top of document) to find a link to download the source for Ethereal version 0.10.11 as a gzip'ed tar archive. Extract the archive to any directory, and copy ethereal-0.10-11-mnv-0.3.patch into the top level of the extracted source. In the top level directory of the extracted source, type: patch -p1 < ethereal-0.10.11-mnv-0.3.patch ./configure && make And then as root: make install This should build and install Ethereal. This installs the GUI by default. If you wish to exclude the GUI or customize anything else, type ./configure --help after patching and read the information there. -- <2c> Mote --------------------------------------------------------- Mote code is provided only as source on the assumption that anyone wanting to use this software will also have the experience and capacity to program motes. Mote code for S-MAC is located in mote/smac-snooper Mote code for B-MAC is located in mote/bmac-snooper Mote code for SCP-MAC is located in mote/scpmac-snooper For each of these, simply ensure that your TOSDIR environment variable is set properly, and then build and install the software as you would any other mote code. Namely, by entering the directory and typing: make install[.id] [options] For example, to install on a MICA-2 with id=0 and default options: make install mica2 The S-MAC New snooper is somewhat different. It modifies a file internal to S-MAC to function. Thus, mote/smac-new-snooper is a mirror of the S-MAC tos-contrib tree. Simply copy the files to the corresponding locations where you have S-MAC installed, and compile the snooper from there. == [3] SETUP ========================================================= -- <3a> Kernel Driver & helper app ----------------------------------- To perform a one-time-only loading of the driver, simple type (as root): /sbin/insmod moteradio.{o,ko} Where you choose "o" for 2.4 kernels and ".ko" for 2.6 kernels. To cause the module to load on every boot, add "moteradio" to /etc/modules.autoload. Once the kernel driver is loaded, you must "attach" it to a serial port, using the program "mrattach". This maps a serial port on your system to a (pseudo) network interface. To accomplish this, simply execute the mrattach program as: ./mrattach /dev/ttyS Where is the number of the serial port that you are going to connect your mote to. Usually this is 0 if you are not using any other serial devices, so: ./mrattach /dev/ttyS0 There is no universal way to cause this to execute on every boot. Please consult your Linux distribution's documentation for ideas on how to accomplish this. When you have attached the serial port, you have a network interface called "mr0" ("mr" for "mote radio") that you can manipulate as you would any other interface using the ifconfig tool. For example (as root): To start the interface: ifconfig mr0 up To stop the interface: ifconfig mr0 down To view interface status: ifconfig mr0 Bringing up the interface as shown above is the last step of setting up the driver and helper. Now your system is ready to convey packets from a mote to Ethereal. Note: You can set up more than one serial port to network interface mapping simultaneously (so long as you are using distinct serial ports). These additional devices are will be called mr1, mr2, etc. Please see section 5a (Known bugs) if you are planning to do this. -- <3b> Ethereal ----------------------------------------------------- Once ethereal is installed, the Ethereal application itself requires no further setup. You can run "ethereal" or "tethereal" and immediately begin capturing packets as described in section 4a (Basic use of Ethereal). However, you may wish to review the settings for the MAC protocol you will be using to ensure that Ethereal's assumptions match your parameters. To view and configure options, in Ethereal, select "Preferences" from the "Edit" menu. Then from the left-hand list under "Protocols", select "Mote Radio", "B-MAC", or "S-MAC". Mote Radio Options: - "Assume all ambiguous packets are" Your choice here should be the MAC protocol that you plan to use Ethereal to analyze. If left to its default setting, Ethereal does its best to guess which MAC you are using, but may make mistakes and show a valid packet of one MAC as a corrupt packet of another. In the rare case that you are capturing a heterogeneous network (this requires two snooper motes and two serial -> network interface mappings), leave as default. Note: At this time, setting this option to SCP-MAC is the only way to capture SCP-MAC packets as no heuristic for detecting SCP-MAC packets has been developed. - "Assume that snooper uses meta flags" If you are using the augmented snooper provided in the mote/smac-new-snooper directory of MNV (or a third party snooper using the same augmented protocol), you will want to choose this option. The augmented snooper allows more robust indications of possible collisions and causes for packet corruption. Note that you also must enable NEWSNOOPER=y in the moteradio driver Makefile when you install the driver. B-MAC Options: - "Maximum payload size (in bytes)" The B-MAC protocol has a fixed-length data field, but the length of this field can be modified at compile-time. This option defaults to the B-MAC default of 29 bytes, but if you have changed this default in your B-MAC application you must also change this setting to match. S-MAC Options: - "Assume S-MAC Application Data packets have Fast Path Schedule header" Select this option if you defined FAST_PATH_SCHEDULE when compiling your S-MAC application. - "Assume S-MAC Application Data packets have a transmission timestamp" Select this option if you defined SMAC_TX_TIMESTAMP when compiling your S-MAC application. - "Assume S-MAC Schedule Synchronization packets have global schedule headers" Select this option if you defined GLOBAL_SCHEDULE when compiling your S-MAC application. - "Assume S-MAC Schedule Synchronization packets have extra debugging headers" Select this option if you defined SMAC_SNOOPER_DEBUG when compiling your S-MAC application. - "Exclude packets with bad CRCs from S-MAC statistics, conversation, and schedule tracking" This option will exclude packets which have been in some way corrupted during transmission from being included in aggregate data calculations. This may throw off some statistics slightly (e.g. a "total packets" count is really a "total non-corrupt packets" count), but prevents spurious "phantom" nodes from showing up when the source or destination field has been corrupted into a random number. This is enabled by default. NOTE: Just because the snooper received a packet with a bad CRC does not mean the destination did as well. The signal may have encountered interference local to the snooper mote. - "Duty Cycle (percentage)" This is the percent of time an S-MAC node keeps its radio on (listens) when it is not actively sending or receiving. By default this matches the S-MAC default of 10. If you changed this default in your application, you should also change it here. - "Synchronization frequency determined by" This is an extremely technical option. Suffice to say, select "Period Count" if: 1. You are using the reference implementation of S-MAC with no changes to the synchronization frequency or period length. 2. You are using a third-party implementation of S-MAC that follows the S-MAC specification (i.e. send a SYNC packet every n *periods* rather than every m *seconds*) In all other cases select independent timer. The "Period Count" method produces more accurate aggregate statistics for the cases in which it can be used. The "Independent Timer" method works for all S-MAC implementations, but tends to produce more error. The S-MAC reference implementation actually does *not* follow the spec, however it behaves as though it is following the spec for the default value of SYNC_PERIOD only. - "Period Count synchronization frequency (periods)" By default S-MAC sends SYNC packets every 10 periods. If you have a third-party implementation that does something different, change this value. This option is moot if you have selected "Independent Timer" above. - "Independent Timer synchronization frequency (milliseconds)" If you have changed SYNC_PERIOD in the reference S-MAC implementation, match the value here. This option is moot if you have selected "Period Count" above. -- <2c> Mote --------------------------------------------------------- Once the mote is programmed with the appropriate snooper code, it must simply be powered, attached to your computer via serial cable, and in a location such that it can overhear as much of the traffic that you're interested in as possible. No further action is required. == [4] USE =========================================================== -- <4a> Basic use of Ethereal ---------------------------------------- This section deals with the GUI. For terminal-based analysis, see section 4d (Using tethereal). If ethereal is properly installed, you may simply type "ethereal" to start the application. Note that depending on how your system is configured you may have to use Ethereal as root to interface with the mote. The quickest way to grab data from your network is to choose "Interfaces" from the "Capture" menu and press the "Capture" button next to the interface you wish to capture from (in the normal case, this is "mr0"). Press "Stop" on the dialog that pops up to stop the capture and view the packets. Do not select "Start" from the "Capture" menu as this will most likely begin capturing packets from your LAN or Internet connection. For more advanced options, select "Options" from the "Capture" menu. Among other things, this allows you to capture to a file and to view your captured packets in real time. Many of these options, however, are irrelevant to sensor networks and have no effect. Once you have a set of captured packets they will display in a list format on the top portion of your screen. This area should show you the destination address (as a mote number a.k.a. a TOS ID), the protocol (which is the highest-level protocol in this packet that Ethereal can decipher), and a summary of the contents. For S-MAC, the source address will also be shown (B-MAC does not have a source address field at the MAC layer). In addition, Ethereal will show you the packet number and the time captured, both relative to start of capture. If you click on a particular packet, information will appear in the middle and bottom portions of the screen. The data in the middle is a human-readable breakdown of the data contained in the packet, organized first by protocol and then by field. The "Frame" protocol is Ethereal meta-data. The "Mote Radio" protocol is the packet length and CRC fields which are actually transmitted over the radio, plus a timestamp which is meta-data added by the kernel driver. Below that you will find your MAC protocol and its associated fields. Below that you will find any higher level (application, transport, etc) protocols that Ethereal recognizes. Expand a protocol to see its constituent fields by clicking the triangle to its left. The bottom portion of the screen is a hex and ASCII representation of the packet data. Clicking on a protocol or field in the middle area will highlight the corresponding byte(s) in the bottom are and vice-versa. You can filter which packets you are looking at using the filter tool at the top. Click the "+ Expression" button. This gives you a list of protocols on the left which can be expanded to revel their constituent fields. Select a field, then input a relation to be satisfied by that field on the right. When you click OK, an expression corresponding to that relation will be appended to the filter box. Click "Apply" to filter the view so that it only displays packets satisfying the given relation. You can concatenate relations using standard C boolean operators &&, ||, !, etc. Click "Clear" to reset the filter. -- <4b> Viewing aggregate data --------------------------------------- Two types of aggregate data are available for all protocols since they are independent of packet content. One is the overall packet summary accessible by selecting "Summary" from the "Statistics" menu. The other is "IO Graphs" also in the "Statistics" menu. This allows you to plot the volume of any arbitrary type of packet over time. You select the packets which will be plotted by entering a filter relation that the packets must satisfy (see the last paragraph of 4a above). S-MAC allows two other types of aggregate data: Conversation and Endpoint tracking This provides statistics on the number and size of packets and data sent between pairs of nodes (conversation) or to and from a particular node (endpoint). "Endpoints" and "Conversations" are both available to view from the "Statistics" menu. One the dialog has opened, select the S-MAC tab. Note that B-MAC cannot support either of these statistics since it does not contain a source address at the MAC layer. Schedule tracking Accessible as "S-MAC Schedules" from the "Statistics" menu, this dialog attempts to determine the various schedules that exist on an S-MAC network over the time of capture. The "By Schedule" tab will show statistics on each schedule similar to the conversation and endpoints statistics and also: - The number of nodes that have ever been on the schedule - The number of nodes that are thought to be on the schedule currently (active) - The time the schedule was first noticed - The time the schedule was last noticed The "By Node" tab shows a tree of schedules that expand into elements of nodes which are on that schedule (i.e. are neighbors of each other). These nodes in turn expand to show the list of all schedules that that node is following. Event visualization Accessible through the "Visualization" button on the Schedule tracking dialog. This presents the user will a chart or graph-like representation of the state and activity of the nodes in the capture over time. One can select to show all nodes or a certain set of nodes, or all nodes on a certain set of schedules, or some combination of the two. One may also select to display or hide: - Horizontal gridlines (node number) - Vertical gridlines (time in seconds) - Scheduled listens (i.e. contention periods, not receptions) - SYNC packets - RTS/CTS packets - Data transfers - Each data packet (i.e. indications of exactly when each packet was sent and received rather than just the beginning and end of the entire transfer) - Colors (which differentiate single-packet events such as RTS, CTS, SYNC and broadcast data) - Text labels (which are another way of differentiating those events) All of these options are enabled by default except for "Each data packet" and "Text labels". One may also zoom in on the data. This is not a true zoom as it does not simply magnify the data; it expands the width of the plot so that increasingly fine-grained slices of time can be differentiated. The vertical scale is not affected by zoom. One may export data using the associated button in one of three formats: - JDB tab-delimited, suitable for processing with jdb or any software that can parse tab-delimited rows of data - Gnuplot (POINTS), suitable for rendering in gnuplot. Points means that it includes phantom "events" so that a default gnuplot render closely resembles the Ethereal+MNV rendering. - Gnuplot (EVENTS), same as above but omits the intermediate phantom "events". This will produce a sawtooth wave rather than a square wave if rendered without options or modifications. Every output file contains comments at the top indicating how to interpret the contents. Finally, there is the option to save the visualization as an image. This will be saved as a PNG image at the current zoom level. -- <4c> Application level protocols ---------------------------------- As stated in section 1 (Status), only the following Application level protocols are currently supported: - SMACTest - Linkstate Data (which is encapsulated within SMACTest) - BMACTest If you are using one of these, Ethereal should automatically notice and display the fields of your application protocol in the middle section of the window below the MAC-level fields. You can create filter relations using these fields the same way as you can using MAC fields. This section to be expanded as more app-level protocols are added. -- <4d> Using tethereal ---------------------------------------------- [TODO] == [5] TROUBLESHOOTING =============================================== -- <5a> Known bugs --------------------------------------------------- Unfortunately, this is beta-quality software at the moment, so some known bugs still exist. They are: 1) BUG: Ethereal captures only a very few packets on a busy network and those that do get captured are corrupted. In addition, "ifconfig mr0" reports a low number of packets received compared to number of bytes received (my packets aren't that big!) FIX: This bug is thought to be fixed in MNV 0.3. If you encounter it, you should contact the maintainer. A workaround is to run the "snoop" program provided in mote/tools for a few seconds between loading the moteradio driver and running "mrattach". Run this as: ./snoop -p -d /dev/ttyS It will produce a raw hex dump of packets coming in from the snooper mote, and also seems to reset the serial port state. 2) BUG: In the "S-MAC Schedules" dialog, Ethereal reports several schedules that I know I am not running any motes on. FIX: In some cases this is not a bug, and these schedules are simply short-lived schedules announced by one of your motes before they adopted a neighbor's schedule. In other cases, these schedules are indeed spurious, but they are not completely random. What has happened is that the real schedules are being split up over time. For example, real schedule A may appear as schedule 1 from time 0 to 100, as schedule 2 from time 101 to 200, and as schedule 3 from time 201 to 300. Rarely will there be a complete spurious schedule reported. This problem was almost entirely eliminated in MNV 0.2, but may still appear in rare instances. 3) BUG: I was running more than one snooper (i.e. more than one mr network interface) at the same time, and my kernel panicked or some other horrible thing happened! FIX: The moteradio driver has not yet been sufficiently tested with multiple interfaces running concurrently. Please take care when you are using this feature, and do not use it in critical situations. In my estimation, running multiple snoopers concurrently is a rare enough occurrence that fixing issues related to it is a back-burner problem. If you have a pressing need to run multiple snoopers with this software, please let me know - see section 8 (Contact information) below. 4) BUG: I am using the S-MAC Network Activity Visualization window and when I zoom in past a certain level, the window goes completely black. FIX: If you are zooming in really tightly on a very large image, GTK seems to sometimes have problems keeping up. In most cases it seems that keying in a higher zoom level (rather than using the arrows) will restore the image at the desired zoom level. If this does not work and you need to zoom in further, consider exporting the data in Gnuplot (POINTS) format and rendering the timeslice you are interested in using gnuplot. -- <5b> Common problems ---------------------------------------------- 1) PROB: I am using a serial mouse and I cannot load the moteradio driver, or the moteradio driver doesn't work, or my mouse goes haywire. SOL : Because there are no free "serial line disciplines" as the kernel calls them available for expansion use, the moteradio driver has to hijack one from an existing device. By default, it hijacks the serial mouse device since serial mice are quite uncommon these days. You can instruct the driver to hijack the discipline for Serial Line IP instead by uncommenting the line reading: CFLAGS += -DMOTERADIO_STEAL_SLIP_LDISC in the Makefile appropriate to your kernel in moteradio/module, and in moteradio/userprog/Makefile. Then, rebuild the moteradio driver and the mrattach program. Note that this causes SLIP to not work instead of serial mice not working. If you need to use both along with moteradio, you are completely out of luck. 2) PROB: I was compiling the moteradio driver, and the compiler gave a warning about not being able to detect the kernel version and referred me to the readme. SOL: If you are using a 2.4 kernel, make sure to use the -2.4 makefile or to add -DMOTERADIO_KERNEL_2_4 to your cflags. If you are using a 2.6 series kernel prior to 2.6.13, add -DMOTERADIO_FORCE_OLD_LDISC_API to your cflags to avoid a serious bug resulting from a change in kernel API. -- <5b> Common questions --------------------------------------------- 1) Q: When I execute "ifconfig mr0" it reports mr0 as a "Serial Line IP" device. Does it really use IP? Is this a bug? A: No, it does not use IP. No, it's not really a bug; it's a limitation of the Linux kernel and of the packet capture libraries used by Ethereal. The moteradio driver does not neatly fit any of the types of network device given in the kernel and there are no "undefined" types available. Serial Line IP (SLIP) is used because it causes the moteradio packets to show up in Ethereal as "Raw IP", from which they can be easily redirected to the moteradio packet processing code based on the start-of-packet symbol in moteradio packets that makes no sense as the first byte of an IP header. 2) Q: Since mr0 is a network interface, can I send packets to it too? A: Moteradio is a read-only driver, and the mote-side snoopers included in this package do not contain transmission capability. However, this is theoretically possible, and I have heard rumors of someone having done this already (look around). 3) Q: Can I have more than one moteradio interface simulataneously? A: In theory, yes. However you must explicitly increase the number of allowed devices in the moteradio driver makefile. The default is 1. In practice, this configuration has not been tested; see known bug 3 above. == [6] PLANS FOR FUTURE DEVELOPMENT ================================== Aside from fixing the bugs listed in section 5a, the two areas that development in the near future will focus on are: 1. Handling of more protocols MAC and application layer protocols are added as requested. In order to have ethereal recognize and break down the packet for a particular protocol, the information needed is: - The format(s) of any packets sent using this protocol - The meanings of each of the fields in these packets - Any behavior of the protocol which may require special consideration when identifying the location of data (e.g. does the location, length, or interpretation of some field change depending on some variable condition?) - Some properties of the packets of this protocol that can be used to distinguish it from other protocols of the same layer Also see section 7b (Writing your own expansions: Ethereal) for a few do-it-yourself pointers. == [7] WRITING YOUR OWN EXPANSIONS =================================== -- <7a> Mote-side ---------------------------------------------------- If you plan to add a new MAC protocol, you need to write a mote-side snooper program that will listen into this MAC and send all overheard data back over a serial cable. It doesn't really matter how you capture the data, but the format of the data going over the serial line must be: [0x7E][length][ . . . Packet Payload . . . ][CRC] In other words, send the byte 0x7E as the start-of-packet symbol, followed by a byte-for-byte dump of the physical layer packet. If your protocol computes the CRC before you can get your hands on it (like B-MAC does), it's okay not to report the actual CRC, though it is preferable if you can. As long as the CRC field somehow allows the host-side software to determine if the CRC check succeeded, either by using the CRC field as a flag (like B-MAC) or sending the whole CRC and allowing the host-side to recheck the CRC (like S-MAC), everything will be fine. While for the most part it doesn't matter what your mote does with the packet before sending it over the serial cable, it is important that your snooper program send the data to the host as soon as possible. If your MAC allows you to receive byte-by-byte, it is advisable to send each byte as you receive it. The kernel driver adds a meta-data high-resolution timestamp to your packet when it receives the start-of-packet symbol (0x7E). This helps Ethereal compute timings more accurately when necessary (e.g. if your packets don't have a timestamp field added by the mote). -- <7b> Ethereal ----------------------------------------------------- In Ethereal terminology, modules that allow it to process a certain protocol are known as "dissectors". A dissector consists of four major parts: 1. Code that registers your protocol with Ethereal 2. Code that registers any preferences or settings related to your protocol with Ethereal 3. Code that defines the various possible fields for your protocol, along with descriptions and possibly friendly readable values 4. Code that actually receives a packet (assumed to be in your protocol's format), indicates which bytes correspond to which fields, and determines what the next-higher protocol in the packet is (if applicable). A good and extremely detailed guide to writing such modules can be found in the Ethereal source itself under doc/README.DEVELOPER. Looking at the existing dissectors for this project is also a good idea. The B-MAC dissector is simpler than the S-MAC dissector, but both are a good deal simpler than anything you'll find in the stock Ethereal library of dissectors (used for non-sensor networks). In the ethereal code base, dissectors are found in epan/dissectors. They are named packet-.c and packet-.h. The .h file is optional and only necessary if other dissectors are going to be calling functions or using variables from the dissector in question. Once you've written a dissector, you also need to write a way for packets to be passed to that dissector. For this, you need to modify the dissector at an immediate lower level to the one you just wrote (if you wrote a MAC dissector, you want "moteradio" for this). Look at the end of its packet-processing function. There should be some code which test various conditions of the remaining data to try to guess at what the next protocol is. Add some heuristic in there for determining that the packet belongs to your protocol, and call your protocol in that case. Once all that is done, add your new code to the makefile. You need to modify epan/dissectors/Makefile.common and epan/dissectors/Makefile.in. Grep through these files for packet-smac, and add a corresponding entry for your dissector everywhere you find an entry for smac. Now simply make clean, reconfigure, and rebuild ethereal. Your dissector should be in there! (make clean and reconfigure is only necessary after you've modified the Makefiles, not every time) More complicated additions (such as new data aggregations) are well beyond the scope of this document. == [8] CONTACT INFORMATION =========================================== The moteradio driver, mrattach, the mote-side code for the B-MAC snooper and S-MAC New Snooper, the modifications to Ethereal (including all new dissectors in this package and all S-MAC aggregate data tools), and this document were written by: Tyler McHenry The snoop tool and the mote-side code for the S-MAC and SCP-MAC snoopers were written by: Wei Ye The dissector for SCP-MAC contains contributions from: Asif Pathan The remaining unmodified parts of Ethereal were written by the Ethereal development team, reachable through their website: http://www.ethereal.com This suite was developed at the the ISI Laboratory for Embedded Networked Sensor Experimentation (I-LENSE) reachable at: http://www.isi.edu/ilense == [9] ACKNOWLEDGEMENTS ============================================== This material is partially based upon work supported by the National Science Foundation (NSF) under Cooperative Agreement #CCR-0121778 (CENS), and partly supported by CiSoft (Center for Interactive Smart Oilfield Technologies), a Center of Research Excellence and Academic Training and a joint venture between the University of Southern California and Chevron Corporation.