Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

answered 2021-02-10 11:42:05 +0000

SYN-bit gravatar image

I've figured out what is the issue: The PC sees GRE / ERSPAN.

OK, that means the offsets of where to find the port numbers is different because of the encapsulation. As the capture filter language does not include code to parse gre/erspan natively, the only thing you can do is work with offsets manually.

So, depending on the version of ERSPAN (there are a couple of versions with different header lengths), you can create a filter. Assuming ERSPAN type II packets, there will be:

  • 14 bytes ethernet header
  • 20 bytes IP header
  • 8 bytes GRE header
  • 8 bytes ERSPAN type II header
  • 14 bytes ethernet header (of the packet of interest)
  • 20 bytes IP header (of the packet of interest)
  • 8 bytes UDP header (of the packet of interest)
  • x bytes of payload (of the packet of interest)

Filtering for destination port 30000 (udp only) would mean pick the two bytes at position 14+20+8+8+14+20 of the frame and compare the value to 30000. This will result in ether[84:2] = 30000. Or ip proto 47 and ip[70:2]=30000 when just filtering for the GRE encapsulated frames and then looking for the correct port number, based of the first IP header.

They result in the following BPF code:

$ tcpdump -i en0 -d ether[84:2] = 30000
(000) ldh      [84]
(001) jeq      #0x7530          jt 2    jf 3
(002) ret      #262144
(003) ret      #0
$ tcpdump -i en0 -d ip proto 47 and ip[70:2]=30000
(000) ldh      [12]
(001) jeq      #0x800           jt 2    jf 7
(002) ldb      [23]
(003) jeq      #0x2f            jt 4    jf 7
(004) ldh      [84]
(005) jeq      #0x7530          jt 6    jf 7
(006) ret      #262144
(007) ret      #0
$