Hello,
On Mon, Jan 18, 2021 at 07:47:56PM +0100, Alexander Bluhm wrote:
> Hi,
>
> tcpdump pflog with addresses rewritten by rdr-to, nat-to, or af-to
> is broken.
>
> 1. Fix address family of the packet in af-to rules:
>
> before:
> 19:26:37.620926 169.254.0.14 > 169.254.0.14: icmp: echo request
> 19:26:37.620946 bad-ip6-version 4
> 19:26:37.620963 fc00::23 > fc00::24: icmp6: echo request
> 19:26:37.620977 bad-ip-version 6
>
> after:
> 19:26:29.606966 169.254.0.14 > 169.254.0.14: icmp: echo request
> 19:26:29.606990 169.254.0.14 > 169.254.0.14: icmp: echo request
> 19:26:29.607006 fc00::23 > fc00::24: icmp6: echo request
> 19:26:29.607019 fc00::24 > fc00::23: icmp6: type-#0
>
> The type-#0 is still buggy, but it is a step in the right direction.
>
> 2. Print the addresses that were rewritten if called with -ev:
>
> This is rdr-to. Note that "orig src" is the modified address.
>
> before:
> 19:32:34.843807 rule 2.regress.19/(match) [uid 0, pid 37810] pass out on
> lo11: [orig src 169.254.0.22:59443, dst 169.254.0.12:9] 169.254.0.12.42793 >
> 169.254.0.12.9: [bad udp cksum 0900! -> 152f] udp 4 (ttl 64, id 11544, len
> 32, bad ip cksum c! -> f9a0)
>
> after:
> 19:32:06.794193 rule 2.regress.19/(match) [uid 0, pid 37810] pass out on
> lo11: [rewritten: src 169.254.0.22:52093, dst 169.254.0.12:9]
> 169.254.0.12.1885 > 169.254.0.12.9: [bad udp cksum 27aa! -> e1ce] udp 4 (ttl
> 64, id 5110, len 32, bad ip cksum c! -> 12c3)
>
> With af-to the old code confuses the address family:
>
> before:
> 19:33:45.731267 rule 2.regress.22/(match) [uid 0, pid 37810] pass in on lo11:
> [orig src 252.0.0.0:64597, dst 252.0.0.0:9] [|ip6]
>
> after:
> 19:34:05.388153 rule 2.regress.22/(match) [uid 0, pid 37810] pass in on lo11:
> [rewritten: src fc00::23:65141, dst fc00::24:9] 169.254.0.14.10027 >
> 169.254.0.14.9: [udp sum ok] udp 4 (ttl 64, id 27481, len 32)
>
> Basically the kernel uses the information from the packet description
> and fills it into the fields in the pflog header. While doing this,
> it is trival to figure out whether the packet has been rewritten.
>
> ok?
>
diff makes sense to me.
OK sashan@
