summaryrefslogtreecommitdiffstats
path: root/examples/widgets/itemviews
diff options
context:
space:
mode:
authorThiago Macieira <thiago.macieira@intel.com>2019-12-05 16:02:56 -0800
committerThiago Macieira <thiago.macieira@intel.com>2019-12-07 10:20:27 -0800
commitc4b0ff4855e81aa8017664a2f1a4353b274c27fd (patch)
treec5bb75a1b1f8f88177bff7e493db5fd35cda1be9 /examples/widgets/itemviews
parent29adc0eed9b9dc3cce92f8acaaeaed3ab1bc6414 (diff)
tst_QNetworkInterface: don't force an IPv4 link-local address5.14
Windows apparently has special code to deal with those addresses. If all your network interfaces are up and have acquired addresses, then the link-local network at 169.254.0.0/16 is unreachable. I had never caught this because both my Windows VM and my bare metal Windows have inactive interfaces (like the Bluetooth PAN one) and, when inactive, Windows assigns a link-local address. But in the CI, the interface(s) were all up and running, causing this issue. Unix systems don't treat IPv4 link-local any differently, so they always worked, so long as any interface was up and there had to be one to reach the network test server. This commit reworks the test to add test addresses based on the addresses found on up & running interfaces (see tst_qudpsocket.cpp). For IPv4, we flip the bits in the local portion of the address. For IPv6, we add a node with an address I generated randomly (non-universal), with the same scope. Fixes: QTBUG-65667 Change-Id: I568dea4813b448fe9ba6fffd15dd9f482db34991 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Diffstat (limited to 'examples/widgets/itemviews')
0 files changed, 0 insertions, 0 deletions