Re: [openssl.org #2833] BIO_CTRL_DGRAM_QUERY_MTU handling is wrong due to bad getsockopt() use

2012-06-14 Thread Robin Seggelmann
Hi, I have just checked the current state of HEAD after 22627. Although laborious, the changes seem fine to me. All occurrences are handled. Best regards Robin On Jun 11, 2012, at 6:48 PM, Michael Tuexen wrote: On Jun 11, 2012, at 4:36 PM, Andy Polyakov wrote: On side note. Looking at

Re: [openssl.org #2833] BIO_CTRL_DGRAM_QUERY_MTU handling is wrong due to bad getsockopt() use

2012-06-11 Thread Tomas Mraz via RT
On Sun, 2012-06-10 at 18:04 +0200, Michael Tuexen wrote: 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

Re: [openssl.org #2833] BIO_CTRL_DGRAM_QUERY_MTU handling is wrong due to bad getsockopt() use

2012-06-11 Thread Michael Tuexen
On Jun 11, 2012, at 8:21 AM, Tomas Mraz via RT wrote: On Sun, 2012-06-10 at 18:04 +0200, Michael Tuexen wrote: 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

Re: [openssl.org #2833] BIO_CTRL_DGRAM_QUERY_MTU handling is wrong due to bad getsockopt() use

2012-06-11 Thread Andy Polyakov
At least this is what I normally use. The type of *option_value might be platform dependent, but then we need some #ifdefs for platforms. But the choice is still between 32- and 64-bit integers. And if so, you can distinguish among them at run time as accurately. Or should one say even I'm

Re: [openssl.org #2833] BIO_CTRL_DGRAM_QUERY_MTU handling is wrong due to bad getsockopt() use

2012-06-11 Thread Andy Polyakov
On side note. Looking at first getsockopt in bss_dgram.c. In non-Windows case it passes pointer to timeval and says it's sizeof(int) large... How would non-Windows BIO_CTRL_DGRAM_GET_RECV_TIMEOUT work when ret is initialized to 1? Consider http://cvs.openssl.org/chngview?cn=22627. Note that

Re: [openssl.org #2833] BIO_CTRL_DGRAM_QUERY_MTU handling is wrong due to bad getsockopt() use

2012-06-11 Thread Michael Tuexen
On Jun 11, 2012, at 10:47 AM, Andy Polyakov wrote: At least this is what I normally use. The type of *option_value might be platform dependent, but then we need some #ifdefs for platforms. But the choice is still between 32- and 64-bit integers. And if so, you can distinguish among them at

Re: [openssl.org #2833] BIO_CTRL_DGRAM_QUERY_MTU handling is wrong due to bad getsockopt() use

2012-06-11 Thread Michael Tuexen
On Jun 11, 2012, at 4:36 PM, Andy Polyakov wrote: On side note. Looking at first getsockopt in bss_dgram.c. In non-Windows case it passes pointer to timeval and says it's sizeof(int) large... How would non-Windows BIO_CTRL_DGRAM_GET_RECV_TIMEOUT work when ret is initialized to 1? Consider

Re: [openssl.org #2833] BIO_CTRL_DGRAM_QUERY_MTU handling is wrong due to bad getsockopt() use

2012-06-10 Thread Andy Polyakov
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

Re: [openssl.org #2833] BIO_CTRL_DGRAM_QUERY_MTU handling is wrong due to bad getsockopt() use

2012-06-10 Thread Michael Tuexen
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

Re: [openssl.org #2833] BIO_CTRL_DGRAM_QUERY_MTU handling is wrong due to bad getsockopt() use

2012-06-10 Thread Andy Polyakov
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

Re: [openssl.org #2833] BIO_CTRL_DGRAM_QUERY_MTU handling is wrong due to bad getsockopt() use

2012-06-10 Thread Michael Tuexen
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

Re: [openssl.org #2833] BIO_CTRL_DGRAM_QUERY_MTU handling is wrong due to bad getsockopt() use

2012-06-10 Thread Michael Tuexen
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

Re: [openssl.org #2833] BIO_CTRL_DGRAM_QUERY_MTU handling is wrong due to bad getsockopt() use

2012-06-09 Thread Michael Tuexen
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

[openssl.org #2833] BIO_CTRL_DGRAM_QUERY_MTU handling is wrong due to bad getsockopt() use

2012-06-08 Thread Tomas Mraz via RT
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 - you will get a