Re: wireshark illegal instruction on older systems

2016-03-19 Thread Christian Weisgerber 
Peter Kay:

> Not wishing to be a dick about this, but what sort of notification is
> in place to stop time being wasted trying to run programs on
> incompatible CPUs?

None. The general policy is that packages must run on all CPUs
supported by the base system.

That said, we now do have a few ports that build with -march=i586
or -march=i686 on i386, because the software requires certain atomic
operations or such that are only available starting from these CPU
models.  The expectation is that this only concerns programs that
nobody would reasonably try to run on older CPUs anyway.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: wireshark illegal instruction on older systems

2016-03-19 Thread Stuart Henderson 
On 2016/03/16 13:42, Peter Kay wrote:
> It's not an AVX instruction, as Wireshark runs on a Core2Duo pre Sandy
> Bridge when AVX arrived.
> 
> I agree that it looks too heavy for a P2, and last time I ran it under
> *nix it would have been the gtk version, I was surprised at all the
> dependencies it pulled in.
> 
> This issue is only likely to get worse, is it wise to do a CPU check,
> and refuse to install some packages?

Sorry I read your mail too quickly and missed the "pentium ii" mention,
I have a diff on ports@ to disable various cpu features that Qt5 had
autodetected which should help this.

Re: wireshark illegal instruction on older systems

2016-03-19 Thread Vadim Zhukov 
2016-03-15 21:33 GMT+03:00 Stuart Henderson <s...@spacehopper.org>:
> On 2016-03-15, Peter Kay <syllops...@syllopsium.co.uk> wrote:
>> It's a MOVSD SSE instruction. Tshark is ok. I can cope with that or tcpdump
>> if need be, but here's the output :
>
> I think this variant of MOVSD might be AVX?
>
>> Starting program: /usr/local/bin/wireshark
>> warning: Lowest section in /usr/local/lib/libicudata.so.9.0 is .hash at
>> 0154
>>
>> Program received signal SIGILL, Illegal instruction.
>> 0x06d685fb in _GLOBAL__sub_I_qguiapplication.cpp () from
>> /usr/local/lib/qt5/./libQt5Gui.so.1.1
>
> Looks like it's in Qt5 then. Wireshark still has the "legacy" gtk GUI
> (it's in a subpackage), you could try that instead for now.
>
> Looks like Qt autodetects at build time, we probably want to configure
> on i386 with no-avx, no-avx2, no-sse4.1, no-sse4.2, maybe no-ssse3.
> (SSE2 is probably reasonable to expect for Qt5 apps, it's present on
> Netburst, Pentium-M, Atom, C7 etc. which seems a sane cut-off point
> for heavy GUI apps).

Yeah. I've patched qmake files, but missed those bits. Modern amd64
makes you blind sometimes. :(

--
  WBR,
  Vadim Zhukov

Re: wireshark illegal instruction on older systems

2016-03-19 Thread Peter Kay 
It's not an AVX instruction, as Wireshark runs on a Core2Duo pre Sandy
Bridge when AVX arrived.

I agree that it looks too heavy for a P2, and last time I ran it under
*nix it would have been the gtk version, I was surprised at all the
dependencies it pulled in.

This issue is only likely to get worse, is it wise to do a CPU check,
and refuse to install some packages?

PK

On 16/03/2016, Vadim Zhukov <persg...@gmail.com> wrote:
> 2016-03-15 21:33 GMT+03:00 Stuart Henderson <s...@spacehopper.org>:
>> On 2016-03-15, Peter Kay <syllops...@syllopsium.co.uk> wrote:
>>> It's a MOVSD SSE instruction. Tshark is ok. I can cope with that or
>>> tcpdump
>>> if need be, but here's the output :
>>
>> I think this variant of MOVSD might be AVX?
>>
>>> Starting program: /usr/local/bin/wireshark
>>> warning: Lowest section in /usr/local/lib/libicudata.so.9.0 is .hash at
>>> 0154
>>>
>>> Program received signal SIGILL, Illegal instruction.
>>> 0x06d685fb in _GLOBAL__sub_I_qguiapplication.cpp () from
>>> /usr/local/lib/qt5/./libQt5Gui.so.1.1
>>
>> Looks like it's in Qt5 then. Wireshark still has the "legacy" gtk GUI
>> (it's in a subpackage), you could try that instead for now.
>>
>> Looks like Qt autodetects at build time, we probably want to configure
>> on i386 with no-avx, no-avx2, no-sse4.1, no-sse4.2, maybe no-ssse3.
>> (SSE2 is probably reasonable to expect for Qt5 apps, it's present on
>> Netburst, Pentium-M, Atom, C7 etc. which seems a sane cut-off point
>> for heavy GUI apps).
>
> Yeah. I've patched qmake files, but missed those bits. Modern amd64
> makes you blind sometimes. :(
>
> --
>   WBR,
>   Vadim Zhukov

Re: wireshark illegal instruction on older systems

2016-03-16 Thread Peter Kay 
Not wishing to be a dick about this, but what sort of notification is
in place to stop time being wasted trying to run programs on
incompatible CPUs? Obviously old processors need to be supported in
base for embedded systems, but it would be nice to have a note for
packages.

Is it viable to redirect/use ports with global compiler flags set to
'no SSE' or in some cases '486 compatible'

I ran it on a pentium ii laptop because it was lying around and seemed
like it would do the job, and a pentium ii system to verify, and
because it's being used for retro gaming. I do have more modern
systems.

On 15/03/2016, Christian Weisgerber  wrote:
> On 2016-03-15, Stuart Henderson  wrote:
>
>> Looks like Qt autodetects at build time, we probably want to configure
>> on i386 with no-avx, no-avx2, no-sse4.1, no-sse4.2, maybe no-ssse3.
>> (SSE2 is probably reasonable to expect for Qt5 apps, it's present on
>> Netburst, Pentium-M, Atom, C7 etc. which seems a sane cut-off point
>> for heavy GUI apps).
>
> Well, Peter did attempt to run it on Pentium II, which doesn't have
> SSE2.
>
> --
> Christian "naddy" Weisgerber  na...@mips.inka.de

Re: wireshark illegal instruction on older systems

2016-03-15 Thread Christian Weisgerber 
On 2016-03-15, Stuart Henderson  wrote:

> Looks like Qt autodetects at build time, we probably want to configure
> on i386 with no-avx, no-avx2, no-sse4.1, no-sse4.2, maybe no-ssse3.
> (SSE2 is probably reasonable to expect for Qt5 apps, it's present on
> Netburst, Pentium-M, Atom, C7 etc. which seems a sane cut-off point
> for heavy GUI apps).

Well, Peter did attempt to run it on Pentium II, which doesn't have
SSE2.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: wireshark illegal instruction on older systems

2016-03-15 Thread Juan Francisco Cantero Hurtado 
On Tue, Mar 15, 2016 at 06:33:56PM +, Stuart Henderson wrote:
> On 2016-03-15, Peter Kay <syllops...@syllopsium.co.uk> wrote:
> > It's a MOVSD SSE instruction. Tshark is ok. I can cope with that or tcpdump
> > if need be, but here's the output :
> 
> I think this variant of MOVSD might be AVX?
> 
> > Starting program: /usr/local/bin/wireshark
> > warning: Lowest section in /usr/local/lib/libicudata.so.9.0 is .hash at
> > 0154
> >
> > Program received signal SIGILL, Illegal instruction.
> > 0x06d685fb in _GLOBAL__sub_I_qguiapplication.cpp () from
> > /usr/local/lib/qt5/./libQt5Gui.so.1.1
> 
> Looks like it's in Qt5 then. Wireshark still has the "legacy" gtk GUI
> (it's in a subpackage), you could try that instead for now.
> 
> Looks like Qt autodetects at build time, we probably want to configure
> on i386 with no-avx, no-avx2, no-sse4.1, no-sse4.2, maybe no-ssse3.
> (SSE2 is probably reasonable to expect for Qt5 apps, it's present on
> Netburst, Pentium-M, Atom, C7 etc. which seems a sane cut-off point
> for heavy GUI apps).

"maybe no-ssse3"

There are a lot of "recent" AMD cpus which don't support ssse3.

cpu0: AMD Athlon(tm) II X4 638 Quad-Core Processor, 2700.26 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,ITSC


> 
> > 0x06d685fb <_GLOBAL__sub_I_qguiapplication.cpp+43>: movsd
> >  0x8(%esp),%xmm0
> ..
> > 0x06d6860c <_GLOBAL__sub_I_qguiapplication.cpp+60>: movsd
> >  %xmm0,0x8(%eax)
> 

-- 
Juan Francisco Cantero Hurtado http://juanfra.info

Re: wireshark illegal instruction on older systems

2016-03-15 Thread Stuart Henderson 
On 2016-03-15, Peter Kay <syllops...@syllopsium.co.uk> wrote:
> It's a MOVSD SSE instruction. Tshark is ok. I can cope with that or tcpdump
> if need be, but here's the output :

I think this variant of MOVSD might be AVX?

> Starting program: /usr/local/bin/wireshark
> warning: Lowest section in /usr/local/lib/libicudata.so.9.0 is .hash at
> 0154
>
> Program received signal SIGILL, Illegal instruction.
> 0x06d685fb in _GLOBAL__sub_I_qguiapplication.cpp () from
> /usr/local/lib/qt5/./libQt5Gui.so.1.1

Looks like it's in Qt5 then. Wireshark still has the "legacy" gtk GUI
(it's in a subpackage), you could try that instead for now.

Looks like Qt autodetects at build time, we probably want to configure
on i386 with no-avx, no-avx2, no-sse4.1, no-sse4.2, maybe no-ssse3.
(SSE2 is probably reasonable to expect for Qt5 apps, it's present on
Netburst, Pentium-M, Atom, C7 etc. which seems a sane cut-off point
for heavy GUI apps).

> 0x06d685fb <_GLOBAL__sub_I_qguiapplication.cpp+43>: movsd
>  0x8(%esp),%xmm0
..
> 0x06d6860c <_GLOBAL__sub_I_qguiapplication.cpp+60>: movsd
>  %xmm0,0x8(%eax)

Re: wireshark illegal instruction on older systems

2016-03-14 Thread Peter Kay 
It's a MOVSD SSE instruction. Tshark is ok. I can cope with that or tcpdump
if need be, but here's the output :

Starting program: /usr/local/bin/wireshark
warning: Lowest section in /usr/local/lib/libicudata.so.9.0 is .hash at
0154

Program received signal SIGILL, Illegal instruction.
0x06d685fb in _GLOBAL__sub_I_qguiapplication.cpp () from
/usr/local/lib/qt5/./libQt5Gui.so.1.1

(gdb) bt
#0  0x06d685fb in _GLOBAL__sub_I_qguiapplication.cpp () from
/usr/local/lib/qt5/./libQt5Gui.so.1.1
#1  0x06d3ddba in ?? () from /usr/local/lib/qt5/./libQt5Gui.so.1.1
#2  0x03ff4931 in _dl_call_init_recurse (object=0x23ff6084,
initfirst=-2136632992) at /usr/src/libexec/ld.so/loader.c:671
#3  0x06d2e40b in _init () from /usr/local/lib/qt5/./libQt5Gui.so.1.1
#4  0x03ff49d1 in _dl_call_init_recurse (object=0x80a5aa00, initfirst=0) at
/usr/src/libexec/ld.so/loader.c:693
#5  0x03ff4971 in _dl_call_init_recurse (object=0x87a66a00, initfirst=0) at
/usr/src/libexec/ld.so/loader.c:679
#6  0x03ff4971 in _dl_call_init_recurse (object=0x80a5a200, initfirst=0) at
/usr/src/libexec/ld.so/loader.c:679
#7  0x03ff4971 in _dl_call_init_recurse (object=0x8162ac00, initfirst=0) at
/usr/src/libexec/ld.so/loader.c:679
#8  0x03ff4a1a in _dl_call_init (object=0x8162ac00) at /usr/src/libexec/
ld.so/loader.c:666
#9  0x03ff580a in _dl_boot (argv=0xcf7bdf84, envp=0xcf7bdf8c,
dyn_loff=67059712, dl_data=0xcf7bdf3c)
at /usr/src/libexec/ld.so/loader.c:595
#10 0x03ff44b5 in _dl_start () at /usr/src/libexec/ld.so/i386/ldasm.S:68
#11 0xcf7bdf84 in ?? ()
#12 0xcf7bdf8c in ?? ()
#13 0x03ff4000 in ?? ()
#14 0xcf7bdf3c in ?? ()
#15 0xcf7bdf80 in ?? ()
#16 0xcf7bdf3c in ?? ()
#17 0x in ?? ()

(gdb) disas 0x06d685fb
Dump of assembler code for function _GLOBAL__sub_I_qguiapplication.cpp:
0x06d685d0 <_GLOBAL__sub_I_qguiapplication.cpp+0>:  push   %edi
0x06d685d1 <_GLOBAL__sub_I_qguiapplication.cpp+1>:  push   %esi
0x06d685d2 <_GLOBAL__sub_I_qguiapplication.cpp+2>:  push   %ebx
0x06d685d3 <_GLOBAL__sub_I_qguiapplication.cpp+3>:  call   0x6d3e13c
<__x86.get_pc_thunk.bx>
0x06d685d8 <_GLOBAL__sub_I_qguiapplication.cpp+8>:  add
 $0x200a22c0,%ebx
0x06d685de <_GLOBAL__sub_I_qguiapplication.cpp+14>: sub$0x10,%esp
0x06d685e1 <_GLOBAL__sub_I_qguiapplication.cpp+17>: call   0x6d3c7a0
<_init+58272>
0x06d685e6 <_GLOBAL__sub_I_qguiapplication.cpp+22>: fstpl  0x8(%esp)
0x06d685ea <_GLOBAL__sub_I_qguiapplication.cpp+26>: lea
 0x5770(%ebx),%esi
0x06d685f0 <_GLOBAL__sub_I_qguiapplication.cpp+32>: call   0x6d3c7a0
<_init+58272>
0x06d685f5 <_GLOBAL__sub_I_qguiapplication.cpp+37>: mov
 0x4328(%ebx),%eax
0x06d685fb <_GLOBAL__sub_I_qguiapplication.cpp+43>: movsd
 0x8(%esp),%xmm0
0x06d68601 <_GLOBAL__sub_I_qguiapplication.cpp+49>: mov
 0x4414(%ebx),%edi
0x06d68607 <_GLOBAL__sub_I_qguiapplication.cpp+55>: sub$0x4,%esp
0x06d6860a <_GLOBAL__sub_I_qguiapplication.cpp+58>: fstpl  (%eax)
0x06d6860c <_GLOBAL__sub_I_qguiapplication.cpp+60>: movsd
 %xmm0,0x8(%eax)
0x06d68611 <_GLOBAL__sub_I_qguiapplication.cpp+65>: mov
 0x4554(%ebx),%eax
0x06d68617 <_GLOBAL__sub_I_qguiapplication.cpp+71>: mov%edi,(%eax)
0x06d68619 <_GLOBAL__sub_I_qguiapplication.cpp+73>: push   %esi
0x06d6861a <_GLOBAL__sub_I_qguiapplication.cpp+74>: push   %eax
0x06d6861b <_GLOBAL__sub_I_qguiapplication.cpp+75>: lea
 0xdff3c658(%ebx),%eax
0x06d68621 <_GLOBAL__sub_I_qguiapplication.cpp+81>: push   %eax
0x06d68622 <_GLOBAL__sub_I_qguiapplication.cpp+82>: call   0x6d37100
<_init+36096>
0x06d68627 <_GLOBAL__sub_I_qguiapplication.cpp+87>: mov
 0x446c(%ebx),%eax
0x06d6862d <_GLOBAL__sub_I_qguiapplication.cpp+93>: add$0xc,%esp
0x06d68630 <_GLOBAL__sub_I_qguiapplication.cpp+96>: mov%edi,(%eax)
0x06d68632 <_GLOBAL__sub_I_qguiapplication.cpp+98>: push   %esi
0x06d68633 <_GLOBAL__sub_I_qguiapplication.cpp+99>: push   %eax
0x06d68634 <_GLOBAL__sub_I_qguiapplication.cpp+100>:lea
 0xdff4af78(%ebx),%eax
0x06d6863a <_GLOBAL__sub_I_qguiapplication.cpp+106>:push   %eax
0x06d6863b <_GLOBAL__sub_I_qguiapplication.cpp+107>:call   0x6d37100
<_init+36096>
0x06d68640 <_GLOBAL__sub_I_qguiapplication.cpp+112>:mov
 0x4178(%ebx),%eax
0x06d68646 <_GLOBAL__sub_I_qguiapplication.cpp+118>:add$0xc,%esp
0x06d68649 <_GLOBAL__sub_I_qguiapplication.cpp+121>:mov%edi,(%eax)
0x06d6864b <_GLOBAL__sub_I_qguiapplication.cpp+123>:push   %esi
0x06d6864c <_GLOBAL__sub_I_qguiapplication.cpp+124>:push   %eax


On 15 March 2016 at 00:30, Michael McConville <mm...@mykolab.com> wrote:

> Peter Kay wrote:
> > Wireshark, running on -current, is dumping core ('illegal
> > instruction') on two separate pentium ii systems here. It's

wireshark illegal instruction on older systems

2016-03-14 Thread Peter Kay 
Wireshark, running on -current, is dumping core ('illegal instruction') on
two separate pentium ii systems here. It's fine on a Core2Duo running i386.

I'm presuming it's using pentium 3 or later instructions/SSE2 etc. Has
anyone else seen this before I look at it?

PK

Re: wireshark illegal instruction on older systems

2016-03-14 Thread Michael McConville 
Peter Kay wrote:
> Wireshark, running on -current, is dumping core ('illegal
> instruction') on two separate pentium ii systems here. It's fine on a
> Core2Duo running i386.
> 
> I'm presuming it's using pentium 3 or later instructions/SSE2 etc. Has
> anyone else seen this before I look at it?

Can you run it in GDB and trigger the crash? That seems like the easiest
way to get the offending instruction.

I know we had to handle something like this in lang/go recently. There
was a discussion on ports@.

Alternatives to Wireshark.

2010-01-27 Thread Christiano F. Haesbaert 
Hi there,

I've always used wireshark for packet sniffing, it solved most of my needs.

First of all, I'm not questioning the why of not having a port, I've
read the previous posts (I really don't care why, don't start a
discussion).

My main need is debugging DNS packets (mDNS), and reading raw tcpdump
output isn't very easy, I need to really debug the protocol, so
something that could show me field names and values would be cool.

Right now I'm using tcpdump and accounting stuff like: ok this is the
id, so the next 2 bytes is the query type and so on... (this isn't
working :-D).

I understand I could make some script to interpret the values, but I'm
sure you guys already though of something better.

Thanks.

Re: Alternatives to Wireshark.

2010-01-27 Thread Bryan Irvine 
I like ettercap for that.

On Wed, Jan 27, 2010 at 12:23 PM, Christiano F. Haesbaert
haesba...@haesbaert.org wrote:
 Hi there,

 I've always used wireshark for packet sniffing, it solved most of my needs.

 First of all, I'm not questioning the why of not having a port, I've
 read the previous posts (I really don't care why, don't start a
 discussion).

 My main need is debugging DNS packets (mDNS), and reading raw tcpdump
 output isn't very easy, I need to really debug the protocol, so
 something that could show me field names and values would be cool.

 Right now I'm using tcpdump and accounting stuff like: ok this is the
 id, so the next 2 bytes is the query type and so on... (this isn't
 working :-D).

 I understand I could make some script to interpret the values, but I'm
 sure you guys already though of something better.

 Thanks.

Re: Alternatives to Wireshark.

2010-01-27 Thread Stuart Henderson 
On 2010-01-27, Christiano F. Haesbaert haesba...@haesbaert.org wrote:
 My main need is debugging DNS packets (mDNS), and reading raw tcpdump
 output isn't very easy, I need to really debug the protocol, so
 something that could show me field names and values would be cool.

 Right now I'm using tcpdump and accounting stuff like: ok this is the
 id, so the next 2 bytes is the query type and so on... (this isn't
 working :-D).

tcpdump already handles mDNS, it shouldn't be too hard to extend
and add what you're missing...

Re: Wireshark

2009-08-20 Thread Pawlowski Marcin Piotr 
On Wed, 19 Aug 2009 19:51:25 +0200
merlyn merlyn...@gmail.com wrote:

 On Monday 17 August 2009 00:51:28 stan wrote:
  I realize that there is histroy here but I really need to make this
  tool work, and OpenBSD is my OS of choice for network related
  functions.
 
  Has anyone gotten wireshark to compile on OpenBSD 4.5? I am trying
  to build version 1.2.1, if that matters.
 
 Hi stan,
 last version of Wireshark I've successfully compiled was 0.99.8.
 If you'll have more good luck than me, send a patch to this mailing
 list.
 
 --
 Merlyn
 Aberdeen
 Scotland
 
 

Here it's 1.0.7 (i think) and it's working under i386 and amd64
http://student.if.uj.edu.pl/Marcin.Pawlowski/openbsd/ports/wireshark.tar.gz
When I will have some free time I will update it ;-)

Cheers,
pmp

Re: Wireshark

2009-08-19 Thread merlyn 
On Monday 17 August 2009 00:51:28 stan wrote:
 I realize that there is histroy here but I really need to make this tool
 work, and OpenBSD is my OS of choice for network related functions.

 Has anyone gotten wireshark to compile on OpenBSD 4.5? I am trying to build
 version 1.2.1, if that matters.

Hi stan,
last version of Wireshark I've successfully compiled was 0.99.8.
If you'll have more good luck than me, send a patch to this mailing list.

--
Merlyn
Aberdeen
Scotland


-- 
merlyn merlyn...@gmail.com
OpenBSD Padik.invalidnivozik.cz 4.5 GENERIC.MP#108 i386
()  ascii ribbon campaign - against html e-mail 
/\  www.asciiribbon.org   - against proprietary attachments

Re: Wireshark

2009-08-19 Thread Tom Van Looy 
You can also capture the packets with tcpdump and open the pcap file in
wireshark on another platform. That's how I do it if I want to use
wireshark.

Kind regards,

Tom


merlyn wrote:
 On Monday 17 August 2009 00:51:28 stan wrote:
 I realize that there is histroy here but I really need to make this tool
 work, and OpenBSD is my OS of choice for network related functions.

 Has anyone gotten wireshark to compile on OpenBSD 4.5? I am trying to build
 version 1.2.1, if that matters.
 
 Hi stan,
 last version of Wireshark I've successfully compiled was 0.99.8.
 If you'll have more good luck than me, send a patch to this mailing list.
 
 --
 Merlyn
 Aberdeen
 Scotland

Wireshark

2009-08-17 Thread stan 
I realize that there is histroy here but I really need to make this tool
work, and OpenBSD is my OS of choice for network related functions.

Has anyone gotten wireshark to compile on OpenBSD 4.5? I am trying to build
version 1.2.1, if that matters.


-- 
One of the main causes of the fall of the roman empire was that, lacking
zero, they had no way to indicate successful termination of their C
programs.

Re: Any Ethereal, Wireshark related software in 4.2 ports?

2007-11-12 Thread Stuart Henderson 
On 2007/11/11 14:20, Ray Percival wrote:
 On Nov 11, 2007, at 10:03 AM, Barry Miller wrote:
 Of course, if a bad guy _does_ get control of wireshark, he OWNS your
 network, but at least you're not totally rooted.  Take your chances.

 How so? Given that all it is a frontend to libpcap. And how does this not 
 apply to tcpdump?

tcpdump runs the scary code in a jail.

Re: Any Ethereal, Wireshark related software in 4.2 ports?

2007-11-12 Thread Siju George 
On Nov 12, 2007 3:09 PM, Stuart Henderson [EMAIL PROTECTED] wrote:

 On 2007/11/11 14:20, Ray Percival wrote:
  On Nov 11, 2007, at 10:03 AM, Barry Miller wrote:
  Of course, if a bad guy _does_ get control of wireshark, he OWNS your
  network, but at least you're not totally rooted.  Take your chances.
 
  How so? Given that all it is a frontend to libpcap. And how does this not
  apply to tcpdump?

 tcpdump runs the scary code in a jail.



Thanks a lot Cabillot, Kevin, Barry, Ray, Bryan and Stuart for the
Detailed Information :-)

Kind Regards

Siju

Re: Any Ethereal, Wireshark related software in 4.2 ports?

2007-11-12 Thread Steve Shockley 

Stuart Henderson wrote:

tcpdump runs the scary code in a jail.


Doesn't http://marc.info/?m=117390704628262 do the same thing?  I 
haven't looked at it, just saw the post.

Re: Any Ethereal, Wireshark related software in 4.2 ports?

2007-11-12 Thread Stuart Henderson 
On 2007/11/12 12:38, Steve Shockley wrote:
 Stuart Henderson wrote:
 tcpdump runs the scary code in a jail.

 Doesn't http://marc.info/?m=117390704628262 do the same thing?  I haven't 
 looked at it, just saw the post.

ah, Nikns' port: this isn't a full jail, but it does drop privileges
so it's a start. http://wiki.wireshark.org/Development/PrivilegeSeparation
references this (so, some wireshark developers do recognise it needs to
be done).

IIRC (it's a while since I looked at it) there are some problems:
you run the whole thing as root (including the GUI, which uses
toolkits which are specifically not meant to be run as root), then
after opening the capture device privs are dropped, at which point
you can no longer access files you should have access to.

There is another hackish workaround: mkfifo a file, then use
tcpdump to do the capture into that. Run wireshark as a normal or
(better) jailed user, and read from the FIFO. Messy, though...

Anyway, this is probably of limited interest on misc@, so
if anyone is interested in continuing this, ports@ is a better
place (or the wireshark lists).

Any Ethereal, Wireshark related software in 4.2 ports?

2007-11-11 Thread Siju George 
Hi,

Both

http://www.wireshark.org/ and http://www.wireshark.org/

are not found in ports. Could somebody recommend any softwarew in 4.2
ports that has related functionality?

Thank you so much

Kind Regards

Siju

Re: Any Ethereal, Wireshark related software in 4.2 ports?

2007-11-11 Thread Cabillot Julien 
You can look at this page :
http://www.cromwell-intl.com/unix/openbsd-dell.html
(I never try)

On Nov 11, 2007 4:43 PM, Siju George [EMAIL PROTECTED] wrote:

 Hi,

 Both

 http://www.wireshark.org/ and http://www.wireshark.org/

 are not found in ports. Could somebody recommend any softwarew in 4.2
 ports that has related functionality?

 Thank you so much

 Kind Regards

 Siju




-- 
Julien Cabillot
Technicien Unix
SDV Plurimedia

Re: Any Ethereal, Wireshark related software in 4.2 ports?

2007-11-11 Thread Stuart Henderson 
 Could somebody recommend any softwarew in 4.2
 ports that has related functionality?

Netdude might be of some use (it's a front-end to tcpdump), but
I usually just use tcpdump directly (some tips: -vv to increase
verbosity, -X for a hex+ascii dump, -s## to increase snap
length to capture entire packets rather than just the headers).

 http://www.wireshark.org/ and http://www.wireshark.org/
 are not found in ports.

This is for security reasons.

The dissectors are often not coded with security in mind, which
isn't good since they usually work with untrusted network data.
For tcpdump(8) in the base system, the dissectors are run with
reduced privileges, protecting from this sort of problem, making
it safer.

Also the UI is built using libraries which are not meant to be
run with root privileges (http://www.gtk.org/setuid.html explicitly
talks about setuid root programs, but I think this would also apply
to any programs which need to run as root: In the opinion of the
GTK+ team, the only correct way to write a setuid program with a
graphical user interface is to have a setuid backend that
communicates with the non-setuid graphical user interface via
a mechanism such as a pipe and that considers the input it
receives to be untrusted.) So, really it needs to be split
into 3: UI with normal user privileges, privileged access to
the network, and reduced privilege for dissectors.

There are some wireshark ports floating around where some
work has been done towards dropping privileges, but they're
not without problems.

Re: Any Ethereal, Wireshark related software in 4.2 ports?

2007-11-11 Thread Barry Miller 
On Sun, Nov 11, 2007 at 09:13:42PM +0530, Siju George wrote:
 Both
 
 http://www.wireshark.org/ and http://www.wireshark.org/
 
 are not found in ports. Could somebody recommend any softwarew in 4.2
 ports that has related functionality?
 
If you don't mind building wireshark yourself, one way you can run it
with limited privileges is:

1. install wireshark from sources
2. groupadd shark
3. chgrp shark /wherever/wireshark /dev/bpf*
4. chmod g+s,o-x /wherever/wireshark
5. chmod g+rw /dev/bpf*
6. use sudo to grant access to wireshark

Of course, if a bad guy _does_ get control of wireshark, he OWNS your
network, but at least you're not totally rooted.  Take your chances.

--Barry

Re: Any Ethereal, Wireshark related software in 4.2 ports?

2007-11-11 Thread Ray Percival 

On Nov 11, 2007, at 10:03 AM, Barry Miller wrote:

Of course, if a bad guy _does_ get control of wireshark, he OWNS your
network, but at least you're not totally rooted.  Take your chances.

How so? Given that all it is a frontend to libpcap. And how does this  
not apply to tcpdump?

--Barry

Re: Any Ethereal, Wireshark related software in 4.2 ports?

2007-11-11 Thread Bryan Irvine 
On 11/11/07, Siju George [EMAIL PROTECTED] wrote:
 Hi,

 Both

 http://www.wireshark.org/ and http://www.wireshark.org/

 are not found in ports. Could somebody recommend any softwarew in 4.2
 ports that has related functionality?

I like ettercap.

Wireshark 0.99 on OpenBSD 3.9

2006-08-07 Thread jjhartley 
FYI.  For those contemplating installing Wireshark, the 0.99.2 snapshot 
currently available on http://www.wireshark.org/download.html does not build on 
3.9.  There has been recent discussion on wireshark-dev@ about this, and the 
latest SVN source appears to correct the problem(s):

http://www.mail-archive.com/wireshark-dev@wireshark.org/msg00328.html

The list of packages  build sequence described at the following page are still 
correct as I have successfully built what becomes Wireshark 0.99.3 from the 
latest SVN source this weekend.

http://www.cromwell-intl.com/unix/openbsd-dell.html

HTH.

Jim