Re: [Wireshark-users] Logging Ups and Downs

[Guy Harris]

On May 7, 2024, at 10:02 AM, Bruce  wrote:

> How and where in WS do I set up a function that will log (to a
> file with dates, times, durations) the Ups and Downs of my Wireless
> (Cellular) Internet Connection through a USB BroadBand Modem ?

That would depend on what information the modem supplies to the host about the 
state of the connection.

Unless that information takes the form of packets, Wireshark won't see it, as 
the capture mechanisms it uses only deal with packets - and, for the modem, 
those packets are probably not low-level cellular radio network packets.

You're probably better off trying to find out what information the broadband 
modem logs or otherwise provides to the host.  Does the modem come with some 
utilities to run on your machine?
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] dumpcap/tshark direction capture filter like tcpdump?

[Guy Harris]

On Feb 29, 2024, at 8:37 PM, David Luu  wrote:

> I came to know of direction filtering for captures with tcpdump per
> https://serverfault.com/questions/628462/packet-captures-filtering-on-rx-vs-tx.
> But from CLI options, seems like dumpcap/tshark doesn't offer similar
> capability?
> 
> Is there any plan to consider that for future?

It's more like "if somebody decides to write the code and make a pull request, 
we'll look at it and, if it's in shape, we'll merge it".  A lot of what's in 
Wireshark isn't from a roadmap, it's from somebody deciding they want the 
feature supported and adding code; we don't have comprehensive plans for 
features.
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] timestamp precision or resolution for dumpcap/tshark captures?

[Guy Harris]

On Feb 23, 2024, at 2:42 PM, David Luu  wrote:

> I see there is a --time-stamp-precision flag parameter for tcpdump
> with option for nano(seconds) and also shorthand flags --nano,
> --micro. But actually supporting the value depends on the OS/hardware.
> 
> I didn't see such option for dumpcap/tshark. Is it available, or
> planned on roadmap?

What's a "roadmap"? :-)

There is no detailed roadmap for Wireshark; some changes may manifest 
themselves as projects intended for a given release, but others are just 
"whatever somebody takes the time to do".

> Given the tools support other pcapng features like adding comment or
> overwriting/setting interface description, was curious to why
> timestamp precision support wasn't added by just using what
> tcpdump/libpcap already offers in that area.

Because nobody's taken the time to do so.

(And it's not specifically a pcapng feature - pcap also supports both 
microsecond and nanosecond precision.)
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] 2 questions

[Guy Harris]

On Dec 30, 2023, at 6:36 PM, Jean-Michel Collard  wrote:

> First of all : Happy New Year to everyone 

Happy New Year to you too!  (Or "have a Happy New Year", as it's now still 
2023-12-30 23:04 local time here. :-))

> Why Wireshark display IPv1/v6 addresses instead of hostnames (if any)?

Because either

1) you don't have network-layer host name resolution enabled

or

2) it's enabled, but Wireshark couldn't translate the IP address to a 
host name.

> Can it be configured to have this ?

To make sure network host name resolution is enabled:

select "Preferences" from the "Edit" menu (Windows, Linux, everything 
else other than macOS) or the "Wireshark" menu (macOS);

select "Name Resolution" from the Preferences dialog;

make sure that "Resolve network (IP) addresses" is checked;

make sure that "Use your system's DNS settings for name resolution" is 
checked;

click the "OK" button.

If that doesn't cause it to resolve IP addresses, it's probably because 
whatever DNS server your system's DNS settings use can't resolve the addresses.

> When one right click on a packet there is no whois ?

I don't think there's a "whois" menu item in Wireshark.

> I know there are already a lot of things with a right-click.

There are, but "whois" isn't one of them.  There may have, in the past, been a 
"resolve IP address(es)" option, but it doesn't appear to be there now.
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] Remote PCAP capture in active mode?

[Guy Harris]

On Nov 17, 2023, at 8:42 AM, David Luu  wrote:

> I guess maybe nevermind, I think I got my answer, unless things have
> changed since then
> https://gitlab.com/wireshark/migration-test/-/issues/4275

I'm not sure how you got there, but the right place to look for issue 4275 is

https://gitlab.com/wireshark/wireshark/-/issues/4275

Updates do *NOT* occur on the migration-test site - that site was, I assume, 
created as a test site for the process of migrating bugs from Bugzilla to 
GitLab, and is not the "live" site for the Wireshark issue list.

But there are no updates to that.
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] Custom CAN dissector script

[Guy Harris]

On Jun 5, 2023, at 1:58 PM, Fabian Cenedese  wrote:

> At 22:29 05.06.2023, Guy Harris wrote:
> 
>> On Jun 5, 2023, at 3:43 AM, Fabian Cenedese  wrote:
>> 
>>> We're using CAN bus as protocol and I implemented a capture
>>> to save the sent and received frames into a .pcapng file.
>> 
>> So presumably that's using LINKTYPE_CAN_SOCKETCAN as the link-layer type in 
>> the IDBs, with the SocketCAN pseudo-header:
>> 
>>   https://www.tcpdump.org/linktypes/LINKTYPE_CAN_SOCKETCAN.html
> 
> I also tried CAN20B (190), but now I'm using SOCKETCAN (227) as this
> worked better.

Unfortunately, CAN20B was never documented, and the people at CACE 
Technologies^W^WRiverbed^WSysdig don't remember what it was any more.

So, yes, LINKTYPE_CAN_SOCKETCAN is what should be used.

>> If by "script" you mean "dissector written in Lua rather than C", that's 
>> going to be a bit tricky; subdissectors called by the SocketCAN dissector 
>> are passed a pointer to a structure that includes, among other things, the 
>> ID, but that's a C structure, and we don't currently have a good way to pass 
>> information to Lua subdissectors.
> 
> I just assumed that lua is the fastest or easiest way to go, but I could
> also create a dll if that is better.

"Better" depends on the criteria; if your dissector needs to get at the CAN ID, 
as their... nonstandard way of using the ID seems to indicate, a C dissector 
would be "better" in that, currently, there's no way to get that from Lua.

(In the long term, we should provide a way to get at that from Lua (which might 
also involve passing information as a key-value store, which would also help 
*C* dissectors, as, instead of getting a blob whose structure is defined only 
by convention between the calling and called dissector, which is rather 
fragile, they'd get it as a key-value store as well.  But that's not what we 
have now.)

>>> as well as the first data byte.
>>> 
>>> How would I register this dissector as it doesn't use an Ethernet
>>> port?
>> 
>> Not sure what an "Ethernet port" is, but various dissectors that call 
>> subdissectors have dissector tables using various keys, such as Ethernet 
>> types, TCP or UDP ports, and so on.
> 
> Exactly, always Ethernet related.

TCP and UDP ports aren't Ethernet-related; only Ethernet types are.
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] Custom CAN dissector script

[Guy Harris]

On Jun 5, 2023, at 3:43 AM, Fabian Cenedese  wrote:

> We're using CAN bus as protocol and I implemented a capture
> to save the sent and received frames into a .pcapng file.

So presumably that's using LINKTYPE_CAN_SOCKETCAN as the link-layer type in the 
IDBs, with the SocketCAN pseudo-header:

https://www.tcpdump.org/linktypes/LINKTYPE_CAN_SOCKETCAN.html

> I can
> load it in Wireshark and the frames are displayed as CAN which
> is correct. However the fields are only shown as identifier and
> data bytes which doesn't say much yet.

I.e., a SocketCAN header with ID, flags, and frame length, followed by an 
undissected Data field?

> I would like to add a custom dissector that will interpret the CAN
> fields further down. The identifier needs to be broken down into
> two separate fields

I.e., you need to redissect the ID field as having two separate subfields?

If by "script" you mean "dissector written in Lua rather than C", that's going 
to be a bit tricky; subdissectors called by the SocketCAN dissector are passed 
a pointer to a structure that includes, among other things, the ID, but that's 
a C structure, and we don't currently have a good way to pass information to 
Lua subdissectors.

> as well as the first data byte.
> 
> How would I register this dissector as it doesn't use an Ethernet
> port?

Not sure what an "Ethernet port" is, but various dissectors that call 
subdissectors have dissector tables using various keys, such as Ethernet types, 
TCP or UDP ports, and so on.

The SocketCAN dissector has two tables, named "can.id " and 
"can.extended_id", which use the un-extended 11-bit ID field and the extended 
29-bit ID field, respectively, as keys.  They use the entire ID field, not a 
subfield of the ID field.  It should be possible to register either a C or Lua 
dissector in that table.

> I'm happy if I can use it in the "Decode As" menu, it
> doesn't need to be applied automatically.

You could use dissector_add_for_decode_as() for a C dissector, or 
dissectortable:add_for_decode_as() for a Lua dissector, to register in the 
"can.subdissector" table; using "Decode As..." to specify that dissector would 
cause all undissected CAN data to be passed that data.
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] Where to find documentation about the formats when to read pcapng data with python?

[Guy Harris]

On Jan 25, 2023, at 6:31 AM, Maynard, Christopher via Wireshark-users 
 wrote:

> I think the best place for pyshark support is over at 
> https://github.com/KimiNewt/pyshark/discussions

And at whatever documentation is provided at

https://github.com/KimiNewt/pyshark

and the "extended" documentation at

http://kiminewt.github.io/pyshark/

The questions being asked here are questions about pyshark, and what it does 
with the packet dissections it gets from TShark, so there's not much 
information you'll be able to get from people familiar with Wireshark/TShark 
but not pyshark.
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] Where to find documentation about the formats when to read pcapng data with python?

[Guy Harris]

On Jan 24, 2023, at 12:37 AM, DIETZ Alexander  
wrote:

> I am very new to wireshark and the pcapng data format used to save wireshark 
> recorded data. I want to read that data with python using the “pyshark” 
> module, but I cannot find proper documentation on the data format(s). The 
> only “extended” documentation I could find is here
>  
> https://kiminewt.github.io/pyshark/
> 
> which I would not consider as extended at all, as the documentation on the 
> data format seems to be missing?
> 
> Is there some other place where the formats of the packages, the layers etc. 
> is described in more detail?

Pcapng files, like pcap files, Sniffer files, Network Monitor files, etc., are 
sequences of one or more records, in a particular format.  Packet records 
contain metadata such as packet lengths and time stamps, as well as a blob of 
raw data.

The blob of raw data may contain additional metadata, followed by raw packet 
data.

Do you want the format of the records in those files described, do you want the 
format of the raw data blobs described, or both?

From "the formats of the packages, the layers etc." it sounds as if you want 
the format of the raw data blobs described.  For example, if the packets are 
Ethernet packets, they begin with a 14-byte Ethernet header; if the type/length 
field in the Ethernet header has a type value rather than a length value, the 
type value indicates the type of packet that follows the 14-byte header.  A 
value of 0x0800, for example, means that the packet is an IPv4 packet, which 
begins with a header as described by RFC 791, and so on.
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] Why does wireshark decode AMB-WR data as "Octet-Aligned Mode" instead of "Bandwidth-Efficient Mode"?

[Guy Harris]

On Sep 21, 2021, at 1:17 AM, Nan Xiao  wrote:

> I have an original pcap file whose RTP payload type is AMR-WB, and it
> uses "Octet-Aligned Mode" to encode data. Then I just changed the
> octet-align from 1 to 0 in SIP/SDP message (The 1st packet, fmtp:123
> octet-align=0), and hope the wireshark can assume the data as
> "Bandwidth-Efficient Mode", but the wireshark still decodes the AMR-WB
> encoding as "Octet-Aligned Mode".

The AMR dissector currently has no mechanism by which it can get an indication 
of whether octet-aligned or bandwidth-efficient mode is used, other than by a 
preference setting for the AMR protocol.

You can work around this in Wireshark by opening up the Preferences dialog, 
opening up the "Protocols" list, going to the "AMR" entry in that list, and 
setting the "Type of AMR encoding of the payload" to "RFC 3267n BW-efficient".

If you want the AMR dissector to get that information from the SIP messages 
used to set up the conversation (if those messages are available!), please file 
an enhancement request at

https://gitlab.com/wireshark/wireshark/-/issues

Attach your capture to the issue.
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] whois,traceroute,ping

[Guy Harris]

On Sep 4, 2021, at 4:03 PM, Dr Jean-Michel Collard  
wrote:

> I have another simple question and afterwards I stop posting :

Questions should be sent to the mailing list, or asked on

https://ask.wireshark.org/

rather than sent to individuals.

> Why does Wireshark display Ipv4/v6 addresses instead of hostnames?

There can be several reasons, but one reason could be that Wireshark's "resolve 
host names" option is turned off.

> Maybe it can be changed but I don't know where.

Select "Name Resolution" from the View menu, and make sure that "Resolve 
Network Addresses" has a checkmark next to it.  If it doesn't, select it, to 
turn it on.
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] whois,traceroute,ping

[Guy Harris]

On Sep 4, 2021, at 7:37 AM, Dr Jean-Michel Collard  
wrote:

> I have a very simple question :
> 
> When one right clicks on a packet we have a LOT of options.
> 
> I couldn't find a whois,traceroute,ping option.
> 
> It's been months that I have been looking for it.

Simple answer: you can't find something that isn't there.  We don't have any 
such network tools built into Wireshark.
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] any examples of how to hook up Lua dissector to user_dlt tree?

[Guy Harris]

On Sep 2, 2021, at 12:05 AM, Ariel Burbaickij  
wrote:

> this type of issue is IMHO better solved through having a link to a more 
> in-depth explanation if somebody cares/wants/has to read it rather than 
> deciding for them beforehand what they need to know and what they don't.

*ANY* documentation is going to "decide beforehand what the reader needs to 
know and what they don't".  For example, our documentation probably will not 
include:

an explanation of Mendelian inheritance;

an explanation of the quantum double-slit experiment;

an explanation of question time in the British parliament;

and so on.  It probably won't even, in a section about registering to dissect a 
given link-layer type, give an explanation of what P and NP problems are.

I.e., we're not going to, for example, dump out the entire Wikipedia and insert 
it at that point.  We're probably not even going to give a link to the 
Wikipedia, or to its pages about the topics I listed above.

> In my example as dissector writer I do not care too much obviously why it 
> happened once I hooked up properly to wtap_encap but in retrospect it was 
> interesting to understand why I spent some half a day in vain trying to 
> utilize "user_dlt"  ;-).

The only explanation needed there, and the only explanation that would in any 
way improve the answer, would be something such as:

Wireshark has its own set of values for link-layer encapsulation types, 
the WTAP_ENCAP values, independent of the various values used in the different 
types of packet capture files that Wireshark can read.

To dissect a particular link-layer type in capture files, a dissector 
must register itself in a dissector table named "wtap_encap".  For dissectors 
written in C, these values have names of the form WTAP_ENCAP_XXX; for Lua 
dissectors, the names are of the form wtap.XXX, where the XXX is the same for 
both names.

For example, to register a dissector for the USER0 link-layer type, 
which corresponds to the pcap and pcapng LINKTYPE_USER0 type, use 
WTAP_ENCAP_USER0 in a C dissector and wtap.USER0 in a Lua dissector.  Note that 
values used by a particular file format, such as LINKTYPE values, will *not* 
work when used with the "wtap_encap" dissector table, and must *not* be used 
with that dissector table.

> in retrospect it was interesting to understand why I spent some half a day in 
> vain trying to utilize "user_dlt"  ;-).

The reason why it was in vain is that there *is* no "user_dlt" dissector table; 
there is no dissector table just for USERn values, there's just the 
"wtap_encap" table, used for *all* encapsulation types, including Ethernet, 
Wi-Fi, etc..

It would also have failed if you used a LINKTYPE value with "wtap_encap", 
because that's not what Wireshark uses, because no file format supports *all* 
the link-layer types that Wireshark can handle, so there is, for example, no 
LINKTYPE value for some of those link-layer types.

The goal is to tell people what they need to do, not to bore them with a tale 
about various BSDs choosing numerical DLT values differently that isn't even 
relevant, given that you don't use those values to register to dissect a 
link-layer type - the difference between LINKTYPE and DLT values is the 
difference between two set of values, *neither* of which will ever work in this 
context.
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] any examples of how to hook up Lua dissector to user_dlt tree?

[Guy Harris]

On Sep 1, 2021, at 1:33 PM, Ariel Burbaickij  wrote:

> thank you very much for your detailed explanations. RIght now OpenBSD is 
> nowhere in the chain but there are some scenarios plausible where it might 
> become part of it. So, if somebody is going to update the Developers' Guide 
> with how user_dlt/wtap_encap for dissector purposes is handled, then why part 
> of it should include the explanations you provided, I reckon.

The only Wireshark developers who have to know or care about LINKTYPEs are:

people adding support for a new LINKTYPE value in the pcap and pcapng 
reading/writing code;

people adding support for that new value in the pcap and pcapng file 
dissectors and in dissectors for protocols that send LINKTYPES over the wire, 
such as the recap protocol.

People adding *dissector* support for a new WTAP_ENCAP do not need to know 
about it, other than "don't use the LINKTYPE numerical value when registering 
in the wtap_encap dissector table".

None of those people need to know the history of why there are separate 
LINKTYPEs and DLTs.
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] any examples of how to hook up Lua dissector to user_dlt tree?

[Guy Harris]

On Sep 1, 2021, at 12:27 AM, Ariel Burbaickij  
wrote:

> thank you for your  detailed answer, I figured the practical part, i.e. not 
> the part related to the design rationale of it myself, as you have seen, was 
> not too complicated, either. And now your answer explained  the design 
> rationale too.   Would be good, maybe, to have this answer, together with 
> some examples, included in the guide or some tutorial, as I see it, as this, 
> maybe somewhat obscure, to the general audience at least, topic, is 
> underrepresented there, no ?

I'd say the LINKTYPE/DLT stuff doesn't really belong in Wireshark documentation 
other than 1) "don't use them to register in the wtap_encap table" and "if 
you're adding support for a newly-assigned LINKTYPE value, here's how you do 
it".  The pcap-linktype man page says:

   For  a  live  capture  or ``savefile'', libpcap supplies, as the return
   value of the pcap_datalink(3PCAP) routine, a value that  indicates  the
   type  of link-layer header at the beginning of the packets it provides.
   This is not necessarily the type of link-layer header that the  packets
   being  captured  have on the network from which they're being captured;
   for example, packets from an IEEE 802.11 network might be  provided  by
   libpcap  with  Ethernet headers that the network adapter or the network
   adapter driver generates from the 802.11 headers.  The names for  those
   values begin with DLT_, so they are sometimes called "DLT_ values".

   The  values  stored in the link-layer header type field in the savefile
   header are, in most but not all cases, the same as the values  returned
   by pcap_datalink().  The names for those values begin with LINKTYPE_.

   The  link-layer  header  types  supported  by  libpcap are described at
   https://www.tcpdump.org/linktypes.html .

which indicates where LINKTYPE values are used and where DLT values are used, 
and that they're not always the same.

(It doesn't indicate *why* they're not always the same, but most people 
probably don't want to waste their times reading me explaining - and 
complaining! - that DLT_RAW being 14 in OpenBSD and 12 everywhere else, and 
that this means that *neither* value should be used in capture files to 
indicate "raw IP" packets, because both values are used for purposes other than 
"raw IP" on some platforms, meaning *neither* of them can be relied on to 
indicate "raw IP" without either ugly heuristics or the user having to indicate 
what the link type means, so I'm not sure that needs to be indicated. :-))

The Wireshark Developer's Guide doesn't have anything on how, in a C dissector, 
to register a dissector for a given link-layer type; it does have documentation 
on how to do that in a Lua dissector in section 10.3 "Example: Dissector 
written in Lua", but it doesn't give more details on the namespace for wtap.* 
values.
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] any examples of how to hook up Lua dissector to user_dlt tree?

[Guy Harris]

> On Aug 31, 2021, at 10:37 PM, Ariel Burbaickij  
> wrote:
> 
> Hello Christopher, all,
> as I wrote "... to write Lua dissector...", so instructions what and how to 
> do on command line do not apply in this case. Meanwhile, I figured out by 
> myself how this is supposed to work:
> 
> local udlt = DissectorTable.get("wtap_encap")
> udlt:add(wtap.USER1, ypp)
> 
> why not to stick to one naming convention of user_dlt

An explanation of various link-layer type indicators:

Wireshark can read several file formats; they do not all use the same numerical 
values for any given link-layer type.

pcap and pcapng files use the LINKTYPEs specified on

https://www.tcpdump.org/linktypes.html

The numerical values in that file appear in the headers of pcap files and the 
Interface Description Blocks of pcapng files.

libpcap uses DLTs in its APIs.  DLTs are *not* guaranteed to have the same 
numerical values on all platforms; historically, various OSes have given some 
DLTs different values on different OSes, so no program should depend on the 
numerical value; libpcap preserves that, for binary compatibility.

The LINKTYPEs were created to provide values that *would* be guaranteed to be 
the same, no matter what platform the file is written on; libpcap maps between 
LINKTYPEs and DLTs.

No current libpcap API uses LINKTYPEs.

Wireshark reads more than just pcap and pcapng files, and some of the files it 
reads have link-layer types for which there is no corresponding LINKTYPE_ 
value.  Therefore, it has its *own* set of link-layer types - those are the 
WTAP_ENCAPs.

There is no guarantee that a WTAP_ENCAP that corresponds to a given LINKTYPE 
has the same numerical value, and there never will be such a guarantee - we 
don't even guarantee that the numerical values of WTAP_ENCAPs will remain the 
same from one Wireshark major release to another.

The APIs Wireshark offers to plugins, whether they're for C or Lua plugins, use 
WTAP_ENCAPs, not LINKTYPEs.  There is, therefore, no guarantee that 148 will 
work as a way to refer to WTAP_ENCAP_USER1, even though the numerical value of 
LINKTYPE_USER1 is 148.  The same applies for all other USERn values from USER0 
to USER15 - use WTAP_ENCAP_USERn, not the numerical value for LINKTYPE_USERn, 
in libwiretap and libwireshark APIs.

The naming convention we use is that, when registering in the "wtap_encap" 
dissector table with the Wireshark encapsulation value WTAP_ENCAP_xxx, you use 
WTAP_ENCAP_xxx in C code and wtap.xxx in Lua code.
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] config problem - not seeing all messages

[Guy Harris]

On May 12, 2021, at 5:17 PM, Jack Jackson  wrote:

> Mirroring is becoming more common on cheaper switches.  I have an 8 port 1 Gb 
> D-Link with that capability that cost somewhat less than $100 3-4 years ago, 
> although the mirroring can't keep up with heavy traffic, there are often some 
> missed messages under load.

We should probably update our page about switches in the Wiki to mention newer 
switches:

https://gitlab.com/wireshark/wireshark/-/wikis/SwitchReference

(or, if there's a page elsewhere that has this information, point to it rather 
than to our Wiki page).

For the benefit of others reading this thread, there's also the Hub Reference:

https://gitlab.com/wireshark/wireshark/-/wikis/HubReference

and the Tap Reference:

https://gitlab.com/wireshark/wireshark/-/wikis/TapReference

and the Ethernet Capture Setup page:

https://gitlab.com/wireshark/wireshark/-/wikis/CaptureSetup/Ethernet

___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] Error when trying to run wireshark-chmodbpf 1.0.2

[Guy Harris]

On Jan 14, 2021, at 5:59 PM, Kok-Yong Tan  wrote:

> The wireshark-chmodbpf script stops at /dev/bpf1.

How do you know that it stops at /dev/bpf1?

The *messages* stop at /dev/bpf1, but those are *not* progress messages, those 
are error messages from the shell.

 The script does *not* print a message for every single BPF device it tries to 
create (by opening it), so if it *succeeds* in opening, for example, /dev/bpf2, 
it will *not* print anything about /dev/bpf2, so the fact that it only prints 
messages about /dev/bpf0 and /dev/bpf1 doesn't mean it stops at /dev/bpf1.

In fact...

> However, there appears to be /dev/bpf0 through /dev/bpf10 in existence when I 
> do a “ls -lu /dev/bpf*” but nothing beyond bpf10.  
> 
> crw-r-  1 root  access_bpf   23,   0 Jan 14 16:57 /dev/bpf0
> crw-r-  1 root  access_bpf   23,   1 Jan 14 16:57 /dev/bpf1
> crw-r-  1 root  access_bpf   23,  10 Jan 14 16:57 /dev/bpf10
> crw-r-  1 root  access_bpf   23,   2 Jan 14 20:50 /dev/bpf2
> crw-r-  1 root  access_bpf   23,   3 Jan 14 20:50 /dev/bpf3
> crw-r-  1 root  access_bpf   23,   4 Jan 14 20:50 /dev/bpf4
> crw-r-  1 root  access_bpf   23,   5 Jan 14 20:50 /dev/bpf5
> crw-r-  1 root  access_bpf   23,   6 Jan 14 20:50 /dev/bpf6
> crw-r-  1 root  access_bpf   23,   7 Jan 14 20:50 /dev/bpf7
> crw-r-  1 root  access_bpf   23,   8 Jan 14 20:50 /dev/bpf8
> crw-r-  1 root  access_bpf   23,   9 Jan 14 20:50 /dev/bpf9

...the existence of those devices, and the fact that they're all owned by the 
access_bpf group, indicates that it did *not* stop at /dev/bpf1!
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] Error when trying to run wireshark-chmodbpf 1.0.2

[Guy Harris]

On Jan 14, 2021, at 5:43 PM, Gerald Combs  wrote:

> I can replicate the "Resource busy" message here by running Wireshark, 
> leaving the welcome screen up and attempting to read from /dev/bpf0:
> 
> 
> $ read -n 0 < /dev/bpf0 > /dev/null 2>&1
> bash: /dev/bpf0: Resource busy
> 
> 
> However, that's just a result of Wireshark updating the interface sparklines 
> via `dumpcap -S`,

Not necessarily:

$ read -n 0 < /dev/bpf0 > /dev/null
-bash: /dev/bpf0: Resource busy
$ ps -ef | egrep -i 'tcpdump|shark|dumpcap'
  501 95591 32227   0 10:00PM ttys1140:00.00 egrep -i 
tcpdump|shark|dumpcap

and that's because:

$ sudo lsof /dev/bpf0 /dev/bpf1
Password:

...

COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
airportd 344 root 41u CHR 23,0 0t0 580 /dev/bpf0
airportd 344 root 42u CHR 23,0 0t0 580 /dev/bpf0
airportd 344 root 43u CHR 23,1 0t0 581 /dev/bpf1
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] [Wireshark-dev] GitLab migration update

[Guy Harris]

On Aug 23, 2020, at 10:42 PM, Gerald Combs  wrote:

> On 8/23/20 9:59 PM, Guy Harris wrote:
>> On Aug 23, 2020, at 9:33 PM, Gerald Combs  wrote:
>> 
>>> You can still comment on Gerrit changes, but it should otherwise be 
>>> read-only. SSH access is still enabled for now in order to make it easier 
>>> to migrate changes. I'll shut it off in the next couple of weeks.
>> 
>> Does "it" mean "Gerrit" or "SSH access to Gerrit"?
> 
> SSH access. I don't have a definite shutdown date for Gerrit, but it won't be 
> for a while.

There's some potentially useful historical information there, when trying to 
research why a change was made.

Is there a way to convert the Gerrit URLs in the issue database to 
corresponding commits in the repository?

>> Where is the link to the issues database from 
>> https://gitlab.com/wireshark/wireshark?  GitHub has one on the top-level 
>> page for GitHub repositories.
> 
> There should be an "Issues" link in the left sidebar. The direct link is 
> https://gitlab.com/wireshark/wireshark/issues.

It's there, but the GitLab folks are not the best icon designers on the planet. 
 The icon looks like a coffee cup, or a side view of a mailbox with the door 
opened up, or whatever.  (And what does a rocket have to do with continuous 
integration?)

___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] [Wireshark-dev] GitLab migration update

[Guy Harris]

On Aug 23, 2020, at 9:33 PM, Gerald Combs  wrote:

> You can still comment on Gerrit changes, but it should otherwise be 
> read-only. SSH access is still enabled for now in order to make it easier to 
> migrate changes. I'll shut it off in the next couple of weeks.

Does "it" mean "Gerrit" or "SSH access to Gerrit"?

> Bugzilla should be read-only as well. Each Bugzilla bug should have a 
> matching entry at https://gitlab.com/wireshark/wireshark/issues

The issue number of the most recent Wireshark bug appears to be the same as its 
Bugzilla bug number; is that a property true for all bugs?

Where is the link to the issues database from 
https://gitlab.com/wireshark/wireshark?  GitHub has one on the top-level page 
for GitHub repositories.
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] [Wireshark-dev] The Wireshark wiki has a new home

[Guy Harris]

On Aug 11, 2020, at 8:52 PM, Guy Harris  wrote:

> So how do we edit a Wiki page?  I'm logged into my gitlab.com account, but I 
> don't see, for example, an "Edit" button.

OK, it worked for me (the capture setup page for Wi-Fi now says "newer Macs may 
require you to disassociate from the network before capturing in monitor mode, 
otherwise you won't see any traffic"), but I'm a core developer, so that 
doesn't help everybody else.

Do the "how to edit" instructions on the Wiki now apply?

(And what's that "-" component of the URL?  Is that a GitLab feature?)
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] [Wireshark-dev] The Wireshark wiki has a new home

[Guy Harris]

On Aug 12, 2020, at 12:44 PM, Roland Knall  wrote:

> I agree that this is not ideal. I would opt for a second project. MoinMoin is 
> really not good anymore from an op-sec point of view

...and my MediaWiki-trained brain hurts every time I edit it.  Markdown may 
also not be the same as MediaWiki markup, but I'm also using it for the 
GitHub-based libpcap and tcpdump projects' issue and pull request lists, so my 
brain may hurt less when using it.
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] [Wireshark-dev] The Wireshark wiki has a new home

[Guy Harris]

On Aug 11, 2020, at 5:18 PM, Gerald Combs  wrote:

> As part of our larger GitLab migration effort I've migrated the Wireshark 
> wiki to its new home at
> 
> https://gitlab.com/wireshark/wireshark/-/wikis/home
> 
> There's still a fair amount of post-migration work to do (for instance the 
> "HowToEdit" is specific to our old wiki), but the new wiki should be faster 
> and easier to edit, particularly if you're familiar with Markdown.

So how do we edit a Wiki page?  I'm logged into my gitlab.com account, but I 
don't see, for example, an "Edit" button.

___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] Installing wireshark on MacOS Catalina via brew

[Guy Harris]

On Mar 10, 2020, at 3:38 PM, varun siripurapu  wrote:

> How do I exit out of tcpdump which is passing the packets to wireshark 
> without closing wireshark application?
> 
> `varuns@varuns ~ %  "tcpdump -c 30 -s 0 -U -n -w - -i et3_5_1" | wireshark -k 
> -i -

Don't run tcpdump in the first place; just do

wireshark -k -i et3_5_1 -c 30

Note: -s 0 is unnecessary in macOS's tcpdump (and in most recent versions of 
tcpdump), as well as in Wireshark, and -n is unnecessary if you're using 
tcpdump to write to a capture file.
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] Installing wireshark on MacOS Catalina via brew

[Guy Harris]

On Mar 10, 2020, at 2:53 PM, varun siripurapu  wrote:

> Awesome. It worked Guy!

Note that Wireshark.org's Wireshark 3.2.x packages include installers for files 
that will put /Applications/Wireshark.app/Contents/MacOS into your path (it 
won't do so for *existing* Terminal windows, but all Terminal windows opened 
after that will pick it up automatically).
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] Installing wireshark on MacOS Catalina via brew

[Guy Harris]

On Mar 10, 2020, at 2:19 PM, varun siripurapu  wrote:

> I installed Wireshark using "brew cask install Wireshark" successfully on Mac 
> OS Catalina as you could see below.

We don't prepare the Homebrew packages, the Homebrew people do.

> I do see that Wireshark.app is present in Applications directory
> 
> `varuns@varuns /Applications % ls | grep -i Wire
> Wireshark.app`

ls -ld /Applications/Wireshark.app

would suffice here.

> But, I see that Wireshark is not installed.
> 
> varuns@varuns ~ % which Wireshark
> Wireshark not found

It would be "not installed" if 
/Applications/Wireshark.app/Contents/MacOS/Wireshark is missing.

If it's *not* missing, then...

> Could someone let me know what is missing here?

.../Applications/Wireshark.app/Contents/MacOS is missing from your $PATH 
setting.
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] Ethernet padding in tcpdump captures?

[Guy Harris]

On Nov 4, 2019, at 6:30 AM, Andreas Sikkema  wrote:

> I have this weird problem filtering out empty UDP messages on my (Linux) 
> firewall and in the captures I noticed something I haven't seen before. 
> 
> If I capture the traffic using tcpdump and open the files using Wireshark, I 
> see Ethernet padding on the messages the firewall doesn't appear to match. 
> 
> Since the UDP messages are empty they are below the 64bytes minimum Ethernet 
> length so padding is to be expected on the wire, but I have never before seen 
> Ethernet padding in captures made on PC hardware running Linux. Is this 
> common?

Unless Linux is removing the padding before the packet gets to a PF_PACKET 
socket, I would expect to see padding for short Ethernet packets in captures on 
Linux, at least if not done on the "any" device.  For *outgoing* packets, you 
probably won't see the padding, but for *incoming* packets, I'd expect to see 
the padding on all OSes.
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] Problem with WinDump

[Guy Harris]

On Oct 29, 2019, at 4:53 AM, Cristian Soto  wrote:

> I’m having some issues with WinDump not showing the VLan although with 
> WireShark I get it.

WinDump is based on an older version of tcpdump that didn't understand that 
particular CDP TLV; the current version of tcpdump does, but there's nobody I 
know of providing a binary version of that for Windows.
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] 5G NR-RRC dissector issue

[Guy Harris]

On Oct 24, 2019, at 11:29 AM, Keval Malde  wrote:

> I am trying to dissect 5G NR RRC MIB paket but it is not working, any 
> possible help would be appreciated. Please find the attachment below.

What is the payload of that UDP packet supposed to be?

Is there some "NR RRC over UDP protocol" being used?
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] accessibility of Wireshark

[Guy Harris]

On Oct 9, 2019, at 8:11 AM, RJ Sandefur  wrote:

> Does wireshark use python?

No.
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] "apply/prepare filter" from the protocol column context menu unavailable

[Guy Harris]

On Jul 20, 2019, at 12:29 PM, phreakocious  wrote:

> Thank you for the detailed reply.  I'll file the bug.
> 
>> That's only inconsistent or unintuitive to people who somehow think that 
>> popping up a context window on a column that says "TCP" should do anything 
>> other than apply a display filter of "tcp".
> 
> They are out there, I assure you. 

They don't understand that their *real* complaint is that the column says "TCP" 
rather than "HTTP" or "NFS" or "SMB" or "SMTP" or... - if they think that 
requesting a display filter for an ACK to a TCP segment containing HTTP traffic 
should give "http" as the filter, presumably that means they think the packet 
is "really" HTTP.  And I think people *have* asked for that.

And perhaps what's really needed there is the ability to look at network 
traffic from multiple different protocol layers, so that you could, for 
example, have a view that would show one row in the packet list for each HTTP 
request/reply, or each NFS request/reply, or each SMB request/reply, or..., so 
that

1) transport-layer-only packets (such as ACK-only packets in TCP) 
wouldn't appear;

2) packets dissected only at layers below the transport layer (such as 
most fragments of a fragmented IP datagram) wouldn't appear;

3) if there are multiple requests or replies in a single TCP segment, 
they would have *separate* rows in the summary list;

4) if a request or reply takes multiple TCP segments, it would take up 
only one row in the summary list;

etc..
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] "apply/prepare filter" from the protocol column context menu unavailable

[Guy Harris]

On Jul 19, 2019, at 11:41 AM, phreakocious  wrote:

> Hello, as mentioned in the subject, these menu options are disabled in the 
> packet list.  My (probably flawed) muscle memory insists that it worked at 
> some point.  The other columns work fine so it seems to be intentional.

Never attribute to intent that which can be explained by "whoops, I guess that 
doesn't work, maybe we need to do that differently".  Copy -> As Filter in the 
Protocol column is disabled in a recent master build if you've just read in a 
file, but if I go to the packet details pane, select a field, use Copy -> As 
Filter on that field, and then go back to the Protocol column, it's re-enabled 
- it still doesn't *work*, but it's re-enabled.

This code needs some work, both for the enabling and for the "still doesn't 
work".

The former may be due to the filter-related menu actions being "shared" between 
the packet list and packet detail panes, which they probably shouldn't be, 
given that they're *not the same actions* - the packet list ones deal with 
filters for *columns*, the packet details ones deal with filters for *fields*.

The latter appears to be due to the fact that we simply don't *set* a filter 
expression for the Protocol column, and may never have done so (so your muscle 
memory may, indeed, be flawed).  That column is currently just set as text by 
dissectors; we'd have to add a separate API for setting the protocol column, 
allowing the column filter to be set, and change the dissectors to use that.

>  My gut says it's due to inconsistent/unintuitive behavior in cases like an 
> ACK, where filtering by protocol would result in all TCP.

That's only inconsistent or unintuitive to people who somehow think that 
popping up a context window on a column that says "TCP" should do anything 
other than apply a display filter of "tcp".

> This is a bit annoying, but debatably less so than the back and forth 
> movement to the details view to filter simpler things like ARP, DHCP, (M)DNS, 
> etc.  
> 
> Given that it's probably just as hard to whitelist the simple protocols as to 
> blacklist the complex ones, maybe it could just be a global option to enable 
> that function for all protocols?

Or maybe it has nothing to do with deliberate disabling for the Protocol 
column, but has to do with

1) bogosity in the UI code causing the enabled status in the packet 
list pane tracking the enabled status in the packet details pane

and

2) not having written the necessary mechanisms to add a filter 
expression for the Protocol column (which isn't necessarily the result of a 
deliberate decision that it *shouldn't* support a column filter).

Please file a bug on the "disabled in the packet list" part, so we can get that 
fixed first; that's just a bug.  Then we can file a separate enhancement to 
allow filtering on the Protocol column.
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] How to disable lua support from command line ?

[Guy Harris]

On Jul 2, 2019, at 11:15 PM, Matt  wrote:

>> you can't control environment variables?  Why not?
> oh I can, that's what I am doing right now (overriding
> XDG_CONFIG_HOME) but it's harder to get right on all platforms,

Why wouldn't that work on all platforms?  Is the concern that you might not 
have a location to point XDG_CONFIG_HOME at that's guaranteed not to have 
plugins on any of the machines you're using?

It might not work on Windows, but that's probably not the only thing to do 
differently on Windows.

> hence
> my wish for a wireshark flag.
> 
>> There's no reason to disable *system* plugins; we're talking about *usr* 
>> plugins.
> Can an admin install additionnal systen plugins ?

Yes - either compiled *or* Lua plugins, so I don't see a need to treat compiled 
and Lua plugins differently.
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] How to disable lua support from command line ?

[Guy Harris]

On Jul 2, 2019, at 8:17 PM, Matt  wrote:

> @Peter thanks for the advice on lua scripts, but this is something I
> can't control on foreign (i.e., user) setups.

You can control the command-line flags but you can't control environment 
variables?  Why not?

> I just thought that wireshark installs by
> default some C module/extensions contrary to lua scripts (none by
> default), but I may be wrong, on that point.

Wireshark installs plugins *as part of the Wireshark installation* by default.  
*Currently*, they happen to be compiled plugins; that's not guaranteed t be 
true forever.

Wireshark installs *no* per-user plugins of any sort.

There's no reason to disable *system* plugins; we're talking about *usr* 
plugins.
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] How to disable lua support from command line ?

[Guy Harris]

On Jul 2, 2019, at 12:22 AM, Matt  wrote:

> I am inspired by the www.nixos.org philosophy which ensures
> reproducibility by being as explicit as possible. In my case, I try to
> specify as much as I can when calling tshark so I am not too worried
> about any .config/wireshark/config interference.

For .config/wireshark/preferences not to matter, you'd have to specify 
everything that's changed from the default.

> To sum up, yes. Might make sense to have a flag for lua and another
> for C modules or some kind of enum.

Why?  Why not just one option to turn them all off?
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] How to disable lua support from command line ?

[Guy Harris]

On Jul 1, 2019, at 8:34 PM, Matt  wrote:

> I want my program to determistically run on other computers as well,
> thus I can't assume anything in advance about users' lua script. I had
> not really thought about compiled plugins but that's the same issue,
> these optional modules may alter the way my program expects tshark to
> behave.

I.e., you want a "disable all user plugins" option.

If you *really* want the program to run deterministically for all users, you 
also need a "disable the user's personal configuration" option.

> I believe for my usecase, the best is to wrap the tshark call with an
> XDG_CONFIG_HOME pointing nowhere or to a vanilla wireshark config. Not
> sure if there is any difficulty though, I will have a try.

As long as the "other computers" aren't running Windows, where XDG_CONFIG_HOME 
has no effect
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] How to disable lua support from command line ?

[Guy Harris]

On Jul 1, 2019, at 7:19 PM, Matt  wrote:

> Lately I've been experimenting with the lua support (I had not
> realized how fantastic it was, I am really looking forward to
> implementing some of the options I wanted but couldn't upstream !).
> The downside is that my lua scripts now interfere with a program that
> launches tshark to generate a csv file of pcap.

It sounds as if what you *really* need is to have one or more of *your scripts* 
disabled.

This is not necessarily an issue specific to Lua scripts; a compiled plugin 
could cause similar problems.

Perhaps we need an option to disable particular plugins by name in TShark and 
some GUI option to disable them in Wireshark.

*If* your plugin (whether Lua or compiled) is a dissector, and it adds a *new* 
protocol, you should be able disable it with the --disable-protocol 
command-line option, specifying its protocol by name.
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] (Is this message being received by anyone?) How to interpret RTT graph

[Guy Harris]

On Mar 28, 2019, at 12:37 PM, Guy Harris  wrote:

> Wireshark *does* have a question-and-answer site, but that's not a forum - a 
> Q site is a crowdsourced FAQ, where the goal is to *avoid* discussion as 
> much as possible by making it possible for people to find questions that have 
> already been asked and answered, so they just have to read the answer, rather 
> than post a question and wait for the answer.  That's why, for example:

...

if a question is asked in a comment on the original question, in order, 
for example, to get more information required to answer the question but not 
present in the original question, the answer to that question should be posted 
as a subsequent comment to the original question, *NOT* as an answer to the 
original question, and why we'll change an "answer" that doesn't answer the 
original question into a comment - an answer, on a Q site, should be an 
answer to the original question;

if a question is asked in a comment on an answer, in order, for 
example, to get details of the answer explained better, the answer to that 
question should be posted as a subsequent comment on that answer.

Note also that you can edit your own question, so that, if a comment is posted 
asking for more details, you can put the details in your question - just post a 
comment saying you've updated the question.  That way, the original question 
can be read by others, to see whether it's the same question as the one to 
which they're looking for an answer.
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] (Is this message being received by anyone?) How to interpret RTT graph

[Guy Harris]

On Mar 28, 2019, at 11:58 AM, Shawn Carroll via Wireshark-users 
 wrote:

> I received it! I think most people have moved to an online forum-I forget the 
> details, but perhaps someone else can chime in with them for us? Thanks! :)

I'm unaware of any online forum for Wireshark.

Wireshark *does* have a question-and-answer site, but that's not a forum - a 
Q site is a crowdsourced FAQ, where the goal is to *avoid* discussion as much 
as possible by making it possible for people to find questions that have 
already been asked and answered, so they just have to read the answer, rather 
than post a question and wait for the answer.  That's why, for example:

when an unrelated question is asked in a comment, we say it should be 
asked separately (with the old Q software, we could turn it *into* a 
question, and did);

we edit unclear question titles to make it clearer what's being asked.
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] Packet Bytes panel column width

[Guy Harris]

On Feb 10, 2019, at 9:54 AM, Lucas Brasilino  wrote:

> Is there a way to change the 'bytes column width' in Packet Byte Panel from
> default 16 bytes per line to, say, 4 or 8 bytes per line?

No, there isn't; that was chosen, I think, because, with 16 bytes per line, the 
low-order nibble of the offset in the data represents which of the 16 octets in 
the row is the octet in question, and the low-order octet in the offset at the 
left-hand edge of the display is always 0.

If you'd like an option to configure the number of bytes per line, please file 
an enhancement request at http://bugs.wireshark.org.
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] unrecognized command line option '-fmacro-prefix-map=old=new'

[Guy Harris]

On Jan 26, 2019, at 9:19 AM, Jaap Keuter  wrote:

> 2. What you’ve shown is a text stage of CMake to find compiler options, these 
> are not Wireshark build errors.

Yes.  "CMakeError.log contains errors" is not a build failure; with any given 
CMake-using project, you *might* happen to be lucky enough that *all* 
command-line flags being tested happen to work on the compiler you're using and 
that *all* symbols/functions/etc. happen to be available and that *all* of the 
structure being tested have the structure member being tested for and..., but 
the chances of that are rather slim on a cross-platform project.

"CMakeError.log contains errors" is the CMake equivalent of "config.log 
contains errors" for autotools.  The standard output and error of CMake will 
report the test errors that are build errors rather than "not on this platform" 
test failures, just as the standard output and errors of an autotools configure 
script will report the test errors that are build errors rather than "not on 
this platform" test failures.
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] Developing a disector in Lua

[Guy Harris]

On Jan 13, 2019, at 11:56 AM, jannis.oh...@ostfalia.de wrote:

> I want to develop a disector in Lua for a L2 IOT radio  Protocol.
> 
> I already looked at the disector. lua example.
> 
> since i want to  register my disector using the DissectorTable.get()
> method i looked in the documentation but i could not find a list of
> valid table names.

It's not listed in the documentation, but a list can be generated by running 
TShark.  The TShark manual page documents the "-G" option, which dumps various 
tables internal to Wireshark/TShark:

   −G  [  ]
   The −G option will cause Tshark to dump one of several types of
   glossaries and then exit.  If no specific glossary type is
   specified, then the fields report will be generated by default.
   Using the report type of help lists all the current report types.

   The available report types include:

...

   dissector‐tables  Dumps a list of dissector tables to stdout.
   There is one record per line.  The fields are tab‐delimited.

* Field 1 = dissector table name, e.g. "tcp.port"
* Field 2 = name used for the dissector table in the GUI
* Field 3 = type (textual representation of the ftenum type)
* Field 4 = base for display (for integer types)
* Field 5 = protocol name
* Field 6 = "decode as" support

> Since I am on L2 i would  have to register on the encapsulation type of
> the captured packet

So, as this is a link-layer protocol (presumably that's what you mean by L2, 
i.e. the data link layer in the OSI model), presumably there isn't some other 
protocol on top of which it runs, and the encapsulation type would be the 
encapsulation type in the capture file.

If there's already a link-layer type in Wireshark for your protocol, you would 
register in the "wtap_encap" table using the WTAP_ENCAP_ name, but with 
"WTAP_ENCAP_" removed - those are defined in init.lua.

If there *isn't* already a link-layer type in Wireshark for your protocol, you 
would have to add one - and make the code for whatever file format your packets 
are stored in support that new encapsulation type; that would involve changing 
the core Wireshark code, not just adding new Lua code.

If there isn't already code for whatever file formats your packets are stored 
in, you'd have to add that as well - *that* can be done in Lua or C.
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] capture not seeing packets

[Guy Harris]

On Jan 5, 2019, at 4:09 PM, Alan Partis  wrote:

> What drives the lights?  I don't have that degree of detail handy, but I
> guess the question I'd have to ask is this: is there a way to get
> Wireshark to _see_ runts or packets with invalid CRC, or other errors?
> I recognize that you're asking if there's a way to get the ethernet
> adapter to supply this info, so I'm going to assume that either way, it's
> not a function of Wireshark.

It's not, except to the extent that some hardware *might* have a "supply bad 
packets to the host" option and some drivers *might* enable that option if you 
ask them to put the device into promiscuous mode; if those are the case, all 
Wireshark could do would be to capture in promiscuous mode.

You'd have to determine what type of interface is on your laptop and whether 
the driver does that.  This would probably be easier for Linux or *BSD than 
for, say, Windows or macOS, as it's easier to figure this out for open-source 
drivers.

(In a better world, all OS kernel capture mechanisms - or mechanisms atop which 
capture mechanisms can be built, such as NDIS on Windows - would offer, for 
wired shared-medium LAN adapters, both "promiscuous" mode, which provides all 
good packets seen by the adapter even if they're not directed to the host but 
discards bad packets and doesn't provide the CRC as part of the packet data, 
and "sniffer" mode, which provides all packets, good or bad, seen by the 
adapter, and provides the CRC as well as error flags such as runt, bad CRC, 
etc..  Sadly, we don't live in that world.

Of course, once you get to switched networks, you probably also have to 
configure a monitor port on which you do sniffing, and the switch would have to 
pass on bad packets to that port, or you'd have to use a tap.  But I 
digress)
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] capture not seeing packets

[Guy Harris]

On Jan 5, 2019, at 9:53 AM, Alan Partis  wrote:

> I've got a case where I'm certain there are packets on the wire, but I'm
> not able to pick them up in wireshark/tshark (or from tcpdump and dumpcap
> either for that matter).
> 
> The setup:
> 
> a device (that is currently under development -- I'm the developer)
> appears to be flooding the network with some kind of packet, but the
> device itself appears to be off line i.e. `ip addr` reports no address for
> the interface and indicates that its 'state' is down.  The packet flood is
> enough to DOS the rest of my LAN (unless I segregate or isolate it) and
> the flood stops when I disconnect the device from the LAN.
> 
> 
> The evidence:
> 
> * the local switch shows flashing activity lights on the port
>   the device is connected to.
> * I've inserted a sharktap device in-line between the device and the
>   switch -- activity lights flash on all ports there as well.

What drives those lights?

I.e., do they light up if:

a runt packet is seen;

a packet with an invalid CRC is seen;

other low-level packet errors occur?

> The problem:
> 
> * I can't sniff these packets.

On the machine on which you're sniffing:

can the Ethernet adapter supply packet events for runt packets/packets 
with an invalid CRC/other errors?

if so, does the driver in the OS for that machine put the adapter into 
that mode when you tell the driver to put the adapter into promiscuous mode (I 
think some drivers do)?

> I have command line/console access on the device itself, but running
> tcpdump there doesn't show the packet flood.  I presume this is because
> the ethernet driver is not reporting anything back to the kernel because
> it thinks it's down.

You'd have to look at the driver, or ask the vendor about it if it's not 
open-source, to see if that's the case.

What OS is the device running?  (I'm guessing it's probably running some OS, 
probably UNIX-like but possibly Windows, given that you mention tcpdump.)

If the interface is configured down, does the code path from whatever code 
would send packets to the point at which packets are handed to the adapter (not 
the driver, the adapter, so this code path includes the driver) still function 
on that OS with that driver?

If so, where is the "looping back" for receiving transmitted packets done?  I 
think it's done above the driver in Linux, but done in the driver in 
BSD-flavored OSes.
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] MPLS over UDP decoding

[Guy Harris]

On Dec 28, 2018, at 2:36 PM, Yang Yu  wrote:

> On Fri, Dec 28, 2018 at 1:07 PM Guy Harris  wrote:
>> From looking at the code, the logic appears to be "is the traffic to or from 
>> UDP port 6635?"
>> 
>> So *is* the traffic to or from UDP port 6635?
> 
> indeed udp.dstport is 6635 (IANA assigned for mpls-udp), so it turned
> out a host was using udp/6635 as ephemeral port to connect to a STUN
> server

So, for this case, follow Hugo van der Kooij's suggestion and disable the MPLS 
dissector.
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] MPLS over UDP decoding

[Guy Harris]

On Dec 27, 2018, at 3:01 PM, Yang Yu  wrote:

> In a packet capture of sFlow export packets, I noticed some sFlow
> samples were decoded as MPLS over UDP. The sFlow sampled packet was
> actually just a UDP VoIP packet with no dissector support.
> 
> What logic does Wireshark use to opportunistically consider UDP
> payload to be MPLS?

From looking at the code, the logic appears to be "is the traffic to or from 
UDP port 6635?"

So *is* the traffic to or from UDP port 6635?
___
Sent via:Wireshark-users mailing list 
Archives:https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
 mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-users] Devices on MAC

[Guy Harris]

Luca Bedogni wrote:

   maybe this could be a really basic question, but when I run  
 wireshark on MAC OS, I can't see any device on any window.

What do the commands

ls -l `which dumpcap`

and

ls -l /dev/bpf*

print if you run them in Terminal?

___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] Summary View Info Column

[Guy Harris]

Stephen Fisher wrote:
 On Fri, Mar 28, 2008 at 11:06:25AM -, Keith French wrote:
 
 In recent versions of Wireshark this behaviour seems to have changed, 
 in that it tries to resolve the source port of the SYN as well. The 
 name it resolves it to (on my PC anyway) is often misleading:-

 qsnet-trans  http [SYN]
 
 This is because we now ship Wireshark with a full services file (port to 
 name mapping) from the IANA.  Windows has one built-in, but it is much 
 shorter than the one we now use.

...and, if Microsoft were to decide to add more entries to their 
services file, you'd have exactly the same problem.

Furthermore, people on at least some UN*Xes already have this problem, 
regardless of *what* version of Wireshark they run:

$ egrep qsnet-trans /etc/services
qsnet-trans 4354/udp# QSNet Transmitter
qsnet-trans 4354/tcp# QSNet Transmitter

and there's no good reason why this is only an issue for Windows users.

This means that not shipping the new services file is *not* a correct 
solution to the problem:

1) it doesn't protect you against Microsoft adding those entries;

2) it doesn't do anything for UN*X users.

 Not unless you want to turn off port name lookups hroughout Wireshark, 
 which can be done in the Name Resolution preferences (transport name 
 resolution).

If this is a serious problem, perhaps we could either supply two 
services files, or flag entries in services files, so we could 
distinguish between common and uncommon well-known port numbers - or 
just distinguish between well-known ports (0-1023) and registered 
ports (1024-49151) - and have an option to resolve only common or 
well-known ports or to resolve uncommon or registered ports along 
with those.
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] Learning to setup WS to see TCP and HTTP

[Guy Harris]

On Mar 26, 2008, at 7:57 PM, Rudyard Wallen wrote:

 OK, some of that went over my head but I think I got the gist. So I
 guess the big question is: Is there a way to see HTTP on this network
 combo of wired and wireless machines that all are connected to this  
 one
 router?

Yes - run Wireshark/TShark, or dumpcap, or tcpdump/WinDump, on the  
machine that's sending out and receiving the HTTP traffic.

You *might* be able to see that traffic from another machine if it's  
wireless traffic and you're capturing on a machine/OS/driver/wireless  
adapter that supports monitor mode (if it's Windows, monitor mode is  
only supported in Vista, and even there it's not supported by WinPcap,  
which is what Wireshark uses to capture traffic on Windows; you could  
also get an AirPcap adapter:

http://www.cacetech.com/products/airpcap_family.htm

and use that, but they're not cheap).

If it's wired traffic (i.e., a machine plugging into an Ethernet  
interface on the WRT54GS), you're probably out of luck, unless the  
WRT54GS supports port mirroring.

 Update: I just connected my laptop via Ethernet to the router. My  
 tower
 is running Wireshark. I see the IP address of my laptop (a Mac) but it
 only shows IGMP, MDNS and UDP packets for that source IP. Could I have
 this thing setup wrong?

IGMP is for managing multicast groups, so at least some IGMP packets  
are probably multicast.

The M in MDNS stands for... multicast, so its packets are multicast.

The other UDP packets you're seeing are probably also broadcast or  
multicast.

I.e., this is the same problem.  You're plugging into a switch, which  
means you aren't necessarily going to see all the traffic passing  
through the switch; a switched Ethernet is different from a  
traditional Ethernet in that fashion.
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] How to get rid of TCP segment of a reassembled PDU messages?

[Guy Harris]

Grant Edwards wrote:
 I'm tracing data in a TCP connection between two devices, and
 about half way through the trace, wireshark stops displaying
 packet info and just shows [TCP segment of a reassembled PDU].
 
 It's _not_ a TCP segment of a reassembled PDU.  It's just a
 stream of bytes.

To what does it refer?  The entire TCP connection is the stream of 
bytes; individual packets are what are reported as TCP segments of a 
reassembled PDU.

The protocol Wireshark thinks the connection is running atop TCP is done 
for which it does reassembly; it appears to think that a packet 
requiring reassembly is in the stream, but, for whatever reason - 
perhaps TCP segments that weren't captured, or perhaps a bug - can't 
finish the reassembly process for that packet.

Try turning the reassembly option off for that protocol (if it has such 
an option in the preferences) or for TCP as a whole.

Could you file a bug on this, and attach a capture that shows the 
problem, so, if there *is* a bug (rather than a missing packet), we can 
try to fix it?  (Even if there is a missing packet, it might be possible 
to get the reassembly code to handle that better.)

 I've told wireshard to not decode that TCP
 stream

What do you mean by not decode?

 but it still refuses to display packet info.  I think
 it's getting confused by packets that aren't part of the TCP
 stream in question.

If they're present in the capture but not part of the stream, that won't 
affect the reassembly (unless there's a bug in the TCP reassembly code).
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] Learning to setup WS to see TCP and HTTP

[Guy Harris]

On Mar 26, 2008, at 2:47 PM, Rudyard Wallen wrote:

 super new to this, but here goes. OK, I have WS running. I am  
 connected
 via ethernet to a Linksys router WRT54GS set for DHCP (I can connect
 wirelessly if need be). Other users connect wirelessly (my laptop for
 instance). Open system, no security.

 I am capturing via the Ethernet card.

 I can see the IP address of my laptop coming up, but under protocols I
 only see UDP and NPNS.

Presumably that's NBNS (which runs atop UDP) and other UDP protocols.

The packets you're seeing are probably all broadcast or multicast  
packets.

 Is there anyway to see TCP and HTTP?

HTTP runs atop TCP, and TCP doesn't use broadcasts or multicasts.   
Only broadcast and multicast packets will show up on all the wired  
ports if they're received by the router.

 Do I need to capture via my wireless NIC?

Unless there's a way to put the wired port into which you're plugging  
the Wireshark machine in a port mirroring mode:


http://wiki.wireshark.org/CaptureSetup/Ethernet#head-5220d760898496c38e928ed3d65ffc8160f6f3a6

you would - and I didn't see anything obvious in the online WRT54GS  
documentation to indicate that you can do that.

I also don't know whether wireless packets would be forwarded to that  
port in any case, although as those packets would be sent *out* an  
Ethernet port to your Internet connection, they might be.

Note that capturing on a wireless adapter probably won't work on  
Windows:

http://wiki.wireshark.org/CaptureSetup/WLAN
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] Ask for cap file including stard fibre channel protocol

[Guy Harris]

zhen li wrote:

I am very excited when finding fibre channel decoding feature in 
 ethereal,
 I wish to see how can ethereal decode fibre channel packets,
 but I can not deviced a cap file including  fibre channel protocol,
 so can you help me to generate  such a file 

Wireshark (that's Ethereal's new name:

http://www.wireshark.org/faq.html#q1.2

) only dissects Fibre Channel when it's encapsulated with:

Cisco's special encapsulations of Fibre Channel frames in Ethernet 
frames (for debugging trace purposes);

CNT's Cross Point Frame Injector encapsulation of FC in UDP packets;

RFC 3821 FCIP;

T11's proposed Fibre Channel over Ethernet encapsulation.

We don't currently support any encapsulation for raw FC frames.

Are you trying to capture a Fibre Channel trace on an FC network (rather 
than an Ethernet or other non-FC network where one of the encapsulations 
listed above are used)?
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] wire shark from the program

[Guy Harris]

Vinay Chilakamarri wrote:
 I thought that Wireshark must have registered itself as one of the 
 environment variables,

I.e., you thought that it would have added the directory containing the 
Wireshark, TShark, etc. executables to the PATH environment variable?
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] wireless lan packet

[Guy Harris]

Daniel Svensson wrote:

 oh, i tought that wireshark could do it anyway?

Wireshark can only do what the network adapter it's using, and the OS 
packet capture mechanism and network adapter driver, allow it to do.

 Is there any other freeware-softwares that do the same thing as airpcap?

AirPcap is hardware, not just software.

It works around an underlying problem with Windows, namely that the 
networking mechanisms in Windows prior to Windows Vista don't do a very 
good job of supporting packet capture on 802.11 devices.

If you're running Windows prior to Vista, the chances are unfortunately 
very good that the driver doesn't support promiscuous mode, which means 
that you won't be able to run in promiscuous mode while associated with 
the access point's network, and the chances are *certain* that the 
driver doesn't support monitor mode.

If you're running Vista, Microsoft Network Monitor:


http://www.microsoft.com/downloads/details.aspx?FamilyID=18b1d59d-f4d8-4213-8d17-2f6dde7d7aacdisplaylang=en

can capture in monitor mode if the driver for the wireless network 
adapter supports it.  I don't know which drivers support it.

If you're not running Windows at all, you might have better luck; the 
drivers do a better job of supporting promiscuous mode, and man of them 
support monitor mode, as per

http://wiki.wireshark.org/CaptureSetup/WLAN
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] wireless lan packet

[Guy Harris]

Hansang Bae wrote:

 I've had better luck with Packetyzer (google network chemistry 
 packetyzer).  For example, Wireshark refuses to open my Cisco wireless 
 adapter, but Packetyzer can bind to the NIC.

Neither Wireshark nor Packetyzer open adapters - they both use WinPcap:

http://sourceforge.net/forum/forum.php?forum_id=602325

http://www.paglo.com/opensource/packetyzer_thankyou

so any difference in the adapters they can open is probably an issue 
with WinPcap.

Are Wireshark and Packetyzer running on the same machine?  What version 
or versions of WinPcap are they using?  (I'm not sure it's possible to 
have more than one version installed on the same machine.)
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] tshark loopback

[Guy Harris]

Tennis Smith wrote:

 tshark -i lo0
 Running as user root and group root. This could be dangerous.
 Capturing on lo0
 tshark: The capture session could not be initiated (SIOCGIFHWADDR: No such 
 device).

...

 ifconfig 

...

 loLink encap:Local Loopback  

I *thought* I'd remembered that it's just called lo, not lo0, on Linux.

Try tshark -i lo instead.
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] tshark loopback

[Guy Harris]

On Mar 20, 2008, at 12:04 PM, DFE (Donald Ernst) wrote:

 I'm running on Windows XP, will this still work?

No:

http://wiki.wireshark.org/CaptureSetup/Loopback
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] Is there a way to get the Tshark command to print the application data?

[Guy Harris]

On Mar 20, 2008, at 11:59 AM, DFE (Donald Ernst) wrote:

 I am trying to use WireShark to measure the response time of my  
 server for certain applications and need to use it without its GUI.   
 Right now, I execute Tshark -a duration:120 -i 2  test.txt to  
 collect the data.  This gives me a nice readable text file I can  
 process with my own program.  However, this method does not give me  
 the application data, just summary information for each packet.  Is  
 there any way to get the actual application data using the Tshark  
 command?

What do you mean by the actual application data?  If you use the - 
V flag, TShark will give a full dissection of the packet (the  
equivalent of what would appear in the packet detail pain for  
Wireshark).

___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] Capture cellular modem traffic

[Guy Harris]

Eli Greenhut wrote:

 Does the traffic captured by wireShark is before the driver or after the 
 driver?

Before the driver.

On Windows, Wireshark uses WinPcap to capture packets, and, on various 
UN*Xes, it uses libpcap.  WinPcap includes its own driver, which 
connects to the networking code above the network device driver (it 
plugs into the top half of the NDIS mechanism, and networking drivers 
plug into the bottom half), and the mechanisms libpcap uses either 
plug into the networking code above the network device drivers or get 
packets supplied by the driver.

You won't, for example, see raw GSM/UMTS/cdmaOne/cdma2000/etc. radio 
traffic, if that's what you're trying to see.
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] TCP Segment of a reassembled PDU from a NetApp filer

[Guy Harris]

On Mar 18, 2008, at 6:22 PM, [EMAIL PROTECTED] wrote:

 I've read previous posts regarding TCP Segment of a reassembled  
 PDU, but I still can't figure out why it is happening in my  
 environment.

There's two questions here:

1) why does TCP Segment of a reassembled PDU happen at all?

2) why, in some cases, don't you eventually see the reassembled PDU?

The answer to 1) is because some protocols running atop TCP either  
put more than one of their PDUs in a TCP segment, with the last of the  
PDUs not fitting in the space left in the TCP segment that the TCP  
implementation chooses to send, or have PDUs that are bigger than the  
TCP segment that the TCP implementation chooses to send; that means  
that the PDU is split between more than one TCP segment, and Wireshark  
tries to reassemble that.

At least one answer to 2) is because, for some reason, the program  
doing the packet capture didn't manage to capture all the segments  
across which the PDU is split, so the reassembly can't complete.

Try turning TCP reassembly off in the preferences for the TCP  
dissector (that'll prevent reassembly being done for any protocol -  
TCP reassembly requires the cooperation of the TCP dissector and the  
dissector for the protocol running atop TCP, as TCP has no idea when  
the PDUs for the protocol running atop it start and end), and see what  
NDMP packets it shows, if any.  Then see if there are any missing TCP  
segments; that could be a networking problem, or could just mean that  
whatever machine couldn't capture and save all the packets in the  
conversation.
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] TCP Segment of a reassembled PDU from aNetApp filer

[Guy Harris]

On Mar 18, 2008, at 7:08 PM, [EMAIL PROTECTED] wrote:

 Thanks very much for this explanation, Guy.  I turned off TCP
 reassembly, and Wireshark then reported the following for every other
 packet from the NetApp: Unreassembled Packet: NDMP.  So should I be
 assuming that NetApp, as an efficiency, stuffs multiple PDUs into the
 TCP segment,

NDMP packets could be bigger than the maximum TCP segment size on the  
network you're on (e.g., 1460 bytes on Ethernet with TCP-over-IPv4),  
in which case *any* NDMP implementation would have to split the NDMP  
packet across two or more TCP segments, even if there *aren't*  
multiple NDMP packets per TCP segment.

As for packing multiple NDMP PDUs into a TCP segment, if, for example,  
the receiving machine has its receive window on the connection shut at  
the time NDMP hands a PDU to TCP on the sending machine, the sending  
machine couldn't immediately send the PDU that had been handed to TCP,  
so its TCP will just buffer up the data for that PDU - and if another  
PDU is handed to TCP for that connection before the receiving opens  
its window, by the time the window opens up, there will be more than  
one PDU buffered up, and TCP will send whatever it chooses to send,  
which might include parts of more than one PDU.

The display you're reporting seems to imply that the NDMP packets take  
two TCP segments.

 and the Wireshark NDMP dissector hasn't been trained to
 decipher this?

No, you shouldn't, because the Wireshark dissector was changed ages  
ago (back when Wireshark was called Ethereal...) to handle that.

However, there might be a TCP reassembly bug, or there might be some  
other reason, such as packets not captured, preventing reassembly.

If you can, send us a capture with at least two of the Unreassembled  
Packet: NDMP packets, and at least two of the packets before them, so  
we can see which of those is the case.
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] Setting up fields with little endianess for a custom dissector

[Guy Harris]

On Mar 17, 2008, at 11:25 AM, Leandro Lucarella wrote:

 But I still can't find a way to tell (looked at FT_* and BASE_*
 constants) wireshark to interpret the field as little endian.

The byte order is *NOT* a property of the field; there exist protocols  
(X11 and DCE RPC, to name two) where a given field might appear as  
little-endian in some packets and big-endian in other packets, even in  
the same capture.

At least as I read the Wireshark Lua reference manual section of the  
Wireshark User's Manual, you want to do

subtree:add_le(pf, buffer(0, 4))

to add a little-endian 4-byte quantity, but I'm not an expert on the  
Lua support.  Luis?

___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] Help.. pcap to ivs

[Guy Harris]

Andrea Faver wrote:

 i know.. i saved my dump.pcap file in wireshark-tcdump-libpcap mode.
 i tried in dos ivstools --convert dump.pcap dump.ivs
 the error message is:
 opening dump.pcap
 dump.pcap isn't a regular 802.11 (wireless) capture

That doesn't mean it's not a pcap file - it means the packets in it 
don't have 802.11 headers.

A lot of 802.11 adapters can be configured to provide to the host fake 
Ethernet packets, rather than 802.11 packets, and a lot of 802.11 
drivers will, by default, configure the adapters to do so.

On Windows prior to Windows Vista, that's how *all* the drivers work, as 
far as I know; the networking stack doesn't handle 802.11 headers.  In 
Windows Vista, the networking stack can handle 802.11 headers, but not 
all drivers have been changed to work with the Native 802.11 mechanism 
- and, even for those that have, WinPcap doesn't put the adapter into 
monitor mode, so they won't supply 802.11 headers.

So if you've captured on Windows with a WinPcap-based application, such 
as WinDump or Wireshark, you won't have an 802.11 capture.

On Linux, adapters don't supply 802.11 headers by default, but a lot of 
them do so in monitor mode.  See


http://wiki.wireshark.org/CaptureSetup/WLAN#head-bb8373ef4903fe9da2b8375331726541fb1ad32d

for information on some adapters.

On FreeBSD, NetBSD, OpenBSD, and, I think, DragonFly BSD, you can get 
802.11 headers in newer versions; see


http://wiki.wireshark.org/CaptureSetup/WLAN#head-2fcfb4ae9d4e09f91c40d7112ba5103f84b5646d

In Mac OS X 10.4, there might be a wlt1 or wlt2 adapter - if you 
capture on that, the capture will be done in monitor mode, and will have 
802.11 headers.  See


http://kismac.macpirate.ch/wiki/doku.php?id=troubleshooting_airport_extreme

for information on tweaking the Info.plist file for the adapter to 
enable the wlt device - I think it's available by default on at least 
some Intel-based Macs, but you have to tweak the Info.plist file and 
reboot to get it on, for example, a PowerBook.

In Mac OS X 10.5, if you select 802.11 headers with the -y flag to 
tcpdump or TShark or the link-layer header type list in Wireshark, the 
capture will be done in monitor mode, and will have 802.11 headers.

In any case, note that, if the adapter is put into monitor mode, it 
might disassociate itself from the network, so you won't necessarily be 
able to capture traffic on a machine while it's active on a wireless 
network - you might only be able to passively capture traffic from other 
machines.
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] Help.. pcap to ivs

[Guy Harris]

On Mar 14, 2008, at 10:20 AM, Guy Harris wrote:

 On Windows prior to Windows Vista, that's how *all* the drivers  
 work, as
 far as I know; the networking stack doesn't handle 802.11 headers.  In
 Windows Vista, the networking stack can handle 802.11 headers, but not
 all drivers have been changed to work with the Native 802.11  
 mechanism
 - and, even for those that have, WinPcap doesn't put the adapter into
 monitor mode, so they won't supply 802.11 headers.

 So if you've captured on Windows with a WinPcap-based application,  
 such
 as WinDump or Wireshark, you won't have an 802.11 capture.

Another option on Windows is to buy an AirPcap adapter:

http://www.cacetech.com/products/airpcap_family.htm

and use that with Wireshark.  It, in effect, always runs in monitor  
mode (it can't be used as a regular 802.11 adapter), and will,  
presumably, be able to capture the traffic that your machine's regular  
802.11 adapter sends and receives.

It's not an inexpensive option, however; the least expensive adapter  
(802.11b/802.11g) costs USD 198.00.
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] Help.. pcap to ivs

[Guy Harris]

On Mar 13, 2008, at 3:21 PM, Andrea Faver wrote:

 i'm trying to convert a pcap file (made with WIRESHARK) to a ivs file
 with aircrack ivstools.exe but it doesn't recognize the file. how  
 can i
 do it?
 When i save my captured packed in WIRESHARK, in wich format should i  
 do
 it? (i have several option, wireshark, modified tcdump, redhat6.1,
 suse6.3...)


Wireshark's default format is Wireshark/tcpdump/... -  
libpcap (that's why it says Wireshark in the name of that  
format :-)).  That's the standard libpcap format that is also used by,  
for example, tcpdump/WinDump.

The other formats are non-standard, and ivs might, or might not, be  
able to understand them (it probably doesn't understand some of them).
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] help in capturing Modbus traffic

[Guy Harris]

On Mar 12, 2008, at 3:46 PM, Niko Kozobolidis wrote:

 Dear Wireshark-users:

 Our Nicaraguan non-profit development organization is in the process  
 of trying to determine a operator panel periodic freeze.  This  
 operator panel receives instructions from a controller.  The  
 operating panel and controller  automate the operations of a 930 kW  
 small hydro plant that provides electricity to a number of rural  
 towns and villages.

 The representative of the control system in Finland indicates that  
 we should tap directly into the cable that sends data back and forth  
 between the AC800M controller and the 235 Operator Panel.  This is a  
 special cable that has a female 9-pin RS-232 plug on one end and an  
 RJ-45 male plug on the other end. A direct serial connection.  How  
 can one capture Modbus traffic or in other words obtain a trace file  
 from this serial connection?

 The control system representative also says that the software must  
 support “MODBUS” protocol.  When you open the Wireshark main page,  
 and drop-down the HELP menu, there is a part of the HELP that gives  
 a list of “ 911 protocols and packet types supported by Wireshark”.   
 On this list we find “MODBUS/TCP” but not “MODBUS”.   The  
 representative from Finland thinks that “MODBUS” is different from  
 “MODBUS/TCP”, and that we need Wireshark to support the “MODBUS”  
 protocol to analyze the AC800M-to-Operator Panel traffic.  Is Modbus/ 
 Tcp different from Modbus and if so can wireshark capture traffic in  
 the Modbus protocol or possibly translate from one protocol to the  
 other?

Well:

http://en.wikipedia.org/wiki/Modbus

For serial connections, two variants exist, with different  
representations of numerical data and slightly different protocol  
details. Modbus RTU is a compact, binary representation of the data.  
Modbus ASCII is human readable, and more verbose. Both of these  
variants use serial communication. The RTU format follows the commands/ 
data with a cyclic redundancy check checksum, while the ASCII format  
uses a longitudinal redundancy check checksum. Nodes configured for  
the RTU variant will not communicate with nodes set for ASCII, and the  
reverse.

For connections over TCP/IP (e.g. Ethernet), the more recent variant  
Modbus/TCP exists. It is easier to implement than Modbus/ASCII or  
Modbus/RTU because it does not require a checksum calculation.

Following links from there to

http://www.modbus.org/

and then looking for the documentation, there's

http://www.modbus.org/docs/PI_MBUS_300.pdf

for an older specification for Modbus-over-serial-line, describing  
both ASCII and RTU,

http://www.modbus.org/docs/Modbus_over_serial_line_V1_02.pdf

for a newer specification, also describing both ASCII and RTU, and


http://www.modbus.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf

for Modbus/TCP.

If the application-layer portion of the protocol is the same for  
Modbus-over-serial and Modbus-over-TCP, most of Wireshark's dissection  
code could be used for both, although we might have to split the  
dissector up.  However, the lowest layers transporting the application- 
layer PDUs are different, so, yes, MODBUS (by which I assume the  
representative from Finland means Modbus-over-serial, given that the  
device uses a serial connection) is different from Modbus-over-TCP.

It appears that Modbus-over-serial uses standard asynchronous  
communication, with either

1) 8 bits plus a parity bit, 1 stop bit

or

2) 8 bits without a parity bit, 2 stop bits

so a standard computer's serial port hardware could handle it if it  
supports whatever the baud rate is for the controller.  The framing  
for RTU mode is done with silent times on the serial line, which  
means software to capture those packets would have to look for those  
silent times to decide when a frame was done.  For ASCII mode, a frame  
is terminated by a CR-LF pair.

In theory, somebody could:

get DLT_MODBUS_ASCII and/or DLT_MODBUS_RTU DLT_ values from  
tcpdump.org;

write code to read Modbus packets from a serial line and supply them  
as DLT_MODBUS_ASCII or DLT_MODBUS_RTU, and add that to the libpcap/ 
WinPcap library;

add support for DLT_MODBUS_ASCII and/or DLT_MODBUS_RTU to Wireshark,  
and build a version of Wireshark and run it using the modified version  
of libpcap/WinPcap;

in which case if you were able to put a serial line tap of some sort  
on the serial line in question, you would be able to sniff the Modbus  
traffic in Wireshark.  However, that would, as Jaap noted, not be an  
off-the-shelf solution.

Searching for

modbus analyzer

in Google found some items such as


http://www.commfront.com/RS232_Protocol_Analyzer_Monitor/Modbus-Control-Protocol-Analyzer.htm

and

http://www.modbus.org/viewdevice.php?id=453

and

http://www.imperioustech.com/Pricing.html

so it sounds as if 

Re: [Wireshark-users] Wireshark

[Guy Harris]

RayMitchell wrote:

 I just installed Wireshark on WinXP and I have a question.  I have 
 Internet access through a cable modem and, thus, I have a LAN IP 
 address (192.168.1.102) as well as an Internet DHCP IP address.  I 
 have a mail server running on my machine that is only visible to the 
 LAN.  The various email clients on my machine (Eudora, Outlook, etc.) 
 seem to work fine using the LAN mail server for local email to each 
 other as well as the mail server supplied by my ISP for Internet 
 email.  When I run Wireshark I can see all the email and other 
 activity between my LAN machine and the Internet but absolutely no 
 activity between my LAN mail server and any of the LAN mail clients,

I.e., when you run Wireshark on a particular machine, you see no traffic 
between two programs running on that same machine?

That traffic is not supplied to the mechanism that WinPcap uses to do 
packet capture; as Wireshark uses WinPcap to capture packets, that means 
that Wireshark won't see that traffic.

See

http://wiki.wireshark.org/CaptureSetup/Loopback
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] Distinguishing Ethernet II and 802.3 frames

[Guy Harris]

Marcus Better wrote:

 I'm looking at some traffic in our LAN, and think I have some problems with
 Ethernet II vs 802.3 framing.
 
 Wireshark shows lots of Ethernet II frames with unknown frame type 0x05ec
 (=1516 decimal). Since that is less than 0x0600, the limit for Ethernet
 frames, shouldn't Wireshark interpret this as an 802.3 frame rather than
 Ethernet II?

Well, to quote 802.3-2005 section 3.2.6 Length/Type field:

This two-octet field takes one of two meanings, depending on its 
numeric value. For numerical evaluation, the first octet is the most 
significant octet of this field.
a) If the value of this field is less than or equal to the value of 
maxValidFrame (as specified in 4.2.7.1), then the Length/Type field 
indicates the number of MAC client data octets contained in the 
subsequent data field of the frame (Length interpretation).
b) If the value of this field is greater than or equal to 1536 
decimal (equal to 0600 hexadecimal), then the Length/Type field 
indicates the nature of the MAC client protocol (Type interpretation).

   The Length and Type interpretations of this field are mutually 
exclusive.

maxValidFrame is 1500, so if the length/type field has a value in the 
range 1501 through 1535, 802.3-2005 doesn't specify how to interpret the 
frame.  1516 is in that range, so Wireshark can interpret the packet as 
an 802.3 frame, an Ethernet II frame, or a plaintive love note from the 
ghost of Richard Milhous Nixon to Margaret Thatcher, and none of those 
interpretations would violate IEEE 802.3.

 In fact the frames have a payload of precisely 1516 bytes, so it seems that
 it is indeed a regular 802.3 frame.

(Well, technically speaking, Ethernet II frames *are* 802.3 frames, at 
least as of 802.3x, but)

 Incidentally the strange frames are all sent from a Netgear wireless router
 to some MacOS X laptops, over a WEP-protected 802.11 network.

Argument number 1,273 against 802.11 adapters and/or drivers removing 
the 802.11 header from frames, slapping a fake Ethernet header on the 
frames, and presenting them to the host and/or host networking stack - 
packets of certain sizes cannot be so transformed in such a way as to 
allow them to be correctly interpreted according to 802.3.

Unfortunately, OS X doesn't follow in the footsteps of 
{Free,Net,Open,DragonFly}BSD by allowing an application using BPF to 
select either Ethernet or 802.11 headers, regardless of whether you're 
capturing in monitor mode or not, so you can't just say please give me 
802.11 headers, thus bypassing the 802.3/Ethernet II dissector, and 
therefore bypassing the is it a length field or is it a type field? 
check.  (It somewhat follows in the footsteps of Linux and Windows Vista 
in that regard, alas, i.e. they support 802.11 headers only in monitor 
mode, as far as I know.)

I suppose interpreting packet length/type values in that particular dead 
zone as having a length field would help in this case; I don't know 
whether it would cause problems with any packet types you'd see on, for 
example, a regular Ethernet.
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] Distinguishing Ethernet II and 802.3 frames

[Guy Harris]

Marcus Better wrote:

 I'm running Wireshark on Linux 2.6.24 though (mac80211 stack). Can it give
 me the 802.11 frames?

That probably depends on the adapter, but, as you're using the mac80211 
stack, the driver for the adapter is probably reasonably modern, so, if 
the adapter supports monitor mode, the driver probably supports it as well.

What type of adapter do you have?

In monitor mode, you should get 802.11 headers.  In promiscuous mode, 
you probably won't.
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] live data capture question

[Guy Harris]

AMEAUME ALAIN wrote:

 NOW, if you want to capture this payload, you need lawfull rights !

Well, one of the people involved with a GSM capture project says, after 
speaking with a lawyer in the UK:

http://wiki.thc.org/gsm#head-e10f6c374cd8f48452202a35d763cbf99e59051d

I have consulted a lawyer in London to find out if what we do is legal 
or not. These are the results:

There is no direct law that forbids what we are doing (Companies like 
Nokia and Sagem are doing exactly the same: Manufacturing GSM scanners 
that anyone  can buy). These are the legal implications in UK:

1. Security Research in general is not forbidden.
2. Designing a GSM receiver is ALLOWED (Nokia does it. Sagem does it).
3. Publishing the design/research is ALLOWED.
4. Receiving GSM signals is ALLOWED.
5. Decoding (e.g. cracking) your own GSM signals is ALLOWED
6. Decoding somebodys else GSM signals is NOT allowed (DANGER).
7. Setting up a baby cell is allowed if you aquire a license (Any 
bank building in Canary Warf/London runs its own GSM baby cell).

The bottom line is: Publishing the research is ok. As long as you 
receive your own traffic and only send after you got the license you are 
on good ground.

This is based on UK law. European law is similiar (if not more relaxed). 
USA law might be completly different and I highly advice to check with a 
lawyer. If you do so please let me know the results.
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] build problem

[Guy Harris]

bitmus DA wrote:

 i waited and downloaded version 0.99.8
 then configured it --without-pcap and compiled. but error still here

That's another bug, not fixed in 0.99.8, but fixed in the current SVN, 
so that *particular* fix should be in the next release.

For better or worse, most developers don't build without libpcap, and 
the buildbots don't build without libpcap, so build problems when 
building without libpcap don't tend to get discovered and fixed.

Obviously, we don't want all the buildbots building *only* without libpcap.

We could perhaps do all builds first with, and then without, libpcap - 
or first without, and then with, libpcap, with post-build tests done on 
the versions with libpcap - although that would slow the buildbots down 
somewhat.

The Solaris buildbot appears to have taken about 4 3/4 minutes to run 
the configure script, and about 1 hour 38 minutes to do the build, 
unless I'm missing something, so it'd add about 1 3/4 hours to the 
Solaris build procedure to do both builds.

However, if we *only* do it on, say, the OS X buildbot, it shouldn't 
slow things down too much (about 15 minutes), and would probably catch 
most if not all of the problems with non-pcap builds.
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] Dissector bug, protocol SNMP: proto.c:2954: failed assertion (guint)hfindex gpa_hfinfo.len

[Guy Harris]

[EMAIL PROTECTED] wrote:
 I'm running into this bug with 0.99.7 on i386 linux.

Does it still happen with 0.99.8?

If so, please file a bug at bugs.wireshark.org, and provide a sample 
capture file with a packet that shows the problem, if possible (no need 
for any other packets).
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] live data capture question

[Guy Harris]

On Feb 28, 2008, at 3:05 PM, stephen galowski wrote:

 with regards to gsm and 3g protocols

 can a mobile phone with usb cable be connected to a computer , and  
 be able to track  them
 or would special equipment be needed to do this

If by GSM and 3G protocols you're referring to the over-the-air  
protocols used between mobile phones over the Um or Uu interface (or  
Xyzzy interface or whatever they call it), you would need special  
equipment to do that.

As far as I know, the USB connection to a normal mobile phone is used  
for stuff such as syncing information between the phone and a  
computer, and possibly for tethering the phone to a computer for use  
as a modem; it doesn't supply raw over-the-air packet information.

There apparently do exist Special Magical Phones - or Special Magical  
Phone Firmware - that might handle that, such as the TEMS Pocket  
software from Ericsson:


http://www.ericsson.com/solutions/tems/realtime_diagnostics/downloads/TEMS_Pocket%20_6.0.pdf

although they say it Supports FTP for network troubleshooting and  
logfile transfer, rather than allowing you to plug the z750i into a  
computer via USB and pass traffic to the computer in real time.

However, a Google for

um interface capture

found

http://thre.at/gsm/

(which raises the questions which countries have the most interesting  
two-letter country codes for use in domain names? :-)).  It refers to  
something called a USRP; following the link from that page to

http://wiki.thc.org/gsm

and then clicking on The GSM/USRP Receiver Project takes you to

http://wiki.thc.org/gsm#head-9e2d9078d8e28d24f20e8fcd7971b2c376f8d0a9

which has a link to

http://gnuradio.org/trac/wiki/USRP

as well as to Ettus Research:

http://www.ettus.com/

from whom you can buy the Universal Software Radio Peripheral.

So it appears you might be able to construct a GSM sniffer from a USRP  
board and a bunch of free software, including a Wireshark patch.  (It  
appears that one of the pieces of free software required is called  
Linux or GNU/Linux, depending on which side of that particular  
debate you're on :-), i.e. it works by using Linux's tunnel device to  
stuff packets into a fake network interface on which Wireshark can  
capture.  If I had an unlimited amount of free time, it might be fun  
to see whether I could construct a libpcap add-on for this, to make it  
work on a variety of OSes as a GSM sniffer; unfortunately, I have  
substantially less free time than I'd like even for the stuff I'm  
already doing) 
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] packet payload string or hex filter

[Guy Harris]

Sake Blok wrote:
 On Thu, Feb 21, 2008 at 10:01:48PM -0700, Stephen Fisher wrote:

...

 This is not currently possible because there is no field that contains 
 the contents of the entire frame.

Actually, there is - frame.

 Well, if the capture file consists of only ethernet frames, then
 you can use the following filters:
 
 eth contains blablabla (string)
 eth contains 00403f (hex)
 
 Those filters will match any packet that contains the string 
 blablabla (or the byte sequence 00 40 3f) anywhere in the packet.

And

frame contains blablabla

or

frame contains 00:40:3f

(rather than 00403f, if you're searching for a byte with the value hex 
00, followed by a byte with the value hex 40, followed by a byte with 
the value hex 3f) will match regardless of whether the frames are 
Ethernet frames or not.

Note, however, that matches a link-layer frame, so if you're looking 
for, for example, an HTTP request or reply containing the string 
foobar, that won't match an HTTP request in which one TCP segment ends 
with foo and the next TCP segment begins with bar.  In that case, 
you'd need to search for

http contains method

which *will*, as far as I know, match that.
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] Intel 4965

[Guy Harris]

On Feb 20, 2008, at 9:17 PM, Fat Ball wrote:

 Who can let me know how to activate the interface of Intel 4965 upon  
 wireshark?

On what OS?

Under Windows, wireless adapters don't work very well (except maybe,  
to a limited degree, on Vista, if the driver is a native 802.11  
driver, and even that doesn't give you monitor mode).

Under Linux, you'd want a system with a 2.6.18 or greater kernel, with  
the mac80211 wireless stack:

http://www.intel.com/support/wireless/wlan/sb/CS-025330.htm

and

http://intellinuxwireless.org/index.php?p=iwlwifi

says of the iwlwifi driver for those adapters that it's been in the  
mainstream kernel since 2.6.24.

Under OpenBSD, you'd need a version of the OS with the iwn driver.   
NetBSD appears to have picked up that driver this month, but that  
probably means it's only in -current.  It appears it's being ported to  
FreeBSD as well:

http://www.clearchain.com/wiki/Iwn
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] Is the -Q flag for Wireshark useful?

[Guy Harris]

On Feb 20, 2008, at 7:59 AM, Jeff Morriss wrote:

 Would anybody miss the current -Q flag if it went away?

 I wouldn't but test/suite-capture.sh would (it uses it for the  
 capture
 10 packets [with the GUI] test).

We already supply our own getopt() for platforms that don't have it  
(for which, at this point, read Windows, as I think every version of  
every UN*X on which we run has it).  Perhaps we should supply our own  
getopt_long(), instead, for platforms that don't have *it* (there's a  
BSD-licensed version that modern versions of FreeBSD/NetBSD/OpenBSD/OS  
X have, and Solaris 10 has a version as well), use it, add long  
options for less-commonly-used options such as that - and add long  
aliases for the existing options.
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] printout file problem

[Guy Harris]

nicolas büchi wrote:

 For a graphic visualization of wireless traffic I want to do with  
 processing,

If you want to do real-time statistics, you might want to look at ntop:

http://www.ntop.org/

to see if it can be made to do what you want.
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

[Wireshark-users] Is the -Q flag for Wireshark useful?

[Guy Harris]

If you specify the -Q flag, it starts a capture immediately and, when 
you stop the capture, Wireshark exits.

This is left over from when Wireshark implemented Update list of 
packets in real time captures by running another copy of Wireshark to 
do the capture and to send messages to the main Wireshark as packets 
arrive; that other copy was run with -Q, so it would exit when the 
capture was complete.

Wireshark no longer implementes Update list of packets in real time 
captures in that fashion; instead, it runs dumpcap.

-Q doesn't appear to be useful for any other purposes - if you run a 
capture like that, you see the capture as it happens, but, when you stop 
the capture, Wireshark shuts down so you don't see any of the traffic. 
If you want to start a Wireshark capture from the command line, and 
*not* have Wireshark exit when the capture is stopped, you can use the 
-k flag.

I have plans to use -Q to specify an 802.11 channel on which to 
capture in monitor mode in tcpdump, TShark, dumpcap, and Wireshark; -Q 
is available in all of those programs except Wireshark, and it doesn't 
appear to do anything useful in Wireshark.

Would anybody miss the current -Q flag if it went away?
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] Filtering tcp payload

[Guy Harris]

Greg Helps wrote:

 Screen redraws, mouse movements and keystrokes are all high priority
 activities compared to something like printing. Therefore, the first two
 bytes of the tcp data are not encrypted

Note that there's no guarantee that the first two bytes of a Citrix ICA 
packet are the first two bytes of a TCP segment - TCP's a byte-stream 
protocol, so a higher-level packet can be fragmented across TCP 
segments, and a TCP segment can contain more than one ICA packet.  As 
such, matching on a particular byte after a TCP header isn't guaranteed 
to match anything.

 I'd like to filter by the first two bits of the second byte of the tcp
 payload data. I am currently trying variations of the following display
 filter :
 (tcp[21]  0xc0) == 0
 
 This filter is rejected as invalid.

Capture filter, or display filter?

It is, confusingly enough, not a valid capture filter.  A valid capture 
filter would be

(tcp[21]  0xc0) = 0

with =, rather than ==, as the comparison operator.  I'm tempted to 
change that in libpcap, so that either = or == can be used.

As for display filters, there are two issues:

The first of which is that the constant operand of  must be a byte 
string, i.e. a sequence of hex values separated by colons, so you have 
to say c0 rather than 0xc0 for a one-byte value.

The second of which is that, at least as I read the man page, that you 
can't do something such as

(tcp[21]  c0) == 0

but you can do

!(tcp[21]  c0)

(Note also that those display and capture filters assume the TCP segment 
has no TCP options.)
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] Wireshark sold on ebay

[Guy Harris]

Joerg Mayer wrote:

 AFAIKT, the offer is perfectly legal.

Legal, but some would consider it wrong, as a customer might not know 
that a version is available for USD/EUR/UKP/RMB/JPY/CAD/BRL/RUB/INR/{ok, 
ok, we get it -ed :-)} 0.00 from http://www.wireshark.org.

I don't know

1) whether it's possible to post a comment on an item in eBay (such as 
hey, you can get this software for free from www.wireshark.org)

or

2) if it's possible, whether you have to have an eBay account to do 
that.
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] Bad Checksum Packet

[Guy Harris]

Andreas Fink wrote:

 in todays wired networks its rather rare to see invalid checksums 
 because it would mean that  a packet get transmitted and received but 
 incorrectly received due to a bad wire o the like.

The same applies for 802.11 wireless networks, at least - you might be 
more likely to get incorrectly-received packets, but the 802.11 adapter 
would probably discard it before handing it to the host, because of a 
bad link-layer CRC (just as would be the case on modern wired LANs and 
WANs).  I suspect that's the case for at least some other wireless 
networks (various mobile phone data networks, WiMAX, etc.).

 So its very unlikely to see tcp.checksum_bad == 1 unless you have a 
 broken TCP stack creating wrong checksums or the like.

...or the hardware passes packets with bad link-layer checksums to the 
host (either by default or because the driver configured it to do so), 
and the driver arranges that they be provide to the packet capture 
mechanism used by libpcap/WinPcap and thus by Wireshark/TShark.  Many 
capture mechanisms are part of the networking stack, and might not be 
designed to allow that (i.e., if the driver passes the packet to the 
networking stack, it might also get supplied to the IP layer and thus 
the TCP layer, even though it's known to be bad), but the BPF mechanism 
in *BSD/OS X/AIX is separate from the rest of the networking stack, and 
I think at least some drivers on some *BSDs will, in promiscuous mode, 
configure the adapter to supply packets with bad CRCs to the host and 
will provide those packets to BPF, and thus to libpcap and ultimately to 
tcpdump/Wireshark/TShark/etc..

However, there's no way to control that behavior, as far as I know 
(other than to turn promiscuous mode on if the driver *already* supports 
it), and, on most platforms, I don't think that behavior is available.
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] Compilation problems with CVS libpcap

[Guy Harris]

Stephen RP O'Connell wrote:
 It prints:
 
 gencode.c:  (void)pcap_parse();
 gencode.h:int pcap_parse(void);
 grammar.c:pcap_parse()
 grammar.y:pcap_parse()

What does

nm -po /usr/local/lib/libpcap.a | egrep pcap_parse

print?

(I'm assuming this is Linux; if it's not, you might as well give up, 
unless you're writing your own USB support or got the USB support from 
somebody else, as the current CVS version of libpcap supports only Linux.)
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] Compilation problems with CVS libpcap

[Guy Harris]

Stephen RP O'Connell wrote:
 nm -po /usr/local/lib/libpcap.a | egrep grammar.o prints:
 

...

 /usr/local/lib/libpcap.a:grammar.o:00a0 T yyparse

Well, *that's* annoying.  That's supposed to be pcap_parse.

What does

egrep YACC Makefile

print in the libpcap source directory?

And what do the commands

which yacc
which bison
which lex
which flex

print?
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] Compilation problems with CVS libpcap

[Guy Harris]

Stephen O'Connell wrote:

 /usr/local/lib/libpcap.a(gencode.o): In function `.L186':
 gencode.c:(.text+0x869): undefined reference to `pcap_parse'

In the source tree of the version of libpcap you built, what does the 
command egrep pcap_parse *.[chyl] print?
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] Build problems with Sun's compiler on Solaris 10

[Guy Harris]

Dr. David Kirkby wrote:

 OK, I'm attaching the part of config.log from the 0.99.7.tar.gz file - 
 there are no patches I've applied, nothing from trunk - just the latest 
 'stable' distribution.
 
 I can attack the full config.log if you want, but it is over 200 KB, so 
 I've cut it down quite a bit, but hopefully still included anything that 
 might be useful.

That was sufficient to determine the problem.

Because, when compiling with GCC, we default to treating warnings as 
errors (in the hopes of reducing the chance that errors will get added 
to the code base), and because, in the case I described (where you have 
a library with routines not declared in the corresponding header file, 
because the library was updated but the header wasn't), you would get 
errors when trying to use a routine of that sort, the configure script 
was checking for that.

Unfortunately, it was checking for that by compiling with the GCC flags 
to check for undeclared functions and to treat warnings as errors, and 
was doing so *even if the compiler wasn't GCC*; compilers that don't 
recognize those files would fail when trying to compile.

I've checked in a change to do that check only if you're compiling with 
warnings treated as errors (the way we do that currently works only with 
GCC, and we default to *not* treating warnings as errors when not 
compiling with GCC).
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] Capture Filter Help

[Guy Harris]

James Pifer wrote:

 I'm trying setup a capture filter to capture only data where the ip
 address contains a certain part of an ip address. We have a lot of
 servers on a distributed network that have standard addresses. 
 
 For example, I'd like to capture data on port 137 if the ip address is
 like 192.xxx.xxx.11 where xxx can be anything. 
 
 Can this be done in a capture filter?

Not conveniently, but it can be done:

(((ip[12:4]  0xFFFF) = 0xC00B) || ((ip[16:4]  0xFFFF) = 
0xC00B))  port 137

(which extracts the IP source address, ANDs it with 0xFFFF, compares 
it with 192.0.0.11, does the same with the IP destination address, 
matches if either are true, and then ANDs that with a match on port 137).
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] Build problems with Sun's compiler on Solaris 10

[Guy Harris]

Dr. David Kirkby wrote:

 2) I just installed libpcap from the file libpcap-0.9.8.tar.gz, but the 
 wireshark configure script complains that the pcap library is more 
 recent than the pcap header.
 
 checking whether pcap_breakloop is present and usable... broken
 configure: WARNING: Your pcap library is more recent than your pcap header.
 configure: WARNING: Wireshark won't be able to use functions not declared
 configure: WARNING: in that header. You should install a newer version of
 configure: WARNING: the header file.
 checking whether pcap_findalldevs is present and usable... yes
 checking for pcap_datalink_val_to_name... yes
 
 I've no idea why this should be so.

Well, one way that should be so would be if, for example, a hypothetical 
maker of UN*X boxes, whose version of UN*X includes libpcap, were to put 
out an online OS update that upgrades its version of libpcap as part of 
a tcpdump/libpcap upgrade to plug some security holes, with the upgrade 
to libpcap being an upgrade from a version without pcap_breakloop() to a 
version with pcap_breakloop(), and if that vendor were to treat header 
files as part of its development tools, and not to update them with that 
online OS update, so that you have a library with pcap_breakloop() and a 
header file that doesn't declare it.

As you built and installed libpcap yourself, that wouldn't be it, so 
we'd have to look elsewhere.  What are the contents of your config.log file?

 6) NOW THIS IS THE SERIOUS PROBLEM - it stops me building wireshark and 
 I have not yet found a solution.
 
 ./configure CC=/opt/SUNWspro/bin/cc CXX=/opt/SUNWspro/bin/CC
 This configures OK - see above for what is configured.
 
 gmake
 
 After quite a bit of time compiling OK, the compilation process aborts 
 with:
 
 source='packet-ecatmb.c' object='packet-ecatmb.lo' libtool=yes \
 DEPDIR=.deps depmode=none /bin/bash ../../depcomp \
 /bin/bash ../../libtool --tag=CC   --mode=compile /opt/SUNWspro/bin/cc 
 -DHAVE_CONFIG_H -I. -I../.. -I../.. -I/usr/local/include  
 -I/usr/local/include 
 '-DPLUGIN_DIR=/usr/local/lib/wireshark/plugins/0.99.7'  -D_U_= -g 
 -I/usr/local/include -mt -I/usr/include/gtk-2.0 
 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 
 -I/usr/include/pango-1.0 -I/usr/openwin/include -I/usr/sfw/include 
 -I/usr/sfw/include/freetype2 -I/usr/include/glib-2.0 
 -I/usr/lib/glib-2.0/include   -c -o packet-ecatmb.lo packet-ecatmb.c
 /opt/SUNWspro/bin/cc -DHAVE_CONFIG_H -I. -I../.. -I../.. 
 -I/usr/local/include -I/usr/local/include 
 -DPLUGIN_DIR=\/usr/local/lib/wireshark/plugins/0.99.7\ -D_U_= -g 
 -I/usr/local/include -mt -I/usr/include/gtk-2.0 
 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 
 -I/usr/include/pango-1.0 -I/usr/openwin/include -I/usr/sfw/include 
 -I/usr/sfw/include/freetype2 -I/usr/include/glib-2.0 
 -I/usr/lib/glib-2.0/include -c packet-ecatmb.c  -KPIC -DPIC -o 
 .libs/packet-ecatmb.o
 packet-ecatmb.c, line 291: improper member use: Control

Are you compiling with the latest version of plugins/ethercat/ecatmb.h? 
What, for example, are the definitions of SoeHeaderControlUnion and 
PETHERCAT_SOE_HEADER in that header?  They should be

typedef union tSoeHeaderControlUnion
{
struct
{
   guint8 OpCode : 3; /* 0 = unused, 1 = readReq, 2 = readRes, 3 
= writeReq, 4 = writeRes
  5 = notification (command changed 
notification)*/
   guint8 InComplete : 1; /* more follows*/
   guint8 Error  : 1; /* an error word follows */
   guint8 DriveNo: 3; /* drive number */

   guint8 DataState  : 1; /* follows or requested */
   guint8 Name   : 1; /* follows or requested */
   guint8 Attribute  : 1; /* follows or requested */
   guint8 Unit   : 1; /* follows or requested */
   guint8 Min: 1; /* follows or requested */
   guint8 Max: 1; /* follows or requested */
   guint8 Value  : 1; /* follows or requested */
   guint8 Reserved   : 1;
} v;
struct
{
   guint8 Control;
   guint8 Element;
} v2;
} SoeHeaderControlUnion;

and

typedef struct TETHERCAT_SOE_HEADER
{
SoeHeaderControlUnion anSoeHeaderControlUnion;
SoeHeaderDataUnion anSoeHeaderDataUnion;
/* typedef union tMailBoxDataUnion
{
guint8Data[]   rest of mailbox data  if (Error==0)
guint16 ErrorCodeif (Error==1)
} MailBoxDataUnion;*/
} ETHERCAT_SOE_HEADER, *PETHERCAT_SOE_HEADER;
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] URL capture filer??

[Guy Harris]

jacob c wrote:
 I have attached two jpg screenshots so you can see what I typed in and 
 then the error I get. Please let me know what I'm doing wrong.

As the message says, unknown host 'www.cnn.com'; Wireshark's unable to 
find the IP address corresponding to the domain name www.cnn.com.

Can you get to

http://www.cnn.com/

from your Web browser?  If not, then it's probably because the browser 
is just as unable to resolve the host name www.cnn.com to an IP 
address as is Wireshark; if you're using Wireshark to try to debug that 
problem, I'd suggest using port domain as your capture filter, as, to 
debug a problem that's probably a DNS problem, you'd need to capture DNS 
traffic.
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] URL capture filer??

[Guy Harris]

jacob c wrote:

 I just wanted/assumed Wireshark would read the http header for 
 www.cnn.com http://www.cnn.com and then capture accordingly.

No.

host XXX in libpcap/WinPcap (the library that Wireshark/TShark - and a 
*lot* of other software, including tcpdump/WinDump - uses to capture 
traffic) - means traffic to or from the IPv4 address or the IPv6 
address corresponding to XXX.

That requires that libpcap/WinPcap (and thus the application using it) 
resolve any host name given in host XXX expressions.

 Is there a way to do that if I am using a proxy?

No.
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] how can i open the package of iris saved

[Guy Harris]

dxf206_163 wrote:

   I have a package that saved by iris, when i open it, wireshark tell me
 : The file E:\Untitled.cap isn't a capture file in a format Wireshark
 understands.,how can i open it with wireshark。

By giving us enough information to figure out how to add code to 
Wireshark to be able to understand the file format of Iris's files, and 
waiting for us to do so.

See

http://www.wireshark.org/faq.html#q1.11

for more information about the information we'd need.

Without that information, it is *impossible* for us to write code for 
Wireshark that would be able to read the file, which would make it 
impossible to read the file.
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] 答复: how can i open the package of iris saved

[Guy Harris]

dxf206_163 wrote:
 thanks for your help. 
 
 but while i use capinfos, it tell me capinfos: Can't open e:\untitled.cap:
 The file isn't a capture file in a known format, i think ,before wireshark
 open a file, it use capinfos to get infomation from file,

No, it doesn't - but Wireshark and capinfos use the same code to read 
files, so, if Wireshark can't read a file, capinfos can't, either.

As I said in my other mail, we would need to add code that can read Iris 
files to the library used by Wireshark and capinfos (and TShark and 
editcap) to read capture files.  In order to do that, we'd need the 
information the FAQ entry mentions, i.e. (quoting the FAQ)

we would either have to have a specification for the file format, or 
the extensions, sufficient to give us enough information to read the 
parts of the file relevant to Wireshark, or would need at least one 
capture file in that format AND a detailed textual analysis of the 
packets in that capture file (showing packet time stamps, packet 
lengths, and the top-level packet header) in order to reverse-engineer 
the file format.

and note also that (again, quoting the FAQ)

there is no guarantee that we will be able to reverse-engineer a 
capture file format.
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] FC Protocol ??

[Guy Harris]

On Jan 30, 2008, at 11:00 AM, Daniel Koepke wrote:

 Sorry for the delay, was pulled in different directions

 Here is a sample of the scan taken today

How did you do that capture?  With what type of machine are you  
capturing?

At least some of the packets appear to have been damaged in the  
process of capturing.

The first packet, for example, has an Ethernet type field value of 0,  
which is not a valid type value (or length value) - Wireshark  
interprets that as Fibre Channel because of the way some Cisco  
equipment works (I think some Cisco Fibre Channel equipment can dump  
internal traffic, and it looks like Ethernet traffic with an all-zero  
type field).

The third packet has an Ethernet type value of 0x, which is also  
not a valid type value (or length value).

The first byte *after* the bogus Ethernet type values in those packets  
is 0x45 in both packets, so they look as if they might be IP packets -  
and, if I use the Analyze  Decode As menu item to force Wireshark to  
decode 0x as IP, those packets, at least, are IP packets;  
unfortunately, as the Ethernet type value for those packets isn't the  
type value for IP, so Wireshark (correctly) doesn't decode them as IP  
packets by default.

Perhaps there's something wrong with the hardware you used to capture  
the traffic, or with the low-level software doing the capture (OS,  
drivers, etc.).
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] can't save filter, please help me

[Guy Harris]

On Jan 30, 2008, at 5:46 PM, dxf206_163 wrote:

I'm newer. I want to define new filter, but i can't find out save  
 button
 in display filter dialog,

There isn't one.  Clicking OK causes all changes you've made,  
including adding new filters, to be saved.

 and in capture filter dialog, i also can't
 find out exprension button.

There isn't one.  For information on the syntax of capture filters, see

http://www.tcpdump.org/tcpdump_man.html

or

http://www.winpcap.org/docs/docs_41b2/html/group__language.html

(look for expression).
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] Capture filter for MAC addresses

[Guy Harris]

On Jan 25, 2008, at 4:24 PM, Frank Bulk wrote:

 I've looked at the wiki page (http://wiki.wireshark.org/Ethernet)  
 but it's
 not entirely clear to me how I would capture the traffic from all  
 those
 devices that share the same OUI.

 For example, if the OUI of interest was Cisco (00:1b:0d), I have  
 tried this:
   ether[0:4]=0x001B0D
 but it didn't seem to work.  I suspect I don't full understand the  
 usage of
 the square brackets, and perhaps I need to use a mask of some kind.

Capture filters can only test 1-byte, 2-byte, or 4-byte fields:

$ man tcpdump

...

 expression
   selects  which  packets  will  be  dumped.   If no  
expression is
   given, all packets on the net will be dumped.
Otherwise,  only
   packets for which expression is `true' will be dumped.

   The  expression  consists of one or more primitives.   
Primitives
   usually consist of an id (name or number)  preceded   
by  one  or
   more qualifiers.  There are three different kinds of  
qualifier:

...

   expr relop expr
  True if the relation holds, where relop is one  
of  ,  ,
  =,  =, =, !=, and expr is an arithmetic  
expression com-
  posed of integer constants (expressed in  
standard C  syn-
  tax),  the normal binary operators [+, -, *, /,  
, |, ,
  ], a length operator, and special  packet   
data  acces-
  sors.   Note  that all comparisons are unsigned,  
so that,
  for example, 0x8000  and  0x  are   
   0.   To
  access data inside the packet, use the following  
syntax:
   proto [ expr : size ]
  Proto  is  one of ether, fddi, tr, wlan, ppp,  
slip, link,
  ip, arp, rarp, tcp, udp, icmp, ip6 or  radio,   
and  indi-
  cates   the  protocol  layer  for  the  index   
operation.
  (ether, fddi, wlan, tr, ppp, slip and link all   
refer  to
  the  link layer. radio refers to the radio  
header added
  to some 802.11 captures.)  Note that tcp, udp   
and  other
  upper-layer  protocol  types only apply to IPv4,  
not IPv6
  (this will be fixed in the  future).   The   
byte  offset,
  relative  to  the  indicated  protocol layer, is  
given by
  expr.  Size is optional and indicates the number  
of bytes
  in  the  field of interest; it can be either  
one, two, or
  four, and defaults to one.  The  length   
operator,  indi-
  cated by the keyword len, gives the length of  
the packet.

so, yes, you'd have to either

1) do ether[0] == 0x00 and ether[1] == 0x1B and ether[2] == 0x0D

or

2) use a mask - (ether[0:4]  0xFF00) == 0x001B0D00

(the latter generates less BPF code, and would run a little faster).
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] Capture filter for MAC addresses

[Guy Harris]

Frank Bulk wrote:
 Now, to take it one step farther, I need to apply that capture filter to the
 client field (labeled in the display filter 'bootp.hw.mac_addr').  
 Is that possible in a capture filter?  And if you're going to ask if the
 offset from the start of the packet is consistent, it's not.
   
Offsets can be computed based on the values in other fields:

  expr relop expr
 True if the relation holds, where relop is one of  
 ,  ,
 =,  =, =, !=, and expr is an arithmetic 
expression com-
 posed of integer constants (expressed in standard 
C  syn-
 tax),  the normal binary operators [+, -, *, /, , 
|, ,
 ], a length operator, and special  packet  data  
acces-
 sors.   Note  that all comparisons are unsigned, so 
that,
 for example, 0x8000  and  0x  are
0.   To
 access data inside the packet, use the following 
syntax:
  proto [ expr : size ]

I.e., it says expr in proto[expr:size], which means the offset in 
proto[expr:size] can be an arbitrary expression.

Figuring out the the right expression is left as an exercise for the 
reader.  (If it involves a loop, however, forget it - the offset 
*eventually* has to be based on values at a fixed offset from, for 
example, the beginning of the UDP payload.  Fortunately, the UDP header 
is fixed-length)
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] top talkers by port usage or SYN attempts - ericsson error

[Guy Harris]

jacob c wrote:
 I appreciate the info. I have actually taken several captures now on 
 individual vlans and have located the top talkers. I also tried the 
 tshark command you mentioned below without success. I get the ericsson 
 error as show below.  Here is what happens:
 C:\Program Files\Wireshark

Oops, cmd.exe, not a UN*X shell, so Sake's command won't work exactly.

If you have Cygwin installed, you could try it from Cygwin.

 tshark -r c:\captures\0_0-10mins -T fields -e 
 ip.src
 tcp.flags.syn==1 
 Could not open file: 'Ericsson.xml', error: No such file or directory
 tshark: Unexpected end of filter string.

The ericsson error isn't the real problem.  The real problem is the 
Unexpected end of filter string; that command isn't complete.

The complete tshark command would be

tshark -r c:\captures\0_0-10mins -T fields -e ip.src tcp.flags.syn==1 
 tcp.flags.ack==0

on *one* command line (I don't know whether cmd.exe supports commands 
split across multiple command lines the way UN*X shells do.

However, the rest of his command, namely the

| sort | uniq -c | sort -rn | head

part, is a bit trickier; cmd.exe *does* support pipes (and I suspect it 
supports them using Win32 pipes, rather than the old run the commands 
one at a time, save the output of command N to a file, and use that file 
as input to command N+1 hack that the MS-DOS command prompt did, due to 
DOS being a single-tasking system), but Windows doesn't come with those 
other commands.

As noted, Cygwin would include those commands.
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] Crashes on OS X 10.5

[Guy Harris]

Rob Heilman wrote:
 Ever since the upgrade to Leopard/10.5 Wireshark has been fairly 
 unstable.

The upgrade introduced a new X server (based on X.org 7.2, as I 
remember, rather than XFree86) with some bugs, one of which causes that 
problem with Wireshark and other GTK+ applications.

See

http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1953

which, at the end, gives information on getting newer versions of X11.app.
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] crashing on OS X

[Guy Harris]

Rob Heilman wrote:
 I am correct in my understanding that the fix is to replace the Xquartz 
 binary provided by Apple with the binary supplied by X.org?

No, the fix is to replace the Xquartz binary provided with Leopard with 
the binary supplied by Apple's Ben Byer:

http://trac.macosforge.org/projects/xquartz

 To state in 
 another way, Apple has yet to address this issue in their release of X11?

Leopard 10.5 and 10.5.1 both have an X11 server with this bug.
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Re: [Wireshark-users] WLAN APC file and RSSI

[Guy Harris]

Avi Berkovich wrote:
 Well, I went through the wiretap library code and saw that while it's 
 aware of the dBm tag (it has it's own switch case), it just doesn't 
 read it.

The problem is that, for 802.11 radio information other than in libpcap 
files (where the radio information appears in the packet data as a 
header preceding the 802.11 header), it's presented to the 802.11 
dissector as a pseudo-header.

That pseudo-header was originally introduced for the file format used by 
AiroPeek before *Peek switched to the new file format (the old file 
format is handled by wiretap/etherpeek.c, because the code to handle it 
was first added to handle files from EtherPeek; the new file format is 
handled by wiretap/airopeek9.c, because the code to handle it was first 
added to handle files from a later version of AiroPeek (the URL 
mentioned in airopeek9.c says 2.0.1)).

The older versions of AiroPeek had a fixed-length radio header, with a 
1-byte data rate value in 500Kb/s units, a 1-byte channel value with a 
channel number and a 1-byte signal level value as a percentage.  Those 
were the only values put into the pseudo-header; some other file formats 
also use it.

The newer versions of EtherPeek, AiroPeek, and presumably OmniPeek, have 
a variable-length TLV-based pseudo-header, with tags for both signal and 
noise as a percentage and as a dBm value, as well as other tags 
(including one mysterious one seen in an EtherPeek capture).  The 
current pseudo-header has no provision for most of those values, so most 
of them are ignored.

There are a couple of ways to handle this:

1) have a new pseudo-header that can handle all the radio 
pseudo-information found in capture files - including in the Prism, AVS, 
and radiotap headers in libpcap - and funnel all radio information 
through that.

2) have some mechanism for supplying the raw new-style *Peek TLV header 
and have a dissector for it - and perhaps even use that for the 
old-style *Peek header, CommView header, etc..

1) has the advantage that all the code that knows about particular forms 
of radio information is in Wiretap, and no dissectors or taps need know 
those details.

2) has the advantages that:

1) we could have an option in the 802.11 dissector to have it either 
just display the extracted radio information (just the values) or 
display a dissection of the raw header - the former is probably what 
most users want (they don't care about the gory details of how a 
radiotap, AVS, or Prism header encodes that information), and the latter 
would be useful if you're debugging a driver generating a radiotap or 
AVS header or are trying to reverse-engineer a radio header);

2) there's no loss of information from transforming the header to a 
pseudo-header, so if you save packets from a capture the radio 
information will be saved as is.

You *would* need multiple radio-information dissectors, but those could, 
at least, build a pseudo-header to hand to taps, so the taps would be 
independent of the capture file you're reading.
___
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users