Le 13.09.2018 14:30, Martin Pieuchot a écrit :
On 11/09/18(Tue) 07:35, [email protected] wrote:
Le 26.06.2018 17:52, Romain Gabet a écrit :
> Hi,
>
> I think there is a problem with ipcomp : packets are compressed even
> in some cases where compression does not reduce their size ; as a
> result they are rejected by the remote system.
> [...]
I think that I found the problem.
In "src/sys/netinet/ip_ipcomp.c" at line 590 :
if (rlen < crp->crp_olen) {
/* Compression was useless, we have lost time. */
crypto_freereq(crp);
if (ipsp_process_done(m, tdb))
ipcompstat_inc(ipcomps_outfail);
NET_UNLOCK();
return;
}
When sizes are checked, the size of IPCOMP header was forgotten and
the size
must be smaller, in agreement with RFC.
(https://tools.ietf.org/html/rfc3173)
"2.2. Non-Expansion Policy
If the total size of a compressed payload and the IPComp header, as
defined in section 3, is not smaller than the size of the original
payload, the IP datagram MUST be sent in the original non-compressed
form."
I propose the following patch to correct the issue.
Thanks, I adapted the diff to -current and committed it. Next snapshot
will contain your fix.
Hi,
I made an error in my code analysis, the patch doesn't correct
completely the problem.
According to the code :
if (rlen <= olen + IPCOMP_HLENGTH) {
/* Compression was useless, we have lost time. */
ipcompstat_inc(ipcomps_minlen); /* misnomer, but like to count */
goto skiphdr;
}
The ipcomp header isn't injected but the packet is still send
compressed. It result an bugued ip packet.
I haven't found how I can modify the code not to send compressed packet.
The issue can be reproduced with enough big packet to procces by ipcomp.
Ex : ping -s 301 "target through the tunnel".
Best regards.
