Re: [Wireshark-dev] Can Wireshark "tail" a capture file?

[Jeff Morriss]

Jose Graziani wrote:
> Can Wireshark tail a file that is continuously been updated by a third 
> party capture device?

No.  It can read from a pipe or named pipe, though (at least on UN*X).
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

[Wireshark-dev] Update title of flow graph save dialog

[Stephen Fisher]

A user asked what file format the flow graph is saved as, which isn't 
apparent by looking at the dialog.  I had to try saving a file and check 
its type -- plain text file.  Could someone please apply the attached 
patch or similar change to graph_analysis.c.  My patch updates the title 
of the dialog box from "Wireshark: Save graph to file" to "Wireshark: 
Save graph to text file".


Steve

Index: gtk/graph_analysis.c
===
--- gtk/graph_analysis.c(revision 19441)
+++ gtk/graph_analysis.c(working copy)
@@ -564,7 +564,7 @@
return;
}
 
-   save_to_file_w = gtk_file_selection_new("Wireshark: Save graph to 
file");
+   save_to_file_w = gtk_file_selection_new("Wireshark: Save graph to text 
file");
 
/* Container for each row of widgets */
vertb = gtk_vbox_new(FALSE, 0);
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

[Wireshark-dev] Can Wireshark "tail" a capture file?

[Jose Graziani]

Can Wireshark tail a file that is continuously been updated
by a third party capture device?

 

Thanks. 






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

[Wireshark-dev] urgent ur kind attention please....

[upasana saxena]

hi everybody...
 
I m in need of some help from any one of u all.
 
Actually I want to know that how we can get network statistics or information of packets from a particular ip address.using ethereal...
 
please guide me properly step wiseactually I m not getting it using it...
 
plz tell me also abt what r the recent developmants going on??I m also desiring to develop some new module in it...
 
I will be very thankful to u all.
Plz reply me as soon as possible..
 
regards...
Upasana___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] problems with fragmented reassembly on tcp

[Tomasz Noiński]

On Wed, 4 Oct 2006 23:22:37 -0700
"John R." <[EMAIL PROTECTED]> wrote:

> Keep in mind that desegment_tcp (which calls the application layer
> dissector, which can call tcp_dissect_pdus) is broken in the case that
> the minimal header spans a tcp segment boundary.

That's nice to know it's a known problem.

I think I described a similar issue in another thread (Message-Id: <[EMAIL 
PROTECTED]>).

In case someone has trouble reproducing this behaviour, I think I have a ready 
example:

http://sphere.pl/~noix/wireshark/packet-noix.c <-- almost "hello world" - a 
dissector of a bogus protocol where PDUs are separated by \0 ("c strings") - 
based on an example from README.developer (which doesn't work)

http://sphere.pl/~noix/wireshark/noix2.pcap <-- a simple packet dump which 
proves this dissector not working

I also tried to read and undestand desegment_tcp, but I wasn't smart or patient 
enough.

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

Re: [Wireshark-dev] bug in packet-bgp.c (Ethereal) and print-bgp.c (tcpdump) (fwd)

[Jaap Keuter]

Hi,

Checked in.

Thanx,
Jaap

On Fri, 6 Oct 2006, Aaron Campbell wrote:

> The expression (BGP_OSPF_RTYPE_EXT ||BGP_OSPF_RTYPE_NSSA) will always
> evaluate to 1.  As well, neither of these constants are defined as flag
> values, so a bitwise op was probably not intended either.
>
> Commit log for packet-bgp.c in Ethereal shows that this code originated
> from Aamer Akhter, and was later ported to tcpdump by Hannes Gredler.  I
> have already received notice from Hannes that he has committed a fix:
>
> http://cvs.tcpdump.org/cgi-bin/cvsweb/tcpdump/print-bgp.c
>
> Below is my attempt to fix the code in Ethereal.  Is it correct?  (This is
> untested, I don't have a trace to test with.)
>
> --- packet-bgp.c.orig Thu Oct  5 19:59:25 2006
> +++ packet-bgp.c  Thu Oct  5 20:00:40 2006
> @@ -2268,7 +2268,7 @@
>   /* always print E2 even if not external route 
> -- receiving router should ignore */
>  if ( (tvb_get_guint8(tvb,q+7)) & 
> BGP_OSPF_RTYPE_METRIC_TYPE ) {
>  junk_gbuf_ptr += 
> g_snprintf(junk_gbuf_ptr, MAX_STR_LEN-(junk_gbuf_ptr-junk_gbuf), " E2");
> -} else if 
> (tvb_get_guint8(tvb,q+6)==(BGP_OSPF_RTYPE_EXT ||BGP_OSPF_RTYPE_NSSA ) ) {
> +} else if ( 
> (tvb_get_guint8(tvb,q+6)==BGP_OSPF_RTYPE_EXT) || 
> (tvb_get_guint8(tvb,q+6)==BGP_OSPF_RTYPE_NSSA) ) {
>  junk_gbuf_ptr += 
> g_snprintf(junk_gbuf_ptr, MAX_STR_LEN-(junk_gbuf_ptr-junk_gbuf), " E1");
>  } else {
>   junk_gbuf_ptr += g_snprintf(junk_gbuf_ptr, 
> MAX_STR_LEN-(junk_gbuf_ptr-junk_gbuf), ", no options");
>
> ---
> Aaron Campbell <[EMAIL PROTECTED]>
> Software Engineer, Arbor Networks, Inc.
>

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

[Wireshark-dev] bug in packet-bgp.c (Ethereal) and print-bgp.c (tcpdump) (fwd)

[Aaron Campbell]

The expression (BGP_OSPF_RTYPE_EXT ||BGP_OSPF_RTYPE_NSSA) will always
evaluate to 1.  As well, neither of these constants are defined as flag
values, so a bitwise op was probably not intended either.

Commit log for packet-bgp.c in Ethereal shows that this code originated
from Aamer Akhter, and was later ported to tcpdump by Hannes Gredler.  I
have already received notice from Hannes that he has committed a fix:

http://cvs.tcpdump.org/cgi-bin/cvsweb/tcpdump/print-bgp.c

Below is my attempt to fix the code in Ethereal.  Is it correct?  (This is
untested, I don't have a trace to test with.)

--- packet-bgp.c.orig   Thu Oct  5 19:59:25 2006
+++ packet-bgp.cThu Oct  5 20:00:40 2006
@@ -2268,7 +2268,7 @@
/* always print E2 even if not external route 
-- receiving router should ignore */
 if ( (tvb_get_guint8(tvb,q+7)) & 
BGP_OSPF_RTYPE_METRIC_TYPE ) {
 junk_gbuf_ptr += g_snprintf(junk_gbuf_ptr, 
MAX_STR_LEN-(junk_gbuf_ptr-junk_gbuf), " E2");
-} else if 
(tvb_get_guint8(tvb,q+6)==(BGP_OSPF_RTYPE_EXT ||BGP_OSPF_RTYPE_NSSA ) ) {
+} else if ( 
(tvb_get_guint8(tvb,q+6)==BGP_OSPF_RTYPE_EXT) || 
(tvb_get_guint8(tvb,q+6)==BGP_OSPF_RTYPE_NSSA) ) {
 junk_gbuf_ptr += g_snprintf(junk_gbuf_ptr, 
MAX_STR_LEN-(junk_gbuf_ptr-junk_gbuf), " E1");
 } else {
junk_gbuf_ptr += g_snprintf(junk_gbuf_ptr, 
MAX_STR_LEN-(junk_gbuf_ptr-junk_gbuf), ", no options");

---
Aaron Campbell <[EMAIL PROTECTED]>
Software Engineer, Arbor Networks, Inc.



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

Re: [Wireshark-dev] [Patch] Re: capture from a fifo

[Richard van der Hoff]

Any thoughts on this? Ulf, in particular? At the very least, a 
clarification of the direction this code is supposed to be going would 
be appreciated.

To summarise the story so far:

- capture from a fifo doesn't work for tshark
- I proposed a patch to make tshark use capture_loop_dispatch rather 
than pcap_dispatch, which handles this more gracefully (and removed some 
common code between tshark and dumpcap)
- Ulf rejected this as he felt it was a retrograde step
- I disagree, and don't understand how he would prefer to have the bug 
fixed.

Thanks,

Richard


Richard van der Hoff wrote:
> Ulf Lamping wrote:
>> Richard van der Hoff wrote:
>>> Richard van der Hoff wrote:
 [tshark from a fifo]
 Ulf - I notice you made the relevant change here (r16787) - is there 
 any reason why tshark shouldn't use capture_loop_dispatch to do its 
 processing, rather than attempting to use cap_pipe_dispatch or 
 pcap_dispatch directly?
>>> well, there didn't seem to be, so I've made a patch which does exactly 
>>> this, and which fixes the problem.
>>>
>>> I've even gone so far as to add a unit test for it :).
>>>
>>> Please could this be applied?
>>>
>> Hi Richard, sorry for the very late response!
>>
>> Yes, there are reasons to use the same code for Wireshark and Tshark:
>>
>> - having duplicated and slightly different code for the same task is a 
>> bad thing (unless there are *very* good reasons to do so)
> 
> Of course; however I rather felt that I was making the code closer to 
> what was done in Wireshark, rather than the opposite! I appreciate 
> there's a long way to go, but still - making both dumpcap and tshark use 
> capture_loop_dispatch seemed an improvement.
> 
>> - these were the first steps towards privilege seperation (which are 
>> mostly finished in Wireshark but needs to be finished in Tshark)
> 
> As in, the intention is to make tshark use dumpcap as well? Fair enough, 
> but (a) I don't see how the change to cap_pipe_dispatch and 
> pcap_dispatch is a helpful step along this path, and (b) I'd still like 
> a fix to this problem in the short term!
> 
> Thanks,
> 
> Richard
> 
> 


-- 
Richard van der Hoff <[EMAIL PROTECTED]>
Project Manager
Tel: +44 (0) 845 666 7778
http://www.mxtelecom.com
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

[Wireshark-dev] wireshark.desktop

[Stephen Fisher]

Should wireshark.desktop be installed with "make install"?  I noticed 
that Gaim installs its .desktop file at make install into 
/usr/local/share/applications/ on my FreeBSD machine with Gnome (is that 
the standard directory?).  Also, its icon "wireshark.png" is not found.


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

Re: [Wireshark-dev] New dissector for Enea's LINX protocol

[Martin Peylo]

Hi,

I'm busy with other tasks right now but I'll add the protocol to the
Wiki and upload sample captures within the next days!

Regards,
Martin



On 10/5/06, Jaap Keuter <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Now that we've added your dissector to the repository could you write up a
> protocol page in the Wiki? Oh, the sample capture goes onto SampleCaptures
> of course.
>
> Thanx,
> Jaap
>
> On Wed, 4 Oct 2006, Martin Peylo wrote:
>
> > Hi,
> >
> > could anybody please check the attached dissector for Enea's LINX
> protocol?
> >
> > A protocol spec is available at
> > . The source of
> > the kernel module could be obtained from Enea by sending a request to
> > "linx at enea dot com".
> >
> > Currently they use ethertype 0x which is not registered at IEEE. I
> > was told they requested one - what should to be done about that?
> >
> > Please come back to me with any remarks!
> >
> > Regards,
> > Martin
> >
>
> ___
> Wireshark-dev mailing list
> Wireshark-dev@wireshark.org
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev