Hi Thomas,
we'll have a look at the issue. We are looking into MTU stuff anyway...
Best regards
Michael
On Jun 9, 2012, at 4:10 AM, Tomas Mraz via RT wrote:
The getsockopt() for IP_MTU and IPV6_MTU at least on Linux returns a
value of length 4. On little endian systems this is not so critical
On Jun 10, 2012, at 2:09 PM, Andy Polyakov wrote:
Hi Thomas,
we'll have a look at the issue. We are looking into MTU stuff anyway...
Best regards
Michael
On Jun 9, 2012, at 4:10 AM, Tomas Mraz via RT wrote:
The getsockopt() for IP_MTU and IPV6_MTU at least on Linux returns a
value of
The getsockopt() for IP_MTU and IPV6_MTU at least on Linux returns a
value of length 4. On little endian systems this is not so critical
problem however on big endian 64 bit systems it means the interpretation
of the returned value by the code in dgram_ctrl() is completely wrong -
Actually
On Jun 10, 2012, at 4:03 PM, Andy Polyakov wrote:
The getsockopt() for IP_MTU and IPV6_MTU at least on Linux returns a
value of length 4. On little endian systems this is not so critical
problem however on big endian 64 bit systems it means the interpretation
of the returned value by the code
On Jun 10, 2012, at 4:03 PM, Andy Polyakov wrote:
The getsockopt() for IP_MTU and IPV6_MTU at least on Linux returns a
value of length 4. On little endian systems this is not so critical
problem however on big endian 64 bit systems it means the interpretation
of the returned value by the code
On Sun, Jun 10, 2012 at 11:15 AM, Andy Polyakov ap...@openssl.org wrote:
The point of these changes is to reduce the skew between versions.
They are not random.
Consider my
http://cvs.openssl.org/filediff?f=openssl/crypto/x86cpuid.plv1=1.24v2=1.25.
What is the criteria for two changes
