This replicates the behavior of oncp_record_read(): if a (D)TLS record
ends with an incomplete PPP packet, we save the read-so-far length as
vpninfo->partial_rec_size, and continue reading at that point on the
next iteration.
This poorly-layered packetisation behavior was observed on Fortinet and
may exist for other encapsulations as well. So we cope with it for
PPP_ENCAP_F5 because it's trivial, but not yet PPP_ENCAP_F5_HDLC which
would be harder; we'll wait until we actually see it there before
delving into that complexity.
This works as expected to prevent loss of synchronization to the
encapsulation header. Here's an example showing receipt of incomplete
Fortinet/PPP packets, during a high rate of incoming packets generated with
'iperf3 -c $IP_ON_REMOTE_NETWORK -R', followed by recovery on subsequent
mainloop iterations:
Received IPv4 data packet of 1183 bytes over TLS
Fortinet packet is incomplete (837 bytes on wire but header payload_len is 1185). Waiting for more.
Packet contains 539 bytes after payload. Assuming concatenated packet.
Received IPv4 data packet of 1183 bytes over TLS
Fortinet packet is incomplete (539 bytes on wire but header payload_len is 1185). Waiting for more.
No work to do; sleeping for 10000 ms...
No work to do; sleeping for 10000 ms...
No work to do; sleeping for 10000 ms...
No work to do; sleeping for 10000 ms...
Packet contains 13101 bytes after payload. Assuming concatenated packet.
Received IPv4 data packet of 1183 bytes over TLS
Packet contains 11910 bytes after payload. Assuming concatenated packet.
Received IPv4 data packet of 1183 bytes over TLS
Packet contains 10719 bytes after payload. Assuming concatenated packet.
Received IPv4 data packet of 1183 bytes over TLS
Packet contains 9528 bytes after payload. Assuming concatenated packet.
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>