CC'ing Pierre, who filed Bug 16450.  Please test this if you have the opportunity.  Thanks!

CC: (none) => pf

MGA5-32 on Acer D620 Xfce.
No installation issues.
First time I run wireshark, get "usr/bin/dumpcap : Access denied". The user has to be member of the wireshark group (involves restart in Xfce, logout in KDE).
Once that settled, I could capture packets on the wireless connectioncould see some statistics, so OK for me.

CC: (none) => herman.viaene
Whiteboard: (none) => MGA5-32-OK

Initial view looks good.  Didn't have to restart KDE -- already member of wireshark group.  The new features in the No. column and the scroll bar are a nice touch...  :)

Created attachment 7221 [details]
Mouse misalignment

Should I open separate bugs, or just add findings here until it moves to Updates?

1. Crash when accessing Edit->Preferences:
$ wireshark
Cannot mix incompatible Qt library (version 0x50400) with this library (version 0x50402)
Aborted

2. Minor issue: with capture pane over side-by-side packet & hex panes (can't access prefs to change) , hex pane field selection (via mouse hover) is not aligned to mouse cursor -- cursor is up to two hex bytes to the right of what is highlighted.

(In reply to Pierre Fortin from comment #4)
> 1. Crash when accessing Edit->Preferences:
> $ wireshark
> Cannot mix incompatible Qt library (version 0x50400) with this library
> (version 0x50402)
> Aborted

I was worried about that.  We'll need to either ship the Qt5 update first, or remove it from updates_testing and rebuild this update.

Nicolas, what should we do here?

> 2. Minor issue: with capture pane over side-by-side packet & hex panes
> (can't access prefs to change) , hex pane field selection (via mouse hover)
> is not aligned to mouse cursor -- cursor is up to two hex bytes to the right
> of what is highlighted.

That's weird.  I wonder if installing the Qt5 5.4.2 in updates_testing would help you there.

Whiteboard: MGA5-32-OK => feedback
CC: (none) => mageia

Updated Qt to 5.4.2 and the crash is gone.  Mouse offset still present.

The mouse offset gets wider to the right; almost like it was based on 2 spaces between bytes instead of 1 actually there.

Thanks for testing that.  The mouse offset issue is probably worth an upstream report.  As for the Qt version mismatch, obviously we'll have to deal with that on our end.

OK, wireshark and qt5 package were removed from updates_testing and wireshark was rebuilt against our current qt5 5.4.0.  Please re-install the wireshark packages and test again.

Whiteboard: feedback => (none)

In VirtualBox, M5, KDE, 32-bit

Package(s) under test:
wireshark libwireshark5

default install of wireshark & libwireshark5

[root@localhost wilcal]# urpmi wireshark
Package wireshark-1.12.8-1.mga5.i586 is already installed
[root@localhost wilcal]# urpmi libwireshark5
Package libwireshark5-1.12.8-1.mga5.i586 is already installed

Running wireshark as root I can capture and save to a file all the
traffic on enp0s3. I can close wireshark then open wireshark again
the previously created file and review the data.

install wireshark & libwireshark6 from updates_testing

[root@localhost wilcal]# urpmi wireshark
Package wireshark-2.0.0-1.mga5.i586 is already installed
[root@localhost wilcal]# urpmi libwireshark6
Package libwireshark6-2.0.0-1.mga5.i586 is already installed

Wireshark reports "No interfaces found". "Capture options" button
does not report any interfaces to monitor.

CC: (none) => wilcal.int

How about if you add a regular user to the wireshark group and try running wireshark as the user and not as root?

It's working here, as expected on a Mageia 5 x86_64 system, where the regular
user is a member of the wireshark group, though for any of the usbmon devices,
the usbmon kernel module must be loaded, and wireshark run as root, since only
root has read access to the /sys/kernel/debug/usb/usbmon/ files.

Advisory added to svn. I'll hold off validating the update till comment 10 is
sorted out.

CC: (none) => davidwhodgins
Whiteboard: (none) => MGA5-64-OK advisory

(In reply to David Walser from comment #11)

> How about if you add a regular user to the wireshark group and try running
> wireshark as the user and not as root?

Added wilcal to the wireshark group. Was able to launch wireshark from terminal.
Wireshark window reported the following:

"Couldn't run /usr/bin/dumpcap in child process: Permission denied"

Wireshark still cannot find a network interface.

(In reply to William Kenney from comment #13)
> (In reply to David Walser from comment #11)
> 
> > How about if you add a regular user to the wireshark group and try running
> > wireshark as the user and not as root?
> 
> Added wilcal to the wireshark group. Was able to launch wireshark from
> terminal.
> Wireshark window reported the following:
> 
> "Couldn't run /usr/bin/dumpcap in child process: Permission denied"
> 
> Wireshark still cannot find a network interface.

When you change group memberships, you need to log out before it will take effect.

(In reply to David Walser from comment #14)

> When you change group memberships, you need to log out before it will take
> effect.

Restarting the client, and launching wireshark from a user ( wilcal )
terminal gets me the same result as in Comment #10.

(In reply to William Kenney from comment #15)
> (In reply to David Walser from comment #14)
> 
> > When you change group memberships, you need to log out before it will take
> > effect.
> 
> Restarting the client, and launching wireshark from a user ( wilcal )
> terminal gets me the same result as in Comment #10.

What do you mean by restarting the client?

Did you log out of the desktop as wilcal and re-login after adding wilcal to the wireshark group?  Does the "id -a" command show the wireshark group in your group memberships?  Does dumpcap work?

(In reply to David Walser from comment #16)

> What do you mean by restarting the client?

I had actually shut the host down after the initial testing this morning.
So a restart was a power down of the host then power up and rerun the client.

> Did you log out of the desktop as wilcal and re-login after adding wilcal to
> the wireshark group?  Does the "id -a" command show the wireshark group in
> your group memberships?  Does dumpcap work?

I've some things to do and will get back to this later today.
Tomorrow is mostly for testing.

Thanks for the help.

David, sorry for the silence...  my motherboard went bad -- fixed now.

Assuming you wanted Nov 27 version tested...  the version number was not changed from the Nov 19 version, so I had to manually remove all those packages first due to "already installed".

Looks the same (still has the mouse location issue); so "works for me" :)

The only thing I missed on the Nov 19 version was that lib64wireshark5-1.12.8-1.mga5 was not removed when lib64wireshark6-2.0.0-1.mga5 was installed -- assuming it should have been removed...

(In reply to Pierre Fortin from comment #18)
> David, sorry for the silence...  my motherboard went bad -- fixed now.

Ouch, nice to have you back.

> Assuming you wanted Nov 27 version tested...  the version number was not
> changed from the Nov 19 version, so I had to manually remove all those
> packages first due to "already installed".

Yep, we cleared out all the Qt5 stuff in updates_testing and I just rebuilt the wireshark update.

> Looks the same (still has the mouse location issue); so "works for me" :)

Did you report this upstream by any chance?

> The only thing I missed on the Nov 19 version was that
> lib64wireshark5-1.12.8-1.mga5 was not removed when
> lib64wireshark6-2.0.0-1.mga5 was installed -- assuming it should have been
> removed...

Nope, libwireshark5 will just get orphaned by the update.  urpme --auto-orphans will remove it.  That's how we usually handle libraries.

(In reply to David Walser from comment #19)
> (In reply to Pierre Fortin from comment #18)
> > Looks the same (still has the mouse location issue); so "works for me" :)
> 
> Did you report this upstream by any chance?

No... is there a simple clue to help me determine what part of an application needs to be reported where?  Guessing that Qt is the "upstream" here; but qt.io doesn't look right...

>   urpme
> --auto-orphans will remove it.  That's how we usually handle libraries.

That always scared the #$%^& outta me...  seeing LOTS of supposed orphans that I was suspicious of caused me to steer clear of --auto-orphans...  

Anyway, left wireshark running (not sniffing) and wanted to start a new capture; but if I add a capture filter (port N), Start, Stop & Restart are greyed out...

(In reply to Pierre Fortin from comment #20)
> (In reply to David Walser from comment #19)
> > (In reply to Pierre Fortin from comment #18)
> > > Looks the same (still has the mouse location issue); so "works for me" :)
> > 
> > Did you report this upstream by any chance?
> 
> No... is there a simple clue to help me determine what part of an
> application needs to be reported where?  Guessing that Qt is the "upstream"
> here; but qt.io doesn't look right...

Upstream would be wireshark (wireshark.org) in this case.  We don't know whether the mouse issue is a bug in the wireshark code or a problem with Qt itself, but I suspect it's a bug in the wireshark code.  Anyway, the wireshark developers would be better equipped to figure that out.

> >   urpme
> > --auto-orphans will remove it.  That's how we usually handle libraries.
> 
> That always scared the #$%^& outta me...  seeing LOTS of supposed orphans
> that I was suspicious of caused me to steer clear of --auto-orphans...  

If you see anything listed as an orphan that you don't want removed, just run urpmi on those packages and they'll be marked as manually installed and won't ever be orphaned.

> Anyway, left wireshark running (not sniffing) and wanted to start a new
> capture; but if I add a capture filter (port N), Start, Stop & Restart are
> greyed out...

Hmm...

(In reply to David Walser from comment #21)

> Upstream would be wireshark (wireshark.org) in this case.
Oops...  I was overthinking "upstream"... lol
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11844

> > Anyway, left wireshark running (not sniffing) and wanted to start a new
> > capture; but if I add a capture filter (port N), Start, Stop & Restart are
> > greyed out...
> 
> Hmm...
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11845

Thanks Pierre!

I'll add the feedback marker while we wait to see what upstream does with these.

Whiteboard: MGA5-64-OK advisory => MGA5-64-OK advisory feedback

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11845 changed to enhancement request.

Hi David,

Trying to really use wireshark just now, and uncovered the following issues:
- [re]start complains of no interface selected -- this should be remembered until changed (not looking for persistence across invocations; just within the current invocation).
- starting a capture which complains about no interface selected, if I click on Capture Options, in the dialog, select the interface and click Close instead of Start; I can click on main window's Start and wireshark claims to capture on the selected interface; but really doesn't...
- selecting a packet to view, then scrolling and pausing -- after a couple seconds (or more -- random), the display returns to the point of the selected packet, making it difficult to go elsewhere in the capture to then select another packet to view. This one is really irritating.
- stop a capture, wireshark becomes unresponsive for random lengths of time.
- sorting is sometimes quite slow too.

Wireshark beyond the UI works; but it looks like the logic of what should happen is badly broken...

Before asking about my hardware :)   I'm running on a Dell M6800 8-thread Intel i7-4710MQ CPU @ 2.50GHz with 32GB of memory, not yet swapping...

Thanks.  Issues found should continue to be reported upstream (but thanks for noting them here too).  I'm disappointed that your previous two reports have not received a response yet.  It sounds like the new interface needs more polishing work.  Hopefully it'll be in better shape for 2.0.1.

Thanks for all the work everyone.

Upstream bugs filed:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11911
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11912
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11914

I've gone back to v1.12.8 as v2 is too frustrating to use...  Would be nice if they could be installed simultaneously for testing.

Upstream suggests using 2.0.1rc1...
 https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11912#c2
Is a new testing package coming?  Thanks!

The 2.0.1rc1 code hasn't been posted yet.  I just see some automated git snapshots here:
https://www.wireshark.org/download/automated/src/

If you'd like to try building it locally, let me know if you need any help.  Some tips on that:
you can download the SRPM from distrib/5/SRPMS/core/updates_testing on a mirror or use mgarepo and check it out with:
mgarepo co -d 5 wireshark

In the SPEC file, change version to 2.0.1, release to %mkrel 0.1, and then you'd have to adjust at least the Source0 line with the correct name for the tarball (and would probably need to change "%setup -q" if "wireshark-2.0.1" is not the name of the directory the tarball extracts.  Change it to "%setup -q -n dirname" for whatever the correct dirname is).  Other than that it should build fine:
bm -ls (to build the source RPM)
urpmi SRPMS/*.src.rpm (as root, to install the build dependencies)
bm -l (back to your regular user account, to build the packages)
rpm -Fvh RPMS/*/*.rpm (as root, to install what you built)

Upstream has released version 1.12.9 and 2.0.1 on December 29:
https://www.wireshark.org/news/20151229.html

Hopefully the issues have been ironed out.

Advisory:
========================

Updated wireshark packages fix security vulnerabilities:

This update provides Wireshark 2.0.1, where the Qt5 GUI is now feature-
complete.  See the upstream blog post and release notes for details.

It also fixes several security issues (parser and dissector crashes) that
affected previous versions.

References:
https://blog.wireshark.org/2015/11/let-me-tell-you-about-wireshark-2-0/
https://www.wireshark.org/docs/relnotes/wireshark-2.0.0.html
https://www.wireshark.org/news/20151229.html
https://www.wireshark.org/docs/relnotes/wireshark-1.12.9.html
https://www.wireshark.org/docs/relnotes/wireshark-2.0.1.html
========================

Updated packages in core/updates_testing:
========================
wireshark-2.0.1-1.mga5
libwireshark6-2.0.1-1.mga5
libwiretap5-2.0.1-1.mga5
libwsutil6-2.0.1-1.mga5
libwireshark-devel-2.0.1-1.mga5
wireshark-tools-2.0.1-1.mga5
tshark-2.0.1-1.mga5
rawshark-2.0.1-1.mga5
dumpcap-2.0.1-1.mga5

from wireshark-2.0.1-1.mga5.src.rpm

Whiteboard: MGA5-64-OK advisory feedback => (none)

Filed new upstream bug: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11951

OpenSuSE has issued an advisory for this today (January 8):
http://lists.opensuse.org/opensuse-updates/2016-01/msg00011.html

URL: (none) => http://lwn.net/Vulnerabilities/671100/

Trying x64 with various test files from release notes bug references:
 dumpcap-2.0.1-1.mga5
 lib64wireshark6-2.0.1-1.mga5
 rawshark-2.0.1-1.mga5
 tshark-2.0.1-1.mga5
 wireshark-2.0.1-1.mga5
 wireshark-tools-2.0.1-1.mga5

$ tshark -nVxr asan_stack-oob_3b5b130_7003_1a184f717196b3f413eebf5feac1cb08.cap
Frame 1: 5143 bytes on wire (41144 bits), 5143 bytes captured (41144 bits)
...
tshark: The file "asan_stack-oob_3b5b130_7003_1a184f717196b3f413eebf5feac1cb08.cap" appears to have been cut short in the middle of a packet.
[rather than crashing]

$ tshark -nVxr asan_stack-oob_9ce363_4234_a2da08e40622e0760e9fe8a18fb74e49.pcap
...
2040  08 00 06 06 00 01 00 07 0d af f4 54 45 4c d8 01   ...........TEL..
2050  00 00 00 00                                       ....
tshark: The file "asan_stack-oob_9ce363_4234_a2da08e40622e0760e9fe8a18fb74e49.pcap" appears to have been cut short in the middle of a packet.
[rather than crashing]

wireshark Qt5 GUI open crash1.pcap, displays without crash (although the host bug refers to wireshark-gtk). Using the mouse on the main panel highlights variable amounts of data, which I imagine is intended & signifcant; the correlation between hex & char panels is correct & consistent.

$ tshark -nVxr asan_heap-oob_933a5a_1611_b1ba7a16afb992aa2ac417de9214c3ce.cap
tshark: The file "asan_heap-oob_933a5a_1611_b1ba7a16afb992aa2ac417de9214c3ce.cap" appears to be damaged or corrupt.
(ngsniffer: REC_FRAME2 record length is less than record header length)
[rather than crashing]

[thunderstorm, must stop]

CC: (none) => lewyssmith

Testing x64 [continued]

Using the Wireshark GUI to 'open' the test files noted in Comment 34, it was encouraging to note that each one popped up an error box with the same essential message as from tshark.
Within my expertise, this update is OK. It updated OK EXCEPT that it left:
 lib64wireshark5-1.12.8-1.mga5
along with the new lib64wireshark6-2.0.1-1.mga5.
 # urpme --auto-orphans
  lib64wireshark5-1.12.8-1.mga5.x86_64
  lib64wiretap4-1.12.8-1.mga5.x86_64
  nodejs-amdefine-0.0.4-2.mga5.noarch
  perl-Devel-Leak-0.30.0-3.mga5.x86_64
At least it is noted as orphaned. Is this correct?
And it seemed to run OK, reacting sensibly to the few PoCs I fed it.
BTW These were selected at random from the bugs cited in the *Release notes*.

@Pierre
You have raised all sorts of issues. Are *you* happy to let this latest update go in spite of your upstream bug reports? Unless there were regressions, I suggest 'yes'. But you are the expert. If you agree, can you please MGA5-64-OK the whiteboard please? On my own, I would. If not, please say why not and grey the update 'feedback'.

(In reply to Lewis Smith from comment #35)
> At least it is noted as orphaned. Is this correct?

Yes, that's how it's supposed to work.

> @Pierre
> You have raised all sorts of issues. Are *you* happy to let this latest
> update go in spite of your upstream bug reports? Unless there were
> regressions, I suggest 'yes'. But you are the expert. If you agree, can you
> please MGA5-64-OK the whiteboard please? On my own, I would. If not, please
> say why not and grey the update 'feedback'.

If the issues don't affect packet analysis, we should OK this.  Packet capture is usually done with other tools anyway.

Closed some upstream bugs.

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11951  is still a problem:  Pane resizing does not work. Changing layout returns panes to default sizes which don't match my preferences.  Usable; but this bug might be more of an issue on smaller screen sizes.  A prominent note might be advised to hopefully avoid a rash of bug reports.

I need to test this again myself.  I'll let you know what I think when I have a look at it.

Argh!  Tested this on a fresh account and pane resizing  works there...  

I did also get this on the konsole of all but my normal userid:
libGL error: failed to open drm device: Permission denied
libGL error: failed to load driver: i965

# grep wire /etc/group
wireshark:x:476:pfortin,pierre,pf,pf2,pf3

The following appears for every layout change -- should be left however the user sets each layout since there's already a Restore Defaults button...
FIX: Auto-size each preference pane.

Whiteboard: (none) => /

(In reply to David Walser from comment #38)
> I need to test this again myself.  I'll let you know what I think when I
> have a look at it.
When you have done, please OK it.

x64
I am happy with this, within the limits of my playing. I will OK x64 if necessary after your next feedback.

OK, I can confirm Pierre's issue about the mouse being slightly off over the hex pane, but that's a very minor one.  Not sure why upstream hasn't confirmed that one as it's pretty obvious.

Looks like most of his other issues were resolved in 2.0.1 except for 11951, but I didn't play with the pane layout.

Certainly for packet analysis, this looks fine to me.  I think we can go ahead and release this, and hopefully other minor UI issues which were reported upstream will be in better shape for 2.0.2.

An update for this issue has been pushed to Mageia Updates repository.

http://advisories.mageia.org/MGAA-2016-0014.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED