-
Notifications
You must be signed in to change notification settings - Fork 5
Description
Had difficulty troubleshooting loss of PDU receipts. Incorrectly suspected a threading problem - perhaps caused by Debug mode instead of Run mode - nope.
Actual problem: running NPS PaloAlto GlobalConnect VPN blocked receipts! Neither multicast nor loopback is mentioned in the documentation, so this is likely an unintended interaction with the network interface card. And so, originally opened this issue as "loss of PDU receipts caused by VPN?!"
Disconnecting VPN showed PDU receipt again. Used DisThreadedNetworkInterface to test. This problem only manifests under Windows, not MacOSX.
Rebooting/retesting 2 days later showed the receipt working again! Something tricky is going on... but it appears to be local to one machine, or possibly to side effects from NPS VPN reconfiguration (in progress). Thus NPS VPN problems per se are not an issue to solve.
However: there ought to be a way to create a general self-test diagnostic that checks for such pathologies when creating DisThreadedNetworkInterface.
- renamed this issue as Need run-time network diagnostics utility method in DisChannel/DisThreadedNetworkIterface
- TODO: make this test part of run-time network interface setup, reporting if sent PDUs are not received.
- TODO: also expose this test as an option for programmers to check status of DisThreadedNetworkInterface at runtime, if troubleshooting or confirmation testing is desired