Am 06.12.22 um 17:19 schrieb Gert Doering:
Hi,
On Tue, Dec 06, 2022 at 04:54:38PM +0100, Gert Doering wrote:
I have not server-tested this, as it "should not" make a difference,
and Arne did test this on s390. The full server tests will run
tonight, though.
I *should* have, as that would have caught the fact that this patch
breaks pkt_testdriver on Linux, no matter if OpenSSL or mbedTLS
[ RUN ] test_calc_session_id_hmac_static
[ ERROR ] --- difference at offset 0 0xffffff84 0xffffff8b
difference at offset 1 0x73 0xffffffeb
difference at offset 2 0x52 0x3d
difference at offset 3 0x2b 0x20
difference at offset 4 0x5b 0x14
difference at offset 5 0xffffffa9 0x53
difference at offset 6 0x2a 0xffffffbe
difference at offset 7 0x70 0x0a
8 bytes of 0x7ffe60967bd0 and 0x7ffe60967bc8 differ
[ LINE ] --- test_pkt.c:492: error: Failure!
[ FAILED ] test_calc_session_id_hmac_static
...
[==========] 9 test(s) run.
[ PASSED ] 8 test(s).
[ FAILED ] 1 test(s), listed below:
[ FAILED ] test_calc_session_id_hmac_static
1 FAILED TEST(S)
FAIL: pkt_testdriver
this is not specific to OpenSSL (1.1.1*) or mbedTLS, but seems to
be "a Linux thing", so I assume it's something related to sockaddr
(as this patch fixes the switch/case to actually look at the IPv4 addr)
Yeah. macOS has:
struct sockaddr_in {
__uint8_t sin_len;
sa_family_t sin_family;
in_port_t sin_port;
struct in_addr sin_addr;
char sin_zero[8];
};
with sa_family_t also uint8_t
and Linux has stupidly complex definition that boils down to:
struct sockaddr_in
{
uint16_t sin_family;
in_port_t sin_port;
struct in_addr sin_addr
char sin_zero[8];
};
So Linux basically has a 16 bit uint16 instead of two uint8_t. Because
s390x is big endian, this happens to be same as on all BSDs with first
byte being 0 and second byte being the family.
I will send a fix that fixes the fix *grumbels*
Arne
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
