LZS decompression failed: File too large

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 1 August 2018 at 16:23, Daniel Lenski <dlenski at gmail.com> wrote:
> On Wed, Aug 1, 2018 at 4:43 AM, Jeroen Balduyck
> <jeroen.balduyck at gmail.com> wrote:
>> Alright, I did get confirmation that the interface on the server side
>> is 1340 MTU when the tunnel gets established. But that was all but
>> certain. I have 1322 MTU on Opnsense (FreeBSD). So in my mind this is
>> a 100% MTU-mismatch.
>
> Yes, I'm pretty sure this is caused by openconnect client not
> tolerating *compressed* packet that are larger than the negotiated
> MTU.  If you can rebuild the client with the patch I sent subsequently
> ("Tolerate packets that are larger than negotiated MTU after
> decompression"), this should allow it to tolerate the mismatch.
> Similar patches have done the trick for other protocol variants in the
> past.
>
> Obviously, figuring out why the server and client have arrived at
> different MTUs and resolving that will be useful? but with so
> different operating systems, networking stacks, and TLS libraries
> (modern Ubuntu build OpenConnect with GnuTLS, not OpenSSL)? they're
> pretty hard to avoid.
>
> Dan
I wish I knew how to do this on *BSD. I *probably* could pull it off
on Linux (giving enough patience).
Any chance you could talk me through? If not I'm still going to try
but don't hold your breath haha:-)



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux