Català-Valencià – Catalan中文 – Chinese (Simplified)中文 – Chinese (Traditional)Česky – CzechDansk – DanishNederlands – DutchEnglish – EnglishSuomi – FinnishFrançais – FrenchDeutsch – Germanעברית – Hebrewहिंदी – HindiMagyar – HungarianBahasa Indonesia – IndonesianItaliano – Italian日本語 – Japanese한국어 – KoreanМакедонски – Macedonianमराठी – MarathiNorsk – NorwegianPolski – PolishPortuguês – PortuguesePortuguês – Portuguese (Brazil)Русский – RussianSlovenčina – SlovakSlovenščina – SlovenianEspañol – SpanishSvenska – SwedishTürkçe – TurkishУкраїнська – UkrainianOëzbekcha – Uzbek

nexmon – Blame information for rev 1

Rev	Author	Line No.	Line
1	office	1	#!/usr/bin/env python
		2	#
		3	# faq.py
		4	#
		5	# Routines to assemble a FAQ list for the Wireshark web site.
		6	# Questions and answer content can be found below. Section and
		7	# question numbers will be automatically generated.
		8	#
		9	# Wireshark - Network traffic analyzer
		10	# By Gerald Combs <gerald@wireshark.org>
		11	# Copyright 1998 Gerald Combs
		12	#
		13	# This program is free software; you can redistribute it and/or
		14	# modify it under the terms of the GNU General Public License
		15	# as published by the Free Software Foundation; either version 2
		16	# of the License, or (at your option) any later version.
		17	#
		18	# This program is distributed in the hope that it will be useful,
		19	# but WITHOUT ANY WARRANTY; without even the implied warranty of
		20	# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
		21	# GNU General Public License for more details.
		22	#
		23	# You should have received a copy of the GNU General Public License
		24	# along with this program; if not, write to the Free Software
		25	# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
		26
		27	import sys
		28	import string
		29
		30	class faq_section:
		31	def __init__(self, name, secnum):
		32	self.name = name
		33	self.secnum = secnum
		34	self.qa = []
		35	self.subsecs = []
		36
		37	def add_qa(self, question, answer, tag):
		38	q_num = len(self.qa) + 1
		39	q_id = "%s.%d" % (self.get_num_string(), q_num)
		40	self.qa.append( (q_id, question, answer, tag) )
		41
		42	def get_all_qa(self):
		43	return self.qa
		44
		45	def add_subsec(self, subsec):
		46	self.subsecs.append(subsec)
		47
		48	def get_all_subsecs(self):
		49	return self.subsecs
		50
		51	def get_num_string(self):
		52	return "%d" % (self.secnum)
		53
		54	def get_name(self):
		55	return self.name
		56
		57	def get_num_name(self):
		58	return "%s. %s" % (self.get_num_string(), self.name)
		59
		60	def get_header_level(self):
		61	return 3
		62
		63	def print_index(self):
		64	print(("<a href=#sec%s><h%d>%s:</h%d></a>\n" % (self.get_num_string(), self.get_header_level(), self.get_num_name(), self.get_header_level())))
		65	for qa in self.qa:
		66	id = qa[0]
		67	question = qa[1]
		68	print('<p class="faq_q">')
		69	print(('<a class="faq_qnum" href=#q%s>%s %s</a>\n' % (id, id, question)))
		70	print('</p>')
		71	for subsec in self.subsecs:
		72	subsec.print_index()
		73
		74	def print_contents(self):
		75	# Table header
		76	print(("""
		77	<h%d id="sec%s">%s</h%d>
		78	""" % (self.get_header_level(), self.get_num_string(), self.get_num_name(), self.get_header_level())))
		79
		80	# Questions and Answers
		81	for qa in self.qa:
		82	id = qa[0]
		83	question = qa[1]
		84	answer = qa[2]
		85	tag = qa[3]
		86
		87	print('<p class="faq_q">')
		88	if tag is not None:
		89	print(('<span id=%s></span>' % (tag)))
		90	print(('<a href=#q%s class="faq_qnum" id=q%s>Q %s: %s</a>' % (id, id, id, question)))
		91	print('</p>')
		92
		93	print('<p class="faq_a">')
		94	print('<span class="faq_anum">A:</span>\n')
		95	print(answer)
		96	print('</p>')
		97
		98	# Subsections
		99	for subsec in self.subsecs:
		100	subsec.print_contents()
		101
		102	# Table footer
		103	print("")
		104
		105	class faq_subsection(faq_section):
		106	def __init__(self, name, secnum, subsecnum):
		107	self.name = name
		108	self.secnum = secnum
		109	self.subsecnum = subsecnum
		110	self.qa = []
		111	self.subsecs = []
		112
		113	def get_num_string(self):
		114	return "%d.%d" % (self.secnum, self.subsecnum)
		115
		116	def get_header_level(self):
		117	return 2
		118
		119	class faq_subsubsection(faq_section):
		120	def __init__(self, name, secnum, subsecnum, subsubsecnum):
		121	self.name = name
		122	self.secnum = secnum
		123	self.subsecnum = subsecnum
		124	self.subsubsecnum = subsubsecnum
		125	self.qa = []
		126	self.subsecs = []
		127
		128	def get_num_string(self):
		129	return "%d.%d.%d" % (self.secnum, self.subsecnum, self.subsubsecnum)
		130
		131	def get_header_level(self):
		132	return 2
		133
		134	sec_num = 0
		135	subsec_num = 0
		136	subsubsec_num = 0
		137	sections = []
		138	current_section = None
		139	parent_section = None
		140	grandparent_section = None
		141	current_question = None
		142	current_tag = None
		143
		144	# Make a URL of itself
		145	def selflink(text):
		146	return "<a href=\"%s\">%s</a>" % (text, text)
		147
		148	# Add a section
		149	def section(name):
		150	global sec_num
		151	global subsec_num
		152	global subsubsec_num
		153	global current_section
		154	global grandparent_section
		155	assert not current_question
		156	sec_num = sec_num + 1
		157	subsec_num = 0
		158	subsubsec_num = 0
		159	sec = faq_section(name, sec_num)
		160	sections.append(sec)
		161	current_section = sec
		162	grandparent_section = sec
		163
		164	# Add a subsection
		165	def subsection(name):
		166	global subsec_num
		167	global subsubsec_num
		168	global current_section
		169	global parent_section
		170	global grandparent_section
		171	assert not current_question
		172	subsec_num = subsec_num + 1
		173	subsubsec_num = 0
		174	sec = faq_subsection(name, sec_num, subsec_num)
		175	grandparent_section.add_subsec(sec)
		176	current_section = sec
		177	parent_section = sec
		178
		179	# Add a subsubsection
		180	def subsubsection(name):
		181	global subsubsec_num
		182	global current_section
		183	global parent_section
		184	assert not current_question
		185	subsubsec_num = subsubsec_num + 1
		186	sec = faq_subsubsection(name, sec_num, subsec_num, subsubsec_num)
		187	parent_section.add_subsec(sec)
		188	current_section = sec
		189
		190	# Add a question
		191	def question(text, tag=None):
		192	global current_question
		193	global current_tag
		194	assert current_section
		195	assert not current_question
		196	assert not current_tag
		197	current_question = text
		198	current_tag = tag
		199
		200	# Add an answer
		201	def answer(text):
		202	global current_question
		203	global current_tag
		204	assert current_section
		205	assert current_question
		206	current_section.add_qa(current_question, text, current_tag)
		207	current_question = None
		208	current_tag = None
		209
		210
		211	# Create the index
		212	def create_index():
		213	print("""
		214	<h1 id="index">Index</h1>
		215	""")
		216	for sec in sections:
		217	sec.print_index()
		218
		219	print("""
		220	""")
		221
		222
		223	# Print result
		224	def create_output(header='', footer=''):
		225
		226	print(header)
		227	create_index()
		228
		229	for sec in sections:
		230	sec.print_contents()
		231
		232	print(footer)
		233
		234	def main():
		235	header = '''\
		236	<!DOCTYPE html>
		237	<html>
		238	<head>
		239	<meta charset="utf-8">
		240	<title>Wireshark Frequently Asked Questions</title>
		241	</head>
		242	<body>
		243	'''
		244	footer = '''\
		245	</body>
		246	</html>
		247	'''
		248
		249	if len(sys.argv) > 1 and sys.argv[1] == '-b': # Only print the document body
		250	header = ''
		251	footer = ''
		252
		253	create_output(header, footer)
		254
		255	#################################################################
		256	section("General Questions")
		257	#################################################################
		258
		259	question("What is Wireshark?")
		260	answer("""
		261	Wireshark&#174; is a network protocol analyzer. It lets you capture and
		262	interactively browse the traffic running on a computer network. It has
		263	a rich and powerful feature set and is world's most popular tool of its
		264	kind. It runs on most computing platforms including Windows, OS X,
		265	Linux, and UNIX. Network professionals, security experts, developers,
		266	and educators around the world use it regularly. It is freely available
		267	as open source, and is released under the GNU General Public License
		268	version 2.
		269
		270	<br>
		271
		272	It is developed and maintained by a global team of protocol experts, and
		273	it is an example of a
		274	<a href="https://en.wikipedia.org/wiki/Disruptive_technology">disruptive
		275	technology</a>.
		276
		277	<br>
		278
		279	Wireshark used to be known as Ethereal&#174;. See the next question
		280	for details about the name change. If you're still using Ethereal, it
		281	is strongly recommended that you upgrade to Wireshark as Ethereal is
		282	unsupported and has known security vulnerabilities.
		283
		284	<br>
		285
		286	For more information, please see the
		287	<a href="https://www.wireshark.org/about.html">About Wireshark</a>
		288	page.
		289	""")
		290
		291
		292	question("What's up with the name change? Is Wireshark a fork?")
		293	answer("""
		294	In May of 2006, Gerald Combs (the original author of Ethereal)
		295	went to work for CACE Technologies (best known for WinPcap).
		296	Unfortunately, he had to leave the Ethereal trademarks behind.
		297
		298	<br>
		299
		300	This left the project in an awkward position. The only reasonable way
		301	to ensure the continued success of the project was to change the name.
		302	This is how Wireshark was born.
		303
		304	<br>
		305
		306	Wireshark is almost (but not quite) a fork. Normally a "fork" of an open source
		307	project results in two names, web sites, development teams, support
		308	infrastructures, etc. This is the case with Wireshark except for one notable
		309	exception -- every member of the core development team is now working on
		310	Wireshark. There has been no active development on Ethereal since the name
		311	change. Several parts of the Ethereal web site (such as the mailing lists,
		312	source code repository, and build farm) have gone offline.
		313
		314	<br>
		315
		316	More information on the name change can be found here:
		317	</p>
		318	<ul class="item_list">
		319
		320	<li><a href="http://www.prweb.com/releases/2006/6/prweb396098.htm">Original press release</a>
		321	<li><a href="http://archive09.linux.com/articles/54968">NewsForge article</a>
		322	<li>Many other articles in <a href="https://www.wireshark.org/bibliography.html">our bibliography</a>
		323	</ul>
		324	<p>
		325	""")
		326
		327
		328	question("Where can I get help?")
		329	answer("""
		330	Community support is available on the
		331	<a href="https://ask.wireshark.org/">Q&amp;A site</a> and on the
		332	wireshark-users mailing list. Subscription information and archives for
		333	all of Wireshark's mailing lists can be found at %s. An IRC channel
		334	dedicated to Wireshark can be found at %s.
		335
		336	<br>
		337
		338	Self-paced and instructor-led training is available at <a
		339	href="http://www.wiresharktraining.com">Wireshark University</a>.
		340	Wireshark University also offers certification via the Wireshark
		341	Certified Network Analyst program.
		342
		343	""" % (selflink("https://www.wireshark.org/mailman/listinfo"),
		344	selflink("irc://irc.freenode.net/wireshark")
		345	))
		346
		347
		348	question("What kind of shark is Wireshark?")
		349	answer("""
		350	<i>carcharodon photoshopia</i>.
		351	""")
		352
		353
		354	question("How is Wireshark pronounced, spelled and capitalized?")
		355	answer("""
		356	Wireshark is pronounced as the word <i>wire</i> followed immediately by
		357	the word <i>shark</i>. Exact pronunciation and emphasis may vary
		358	depending on your locale (e.g. Arkansas).
		359
		360	<br>
		361
		362	It's spelled with a capital <i>W</i>, followed by a lower-case
		363	<i>ireshark</i>. It is not a CamelCase word, i.e., <i>WireShark</i>
		364	is incorrect.
		365	""")
		366
		367
		368	question("How much does Wireshark cost?", "but_thats_not_all")
		369	answer("""
		370	Wireshark is "free software"; you can download it without paying any
		371	license fee. The version of Wireshark you download isn't a "demo"
		372	version, with limitations not present in a "full" version; it
		373	<em>is</em> the full version.
		374
		375	<br>
		376
		377	The license under which Wireshark is issued is <a
		378	href="https://www.gnu.org/licenses/gpl-2.0.html">the GNU General Public
		379	License version 2</a>. See <a
		380	href="https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html">the GNU
		381	GPL FAQ</a> for some more information.
		382	""")
		383
		384	question("But I just paid someone on eBay for a copy of Wireshark! Did I get ripped off?")
		385	answer("""
		386	That depends. Did they provide any sort of value-added product or service, such
		387	as installation support, installation media, training, trace file analysis, or
		388	funky-colored shark-themed socks? Probably not.
		389
		390	<br>
		391
		392	Wireshark is <a href="https://www.wireshark.org/download.html">available for
		393	anyone to download, absolutely free, at any time</a>. Paying for a copy implies
		394	that you should get something for your money.
		395	""")
		396
		397	question("Can I use Wireshark commercially?")
		398	answer("""
		399	Yes, if, for example, you mean "I work for a commercial organization;
		400	can I use Wireshark to capture and analyze network traffic in our
		401	company's networks or in our customer's networks?"
		402
		403	<br>
		404
		405	If you mean "Can I use Wireshark as part of my commercial product?", see
		406	<a href="#derived_work_gpl">the next entry in the FAQ</a>.
		407	""")
		408
		409
		410	question("Can I use Wireshark as part of my commercial product?",
		411	"derived_work_gpl")
		412
		413	answer("""
		414	As noted, Wireshark is licensed under <a
		415	href="https://www.gnu.org/licenses/gpl-2.0.html">the GNU General Public
		416	License, version 2</a>. The GPL imposes conditions on your use of GPL'ed
		417	code in your own products; you cannot, for example, make a "derived
		418	work" from Wireshark, by making modifications to it, and then sell the
		419	resulting derived work and not allow recipients to give away the
		420	resulting work. You must also make the changes you've made to the
		421	Wireshark source available to all recipients of your modified version;
		422	those changes must also be licensed under the terms of the GPL. See the
		423	<a href="https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html">GPL
		424	FAQ</a> for more details; in particular, note the answer to <a
		425	href="https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#GPLCommercially">the
		426	question about modifying a GPLed program and selling it
		427	commercially</a>, and <a
		428	href="https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#LinkingWithGPL">the
		429	question about linking GPLed code with other code to make a proprietary
		430	program</a>.
		431
		432	<br>
		433
		434	You can combine a GPLed program such as Wireshark and a commercial
		435	program as long as they communicate "at arm's length", as per <a
		436	href="https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#GPLInProprietarySystem">this
		437	item in the GPL FAQ</a>.
		438
		439	<br>
		440
		441	We recommend keeping Wireshark and your product completely separate,
		442	communicating over sockets or pipes. If you're loading any part of
		443	Wireshark as a DLL, you're probably doing it wrong.
		444	""")
		445
		446	question("What protocols are currently supported?")
		447	answer("""
		448	There are currently hundreds of supported
		449	protocols and media. Details can be found in the
		450	<a
		451	href="https://www.wireshark.org/docs/man-pages/wireshark.html">wireshark(1)</a>
		452	man page.
		453	""")
		454
		455
		456	question("Are there any plans to support {your favorite protocol}?")
		457	answer("""
		458	Support for particular protocols is added to Wireshark as a result of
		459	people contributing that support; no formal plans for adding support for
		460	particular protocols in particular future releases exist.
		461	""")
		462
		463
		464	question("""Can Wireshark read capture files from {your favorite network
		465	analyzer}?""")
		466
		467	answer("""
		468	Support for particular capture file formats is added to Wireshark as a result
		469	of people contributing that support; no formal plans for adding support for
		470	particular capture file formats in particular future releases exist.
		471
		472	<br>
		473
		474	If a network analyzer writes out files in a format already supported by
		475	Wireshark (e.g., in libpcap format), Wireshark may already be able to read
		476	them, unless the analyzer has added its own proprietary extensions to
		477	that format.
		478
		479	<br>
		480
		481	If a network analyzer writes out files in its own format, or has added
		482	proprietary extensions to another format, in order to make Wireshark read
		483	captures from that network analyzer, we would either have to have a
		484	specification for the file format, or the extensions, sufficient to give
		485	us enough information to read the parts of the file relevant to
		486	Wireshark, or would need at least one capture file in that format
		487	<strong>AND</strong> a detailed textual analysis of the packets in that
		488	capture file (showing packet time stamps, packet lengths, and the
		489	top-level packet header) in order to reverse-engineer the file
		490	format.
		491
		492	<br>
		493
		494	Note that there is no guarantee that we will be able to reverse-engineer
		495	a capture file format.
		496	""")
		497
		498
		499	question("What devices can Wireshark use to capture packets?")
		500	answer("""
		501	Wireshark can read live data from Ethernet, Token-Ring, FDDI, serial (PPP
		502	and SLIP) (if the OS on which it's running allows Wireshark to do so),
		503	802.11 wireless LAN (if the OS on which it's running allows Wireshark to
		504	do so), ATM connections (if the OS on which it's running allows Wireshark
		505	to do so), and the "any" device supported on Linux by recent versions of
		506	libpcap.
		507
		508	<br>
		509
		510	See <a href="https://wiki.wireshark.org/CaptureSetup/NetworkMedia">the list of
		511	supported capture media on various OSes</a> for details (several items
		512	in there say "Unknown", which doesn't mean "Wireshark can't capture on
		513	them", it means "we don't know whether it can capture on them"; we
		514	expect that it will be able to capture on many of them, but we haven't
		515	tried it ourselves - if you try one of those types and it works, please
		516	update the wiki page accordingly.
		517
		518	<br>
		519
		520	It can also read a variety of capture file formats, including:
		521
		522	</p>
		523	<ul>
		524
		525	<li> AG Group/WildPackets/Savvius EtherPeek/TokenPeek/AiroPeek/EtherHelp/Packet Grabber captures
		526	<li> AIX's iptrace captures
		527	<li> Accellent's 5Views LAN agent output
		528	<li> Cinco Networks NetXRay captures
		529	<li> Cisco Secure Intrusion Detection System IPLog output
		530	<li> CoSine L2 debug output
		531	<li> DBS Etherwatch VMS text output
		532	<li> Endace Measurement Systems' ERF format captures
		533	<li> EyeSDN USB S0 traces
		534	<li> HP-UX nettl captures
		535	<li> ISDN4BSD project i4btrace captures
		536	<li> Linux Bluez Bluetooth stack hcidump -w traces
		537	<li> Lucent/Ascend router debug output
		538	<li> Microsoft Network Monitor captures
		539	<li> Network Associates Windows-based Sniffer captures
		540	<li> Network General/Network Associates DOS-based Sniffer (compressed or uncompressed) captures
		541	<li> Network Instruments Observer version 9 captures
		542	<li> Novell LANalyzer captures
		543	<li> RADCOM's WAN/LAN analyzer captures
		544	<li> Shomiti/Finisar Surveyor captures
		545	<li> Toshiba's ISDN routers dump output
		546	<li> VMS TCPIPtrace/TCPtrace/UCX$TRACE output
		547	<li> Visual Networks' Visual UpTime traffic capture
		548	<li> libpcap, tcpdump and various other tools using tcpdump's capture format
		549	<li> snoop and atmsnoop output
		550
		551	</ul>
		552
		553	<p>
		554	so that it can read traces from various network types, as captured by
		555	other applications or equipment, even if it cannot itself capture on
		556	those network types.
		557	""")
		558
		559	question("""
		560	Does Wireshark work on Windows Vista or Windows Server 2008?
		561	""")
		562
		563	answer("""
		564	Yes, but if you want to capture packets as a normal user, you must make sure
		565	npf.sys is loaded. Wireshark's installer enables this by default. This is not a
		566	concern if you run Wireshark as Administrator, but this is discouraged. See the
		567	<a
		568	href="https://wiki.wireshark.org/CaptureSetup/CapturePrivileges#windows">CapturePrivileges</a>
		569	page on the wiki for more details.
		570	""")
		571
		572
		573	#################################################################
		574	section("Installing Wireshark")
		575	#################################################################
		576
		577
		578	question("""I installed the Wireshark RPM (or other package); why did
		579	it install TShark but not Wireshark?""")
		580
		581	answer("""
		582	Many distributions have separate Wireshark packages, one for non-GUI
		583	components such as TShark, editcap, dumpcap, etc. and one for the GUI.
		584	If this is the case on your system, there's probably a separate package
		585	named <code>wireshark-gnome</code> or <code>wireshark-gtk+</code>. Find it and
		586	install it.
		587	""")
		588
		589
		590	#################################################################
		591	section("Building Wireshark")
		592	#################################################################
		593
		594
		595	question("""I have libpcap installed; why did the configure script not
		596	find pcap.h or bpf.h?""")
		597
		598	answer("""
		599	Are you sure pcap.h and bpf.h are installed? The official distribution
		600	of libpcap only installs the libpcap.a library file when "make install"
		601	is run. To install pcap.h and bpf.h, you must run "make install-incl".
		602	If you're running Debian or Redhat, make sure you have the "libpcap-dev"
		603	or "libpcap-devel" packages installed.
		604
		605	<br>
		606
		607	It's also possible that pcap.h and bpf.h have been installed in a strange
		608	location. If this is the case, you may have to tweak aclocal.m4.
		609	""")
		610
		611
		612	question("""
		613	Why do I get the error
		614
		615	<em>dftest_DEPENDENCIES was already defined in condition TRUE,
		616	which implies condition HAVE_PLUGINS_TRUE</em>
		617
		618	when I try to build Wireshark from SVN or a SVN snapshot?
		619	""")
		620
		621	answer("""
		622	You probably have automake 1.5 installed on your machine (the command
		623	<kbd>automake --version</kbd> will report the version of automake on
		624	your machine). There is a bug in that version of automake that causes
		625	this problem; upgrade to a later version of automake (1.6 or later).
		626	""")
		627
		628	question("""
		629	Why does the linker fail with a number of "Output line too long." messages
		630	followed by linker errors when I try to build Wireshark?
		631	""")
		632
		633	answer("""
		634	The version of the <code>sed</code> command on your system is incapable of
		635	handling very long lines. On Solaris, for example,
		636	<code>/usr/bin/sed</code> has a line length limit too low to allow
		637	<code>libtool</code> to work; <code>/usr/xpg4/bin/sed</code> can handle it, as
		638	can GNU <code>sed</code> if you have it installed.
		639
		640	<br>
		641
		642	On Solaris, changing your command search path to search
		643	<code>/usr/xpg4/bin</code> before <code>/usr/bin</code> should make the problem
		644	go away; on any platform on which you have this problem, installing GNU
		645	<code>sed</code> and changing your command path to search the directory in
		646	which it is installed before searching the directory with the version of
		647	<code>sed</code> that came with the OS should make the problem go away.
		648	""")
		649
		650	question("""
		651	When I try to build Wireshark on Solaris, why does the link fail
		652	complaining that <code>plugin_list</code> is undefined?
		653	""")
		654
		655	answer("""
		656	This appears to be due to a problem with some versions of the GTK+ and
		657	GLib packages from www.sunfreeware.org; un-install those packages, and
		658	try getting the 1.2.10 versions from that site, or the versions from <a
		659	href="http://www.thewrittenword.com">The Written Word</a>, or the
		660	versions from Sun's GNOME distribution, or the versions from the
		661	supplemental software CD that comes with the Solaris media kit, or build
		662	them from source from <a href="http://www.gtk.org/">the GTK Web
		663	site</a>. Then re-run the configuration script, and try rebuilding
		664	Wireshark. (If you get the 1.2.10 versions from www.sunfreeware.org, and
		665	the problem persists, un-install them and try installing one of the
		666	other versions mentioned.)
		667	""")
		668
		669	question("""
		670	When I try to build Wireshark on Windows, why does the build fail because
		671	of conflicts between <code>winsock.h</code> and <code>winsock2.h</code>?
		672	""")
		673
		674	answer("""
		675	As of Wireshark 0.9.5, you must install WinPcap 2.3 or later, and the
		676	corresponding version of the developer's pack, in order to be able to
		677	compile Wireshark; it will not compile with older versions of the
		678	developer's pack. The symptoms of this failure are conflicts between
		679	definitions in <code>winsock.h</code> and in <code>winsock2.h</code>; Wireshark
		680	uses <code>winsock2.h</code>, but pre-2.3 versions of the WinPcap
		681	developer's packet use <code>winsock.h</code>. (2.3 uses
		682	<code>winsock2.h</code>, so if Wireshark were to use <code>winsock.h</code>, it
		683	would not be able to build with current versions of the WinPcap
		684	developer's pack.)
		685
		686	<br>
		687
		688	Note that the installed version of the developer's pack should be the
		689	same version as the version of WinPcap you have installed.
		690	""")
		691
		692	#################################################################
		693	section("Starting Wireshark")
		694	#################################################################
		695
		696
		697	question("""Why does Wireshark crash with a Bus Error when I try to run
		698	it on Solaris 8?""")
		699
		700	answer("""
		701	Some versions of the GTK+ library from www.sunfreeware.org appear to be
		702	buggy, causing Wireshark to drop core with a Bus Error. Un-install those
		703	packages, and try getting the 1.2.10 version from that site, or the
		704	version from <a href="http://www.thewrittenword.com">The Written
		705	Word</a>, or the version from Sun's GNOME distribution, or the version
		706	from the supplemental software CD that comes with the Solaris media kit,
		707	or build it from source from <a href="http://www.gtk.org/">the GTK Web
		708	site</a>. Update the GLib library to the 1.2.10 version, from the same
		709	source, as well. (If you get the 1.2.10 versions from
		710	www.sunfreeware.org, and the problem persists, un-install them and try
		711	installing one of the other versions mentioned.)
		712
		713	<br>
		714
		715	Similar problems may exist with older versions of GTK+ for earlier
		716	versions of Solaris.
		717	""")
		718
		719	question("""When I try to run Wireshark, why does it complain about
		720	<code>sprint_realloc_objid</code> being undefined?""")
		721
		722	answer("""
		723	Wireshark can only be linked with version 4.2.2 or later of UCD SNMP.
		724	Your version of Wireshark was dynamically linked with such a version of
		725	UCD SNMP; however, you have an older version of UCD SNMP installed,
		726	which means that when Wireshark is run, it tries to link to the older
		727	version, and fails. You will have to replace that version of UCD SNMP
		728	with version 4.2.2 or a later version.
		729	""")
		730
		731	question("""
		732	I've installed Wireshark from Fink on OS X; why is it very slow to
		733	start up?
		734	""")
		735
		736	answer("""
		737	When an application is installed on OS X, prior to 10.4, it is usually
		738	"prebound" to speed up launching the application. (That's what the
		739	"Optimizing" phase of installation is.)
		740
		741	<br>
		742
		743	Fink normally performs prebinding automatically when you install a
		744	package. However, in some rare cases, for whatever reason the prebinding
		745	caches get corrupt, and then not only does prebinding fail, but startup
		746	actually becomes much slower, because the system tries in vain to
		747	perform prebinding "on the fly" as you launch the application. This
		748	fails, causing sometimes huge delays.
		749
		750	<br>
		751
		752	To fix the prebinding caches, run the command
		753	</p>
		754
		755	<pre>
		756	sudo /sw/var/lib/fink/prebound/update-package-prebinding.pl -f
		757	</pre>
		758	<p>
		759	""")
		760
		761	#################################################################
		762	section("Crashes and other fatal errors")
		763	#################################################################
		764
		765
		766	question("""
		767	I have an XXX network card on my machine; if I try to capture on it, why
		768	does my machine crash or reset itself?
		769	""")
		770
		771	answer("""
		772	This is almost certainly a problem with one or more of:
		773	</p>
		774
		775	<ul>
		776	<li>the operating system you're using;
		777	<li>the device driver for the interface you're using;
		778	<li>the libpcap/WinPcap library and, if this is Windows, the WinPcap
		779	device driver;
		780	</ul>
		781
		782	<p>
		783	so:
		784	</p>
		785
		786	<ul>
		787	<li>if you are using Windows, see <a
		788	href="https://www.winpcap.org/contact.htm">the WinPcap support
		789	page</a> - check the "Submitting bugs" section;
		790	<li>if you are using some Linux distribution, some version of BSD, or
		791	some other UNIX-flavored OS, you should report the problem to the
		792	company or organization that produces the OS (in the case of a Linux
		793	distribution, report the problem to whoever produces the distribution).
		794	</ul>
		795	<p>
		796	""")
		797
		798	question("""
		799	Why does my machine crash or reset itself when I select "Start" from the
		800	"Capture" menu or select "Preferences" from the "Edit" menu?
		801	""")
		802
		803	answer("""
		804	Both of those operations cause Wireshark to try to build a list of the
		805	interfaces that it can open; it does so by getting a list of interfaces
		806	and trying to open them. There is probably an OS, driver, or, for
		807	Windows, WinPcap bug that causes the system to crash when this happens;
		808	see the previous question.
		809	""")
		810
		811	#################################################################
		812	section("Capturing packets")
		813	#################################################################
		814
		815
		816	question("""When I use Wireshark to capture packets, why do I see only
		817	packets to and from my machine, or not see all the traffic I'm expecting
		818	to see from or to the machine I'm trying to monitor?""", "promiscsniff")
		819
		820	answer("""
		821	This might be because the interface on which you're capturing is plugged
		822	into an Ethernet or Token Ring switch; on a switched network, unicast
		823	traffic between two ports will not necessarily appear on other ports -
		824	only broadcast and multicast traffic will be sent to all ports.
		825
		826	<br>
		827
		828	Note that even if your machine is plugged into a hub, the "hub" may be
		829	a switched hub, in which case you're still on a switched network.
		830
		831	<br>
		832
		833	Note also that on the Linksys Web site, they say that their
		834	auto-sensing hubs "broadcast the 10Mb packets to the port that operate
		835	at 10Mb only and broadcast the 100Mb packets to the ports that operate
		836	at 100Mb only", which would indicate that if you sniff on a 10Mb port,
		837	you will not see traffic coming sent to a 100Mb port, and <i>vice
		838	versa</i>. This problem has also been reported for Netgear dual-speed
		839	hubs, and may exist for other "auto-sensing" or "dual-speed" hubs.
		840
		841	<br>
		842
		843	Some switches have the ability to replicate all traffic on all ports to
		844	a single port so that you can plug your analyzer into that single port to
		845	sniff all traffic. You would have to check the documentation for the
		846	switch to see if this is possible and, if so, to see how to do this.
		847	See <a href="https://wiki.wireshark.org/SwitchReference">the switch
		848	reference page</a> on <a href="https://wiki.wireshark.org/">the Wireshark
		849	Wiki</a> for information on some switches. (Note that it's a Wiki, so
		850	you can update or fix that information, or add additional information on
		851	those switches or information on new switches, yourself.)
		852
		853	<br>
		854
		855	Note also that many firewall/NAT boxes have a switch built into them;
		856	this includes many of the "cable/DSL router" boxes. If you have a box
		857	of that sort, that has a switch with some number of Ethernet ports into
		858	which you plug machines on your network, and another Ethernet port used
		859	to connect to a cable or DSL modem, you can, at least, sniff traffic
		860	between the machines on your network and the Internet by plugging
		861	the Ethernet port on the router going to the modem, the Ethernet port on
		862	the modem, and the machine on which you're running Wireshark into a hub
		863	(make sure it's not a switching hub, and that, if it's a dual-speed hub,
		864	all three of those ports are running at the same speed.
		865
		866	<br>
		867
		868	If your machine is <em>not</em> plugged into a switched network or a
		869	dual-speed hub, or it is plugged into a switched network but the port is
		870	set up to have all traffic replicated to it, the problem might be that
		871	the network interface on which you're capturing doesn't support
		872	"promiscuous" mode, or because your OS can't put the interface into
		873	promiscuous mode. Normally, network interfaces supply to the host only:
		874	</p>
		875
		876	<ul>
		877	<li>packets sent to one of that host's link-layer addresses;
		878	<li>broadcast packets;
		879	<li>multicast packets sent to a multicast address that the host has
		880	configured the interface to accept.
		881	</ul>
		882
		883	<p>
		884	Most network interfaces can also be put in "promiscuous" mode, in which
		885	they supply to the host all network packets they see. Wireshark will try
		886	to put the interface on which it's capturing into promiscuous mode
		887	unless the "Capture packets in promiscuous mode" option is turned off in
		888	the "Capture Options" dialog box, and TShark will try to put the
		889	interface on which it's capturing into promiscuous mode unless the
		890	<code>-p</code> option was specified. However, some network interfaces
		891	don't support promiscuous mode, and some OSes might not allow interfaces
		892	to be put into promiscuous mode.
		893
		894	<br>
		895
		896	If the interface is not running in promiscuous mode, it won't see any
		897	traffic that isn't intended to be seen by your machine. It
		898	<strong>will</strong> see broadcast packets, and multicast packets sent
		899	to a multicast MAC address the interface is set up to receive.
		900
		901	<br>
		902
		903	You should ask the vendor of your network interface whether it supports
		904	promiscuous mode. If it does, you should ask whoever supplied the
		905	driver for the interface (the vendor, or the supplier of the OS you're
		906	running on your machine) whether it supports promiscuous mode with that
		907	network interface.
		908
		909	<br>
		910
		911	In the case of token ring interfaces, the drivers for some of them, on
		912	Windows, may require you to enable promiscuous mode in order to capture
		913	in promiscuous mode. See <a
		914	href="https://wiki.wireshark.org/CaptureSetup/TokenRing">the Wireshark
		915	Wiki item on Token Ring capturing</a> for details.
		916
		917	<br>
		918
		919	In the case of wireless LAN interfaces, it appears that, when those
		920	interfaces are promiscuously sniffing, they're running in a
		921	significantly different mode from the mode that they run in when they're
		922	just acting as network interfaces (to the extent that it would be a
		923	significant effort for those drivers to support for promiscuously
		924	sniffing <em>and</em> acting as regular network interfaces at the same
		925	time), so it may be that Windows drivers for those interfaces don't
		926	support promiscuous mode.
		927	""")
		928
		929	question("""When I capture with Wireshark, why can't I see any TCP
		930	packets other than packets to and from my machine, even though another
		931	analyzer on the network sees those packets?""")
		932
		933	answer("""
		934	You're probably not seeing <em>any</em> packets other than unicast
		935	packets to or from your machine, and broadcast and multicast packets; a
		936	switch will normally send to a port only unicast traffic sent to the MAC
		937	address for the interface on that port, and broadcast and multicast
		938	traffic - it won't send to that port unicast traffic sent to a MAC
		939	address for some other interface - and a network interface not in
		940	promiscuous mode will receive only unicast traffic sent to the MAC
		941	address for that interface, broadcast traffic, and multicast traffic
		942	sent to a multicast MAC address the interface is set up to receive.
		943
		944	<br>
		945
		946	TCP doesn't use broadcast or multicast, so you will only see your own
		947	TCP traffic, but UDP services may use broadcast or multicast so you'll
		948	see some UDP traffic - however, this is not a problem with TCP traffic,
		949	it's a problem with unicast traffic, as you also won't see all UDP
		950	traffic between other machines.
		951
		952	<br>
		953
		954	I.e., this is probably <a href="#promiscsniff">the same question
		955	as this earlier one</a>; see the response to that question.
		956	""")
		957
		958	question("""Why am I only seeing ARP packets when I try to capture
		959	traffic?""")
		960
		961	answer("""
		962	You're probably on a switched network, and running Wireshark on a machine
		963	that's not sending traffic to the switch and not being sent any traffic
		964	from other machines on the switch. ARP packets are often broadcast
		965	packets, which are sent to all switch ports.
		966
		967	<br>
		968
		969	I.e., this is probably <a href="#promiscsniff">the same question
		970	as this earlier one</a>; see the response to that question.
		971	""")
		972
		973	question("""
		974	Why am I not seeing any traffic when I try to capture traffic?""")
		975
		976	answer("""
		977	Is the machine running Wireshark sending out any traffic on the network
		978	interface on which you're capturing, or receiving any traffic on that
		979	network, or is there any broadcast traffic on the network or multicast
		980	traffic to a multicast group to which the machine running Wireshark
		981	belongs?
		982
		983	<br>
		984
		985	If not, this may just be a problem with promiscuous sniffing, either due
		986	to running on a switched network or a dual-speed hub, or due to problems
		987	with the interface not supporting promiscuous mode; see the response to
		988	<a href="#promiscsniff">this earlier question</a>.
		989
		990	<br>
		991
		992	Otherwise, on Windows, see the response to <a href="#capprobwin">this
		993	question</a> and, on a UNIX-flavored OS, see the response to <a
		994	href="#capprobunix">this question</a>.
		995	""")
		996
		997	question("""
		998	Can Wireshark capture on (my T1/E1 line, SS7 links, etc.)?
		999	""")
		1000
		1001	answer("""
		1002	Wireshark can only capture on devices supported by libpcap/WinPcap. On
		1003	most OSes, only devices that can act as network interfaces of the type
		1004	that support IP are supported as capture devices for libpcap/WinPcap,
		1005	although the device doesn't necessarily have to be running as an IP
		1006	interface in order to support traffic capture.
		1007
		1008	<br>
		1009
		1010	On Linux and FreeBSD, libpcap 0.8 and later support the API for <a
		1011	href="http://www.endace.com/products.htm">Endace Measurement Systems'
		1012	DAG cards</a>, so that a system with one of those cards, and its driver
		1013	and libraries, installed can capture traffic with those cards with
		1014	libpcap-based applications. You would either have to have a version of
		1015	Wireshark built with that version of libpcap, or a dynamically-linked
		1016	version of Wireshark and a shared libpcap library with DAG support, in
		1017	order to do so with Wireshark. You should ask Endace whether that could
		1018	be used to capture traffic on, for example, your T1/E1 link.
		1019
		1020	<br>
		1021
		1022	See <a href="https://wiki.wireshark.org/CaptureSetup/SS7">the SS7 capture
		1023	setup page</a> on <a href="https://wiki.wireshark.org/">the Wireshark
		1024	Wiki</a> for current information on capturing SS7 traffic on TDM
		1025	links.
		1026	""")
		1027
		1028	question("""How do I put an interface into promiscuous mode?""")
		1029
		1030	answer("""
		1031	By not disabling promiscuous mode when running Wireshark or TShark.
		1032
		1033	<br>
		1034
		1035	Note, however, that:
		1036	</p>
		1037	<ul>
		1038	<li>the form of promiscuous mode that libpcap (the library that
		1039	programs such as tcpdump, Wireshark, etc. use to do packet capture)
		1040	turns on will <strong>not</strong> necessarily be shown if you run
		1041	<code>ifconfig</code> on the interface on a UNIX system;
		1042	<li>some network interfaces might not support promiscuous mode, and some
		1043	drivers might not allow promiscuous mode to be turned on - see <a
		1044	href="#promiscsniff">this earlier question</a> for more information on
		1045	that;
		1046	<li>the fact that you're not seeing any traffic, or are only seeing
		1047	broadcast traffic, or aren't seeing any non-broadcast traffic other than
		1048	traffic to or from the machine running Wireshark, does not mean that
		1049	promiscuous mode isn't on - see <a href="#promiscsniff">this earlier
		1050	question</a> for more information on that.
		1051	</ul>
		1052
		1053	<p>
		1054	I.e., this is probably <a href="#promiscsniff">the same question
		1055	as this earlier one</a>; see the response to that question.
		1056	""")
		1057
		1058	question("""
		1059	I can set a display filter just fine; why don't capture filters work?
		1060	""")
		1061
		1062	answer("""
		1063	Capture filters currently use a different syntax than display filters. Here's
		1064	the corresponding section from the
		1065	<a
		1066	href="https://www.wireshark.org/docs/man-pages/wireshark.html">wireshark(1)</a>
		1067	man page:
		1068
		1069	<br>
		1070
		1071	"Display filters in Wireshark are very powerful; more fields are filterable
		1072	in Wireshark than in other protocol analyzers, and the syntax you can
		1073	use to create your filters is richer. As Wireshark progresses, expect
		1074	more and more protocol fields to be allowed in display filters.
		1075
		1076	<br>
		1077
		1078	Packet capturing is performed with the pcap library. The capture filter
		1079	syntax follows the rules of the pcap library. This syntax is different
		1080	from the display filter syntax."
		1081
		1082	<br>
		1083
		1084	The capture filter syntax used by libpcap can be found in the
		1085	<a href="http://www.tcpdump.org/tcpdump_man.html">tcpdump(8)</a>
		1086	man page.
		1087	""")
		1088
		1089
		1090	question("""I'm entering valid capture filters; why do I still get
		1091	"parse error" errors?""")
		1092
		1093	answer("""
		1094	There is a bug in some versions of libpcap/WinPcap that cause it to
		1095	report parse errors even for valid expressions if a previous filter
		1096	expression was invalid and got a parse error.
		1097
		1098	<br>
		1099
		1100	Try exiting and restarting Wireshark; if you are using a version of
		1101	libpcap/WinPcap with this bug, this will "erase" its memory of the
		1102	previous parse error. If the capture filter that got the "parse error"
		1103	now works, the earlier error with that filter was probably due to this
		1104	bug.
		1105
		1106	<br>
		1107
		1108	The bug was fixed in libpcap 0.6; 0.4[.x] and 0.5[.x] versions of
		1109	libpcap have this bug, but 0.6[.x] and later versions don't.
		1110
		1111	<br>
		1112
		1113	Versions of WinPcap prior to 2.3 are based on pre-0.6 versions of
		1114	libpcap, and have this bug; WinPcap 2.3 is based on libpcap 0.6.2, and
		1115	doesn't have this bug.
		1116
		1117	<br>
		1118
		1119	If you are running Wireshark on a UNIX-flavored platform, run "wireshark
		1120	-v", or select "About Wireshark..." from the "Help" menu in Wireshark, to
		1121	see what version of libpcap it's using. If it's not 0.6 or later, you
		1122	will need either to upgrade your OS to get a later version of libpcap,
		1123	or will need to build and install a later version of libpcap from <a
		1124	href="http://www.tcpdump.org/">the tcpdump.org Web site</a> and then
		1125	recompile Wireshark from source with that later version of libpcap.
		1126
		1127	<br>
		1128
		1129	If you are running Wireshark on Windows with a pre-2.3 version of
		1130	WinPcap, you will need to un-install WinPcap and then download and
		1131	install WinPcap 2.3.
		1132	""")
		1133
		1134	question("""
		1135	How can I capture packets with CRC errors?
		1136	""")
		1137
		1138	answer("""
		1139	Wireshark can capture only the packets that the packet capture library -
		1140	libpcap on UNIX-flavored OSes, and the WinPcap port to Windows of libpcap
		1141	on Windows - can capture, and libpcap/WinPcap can capture only the
		1142	packets that the OS's raw packet capture mechanism (or the WinPcap
		1143	driver, and the underlying OS networking code and network interface
		1144	drivers, on Windows) will allow it to capture.
		1145
		1146	<br>
		1147
		1148	Unless the OS always supplies packets with errors such as invalid CRCs
		1149	to the raw packet capture mechanism, or can be configured to do so,
		1150	invalid CRCs to the raw packet capture mechanism, Wireshark - and other
		1151	programs that capture raw packets, such as tcpdump - cannot capture
		1152	those packets. You will have to determine whether your OS needs to be
		1153	so configured and, if so, can be so configured, configure it if
		1154	necessary and possible, and make whatever changes to libpcap and the
		1155	packet capture program you're using are necessary, if any, to support
		1156	capturing those packets.
		1157
		1158	<br>
		1159
		1160	Most OSes probably do <strong>not</strong> support capturing packets
		1161	with invalid CRCs on Ethernet, and probably do not support it on most
		1162	other link-layer types. Some drivers on some OSes do support it, such
		1163	as some Ethernet drivers on FreeBSD; in those OSes, you might always get
		1164	those packets, or you might only get them if you capture in promiscuous
		1165	mode (you'd have to determine which is the case).
		1166
		1167	<br>
		1168
		1169	Note that libpcap does not currently supply to programs that use it an
		1170	indication of whether the packet's CRC was invalid (because the drivers
		1171	themselves do not supply that information to the raw packet capture
		1172	mechanism); therefore, Wireshark will not indicate which packets had CRC
		1173	errors unless the FCS was captured (see the next question) and you're
		1174	using Wireshark 0.9.15 and later, in which case Wireshark will check the
		1175	CRC and indicate whether it's correct or not.
		1176	""")
		1177
		1178	question("""
		1179	How can I capture entire frames, including the FCS?
		1180	""")
		1181
		1182	answer("""
		1183	Wireshark can only capture data that the packet capture library -
		1184	libpcap on UNIX-flavored OSes, and the WinPcap port to Windows of
		1185	libpcap on Windows - can capture, and libpcap/WinPcap can capture only
		1186	the data that the OS's raw packet capture mechanism (or the WinPcap
		1187	driver, and the underlying OS networking code and network interface
		1188	drivers, on Windows) will allow it to capture.
		1189
		1190	<br>
		1191
		1192	For any particular link-layer network type, unless the OS supplies the
		1193	FCS of a frame as part of the frame, or can be configured to do so,
		1194	Wireshark - and other programs that capture raw packets, such as tcpdump
		1195	- cannot capture the FCS of a frame. You will have to determine whether
		1196	your OS needs to be so configured and, if so, can be so configured,
		1197	configure it if necessary and possible, and make whatever changes to
		1198	libpcap and the packet capture program you're using are necessary, if
		1199	any, to support capturing the FCS of a frame.
		1200
		1201	<br>
		1202
		1203	Most OSes do <strong>not</strong> support capturing the FCS of a frame
		1204	on Ethernet, and probably do not support it on most other link-layer
		1205	types. Some drivres on some OSes do support it, such as some (all?)
		1206	Ethernet drivers on NetBSD and possibly the driver for Apple's gigabit
		1207	Ethernet interface in OS X; in those OSes, you might always get the
		1208	FCS, or you might only get the FCS if you capture in promiscuous mode
		1209	(you'd have to determine which is the case).
		1210
		1211	<br>
		1212
		1213	Versions of Wireshark prior to 0.9.15 will not treat an Ethernet FCS in a
		1214	captured packet as an FCS. 0.9.15 and later will attempt to determine
		1215	whether there's an FCS at the end of the frame and, if it thinks there
		1216	is, will display it as such, and will check whether it's the correct
		1217	CRC-32 value or not.
		1218	""")
		1219
		1220	question("""
		1221	I'm capturing packets on a machine on a VLAN; why don't the packets I'm
		1222	capturing have VLAN tags?
		1223	""")
		1224
		1225	answer("""
		1226	You might be capturing on what might be called a "VLAN interface" - the
		1227	way a particular OS makes VLANs plug into the networking stack might,
		1228	for example, be to have a network device object for the physical
		1229	interface, which takes VLAN packets, strips off the VLAN header and
		1230	constructs an Ethernet header, and passes that packet to an internal
		1231	network device object for the VLAN, which then passes the packets onto
		1232	various higher-level protocol implementations.
		1233
		1234	<br>
		1235
		1236	In order to see the raw Ethernet packets, rather than "de-VLANized"
		1237	packets, you would have to capture not on the virtual interface for the
		1238	VLAN, but on the interface corresponding to the physical network device,
		1239	if possible. See <a
		1240	href="https://wiki.wireshark.org/CaptureSetup/VLAN">the Wireshark Wiki
		1241	item on VLAN capturing</a> for details.
		1242	""")
		1243
		1244	question("""
		1245	Why does Wireshark hang after I stop a capture?
		1246	""")
		1247
		1248	answer("""
		1249	The most likely reason for this is that Wireshark is trying to look up an
		1250	IP address in the capture to convert it to a name (so that, for example,
		1251	it can display the name in the source address or destination address
		1252	columns), and that lookup process is taking a very long time.
		1253
		1254	<br>
		1255
		1256	Wireshark calls a routine in the OS of the machine on which it's running
		1257	to convert of IP addresses to the corresponding names. That routine
		1258	probably does one or more of:
		1259	</p>
		1260	<ul><li>a search of a system file listing IP addresses and names;
		1261	<li>a lookup using DNS;
		1262	<li>on UNIX systems, a lookup using NIS;
		1263	<li>on Windows systems, a NetBIOS-over-TCP query.
		1264	</ul>
		1265
		1266	<p>
		1267	If a DNS server that's used in an address lookup is not responding, the
		1268	lookup will fail, but will only fail after a timeout while the system
		1269	routine waits for a reply.
		1270
		1271	<br>
		1272
		1273	In addition, on Windows systems, if the DNS lookup of the address fails,
		1274	either because the server isn't responding or because there are no
		1275	records in the DNS that could be used to map the address to a name, a
		1276	NetBIOS-over-TCP query will be made. That query involves sending a
		1277	message to the NetBIOS-over-TCP name service on that machine, asking for
		1278	the name and other information about the machine. If the machine isn't
		1279	running software that responds to those queries - for example, many
		1280	non-Windows machines wouldn't be running that software - the lookup will
		1281	only fail after a timeout. Those timeouts can cause the lookup to take
		1282	a long time.
		1283
		1284	<br>
		1285
		1286	If you disable network address-to-name translation - for example, by
		1287	turning off the "Enable network name resolution" option in the "Capture
		1288	Options" dialog box for starting a network capture - the lookups of the
		1289	address won't be done, which may speed up the process of reading the
		1290	capture file after the capture is stopped. You can make that setting
		1291	the default by selecting "Preferences" from the "Edit" menu, turning off
		1292	the "Enable network name resolution" option in the "Name resolution"
		1293	options in the preferences disalog box, and using the "Save" button in
		1294	that dialog box; note that this will save <em>all</em> your current
		1295	preference settings.
		1296
		1297	<br>
		1298
		1299	If Wireshark hangs when reading a capture even with network name
		1300	resolution turned off, there might, for example, be a bug in one of
		1301	Wireshark's dissectors for a protocol causing it to loop infinitely. If
		1302	you're not running the most recent release of Wireshark, you should first
		1303	upgrade to that release, as, if there's a bug of that sort, it might've
		1304	been fixed in a release after the one you're running. If the hang
		1305	occurs in the most recent release of Wireshark, the bug should be
		1306	reported to <a href="mailto:wireshark-dev@wireshark.org">the Wireshark
		1307	developers' mailing list</a> at <code>wireshark-dev@wireshark.org</code>.
		1308
		1309	<br>
		1310
		1311	On UNIX-flavored OSes, please try to force Wireshark to dump core, by
		1312	sending it a <code>SIGABRT</code> signal (usually signal 6) with the
		1313	<code>kill</code> command, and then get a stack trace if you have a debugger
		1314	installed. A stack trace can be obtained by using your debugger
		1315	(<code>gdb</code> in this example), the Wireshark binary, and the resulting
		1316	core file. Here's an example of how to use the gdb command
		1317	<code>backtrace</code> to do so.
		1318	</p>
		1319
		1320	<pre>
		1321	$ gdb wireshark core
		1322	(gdb) backtrace
		1323	..... prints the stack trace
		1324	(gdb) quit
		1325	$
		1326	</pre>
		1327
		1328	<p>
		1329	The core dump file may be named "wireshark.core" rather than "core" on
		1330	some platforms (e.g., BSD systems).
		1331
		1332	<br>
		1333
		1334	Also, if at all possible, please send a copy of the capture file that caused
		1335	the problem. When capturing packets, Wireshark normally writes captured
		1336	packets to a temporary file, which will probably be in <code>/tmp</code> or
		1337	<code>/var/tmp</code> on UNIX-flavored OSes, <code>\\TEMP</code> on the main system disk
		1338	(normally <code>\\Documents and Settings\\</code><var>your login name</var>
		1339	<code>\\Local Settings\\Temp</code> on the main system disk on Windows
		1340	Windows XP and Server 2003, and
		1341	<code>\\Users\\<var>your login name</var>\\AppData\\Local\\Temp</code> on the main
		1342	system disk on Windows Vista and later, so the capture file will probably be there. If you
		1343	are capturing on a single interface, it will have a name of the form,
		1344	<code>wireshark_&lt;iface&gt;_YYYYmmddHHMMSS_XXXXXX.&lt;fmt&gt;</code>, where
		1345	&lt;fmt&gt; is the capture file format (pcap or pcapng), and &lt;iface&gt; is
		1346	the actual name of the interface you are capturing on; otherwise, if you are
		1347	capturing on multiple interfaces, it will have a name of the form,
		1348	<code>wireshark_&lt;N&gt;_interfaces_YYYYmmddHHMMSS_XXXXXX.&lt;fmt&gt;</code>, where &lt;N&gt;
		1349	is the number of simultaneous interfaces you are capturing on. Please don't
		1350	send a trace file greater than 1 MB when compressed; instead, make it available
		1351	via FTP or HTTP, or say it's available but leave it up to a developer to ask
		1352	for it. If the trace file contains sensitive information (e.g., passwords),
		1353	then please do not send it.
		1354	""")
		1355
		1356
		1357	#################################################################
		1358	section("Capturing packets on Windows")
		1359	#################################################################
		1360
		1361	question("""
		1362	I'm running Wireshark on Windows; why does some network interface on my
		1363	machine not show up in the list of interfaces in the "Interface:" field
		1364	in the dialog box popped up by "Capture->Start", and/or why does
		1365	Wireshark give me an error if I try to capture on that interface?
		1366	""", "capprobwin")
		1367
		1368	answer("""
		1369	If you are running Wireshark on Windows XP,
		1370	or Windows Server 2003, and this is the first time you have run a
		1371	WinPcap-based program (such as Wireshark, or TShark, or WinDump, or
		1372	Analyzer, or...) since the machine was rebooted, you need to run that
		1373	program from an account with administrator privileges; once you have run
		1374	such a program, you will not need administrator privileges to run any
		1375	such programs until you reboot.
		1376
		1377	<br>
		1378
		1379	If you are running on Windows Windows XP or Windows Server
		1380	2003 and have administrator privileges or a WinPcap-based program has
		1381	been run with those privileges since the machine rebooted, this problem
		1382	<em>might</em> clear up if you completely un-install WinPcap and then
		1383	re-install it.
		1384
		1385	<br>
		1386
		1387	If that doesn't work, then note that Wireshark relies on the WinPcap
		1388	library, on the WinPcap device driver, and on the facilities that come
		1389	with the OS on which it's running in order to do captures.
		1390
		1391	<br>
		1392
		1393	Therefore, if the OS, the WinPcap library, or the WinPcap driver don't
		1394	support capturing on a particular network interface device, Wireshark
		1395	won't be able to capture on that device.
		1396
		1397	<br>
		1398
		1399	WinPcap 2.3 has problems supporting PPP WAN interfaces on Windows NT
		1400	4.0, Windows 2000, Windows XP, and Windows Server 2003, and, to avoid
		1401	those problems, support for PPP WAN interfaces on those versions of
		1402	Windows has been disabled in WinPcap 3.0. Regular dial-up lines, ISDN
		1403	lines, ADSL connections using PPPoE or PPPoA, and various other lines
		1404	such as T1/E1 lines are all PPP interfaces, so those interfaces might
		1405	not show up on the list of interfaces in the "Capture Options"
		1406	dialog on those OSes.
		1407
		1408	<br>
		1409
		1410	On Windows 2000, Windows XP, and Windows Server 2003, but
		1411	<strong>not</strong> Windows NT 4.0 or Windows Vista Beta 1, you should
		1412	be able to capture on the "GenericDialupAdapter" with WinPcap 3.1. (3.1
		1413	beta releases called it the "NdisWanAdapter"; if you're using a 3.1 beta
		1414	release, you should un-install it and install the final 3.1 release.)
		1415	See <a href="https://wiki.wireshark.org/CaptureSetup/PPP">the Wireshark
		1416	Wiki item on PPP capturing</a> for details.
		1417
		1418	<br>
		1419
		1420	WinPcap prior to 3.0 does not support multiprocessor machines (note
		1421	that machines with a single multi-threaded processor, such as Intel's
		1422	new multi-threaded x86 processors, are multiprocessor machines as far as
		1423	the OS and WinPcap are concerned), and recent 2.x versions of WinPcap
		1424	refuse to operate if they detect that they're running on a
		1425	multiprocessor machine, which means that they may not show any network
		1426	interfaces. You will need to use WinPcap 3.0 to capture on a
		1427	multiprocessor machine.
		1428
		1429	<br>
		1430
		1431	If an interface doesn't show up in the list of interfaces in the
		1432	"Interface:" field, and you know the name of the interface, try entering
		1433	that name in the "Interface:" field and capturing on that device.
		1434
		1435	<br>
		1436
		1437	If the attempt to capture on it succeeds, the interface is somehow not
		1438	being reported by the mechanism Wireshark uses to get a list of
		1439	interfaces. Try listing the interfaces with WinDump; see <a
		1440	href="https://www.windump.org/">the WinDump Web site</a>
		1441	for information on using WinDump.
		1442
		1443	<br>
		1444
		1445	You would run WinDump with the <code>-D</code> flag; if it lists the
		1446	interface, please report this to <a
		1447	href="mailto:wireshark-dev@wireshark.org">wireshark-dev@wireshark.org</a>
		1448	giving full details of the problem, including
		1449	</p>
		1450
		1451	<ul>
		1452	<li>the operating system you're using, and the version of that operating
		1453	system;
		1454	<li>the type of network device you're using;
		1455	<li>the output of WinDump.
		1456	</ul>
		1457
		1458	<p>
		1459	If WinDump does <em>not</em> list the interface,
		1460	this is almost certainly a problem with one or more of:
		1461	</p>
		1462
		1463	<ul>
		1464	<li>the operating system you're using;
		1465	<li>the device driver for the interface you're using;
		1466	<li>the WinPcap library and/or the WinPcap device driver;
		1467	</ul>
		1468
		1469	<p>
		1470	so first check <a href="https://www.winpcap.org/misc/faq.htm">the
		1471	WinPcap FAQ</a> to see if your problem is mentioned there. If not, then see <a
		1472	href="https://www.winpcap.org/contact.htm">the WinPcap support page</a>
		1473	- check the "Submitting bugs" section.
		1474
		1475	<br>
		1476
		1477	If you are having trouble capturing on a particular network interface,
		1478	first try capturing on that device with WinDump; see <a
		1479	href="https://www.windump.org/">the WinDump Web site</a>
		1480	for information on using WinDump.
		1481
		1482	<br>
		1483
		1484	If you can capture on the interface with WinDump, send mail to <a
		1485	href="mailto:wireshark-users@wireshark.org">wireshark-users@wireshark.org</a>
		1486	giving full details of the problem, including
		1487	</p>
		1488
		1489	<ul>
		1490	<li>the operating system you're using, and the version of that operating
		1491	system;
		1492	<li>the type of network device you're using;
		1493	<li>the error message you get from Wireshark.
		1494	</ul>
		1495
		1496	<p>
		1497	If you <em>cannot</em> capture on the interface with WinDump,
		1498	this is almost certainly a problem with one or more of:
		1499	</p>
		1500
		1501	<ul>
		1502	<li>the operating system you're using;
		1503	<li>the device driver for the interface you're using;
		1504	<li>the WinPcap library and/or the WinPcap device driver;
		1505	</ul>
		1506
		1507	<p>
		1508	so first check <a href="https://www.winpcap.org/misc/faq.htm">the
		1509	WinPcap FAQ</a> to see if your problem is mentioned there. If not, then see <a
		1510	href="https://www.winpcap.org/contact.htm">the WinPcap support page</a>
		1511	- check the "Submitting bugs" section.
		1512
		1513	<br>
		1514
		1515	You may also want to ask the <a
		1516	href="mailto:wireshark-users@wireshark.org">wireshark-users@wireshark.org</a>
		1517	and the <a
		1518	href="mailto:winpcap-users@winpcap.org">winpcap-users@winpcap.org</a>
		1519	mailing lists to see if anybody happens to know about the problem and
		1520	know a workaround or fix for the problem. (Note that you will have to
		1521	subscribe to that list in order to be allowed to mail to it; see <a
		1522	href="https://www.winpcap.org/contact.htm">the WinPcap support
		1523	page</a> for information on the mailing list.) In your mail,
		1524	please give full details of the problem, as described above, and also
		1525	indicate that the problem occurs with WinDump, not just with Wireshark.
		1526	""")
		1527
		1528	question("""
		1529	I'm running Wireshark on Windows; why do no network interfaces show up in
		1530	the list of interfaces in the "Interface:" field in the dialog box
		1531	popped up by "Capture->Start"?
		1532	""")
		1533
		1534	answer("""
		1535	This is really <a href="#capprobwin">the same question as a previous
		1536	one</a>; see the response to that question.
		1537	""")
		1538
		1539	question("""
		1540	I'm running Wireshark on Windows; why doesn't my serial port/ADSL
		1541	modem/ISDN modem show up in the list of interfaces in the "Interface:"
		1542	field in the dialog box popped up by "Capture->Start"?
		1543	""")
		1544
		1545	answer("""
		1546	Internet access on those devices is often done with the Point-to-Point
		1547	(PPP) protocol; WinPcap 2.3 has problems supporting PPP WAN interfaces
		1548	on Windows NT 4.0, Windows 2000, Windows XP, and Windows Server 2003,
		1549	and, to avoid those problems, support for PPP WAN interfaces on those
		1550	versions of Windows has been disabled in WinPcap 3.0.
		1551
		1552	<br>
		1553
		1554	On Windows 2000, Windows XP, and Windows Server 2003, but
		1555	<strong>not</strong> Windows NT 4.0 or Windows Vista Beta 1, you should
		1556	be able to capture on the "GenericDialupAdapter" with WinPcap 3.1. (3.1
		1557	beta releases called it the "NdisWanAdapter"; if you're using a 3.1 beta
		1558	release, you should un-install it and install the final 3.1 release.)
		1559	See <a href="https://wiki.wireshark.org/CaptureSetup/PPP">the Wireshark
		1560	Wiki item on PPP capturing</a> for details.
		1561	""")
		1562
		1563	question("""
		1564	I'm running Wireshark on Windows NT 4.0/Windows 2000/Windows XP/Windows
		1565	Server 2003; my machine has a PPP (dial-up POTS, ISDN, etc.) interface,
		1566	and it shows up in the "Interface" item in the "Capture Options" dialog
		1567	box. Why can no packets be sent on or received from that network while
		1568	I'm trying to capture traffic on that interface?""", "nt_ppp_sniff")
		1569
		1570	answer("""
		1571	Some versions of WinPcap have problems with PPP WAN interfaces on
		1572	Windows NT 4.0, Windows 2000, Windows XP, and Windows Server 2003; one
		1573	symptom that may be seen is that attempts to capture in promiscuous mode
		1574	on the interface cause the interface to be incapable of sending or
		1575	receiving packets. You can disable promiscuous mode using the
		1576	<code>-p</code> command-line flag or the item in the "Capture Preferences"
		1577	dialog box, but this may mean that outgoing packets, or incoming
		1578	packets, won't be seen in the capture.
		1579
		1580	<br>
		1581
		1582	On Windows 2000, Windows XP, and Windows Server 2003, but
		1583	<strong>not</strong> Windows NT 4.0 or Windows Vista Beta 1, you should
		1584	be able to capture on the "GenericDialupAdapter" with WinPcap 3.1. (3.1
		1585	beta releases called it the "NdisWanAdapter"; if you're using a 3.1 beta
		1586	release, you should un-install it and install the final 3.1 release.)
		1587	See <a href="https://wiki.wireshark.org/CaptureSetup/PPP">the Wireshark
		1588	Wiki item on PPP capturing</a> for details.
		1589	""")
		1590
		1591	question("""
		1592	I'm running Wireshark on Windows; why am I not seeing any traffic being
		1593	sent by the machine running Wireshark?""")
		1594
		1595	answer("""
		1596	If you are running some form of VPN client software, it might be causing
		1597	this problem; people have seen this problem when they have Check Point's
		1598	VPN software installed on their machine. If that's the cause of the
		1599	problem, you will have to remove the VPN software in order to have
		1600	Wireshark (or any other application using WinPcap) see outgoing packets;
		1601	unfortunately, neither we nor the WinPcap developers know any way to
		1602	make WinPcap and the VPN software work well together.
		1603
		1604	<br>
		1605
		1606	Also, some drivers for Windows (especially some wireless network
		1607	interface drivers) apparently do not, when running in promiscuous mode,
		1608	arrange that outgoing packets are delivered to the software that
		1609	requested that the interface run promiscuously; try turning promiscuous
		1610	mode off.
		1611	""")
		1612
		1613	question("""
		1614	When I capture on Windows in promiscuous mode, I can see packets other
		1615	than those sent to or from my machine; however, those packets show up
		1616	with a "Short Frame" indication, unlike packets to or from my machine.
		1617	What should I do to arrange that I see those packets in their entirety?
		1618	""")
		1619
		1620	answer("""
		1621	In at least some cases, this appears to be the result of PGPnet running
		1622	on the network interface on which you're capturing; turn it off on that
		1623	interface.
		1624	""")
		1625
		1626	question("""
		1627	I'm trying to capture 802.11 traffic on Windows; why am I not seeing any
		1628	packets?
		1629	""", "win802_11promisc")
		1630
		1631	answer("""
		1632	At least some 802.11 card drivers on Windows appear not to see any
		1633	packets if they're running in promiscuous mode. Try turning promiscuous
		1634	mode off; you'll only be able to see packets sent by and received by
		1635	your machine, not third-party traffic, and it'll look like Ethernet
		1636	traffic and won't include any management or control frames, but that's a
		1637	limitation of the card drivers.
		1638
		1639	<br>
		1640
		1641	See the archived <a
		1642	href="https://web.archive.org/web/20090226193157/http://www.micro-logix.com/winpcap/Supported.asp">MicroLogix's
		1643	list of cards supported with WinPcap</a> for information on
		1644	support of various adapters and drivers with WinPcap.
		1645	""")
		1646
		1647	question("""
		1648	I'm trying to capture 802.11 traffic on Windows; why am I seeing packets
		1649	received by the machine on which I'm capturing traffic, but not packets
		1650	sent by that machine?
		1651	""")
		1652
		1653	answer("""
		1654	This appears to be another problem with promiscuous mode; try turning it
		1655	off.
		1656	""")
		1657
		1658	question("""
		1659	I'm trying to capture Ethernet VLAN traffic on Windows, and I'm
		1660	capturing on a "raw" Ethernet device rather than a "VLAN interface", so
		1661	that I can see the VLAN headers; why am I seeing packets received by the
		1662	machine on which I'm capturing traffic, but not packets sent by that
		1663	machine?
		1664	""")
		1665
		1666	answer("""
		1667	The way the Windows networking code works probably means that packets
		1668	are sent on a "VLAN interface" rather than the "raw" device, so packets
		1669	sent by the machine will only be seen when you capture on the "VLAN
		1670	interface". If so, you will be unable to see outgoing packets when
		1671	capturing on the "raw" device, so you are stuck with a choice between
		1672	seeing VLAN headers and seeing outgoing packets.
		1673	""")
		1674
		1675	#################################################################
		1676	section("Capturing packets on UN*Xes")
		1677	#################################################################
		1678
		1679	question("""
		1680	I'm running Wireshark on a UNIX-flavored OS; why does some network
		1681	interface on my machine not show up in the list of interfaces in the
		1682	"Interface:" field in the dialog box popped up by "Capture->Start",
		1683	and/or why does Wireshark give me an error if I try to capture on that
		1684	interface? """, "capprobunix")
		1685
		1686	answer("""
		1687	You may need to run Wireshark from an account with sufficient privileges
		1688	to capture packets, such as the super-user account, or may need to give
		1689	your account sufficient privileges to capture packets. Only those
		1690	interfaces that Wireshark can open for capturing show up in that list; if
		1691	you don't have sufficient privileges to capture on any interfaces, no
		1692	interfaces will show up in the list. See
		1693	<a href="https://wiki.wireshark.org/CaptureSetup/CapturePrivileges">the
		1694	Wireshark Wiki item on capture privileges</a> for details on how to give
		1695	a particular account or account group capture privileges on platforms
		1696	where that can be done.
		1697
		1698	<br>
		1699
		1700	If you are running Wireshark from an account with sufficient privileges,
		1701	then note that Wireshark relies on the libpcap library, and on the
		1702	facilities that come with the OS on which it's running in order to do
		1703	captures. On some OSes, those facilities aren't present by default; see
		1704	<a href="https://wiki.wireshark.org/CaptureSetup/CaptureSupport">the
		1705	Wireshark Wiki item on adding capture support</a> for details.
		1706
		1707	<br>
		1708
		1709	And, even if you're running with an account that has sufficient
		1710	privileges to capture, and capture support is present in your OS, if the
		1711	OS or the libpcap library don't support capturing on a particular
		1712	network interface device or particular types of devices, Wireshark won't
		1713	be able to capture on that device.
		1714
		1715	<br>
		1716
		1717	On Solaris, note that libpcap 0.6.2 and earlier didn't support Token
		1718	Ring interfaces; the current version, 0.7.2, does support Token Ring,
		1719	and the current version of Wireshark works with libpcap 0.7.2 and later.
		1720
		1721	<br>
		1722
		1723	If an interface doesn't show up in the list of interfaces in the
		1724	"Interface:" field, and you know the name of the interface, try entering
		1725	that name in the "Interface:" field and capturing on that device.
		1726
		1727	<br>
		1728
		1729	If the attempt to capture on it succeeds, the interface is somehow not
		1730	being reported by the mechanism Wireshark uses to get a list of
		1731	interfaces; please report this to <a
		1732	href="mailto:wireshark-dev@wireshark.org">wireshark-dev@wireshark.org</a>
		1733	giving full details of the problem, including
		1734	</p>
		1735
		1736	<ul>
		1737	<li>the operating system you're using, and the version of that operating
		1738	system (for Linux, give both the version number of the kernel and the
		1739	name and version number of the distribution you're using);
		1740	<li>the type of network device you're using.
		1741	</ul>
		1742
		1743	<p>
		1744	If you are having trouble capturing on a particular network interface,
		1745	and you've made sure that (on platforms that require it) you've arranged
		1746	that packet capture support is present, as per the above, first try
		1747	capturing on that device with <code>tcpdump</code>.
		1748
		1749	<br>
		1750
		1751	If you can capture on the interface with <code>tcpdump</code>, send mail to
		1752	<a
		1753	href="mailto:wireshark-users@wireshark.org">wireshark-users@wireshark.org</a>
		1754	giving full details of the problem, including
		1755	</p>
		1756
		1757	<ul>
		1758	<li>the operating system you're using, and the version of that operating
		1759	system (for Linux, give both the version number of the kernel and the
		1760	name and version number of the distribution you're using);
		1761	<li>the type of network device you're using;
		1762	<li>the error message you get from Wireshark.
		1763	</ul>
		1764
		1765	<p>
		1766	If you <em>cannot</em> capture on the interface with <code>tcpdump</code>,
		1767	this is almost certainly a problem with one or more of:
		1768	</p>
		1769
		1770	<ul>
		1771	<li>the operating system you're using;
		1772	<li>the device driver for the interface you're using;
		1773	<li>the libpcap library;
		1774	</ul>
		1775
		1776	<p>
		1777	so you should report the problem to the company or organization that
		1778	produces the OS (in the case of a Linux distribution, report the problem
		1779	to whoever produces the distribution).
		1780
		1781	<br>
		1782
		1783	You may also want to ask the <a
		1784	href="mailto:wireshark-users@wireshark.org">wireshark-users@wireshark.org</a>
		1785	and the <a
		1786	href="mailto:tcpdump-workers@lists.tcpdump.org">tcpdump-workers@lists.tcpdump.org</a>
		1787	mailing lists to see if anybody happens to know about the problem and
		1788	know a workaround or fix for the problem. In your mail, please give
		1789	full details of the problem, as described above, and also indicate that
		1790	the problem occurs with <code>tcpdump</code> not just with Wireshark.
		1791	""")
		1792
		1793	question("""
		1794	I'm running Wireshark on a UNIX-flavored OS; why do no network interfaces
		1795	show up in the list of interfaces in the "Interface:" field in the
		1796	dialog box popped up by "Capture->Start"?
		1797	""")
		1798
		1799	answer("""
		1800	This is really <a href="#capprobunix">the same question as the previous
		1801	one</a>; see the response to that question.
		1802	""")
		1803
		1804	question("""I'm capturing packets on Linux; why do the time stamps have
		1805	only 100ms resolution, rather than 1us resolution?""")
		1806
		1807	answer("""
		1808	Wireshark gets time stamps from libpcap/WinPcap, and
		1809	libpcap/WinPcap get them from the OS kernel, so Wireshark - and any other
		1810	program using libpcap, such as tcpdump - is at the mercy of the time
		1811	stamping code in the OS for time stamps.
		1812
		1813	<br>
		1814
		1815	At least on x86-based machines, Linux can get high-resolution time
		1816	stamps on newer processors with the Time Stamp Counter (TSC) register;
		1817	for example, Intel x86 processors, starting with the Pentium Pro, and
		1818	including all x86 processors since then, have had a TSC, and other
		1819	vendors probably added the TSC at some point to their families of x86
		1820	processors.
		1821
		1822	The Linux kernel must be configured with the CONFIG_X86_TSC option
		1823	enabled in order to use the TSC. Make sure this option is enabled in
		1824	your kernel.
		1825
		1826	<br>
		1827
		1828	In addition, some Linux distributions may have bugs in their versions of
		1829	the kernel that cause packets not to be given high-resolution time
		1830	stamps even if the TSC is enabled. See, for example, bug 61111 for Red
		1831	Hat Linux 7.2. If your distribution has a bug such as this, you may
		1832	have to run a standard kernel from kernel.org in order to get
		1833	high-resolution time stamps.
		1834	""")
		1835
		1836	#################################################################
		1837	section("Capturing packets on wireless LANs")
		1838	#################################################################
		1839
		1840
		1841	question("""
		1842	How can I capture raw 802.11 frames, including non-data (management,
		1843	beacon) frames?
		1844	""", "raw_80211_sniff")
		1845
		1846	answer("""
		1847	That depends on the operating system on which you're running, and on the
		1848	802.11 interface on which you're capturing.
		1849
		1850	<br>
		1851
		1852	This would probably require that you capture in promiscuous mode or in
		1853	the mode called "monitor mode" or "RFMON mode". On some platforms, or
		1854	with some cards, this might require that you capture in monitor mode -
		1855	promiscuous mode might not be sufficient. If you want to capture
		1856	traffic on networks other than the one with which you're associated, you
		1857	will have to capture in monitor mode.
		1858
		1859	<br>
		1860
		1861	Not all operating systems support capturing non-data packets and, even
		1862	on operating systems that do support it, not all drivers, and thus not
		1863	all interfaces, support it. Even on those that do, monitor mode might
		1864	not be supported by the operating system or by the drivers for all
		1865	interfaces.
		1866
		1867	<br>
		1868
		1869	<strong>NOTE:</strong> an interface running in monitor mode will, on
		1870	most if not all platforms, not be able to act as a regular network
		1871	interface; putting it into monitor mode will, in effect, take your
		1872	machine off of whatever network it's on as long as the interface is in
		1873	monitor mode, allowing it only to passively capture packets.
		1874
		1875	<br>
		1876
		1877	This means that you should disable name resolution when capturing in
		1878	monitor mode; otherwise, when Wireshark (or TShark, or tcpdump) tries
		1879	to display IP addresses as host names, it will probably block for a long
		1880	time trying to resolve the name because it will not be able to
		1881	communicate with any DNS or NIS servers.
		1882
		1883	<br>
		1884
		1885	See <a
		1886	href="https://wiki.wireshark.org/CaptureSetup/WLAN">the Wireshark
		1887	Wiki item on 802.11 capturing</a> for details.
		1888	""")
		1889
		1890	question("""
		1891	How do I capture on an 802.11 device in monitor mode?""",
		1892	"monitor")
		1893
		1894	answer("""
		1895	Whether you will be able to capture in monitor mode depends on the
		1896	operating system, adapter, and driver you're using.
		1897	See <a href="#raw_80211_sniff">the previous question</a> for information
		1898	on monitor mode, including a link to the Wireshark Wiki page that gives
		1899	details on 802.11 capturing.
		1900	""")
		1901
		1902	#################################################################
		1903	section("Viewing traffic")
		1904	#################################################################
		1905
		1906
		1907	question("Why am I seeing lots of packets with incorrect TCP checksums?")
		1908
		1909	answer("""
		1910	If the packets that have incorrect TCP checksums are all being sent by
		1911	the machine on which Wireshark is running, this is probably because the
		1912	network interface on which you're capturing does TCP checksum
		1913	offloading. That means that the TCP checksum is added to the packet by
		1914	the network interface, not by the OS's TCP/IP stack; when capturing on
		1915	an interface, packets being sent by the host on which you're capturing
		1916	are directly handed to the capture interface by the OS, which means that
		1917	they are handed to the capture interface without a TCP checksum being
		1918	added to them.
		1919
		1920	<br>
		1921
		1922	The only way to prevent this from happening would be to disable TCP
		1923	checksum offloading, but
		1924	</p>
		1925
		1926	<ol>
		1927	<li>that might not even be possible on some OSes;
		1928	<li>that could reduce networking performance significantly.
		1929	</ol>
		1930
		1931	<p>
		1932	However, you can disable the check that Wireshark does of the TCP
		1933	checksum, so that it won't report any packets as having TCP checksum
		1934	errors, and so that it won't refuse to do TCP reassembly due to a packet
		1935	having an incorrect TCP checksum. That can be set as an Wireshark
		1936	preference by selecting "Preferences" from the "Edit" menu, opening up
		1937	the "Protocols" list in the left-hand pane of the "Preferences" dialog
		1938	box, selecting "TCP", from that list, turning off the "Check the
		1939	validity of the TCP checksum when possible" option, clicking "Save" if
		1940	you want to save that setting in your preference file, and clicking
		1941	"OK".
		1942
		1943	<br>
		1944
		1945	It can also be set on the Wireshark or TShark command line with a
		1946	<code>-o tcp.check_checksum:false</code> command-line flag, or manually set
		1947	in your preferences file by adding a <code>tcp.check_checksum:false</code>
		1948	line.
		1949	""")
		1950
		1951	question("""
		1952	I've just installed Wireshark, and the traffic on my local LAN
		1953	is boring. Where can I find more interesting captures?
		1954	""")
		1955
		1956	answer("""
		1957	We have a collection of strange and exotic sample capture
		1958	files at %s""" % (selflink("https://wiki.wireshark.org/SampleCaptures")))
		1959
		1960
		1961	question("""
		1962	Why doesn't Wireshark correctly identify RTP packets? It shows them
		1963	only as UDP.""")
		1964
		1965	answer("""
		1966	Wireshark can identify a UDP datagram as containing a packet of a
		1967	particular protocol running atop UDP only if
		1968	</p>
		1969
		1970	<ol>
		1971	<li> The protocol in question has a particular standard port
		1972	number, and the UDP source or destination port number is that port
		1973
		1974	<li> Packets of that protocol can be identified by looking for a
		1975	"signature" of some type in the packet - i.e., some data
		1976	that, if Wireshark finds it in some particular part of a
		1977	packet, means that the packet is almost certainly a packet of
		1978	that type.
		1979
		1980	<li> Some <em>other</em> traffic earlier in the capture indicated that,
		1981	for example, UDP traffic between two particular addresses and
		1982	ports will be RTP traffic.
		1983	</ol>
		1984
		1985	<p>
		1986	RTP doesn't have a standard port number, so 1) doesn't work; it doesn't,
		1987	as far as I know, have any "signature", so 2) doesn't work.
		1988
		1989	<br>
		1990
		1991	That leaves 3). If there's RTSP traffic that sets up an RTP session,
		1992	then, at least in some cases, the RTSP dissector will set things up so
		1993	that subsequent RTP traffic will be identified. Currently, that's the
		1994	only place we do that; there may be other places.
		1995
		1996	<br>
		1997
		1998	However, there will always be places where Wireshark is simply
		1999	<b>incapable</b> of deducing that a given UDP flow is RTP; a mechanism
		2000	would be needed to allow the user to specify that a given conversation
		2001	should be treated as RTP. As of Wireshark 0.8.16, such a mechanism
		2002	exists; if you select a UDP or TCP packet, the right mouse button menu
		2003	will have a "Decode As..." menu item, which will pop up a dialog box
		2004	letting you specify that the source port, the destination port, or both
		2005	the source and destination ports of the packet should be dissected as
		2006	some particular protocol.
		2007	""")
		2008
		2009	question("""
		2010	Why doesn't Wireshark show Yahoo Messenger packets in captures that
		2011	contain Yahoo Messenger traffic?""")
		2012
		2013	answer("""
		2014	Wireshark only recognizes as Yahoo Messenger traffic packets to or from TCP
		2015	port 3050 that begin with "YPNS", "YHOO", or "YMSG". TCP segments that
		2016	start with the middle of a Yahoo Messenger packet that takes more than one
		2017	TCP segment will not be recognized as Yahoo Messenger packets (even if the
		2018	TCP segment also contains the beginning of another Yahoo Messenger
		2019	packet).
		2020	""")
		2021
		2022	#################################################################
		2023	section("Filtering traffic")
		2024	#################################################################
		2025
		2026
		2027	question("""I saved a filter and tried to use its name to filter the
		2028	display; why do I get an "Unexpected end of filter string" error?""")
		2029
		2030	answer("""
		2031	You cannot use the name of a saved display filter as a filter. To
		2032	filter the display, you can enter a display filter expression -
		2033	<strong>not</strong> the name of a saved display filter - in the
		2034	"Filter:" box at the bottom of the display, and type the &lt;Enter&gt; key or
		2035	press the "Apply" button (that does not require you to have a saved
		2036	filter), or, if you want to use a saved filter, you can press the
		2037	"Filter:" button, select the filter in the dialog box that pops up, and
		2038	press the "OK" button.""")
		2039
		2040	question("""
		2041	How can I search for, or filter, packets that have a particular string
		2042	anywhere in them?
		2043	""")
		2044
		2045	answer("""
		2046	If you want to do this when capturing, you can't. That's a feature that
		2047	would be hard to implement in capture filters without changes to the
		2048	capture filter code, which, on many platforms, is in the OS kernel and,
		2049	on other platforms, is in the libpcap library.
		2050
		2051	<br>
		2052
		2053	After capture, you can search for text by selecting <i>Edit&#8594;Find
		2054	Packet...</i> and making sure <i>String</i> is selected. Alternately, you can
		2055	use the "contains" display filter operator or "matches" operator if it's
		2056	supported on your system.
		2057	""")
		2058
		2059	question("""
		2060	How do I filter a capture to see traffic for virus XXX?
		2061	""")
		2062
		2063	answer("""
		2064	For some viruses/worms there might be a capture filter to recognize the
		2065	virus traffic. Check the <a
		2066	href="https://wiki.wireshark.org/CaptureFilters">CaptureFilters</a> page
		2067	on the <a href="https://wiki.wireshark.org/">Wireshark Wiki</a> to see if
		2068	anybody's added such a filter.
		2069
		2070	<br>
		2071
		2072	Note that Wireshark was not designed to be an intrusion detection system;
		2073	you might be able to use it as an IDS, but in most cases software
		2074	designed to be an IDS, such as <a href="https://www.snort.org/">Snort</a>
		2075	or <a href="https://www.prelude-siem.org/">Prelude</a>, will probably work
		2076	better.
		2077	""")
		2078
		2079	#################################################################
		2080	if __name__ == '__main__':
		2081	sys.exit(main())
		2082	#################################################################