Re: [tcpdump-workers] Request for new DLT value for Wireshark Dissector
On Feb 4, 2011, at 1:59 AM, Schemmel, Hans-Christoph wrote: > The parts that don´t correspond to a PPP packet are AT commands or responses > (like "ATI", "AT+CSQ" or "+CSQ: 18,99"). This content is interpreted and > displayed as raw text in the Wireshark subtree for the payload/information of > a > packet. These commands and responses don´t need to be dissected. ...lthough it might be interesting information, so it might be worth showing it as text. For link-layer types that don't correspond to published standards, I like to have a description in bpf.h, so that people know how to dissect the link-layer header (and know not to use the link-layer type if the header isn't exactly the same); should I just describe the holes as "other data", so you're not constrained to forever make them all be AT command/response text, or is it guaranteed (now and forever) to be AT-command-or-response text?- This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] A puzzled maintainer with questions regarding
On Feb 4, 2011, at 12:25 AM, M.Baris Demiray wrote: > In fact this is not what STANAG 5066 Annex H "Implementation Guide and > Notes" section suggests. According to this section and the tests held > by DRA (Defence Research Agency), > > 1) The throughput is not strongly sensitive to frame size > 2) 200 bytes is a good 'compromise' selection for frame size > > Besides, STANAG 5066 has the ability of doing DRC (Data Rate Change) > in accordance with SNR values so what is suggested by that white > paper, I think, is not applicable. That's somewhat of an implementation detail that shouldn't affect code that tries to dissect those packets. > Precisely. Yet may be a little clarification is needed. You might have > noticed that in my first e-mail I mentioned about DTS (Data Transfer > Sublayer) and that one of our dissector methods has the name > dissect_s5066dts() but now we are talking about MAC layer and all this > may look like a confusion but it is not. As explained in Isode white > paper there are three versions of STANAG 5066. MAC (Medium Access > Control) layer was introduced in Edition 2 (which was later renamed as > Edition 3) and designated to manage HF modem interface that DTS was > designated to do the same before. So is there a publicly-available specification that documents what the packets using this link-layer type look like?- This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] The network is cut with tcpdump.
On Feb 3, 2011, at 10:36 AM, Masahiro Kamikubo wrote: > When the tcpdump command was executed hereafter, the network was cut. "Cut" meaning that you lost network connection on the network interface on which you were capturing network traffic? If so, that might be a problem with... > The environment is CnetOS5.5 that operates on VMware Player. ...VMware's emulated network adapter on the virtual machine. You might want to ask VMware about it. > Is there a problem in the format of the command? No. tcpdump doesn't do anything to disable a network interface; it uses libpcap, which also doesn't do anything that should disable a network interface (except perhaps turn monitor mode on, which *might* disassociate the adapter from the network, but that only applies to Wi-Fi interfaces). > Mar 2 02:07:49 localhost kernel: audit(1299049669.539:3): dev=eth0 prom=256 > old_prom=0 auid=4294967295 ses=4294967295 I guess it's saying "I've turned promiscuous mode on". Try running tcpdump with the "-p" flag, which leaves promiscuous mode *off* (the default is to turn it on). If that fixes the problem, report this to the people at VMware, telling them that your network connection goes away when you put a guest network interface into promiscuous mode. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] HUGE packet-drop
On Jan 31, 2011, at 10:56 AM, Jesper Dangaard Brouer wrote:
> M. V. yahoo.com> writes:
>
>> so, i dont know what else to do, seems like nothing works for me :-S
>> 1) does anyone have any other suggestions that may help?
>> 2) about MMAP support in Debian kernel: i installed Debian5.0.3 from
>> original
>> ISO file. does anyone know if MMAP exists in its kernel by default? how can
>> i
>> get sure about that?
>
> The easiest way to see if you are using the MMAPed version is to look in:
> /proc/net/ptype
>
> Your are using the MMAP version if the Function "tpacket_rcv" is listed (while
> you perform a tcpdump). Notice the "t" in front of "packet_rcv", if the "t" is
> missing, then you are using the old/normal version.
>
> If I remember correctly, you need at least libpcap 1.0.0 to have
> MMAP/tpacket_rcv support.
You need at least libpcap 1.0.0 to have tpacket ("turbo-packet", right?)
support in the standard libpcap. You could also get it with the Phil Wood
patches he mentioned, although that only supports memory-mapped access on
Linux, not FreeBSD - but he's using Linux, so that doesn't apply (well, unless
it's Debian GNU/kFreeBSD or whatever they're calling it :-)).
> And I think that if you compile libpcap on a Debian 5.0/lenny, you will not
> get
> MMAP support, because this Debian has to old version of the kernel headers.
> AFAICR, MMAP support got added in kernel 2.6.27 and Debian lenny runs 2.6.26.
I see code for tpacket support in the 2.4.20 source (two dot four dot twenty,
not two dot six dot anything); I think it dates back before then (perhaps
2.4.0). It requires CONFIG_PACKET_MMAP.
I don't know whether any of the kernel configuration stuff shipped with the
kernel has a notion of defaults or not; perhaps the default changed in 2.6.27,
so that you got tpacket support unless you explicitly configured it *out* of
the kernel, rather than not getting it unless you explicitly configured it
*into* the kernel. However, I think distributions can choose their own
defaults, so perhaps Debian changed the default at some point.
Looking at the 2.6.27 changelog:
http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.27
indicates that what *did* change in 2.6.27 was that they fixed some 64-bit
issues in tpacket (if I remember correctly when I looked at this issue, it was
a problem with 32-bit usermode code with a 64-bit kernel):
commit bbd6ef87c544d88c30e4b762b1b61ef267a7d279
Author: Patrick McHardy
Date: Mon Jul 14 22:50:15 2008 -0700
packet: support extensible, 64 bit clean mmaped ring structure
The tpacket_hdr is not 64 bit clean due to use of an unsigned long
and can't be extended because the following struct sockaddr_ll needs
to be at a fixed offset.
Add support for a version 2 tpacket protocol that removes these
limitations.
Userspace can query the header size through a new getsockopt option
and change the protocol version through a setsockopt option. The
changes needed to switch to the new protocol version are:
1. replace struct tpacket_hdr by struct tpacket2_hdr
2. query header len and save
3. set protocol version to 2
- set up ring as usual
4. for getting the sockaddr_ll, use (void *)hdr + TPACKET_ALIGN(hdrlen)
instead of (void *)hdr + TPACKET_ALIGN(sizeof(struct tpacket_hdr))
Steps 2 and 4 can be omitted if the struct sockaddr_ll isn't needed.
Signed-off-by: Patrick McHardy
Signed-off-by: David S. Miller
and made some changes to pass VLAN information to tpacket users when the
hardware strips the information from the packet (and presumably supplies it
out-of-band):
commit 393e52e33c6c26ec7db290dab803bac1bed962d4
Author: Patrick McHardy
Date: Mon Jul 14 22:50:39 2008 -0700
packet: deliver VLAN TCI to userspace
Store the VLAN tag in the auxillary data/tpacket2_hdr so userspace can
properly deal with hardware VLAN tagging/stripping.
Signed-off-by: Patrick McHardy
Signed-off-by: David S. Miller
But, as noted, whether the Debian lenny kernel has tpacket support configured
in by default is another matter.-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Best OS / Distribution for gigabit capture?
On Feb 5, 2011, at 11:20 PM, M. V. wrote: > as i mentioned in my previous mail, (with the title: "HUGE packet-drop") i'm > having problem trying to dump gigabit traffic on harddisk with tcpdump on > Debian5.0. i tried almost everything but got no success. Did you try to check whether the memory-mapped "tpacket" mechanism was being used by libpcap? > From: Jesper Dangaard Brouer > Subject: Re: [tcpdump-workers] HUGE packet-drop > Date: January 31, 2011 10:56:22 AM PST > To: tcpdump-workers@lists.tcpdump.org ... > The easiest way to see if you are using the MMAPed version is to look in: > /proc/net/ptype > > Your are using the MMAP version if the Function "tpacket_rcv" is listed (while > you perform a tcpdump). Notice the "t" in front of "packet_rcv", if the "t" is > missing, then you are using the old/normal version. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] allow cooked mode on linux ethernet devices
hi, i'd like to be able to capture from an ethernet device on linux using the DLT_LINUX_SLL link type. i don't see any way to accomplish this using the existing API; libpcap really wants to give me a DLT_EN10MB handle. i submitted a patch to allow DLT_LINUX_SLL on ethernet devices a few months back: http://sourceforge.net/tracker/?func=detail&atid=469579&aid=3078313&group_id=53067 could someone please look at this and tell me if the patch needs more work or if it can be merged to mainline? thanks. -- Robert Edmonds edmo...@debian.org - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] HUGE packet-drop
Guy Harris scrisse:
> You need at least libpcap 1.0.0 to have tpacket ("turbo-packet",
> right?) support in the standard libpcap. You could also get it with
> the Phil Wood patches he mentioned, although that only supports
> memory-mapped access on Linux, not FreeBSD - but he's using Linux, so
> that doesn't apply (well, unless it's Debian GNU/kFreeBSD or whatever
> they're calling it :-)).
>
> I see code for tpacket support in the 2.4.20 source (two dot four dot
> twenty, not two dot six dot anything); I think it dates back before
> then (perhaps 2.4.0). It requires CONFIG_PACKET_MMAP.
>
> I don't know whether any of the kernel configuration stuff shipped
> with the kernel has a notion of defaults or not; perhaps the default
> changed in 2.6.27, so that you got tpacket support unless you
> explicitly configured it *out* of the kernel, rather than not getting
> it unless you explicitly configured it *into* the kernel. However, I
> think distributions can choose their own defaults, so perhaps Debian
> changed the default at some point.
I can't speak for Lenny, but it looks like Squeeze (which was released
a couple of days ago) has both:
* http://packages.debian.org/squeeze/libpcap0.8
* http://merkel.debian.org/~jurij/2.6.32-30/amd64/
You may want to try there, adding patches and sysctl on top of it.
Cheers, Luca
--
.''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso)
: :' : The Universal O.S.| lucab (AT) debian.org
`. `'` | GPG Key ID: 3BFB9FB3
`- http://www.debian.org | Debian GNU/Linux Developer
signature.asc
Description: PGP signature
Re: [tcpdump-workers] A puzzled maintainer with questions regarding
Hello, On Mon, Feb 7, 2011 at 12:21 AM, Guy Harris wrote: > > On Feb 4, 2011, at 12:25 AM, M.Baris Demiray wrote: > >> In fact this is not what STANAG 5066 Annex H "Implementation Guide and >> Notes" section suggests. According to this section and the tests held >> by DRA (Defence Research Agency), >> >> 1) The throughput is not strongly sensitive to frame size >> 2) 200 bytes is a good 'compromise' selection for frame size >> >> Besides, STANAG 5066 has the ability of doing DRC (Data Rate Change) >> in accordance with SNR values so what is suggested by that white >> paper, I think, is not applicable. > > That's somewhat of an implementation detail that shouldn't affect code that > tries to dissect those packets. While I was writing this I was aware that I was diverging from the topic a little yet I wanted to add that since now I use DLT_USER0 and there are header and payload size fields at the Wireshark interface where I associate DLT_USER0 and s5066mac dissector. So I thought it may be helpful to provide that information. Sorry if I bothered with implementation details. >> Precisely. Yet may be a little clarification is needed. You might have >> noticed that in my first e-mail I mentioned about DTS (Data Transfer >> Sublayer) and that one of our dissector methods has the name >> dissect_s5066dts() but now we are talking about MAC layer and all this >> may look like a confusion but it is not. As explained in Isode white >> paper there are three versions of STANAG 5066. MAC (Medium Access >> Control) layer was introduced in Edition 2 (which was later renamed as >> Edition 3) and designated to manage HF modem interface that DTS was >> designated to do the same before. > > So is there a publicly-available specification that documents what the > packets using this link-layer type look like?- Unfortunately no, there is not. As in SIS Layer dissector this is also a part of a standard which is available only to NATO member states and that therefore we access through an account. However there is a version called 1.0.2 on the Internet and there you may find the section C.3 Structure of sublayer protocol data units (D_PDUs) in order to observe what a DPDU header looks like. This is a really old version and I think that's why it's unclassified. Here is the link, http://www.armymars.net/ArmyMARS/HF-Email/resources/stanag5066.pdf Besides this I will check if I can provide any recent versions of DPDU headers. Thanks, > This is the tcpdump-workers list. > Visit https://cod.sandelman.ca/ to unsubscribe. -- M. Baris Demiray - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] HUGE packet-drop
On Feb 6, 2011, at 10:07 PM, Luca Bruno wrote: > I can't speak for Lenny, but it looks like Squeeze (which was released > a couple of days ago) has both: > * http://packages.debian.org/squeeze/libpcap0.8 Ah, so Squeeze has the libpcap 1.1.1 version of libpcap 0.8. :-) (Yes, it makes no sense to me whatsoever until I remind myself that the "0.8" in "libpcap 0.8" has absolutely nothing whatsoever to do with, for example, the "0.8.1" in "libpcap 0.8.1": http://www.tcpdump.org/release/libpcap-0.8.1.tar.gz .) - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
