On Wed, Jul 06, 2011 at 11:00:25PM +0200, Romain Francoise wrote:
> Yes, I was planning a s-p-u upload to address this (and also #612803), but
> the fix needs further changes to address #625443. Upstream made the
> required changes in Git, I just have to backport them to our version.
Great, thanks
Hi,
Yes, I was planning a s-p-u upload to address this (and also #612803), but
the fix needs further changes to address #625443. Upstream made the
required changes in Git, I just have to backport them to our version.
Regarding an update in lenny: as far as I can tell the combination of
lenny's ke
Dear maintainer,
Recently you fixed one or more security problems and as a result you closed
this bug. These problems were not serious enough for a Debian Security
Advisory, so they are now on my radar for fixing in the following suites
through point releases:
lenny (5.0.9)
squeeze (6.0.2)
Pleas
Romain Francoise wrote:
> Robert Edmonds writes:
>
> > for instance, a snapshot length of 1514 actually results in only a
> > maximum of 1498 bytes being captured, so those who think they are
> > doing "full packet capture" actually are not, thus breaking TCP
> > stream reassembly and IP defragme
Robert Edmonds writes:
> for instance, a snapshot length of 1514 actually results in only a
> maximum of 1498 bytes being captured, so those who think they are
> doing "full packet capture" actually are not, thus breaking TCP
> stream reassembly and IP defragmentation, potentially blinding
> sens
Romain Francoise wrote:
> Robert Edmonds writes:
>
> > attached is a backport of this commit to 1.1.1, and a patch to the
> > debian package containing the fix.
>
> Thanks, I'll merge this for the next upload.
>
> However, I don't think this issue is really "grave". It doesn't
> cause data loss
Robert Edmonds writes:
> attached is a backport of this commit to 1.1.1, and a patch to the
> debian package containing the fix.
Thanks, I'll merge this for the next upload.
However, I don't think this issue is really "grave". It doesn't
cause data loss, it just results in less data than reques
Processing commands for cont...@bugs.debian.org:
> tag 623868 + patch
Bug #623868 [libpcap0.8] snapshot length corruption on live captures
Added tag(s) patch.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
623868: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=
tag 623868 + patch
thanks
Robert Edmonds wrote:
> this is fixed in upstream commit ea9432fabdf4b33cbc76d9437200e028f1c47c93,
> "Fix the calculation of the frame size in memory-mapped captures."
attached is a backport of this commit to 1.1.1, and a patch to the
debian package containing the fix.
Package: libpcap0.8
Version: 1.1.1-2
Severity: grave
Tags: squeeze sid
Justification: causes data loss
see: http://thread.gmane.org/gmane.network.tcpdump.devel/5018
this can be trivially reproduced on squeeze or sid:
edmonds@zappa{0}:~$ tcpdump --version
tcpdump version
10 matches
Mail list logo
