To repro, add IPv6 protocol to a stream and set src and dst adddress as 1234:1::65/96 and 1234:2::65/96 with mode as Increment Host for 5 counts.
Expected src and dst IP addresses are 1234:1::[65-69] and 1234:2::[65-69]
On some platforms (e.g. Windows 10 with MinGW-W64 5.3.0 in release mode), the generated (incorrect) IPs are 1234:1:0:[0-4]::[65-69] and 1234:2:0:[0-4]::[65-69]
The problem seems to be in the following line in ip6.cpp when p is 64
if (p > 0)
maskHi = ~((quint64(1) << p) - 1);
The expectation is that maskHi should be all 1s (for p==64), but on some platforms it is all 0s. Looks like this is undefined behaviour as per the C/C++ standard since p == width of variable.
Not fixing this right now because we are very close to the release of 1.0 - I don't want to introduce more regressions.
The fix, when implemented, should use the new UInt128 type/class that is used with devices.
To repro, add IPv6 protocol to a stream and set src and dst adddress as 1234:1::65/96 and 1234:2::65/96 with mode as Increment Host for 5 counts.
Expected src and dst IP addresses are 1234:1::[65-69] and 1234:2::[65-69]
On some platforms (e.g. Windows 10 with MinGW-W64 5.3.0 in release mode), the generated (incorrect) IPs are 1234:1:0:[0-4]::[65-69] and 1234:2:0:[0-4]::[65-69]
The problem seems to be in the following line in
ip6.cppwhen p is 64The expectation is that maskHi should be all 1s (for p==64), but on some platforms it is all 0s. Looks like this is undefined behaviour as per the C/C++ standard since p == width of variable.
Not fixing this right now because we are very close to the release of 1.0 - I don't want to introduce more regressions.
The fix, when implemented, should use the new UInt128 type/class that is used with devices.