[tcpdump-workers] Update of XRA header spec

[Bruno Verstuyft]

Hi,


I was wondering what the procedures are for updating specifications for a 
certain link type?

More specifically, we want to add some extra TLVs to the specification of 
DLT_DOCSIS31_XRA31 
(https://support.excentis.com/index.php?/Knowledgebase/Article/View/159).

All changes are of course backwards-compatible.


Best Regards,



Bruno Verstuyft
Senior Testing and Software Engineer
Excentis
Gildestraat 8
9000 Gent  -  Belgium
Tel: +32 9 269 22 91


Did you re-subscribe to our newsletter? If not, just click 
here to do it right now.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

[tcpdump-workers] Endianness issue with selecting non-fragmented packets

[Richard Clayton]

I am running tcpdump under FreeBSD 11 on an AMD64.

I have a file containing UDP packets and IP fragments.

This command (the filter corresponds to the information on the man
page):

tcpdump -r file.pcap "(ip[6:2] & 0x1FFF = 0)"

unexpectedly prints all of the packets :-(

The command:

tcpdump -r file.pcap "(ip[6:2] & 0xFF1F = 0)"

skips all the fragments and only prints complete packets.


This is clearly an endianness issue ... but shouldn't tcpdump/libpcap be
hiding that from me ?  or is the man page incorrect ??

# sysctl hw.model hw.machine hw.ncpu
hw.model: Intel(R) Celeron(R) CPU G1620 @ 2.70GHz
hw.machine: amd64
hw.ncpu: 2

# uname -v
FreeBSD 11.2-STABLE #9: etc

# tcpdump --version
tcpdump version 4.9.2
libpcap version 1.9.0
OpenSSL 1.0.2o-freebsd  27 Mar 2018

-- 
richard   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] Endianness issue with selecting non-fragmented packets

[Guy Harris]

On Jul 27, 2018, at 11:21 AM, Richard Clayton  wrote:

> I am running tcpdump under FreeBSD 11 on an AMD64.
> 
> I have a file containing UDP packets and IP fragments.
> 
> This command (the filter corresponds to the information on the man
> page):
> 
>tcpdump -r file.pcap "(ip[6:2] & 0x1FFF = 0)"
> 
> unexpectedly prints all of the packets :-(
> 
> The command:
> 
>tcpdump -r file.pcap "(ip[6:2] & 0xFF1F = 0)"
> 
> skips all the fragments and only prints complete packets.
> 
> 
> This is clearly an endianness issue ... but shouldn't tcpdump/libpcap be
> hiding that from me ?

Yes.  The BPF code generated for that expression is

# load 2-byte value at offset 12, i.e. Ethernet type
(000) ldh  [12]
# Compare for equality against 0x800, i.e. IPv4; if equal,
# go to instruction 002, otherwise go to instruction 005.
(001) jeq  #0x800   jt 2jf 5
# Load 2-byte value at offset 20, i.e. 14+6, so at an offset
# of 6 from the beginning of the Ethernet payload, so at
# an offset of 6 from the beginning of the IPv4 header,
# so the flags and fragment offset.
(002) ldh  [20]
# Test bits 0x1fff; if any are set, go to instruction 0005,
# and if they're all clear, go to instruction 0004.
(003) jset #0x1fff  jt 5jf 4
# Return the snapshot length, meaning "accept the packet
# and return that many bytes of packet data".
(004) ret  #65535
# Return 0, meaning "reject the packet".
(005) ret  #0

The load instructions are all loading the data as big-endian, i.e. they don't 
load a machine word in its native byte order, they load it as if it were in 
network byte order, so the same value should be loaded on a little-endian x86 
machine like yours or a big-endian machine such as a 
SPARC/{most}PowerPC/{S/390, z/Architecture} machine.

And I tested its on my x86-64 Mac, using the tip-of-the-1.9-branch libpcap and 
the tip-of-the-4.9-branch tcpdump, with a capture file with some fragmented IP 
packets, and the filter "(ip[6:2] & 0x1FFF = 0)" rejected the fragmented 
packets.  The filter "(ip[6:2] & 0xFF1F = 0)" rejected *all* the packets.

Nothing was done to libpcap or tcpdump since the 1.9.0/4.9.2 releases to affect 
that.

___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] Update of XRA header spec

[Guy Harris]

On Jul 27, 2018, at 3:51 AM, Bruno Verstuyft  
wrote:

> I was wondering what the procedures are for updating specifications for a 
> certain link type?

If the layout of the header is specified, in whole or in part, by a page on 
tcpdump.org's Web site, i.e. one of the linktypes/LINKTYPE_XXX.html files, and 
the part that's changing is in one of those files, it would be updated by 
providing an update to the file, e.g. as a pull request at

https://github.com/the-tcpdump-group/tcpdump-htdocs

If the layout of the header is specified, in whole or in part, by a page that 
the provider of the specification maintains on some other Web site, and the 
part that's changing is in *that* page, it would be updating by updating that 
page.

> More specifically, we want to add some extra TLVs to the specification of 
> DLT_DOCSIS31_XRA31 
> (https://support.excentis.com/index.php?/Knowledgebase/Article/View/159).

If you can just update that page, that's the easiest way to update it.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers