Re: [tcpdump-workers] tcpdump 4.0.0 + libpcap 1.0.0 Released

[Tyson Key]

Hi, nice to see a shiny new release of libpcap and tcpdump so soon.
Out of interest, is the "tcpdump: unsupported data link type USB_LINUX"
bug/issue resolved when trying to capture USB traffic on a Linux box? (I'm
using Fedora 8 at present, with the CVS version of libpcap, although I'm
about to try this release).

Thanks, Tyson.

On Tue, Oct 28, 2008 at 2:24 AM, Ken Bantoft <[EMAIL PROTECTED]> wrote:

>
> Hi,
>
> Thanks to last minute checkins from Guy, tcpdump 4.0.0 + libpcap 1.0.0 are
> now released and available at http://www.tcpdump.org
>
> Release Notes:
> tcpdump 4.0.0 - http://www.tcpdump.org/tcpdump-changes.txt
> libpcap 1.0.0 - http://www.tcpdump.org/libpcap-changes.txt
>
>
> As always, please check the signatures with the Signing Key (available from
> http://www.tcpdump.org/tcpdump-workers.asc, or your nearest GPG Keyserver)
>
> Bugs/comments/complaints to tcpdump-workers@lists.tcpdump.org please.
>
> Ken
>
> -
> This is the tcpdump-workers list.
> Visit https://cod.sandelman.ca/ to unsubscribe.
>



-- 
Fight Internet Censorship! http://www.eff.org
  ~
Open-Source Community, and Technology Testbed: http://www.house404.co.uk/
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] tcpdump 4.0.0 + libpcap 1.0.0 Released

[Tyson Key]

Hi, thanks for the tip (it was probably an oversight on my part, since I
didn't know about that limitation).
It seems to work fine now, although I could probably do with automatically
setting the "snaplen" somehow.
Thanks.

On Tue, Oct 28, 2008 at 11:54 PM, Guy Harris <[EMAIL PROTECTED]> wrote:

>
> On Oct 28, 2008, at 2:05 PM, Tyson Key wrote:
>
>  Hi, nice to see a shiny new release of libpcap and tcpdump so soon.
>> Out of interest, is the "tcpdump: unsupported data link type USB_LINUX"
>> bug/issue resolved when trying to capture USB traffic on a Linux box?
>>
>
> If you mean "if I try to capture USB traffic on a Linux box, and don't give
> the '-w' flag to get it to write the raw traffic to a file, will it print
> 'tcpdump: unsupported data link type USB_LINUX'?", the answer is "yes",
> because nobody's written a USB printer routine for tcpdump, so it *can't*
> handle USB traffic in that case.  If that's the problem in question - which
> is more of a "lack of a feature" than a bug - it's still there.
>
> if you mwan "if I try to capture USB traffic on a Linux box, and *do* give
> the '-w' flag to get it to write the raw traffic to a file, will it print
> 'tcpdump: unsupported data link type USB_LINUX'?", the answer is "no",
> because it just dumps the traffic out without interpretation, regardless of
> whether it has a printer for the link-layer type or not, and thus can handle
> USB traffic or any other type of traffic.  If that's the problem in
> question, it's fixed.
>
> -
> This is the tcpdump-workers list.
> Visit https://cod.sandelman.ca/ to unsubscribe.
>



-- 
Fight Internet Censorship! http://www.eff.org
  ~
Open-Source Community, and Technology Testbed: http://www.house404.co.uk/
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] tcpdump 4.0.0 + libpcap 1.0.0 Released

[Tyson Key]

Hi Guy. Yes, that (defaulting to the maximum allowed by the protocol/system)
was what I'm referring to.
Also, is it considered normal for Linux 2.6.25 and above (or libpcap,
although I'm not sure exactly what to blame) to truncate large numbers of
USB packets? (I assume this has been hashed to death on the list in the
past, though).

Thanks.

On Wed, Oct 29, 2008 at 6:58 PM, Guy Harris <[EMAIL PROTECTED]> wrote:

>
> On Oct 29, 2008, at 10:48 AM, Tyson Key wrote:
>
>  It seems to work fine now, although I could probably do with automatically
>> setting the "snaplen" somehow.
>>
>
> I.e., defaulting to the maximum (65535) rather than the current default of
> 64 (without IPv6) or 96 (with IPv6)?
>
> At least one OS that distributes tcpdump has considered making the default
> 65535.  Should the default be 65535, especially given that, the "tcp" in
> "tcpdump" nonwithstanding, it's used to do more than just look at TCP
> behavior?
>
> -
> This is the tcpdump-workers list.
> Visit https://cod.sandelman.ca/ to unsubscribe.
>



-- 
Fight Internet Censorship! http://www.eff.org
  ~
Open-Source Community, and Technology Testbed: http://www.house404.co.uk/
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] tcpdump 4.0.0 + libpcap 1.0.0 Released

[Tyson Key]

Bad form to reply to my own mail, I know, although the output of "tcpdump
-V" is as follows if it helps:
tcpdump version 3.9-PRE-CVS_2008_10_27
libpcap version 0.9-PRE-CVS

Thanks.

On Thu, Oct 30, 2008 at 12:33 PM, Tyson Key <[EMAIL PROTECTED]> wrote:

> Hi again, Guy. I've just been doing some strace-ing, and it appears to
> doing a "open("/dev/usbmon2", O_RDONLY|O_LARGEFILE) = 3". Not sure if the
> script log will be of use to you, although I'll attach it anyway.
> Going to try the printf() kludge soon.
>
> Tyson.
>
>
> On Thu, Oct 30, 2008 at 12:27 AM, Guy Harris <[EMAIL PROTECTED]> wrote:
>
>>
>> On Oct 29, 2008, at 1:16 PM, Tyson Key wrote:
>>
>>  Also, is it considered normal for Linux 2.6.25 and above (or libpcap,
>>> although I'm not sure exactly what to blame) to truncate large numbers of
>>> USB packets? (I assume this has been hashed to death on the list in the
>>> past, though).
>>>
>>
>> Paolo?  Could it be using the text interface rather than the binary
>> interface?  I think I remember you indicating that the text interface
>> doesn't supply the full packet.
>>
>> Tyson, you said you were using the CVS version of libpcap (presumably
>> meaning top-of-tree CVS, the pcap-usb-linux.c of which is identical to 1.0's
>> pcap-usb-linux.c), so presumably you built it from source.  You might want
>> to stick some debugging printfs into usb_activate() to see whether it uses
>> mmap access to the binary interface, non-mmap access to the binary
>> interface, or the text interface.
>>
>> -
>> This is the tcpdump-workers list.
>> Visit https://cod.sandelman.ca/ to unsubscribe.
>>
>
>
>
> --
> Fight Internet Censorship! http://www.eff.org
>   ~
> Open-Source Community, and Technology Testbed: http://www.house404.co.uk/
>



-- 
Fight Internet Censorship! http://www.eff.org
  ~
Open-Source Community, and Technology Testbed: http://www.house404.co.uk/
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] [Patch/Workaround?] pcap-usb-linux.c

[Tyson Key]

Hi Jean-Louis, does libpcap compile with the supplied patch for you?
It applied cleanly here, although I can't complete the ./configure phase
(the error produced is below):
./pcap-usb-linux.c: In function 'usb_read_linux_mmap':
./pcap-usb-linux.c:708: error: 'clen' undeclared (first use in this
function)
./pcap-usb-linux.c:708: error: (Each undeclared identifier is reported only
once
./pcap-usb-linux.c:708: error: for each function it appears in.)
make: *** [pcap-usb-linux.o] Error 1

Thanks.

On Thu, Oct 30, 2008 at 11:48 AM, Jean-Louis <[EMAIL PROTECTED]> wrote:

> Jean-Louis ha scritto:
>
>> Jean-Louis ha scritto:
>
>> today I have found some bug on pcap-usb-linux.c
>>>
>>> now i can try to tell you which are
>>>
>>>
>> in accordance with usbmon.txt in "mmap mode" the data is at
>>
>> &mmap_area[vec[i]] + 64;
>>
>> rather than
>>
>> &mmap_area[vec[i]] + 48;
>>
>> with mmap ther'is 16Byte filled with 0 first to the real data...
>>
>> so if i.e. I have caplen = 18Byte, in file.pcap I have 16Byte with garbage
>> (0x00) and only 2Byte with real data other 16Byte of real data is lost.
>>
>> the mmap mode is *default* with kernel >= 2.6.25-rc8-mm1
>>
>> I'm newbie with libpcap and I don't know how I can fix that without
>> degrading performance
>>
>
> I have patched this bug, but seems to be workaround-ish
>
> so now pcap file is ok
>
> -
> This is the tcpdump-workers list.
> Visit https://cod.sandelman.ca/ to unsubscribe.
>
>


-- 
Fight Internet Censorship! http://www.eff.org
  ~
Open-Source Community, and Technology Testbed: http://www.house404.co.uk/
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] tcpdump 4.0.0 + libpcap 1.0.0 Released

[Tyson Key]

Hi again, Guy. I've just been doing some strace-ing, and it appears to doing
a "open("/dev/usbmon2", O_RDONLY|O_LARGEFILE) = 3". Not sure if the script
log will be of use to you, although I'll attach it anyway.
Going to try the printf() kludge soon.

Tyson.

On Thu, Oct 30, 2008 at 12:27 AM, Guy Harris <[EMAIL PROTECTED]> wrote:

>
> On Oct 29, 2008, at 1:16 PM, Tyson Key wrote:
>
>  Also, is it considered normal for Linux 2.6.25 and above (or libpcap,
>> although I'm not sure exactly what to blame) to truncate large numbers of
>> USB packets? (I assume this has been hashed to death on the list in the
>> past, though).
>>
>
> Paolo?  Could it be using the text interface rather than the binary
> interface?  I think I remember you indicating that the text interface
> doesn't supply the full packet.
>
> Tyson, you said you were using the CVS version of libpcap (presumably
> meaning top-of-tree CVS, the pcap-usb-linux.c of which is identical to 1.0's
> pcap-usb-linux.c), so presumably you built it from source.  You might want
> to stick some debugging printfs into usb_activate() to see whether it uses
> mmap access to the binary interface, non-mmap access to the binary
> interface, or the text interface.
>
> -
> This is the tcpdump-workers list.
> Visit https://cod.sandelman.ca/ to unsubscribe.
>



-- 
Fight Internet Censorship! http://www.eff.org
  ~
Open-Source Community, and Technology Testbed: http://www.house404.co.uk/
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] [Patch/Workaround?] pcap-usb-linux.c

[Tyson Key]

Hi Jean-Louis, just applied the patches and it compiles and installs
successfully.
Still looks like certain packets are being truncated (mostly URB_ISOCHRONOUS
ones from what I can tell).
Thanks.

On Thu, Oct 30, 2008 at 4:33 PM, Jean-Louis <[EMAIL PROTECTED]> wrote:

> Tyson Key ha scritto:
>
>> Hi Jean-Louis, does libpcap compile with the supplied patch for you?
>> It applied cleanly here, although I can't complete the ./configure phase
>> (the error produced is below):
>> ./pcap-usb-linux.c: In function 'usb_read_linux_mmap':
>> ./pcap-usb-linux.c:708: error: 'clen' undeclared (first use in this
>> function)
>> ./pcap-usb-linux.c:708: error: (Each undeclared identifier is reported
>> only
>> once
>> ./pcap-usb-linux.c:708: error: for each function it appears in.)
>> make: *** [pcap-usb-linux.o] Error 1
>>
>> Thanks.
>>
>>
> Hi Tyson, the clen definition is in patch 4_4
>
> applied the patch in order: 1_4, 2_4, 3_4, 4_4, 1_1
>
>
> -
> This is the tcpdump-workers list.
> Visit https://cod.sandelman.ca/ to unsubscribe.
>



-- 
Fight Internet Censorship! http://www.eff.org
  ~
Open-Source Community, and Technology Testbed: http://www.house404.co.uk/
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] [Patch/Workaround?] pcap-usb-linux.c

[Tyson Key]

Hi Jean-Louis, I'm currently using the patched version of tcpdump/libpcap to
capture traffic, and Wireshark to dissect/view it. I do intend to do
capturing with Wireshark though, when I've got round to recompiling it
against the new libpcap.
Thanks.

On Thu, Oct 30, 2008 at 6:18 PM, Jean-Louis <[EMAIL PROTECTED]> wrote:

> Jean-Louis ha scritto:
>
>> Tyson Key ha scritto:
>>
>>> Hi Jean-Louis, just applied the patches and it compiles and installs
>>> successfully.
>>> Still looks like certain packets are being truncated (mostly
>>> URB_ISOCHRONOUS
>>> ones from what I can tell).
>>> Thanks.
>>>
>>>
>> now also the mmap mode have snaplen limitation...
>>
>> try to capture traffic with -s 0 tcpdump option.
>>
>> i.e. tcpdump -i2 -w file.pcap -s 0
>>
>> if you would make default maximum, look #DEFINE of DEFAULT_SNAPLEN
>> in tcpdump/interface.h and tcpdump/netdissect.h
>>
>> I have found this with
>>
>> find -name "*.[ch]" | xargs grep "DEFAULT_SNAPLEN"
>>
>
> only one question: what you are using for dissect packets?
>
> If response is whireshark, in the dissector for usb raw traffic ther'is
> some workaround and misunderstood of usb specification... I don't know if
> "truncate packet" say in whireshark is attendible. If I have free time, this
> week, I would try to fix this dissector.
>
> -
> This is the tcpdump-workers list.
> Visit https://cod.sandelman.ca/ to unsubscribe.
>



-- 
Fight Internet Censorship! http://www.eff.org
  ~
Open-Source Community, and Technology Testbed: http://www.house404.co.uk/
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] how to merge pcap files?

[Tyson Key]

Hi, you can use the mergecap utility supplied with Wireshark.
Hope that helps.

Tyson

On 11/12/08, hossein talebi <[EMAIL PROTECTED]> wrote:
> Hi
> how to merge pcap files saved by -w option?
>
> --
> Talebi Mazraeh Shahi Hossein
> -
> This is the tcpdump-workers list.
> Visit https://cod.sandelman.ca/ to unsubscribe.
>

-- 
Sent from Google Mail for mobile | mobile.google.com

Fight Internet Censorship! http://www.eff.org
   ~
Open-Source Community, and Technology Testbed: http://www.house404.co.uk/
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] any device doesn't work anymore

[Tyson Key]

Hi Giovanni, I don't know for certain what's happened either, although I can
confirm that after installing libpcap version 0.9-PRE-CVS (from Git), the
any device is no longer available.
Hopefully a fix will come from someone soon.

Slightly off-topic: The Bluetooth capturing devices don't; seem to work
properly either (they don't appear in the device list until I start a PPP
session for some reason, and even then, no packets are collected despite
being counted).

Tyson.

On Mon, Nov 17, 2008 at 11:15 PM, Giovanni Venturi <[EMAIL PROTECTED]>wrote:

> As reported in man:
>
> pcap_create() is used to create a packet capture handle to look at packets
> on
> the network. source is a string that specifies the network device to open;
> on
> Linux systems with 2.2 or later kernels, a source argument of "any" or NULL
> can be used to capture packets from all interfaces.
>
> block1:
>  if ((m_pcapfp = pcap_create("any", errbuf)) == NULL)
>cout << "NULL";
>  pcap_set_snaplen(m_pcapfp, PKTMAX);
>  pcap_set_promisc(m_pcapfp, 0);
>  pcap_activate(m_pcapfp);
>
> block2:
>  if (pcap_open_live("any", PKTMAX, 0, -1, errbuf) == NULL)
>  {cout << errbuf; return;}
>
> just block told me that:
>
> SIOCGIFHWADDR: No such device
>
> All what worked before doesn't work now anymore. :(
>
> If I use NULL no block tell me that there is a problem. I got crash on
> (FD_SET):
>
> #ifdef HAVE_PCAP_GET_SELECTABLE_FD
>m_pcap_fd = pcap_get_selectable_fd(m_pcapfp);
> #else
>m_pcap_fd = pcap_fileno(m_pcapfp);
> #endif
>
> FD_ZERO(&m_fdset);
> FD_SET(m_pcap_fd, &m_fdset);
>
>
> What's happening?
>
> Giovanni
>
> --
> A KDE Italian translator and KSniffer core developer
> Slackware GNU/Linux current version - kernel 2.6.27.4
> KSniffer Project - http://www.ksniffer.org/
>



-- 
Fight Internet Censorship! http://www.eff.org
  ~
Open-Source Community, and Technology Testbed: http://www.house404.co.uk/
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] [BUG] pcap-usb-linux.c

[Tyson Key]

Hi, any chance that a "usbany" (or similar) pseudo-device could be added in
a future version to capture on all USB buses, similar to the standard "any"
device for non-USB interfaces?

Thanks, Tyson.

On Mon, Nov 24, 2008 at 8:10 PM, Guy Harris <[EMAIL PROTECTED]> wrote:

>
> On Oct 29, 2008, at 7:38 PM, Jean-Louis wrote:
>
>  in accordance with usbmon.txt in "mmap mode" the data is at
>>
>> &mmap_area[vec[i]] + 64;
>>
>> rather than
>>
>> &mmap_area[vec[i]] + 48;
>>
>> with mmap ther'is 16Byte filled with 0 first to the real data...
>>
>> so if i.e. I have caplen = 18Byte, in file.pcap I have 16Byte with garbage
>> (0x00) and only 2Byte with real data other 16Byte of real data is lost.
>>
>> the mmap mode is *default* with kernel >= 2.6.25-rc8-mm1
>>
>> I'm newbie with libpcap and I don't know how I can fix that without
>> degrading performance
>>
>
> The only way to fix that without doing a lot of copying would be to add a
> new DLT_ value for Linux mmapped access, with the USB header defined to
> include the padding (and change apps that handle USB captures to handle the
> new DLT_ value).-
>
> This is the tcpdump-workers list.
> Visit https://cod.sandelman.ca/ to unsubscribe.
>



-- 
Fight Internet Censorship! http://www.eff.org
  ~
Open-Source Community, and Technology Testbed: http://i9.house404.co.uk/
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] make releasetar on libpcap

[Tyson Key]

On Fri, Mar 5, 2010 at 6:59 PM, Michael Richardson  wrote:

>
> > "Guy" == Guy Harris  writes:
>Guy> The Makefile has a rule to "generate" it, so I'd see that as
>Guy> OK.  (It also means that "make clean" would remove the symlink,
>Guy> which is arguably the right thing for it to do.)
>
>>> The other way is to make releasetar: depend upon bpf_filter.c, so
>>> that the symlink is shipped, but I think we shouldn't ship the
>>> symlink.
>
> Guy> Or we could just get rid of the bpf/net directory entirely, and
>Guy> move bpf_filter.c to the top-level directory; we already have
>Guy> bpf_dump.c and bpf_image.c there.  I assume part of the
>Guy> rationale there was to put the stuff that could go into an OS
>Guy> kernel into a subdirectory, but we've already moved most of the
>Guy> files out of there, and the developers of the OSes that don't
>Guy> already have a BPF interpreter can probably figure out what
>Guy> pieces they need and put them into the source tree
>Guy> appropriately.
>
> Yeah, lets do this.
>
> --
> ]   He who is tired of Weird Al is tired of life!   |
>  firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net
> architect[
> ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device
> driver[
>   Kyoto Plus: watch the video 
>   then sign the petition.
> -
> This is the tcpdump-workers list.
> Visit https://cod.sandelman.ca/ to unsubscribe.
>



-- 
Fight Internet Censorship! http://www.eff.org
  ~
http://i9.house404.co.uk/ | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] tcpdump license and Nokia

[Tyson Key]

Hi Chris,

As far as I'm aware, TCPDump is released under the terms of the BSD Licence
- meaning that Nokia haven't got any obligations regarding releasing their
modifications; and whilst it's not the most reliable information source on
the planet, Wikipedia seems to corroborate that thought.

I hope that helps,

Tyson.

On 21 December 2011 16:20, Chris Maynard  wrote:

> If I visit http://www.wireshark.org/, I can find the GPL license without
> too
> much searching at the bottom of this page:
> http://www.wireshark.org/about.html.
>  I can't seem to find the tcpdump/libpcap license mentioned anywhere on
> http://www.tcpdump.org/.  Is it mentioned somewhere and I'm just missing
> it?
>
> The reason I bring this up is because I believe Nokia has modified tcpdump
> and
> is including it with their IPSO software.  Tcpdump is GPL'd, isn't it?  So
> Nokia
> should be making their modified tcpdump sources available; yet I can't
> seem to
> find it available for download anywhere.
>
> Thanks.
> - Chris
>
>
> -
> This is the tcpdump-workers list.
> Visit https://cod.sandelman.ca/ to unsubscribe.
>



-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] tcpdump license and Nokia

[Tyson Key]

For what it's worth, you could try asking Petra Söderling (
petra.soderl...@nokia.com) - who happens to head some of the Open Source
initiatives at Nokia.

Tyson.

On 21 December 2011 16:20, Chris Maynard  wrote:

> If I visit http://www.wireshark.org/, I can find the GPL license without
> too
> much searching at the bottom of this page:
> http://www.wireshark.org/about.html.
>  I can't seem to find the tcpdump/libpcap license mentioned anywhere on
> http://www.tcpdump.org/.  Is it mentioned somewhere and I'm just missing
> it?
>
> The reason I bring this up is because I believe Nokia has modified tcpdump
> and
> is including it with their IPSO software.  Tcpdump is GPL'd, isn't it?  So
> Nokia
> should be making their modified tcpdump sources available; yet I can't
> seem to
> find it available for download anywhere.
>
> Thanks.
> - Chris
>
>
> -
> This is the tcpdump-workers list.
> Visit https://cod.sandelman.ca/ to unsubscribe.
>



-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] [Wireshark-dev] tcpdump-workers mailing list troubles

[Tyson Key]

I happened to have received this one, for what it's worth...

Tyson.

2012/4/21 Christopher Maynard 

> Guy Harris  alum.mit.edu> writes:
>
> > On Apr 18, 2012, at 3:05 PM, Sam Roberts wrote:
> >
> > > For what its worth, the last message I saw was on Mar 13th, thought I
> > > have 2 or 3 more messages than I can see on
> > > http://news.gmane.org/gmane.network.tcpdump.devel
> > >
> > > I'm CCing tcpdump-workers, I'll see if I have the problem, too.
> >
> > For what it's worth, this message just arrived in my mailbox from
> tcpdump-workers; it arrived from
> > wireshark-dev a couple of days ago.
>
> Very strange things seem to be happening.
>
> Since your response was CC'd to wireshark-dev, the threading seems to have
> broken.
>
> Compare threading: http://news.gmane.org/gmane.network.wireshark.devel
> Vs. blog-like, flat interface:
> http://comments.gmane.org/gmane.network.wireshark.devel/25291
>
>
> But nothing about these messages seems to appear on tcpdump-devel, either
> threaded or blog-like:
>
> Threaded: http://news.gmane.org/gmane.network.tcpdump.devel
> Blog-like: http://blog.gmane.org/gmane.network.tcpdump.devel
>
> But then on the left-hand side of the blog page, there's a calendar,
> currently
> "April 2012" where each day of the month where there are messages posted
> being
> clickable to bring up those messages for that day.  For April, only the
> 21st is
> clickable and only Guy's post shows up.  But why doesn't it appear on the
> threaded or blog-like page w/out selecting the 21st?
>
> There seem to have been a lot of lost messages ... in fact, this one might
> be as
> well, in which case I'm just typing to myself ... again.
>
> - Chris
>
>
> -
> This is the tcpdump-workers list.
> Visit https://cod.sandelman.ca/ to unsubscribe.
>



-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.