From Scott Renfro: correctly handle merging multiple files with

different encapsulation types (as best we can).

svn path=/trunk/; revision=3720

1 files changed, 11 insertions, 6 deletions

diff --git a/doc/mergecap.pod b/doc/mergecap.pod
index f0d7fda248..2cb39523ca 100644
--- a/doc/mergecap.pod
+++ b/doc/mergecap.pod
@@ -6,12 +6,10 @@ mergecap - Merges two capture files into one
 =head1 SYNOPSYS
 
 B<mergecap>
+S<[ B<-hva> ]>
+S<[ B<-s> I<snaplen> ]>
 S<[ B<-F> I<file format> ]>
 S<[ B<-T> I<encapsulation type> ]>
-S<[ B<-a> ]>
-S<[ B<-v> ]>
-S<[ B<-s> I<snaplen> ]>
-S<[ B<-h> ]>
 S<B<-w> I<outfile>>
 I<infile>
 I<...>
@@ -60,10 +58,17 @@ appear to reject Ethernet frames larger than the standard Ethernet MTU,
 making them incapable of handling gigabit Ethernet captures if jumbo
 frames were used).
 
-If the B<-T> flag is used to specify an encapsulation type, the
+The output file frame encapsulation type is set to the type of the input
+files, if all input files have the same type.  If not all of the input
+files have the same frame encapsulation type, the output file type is
+set to WTAP_ENCAP_PER_PACKET.  Note that some capture file formats, most
+notably B<libpcap>, do not currently support WTAP_ENCAP_PER_PACKET.
+This combination will cause the output file creation to fail.
+
+If the B<-T> flag is used to specify a frame encapsulation type, the
 encapsulation type of the output capture file will be forced to the
 specified type, rather than being the type appropriate to the
-encapsulation type of the input capture file.  Note that this merely
+encapsulation type of the input capture files.  Note that this merely
 forces the encapsulation type of the output file to be the specified
 type; the packet headers of the packets will not be translated from the
 encapsulation type of the input capture file to the specified