Brain dumping what I discovered recently while investigating a bug that thebaratusii reported:
When testing the new uplink functionality with a Windows-based client, Baratus found that a DOSbox client couldn't connect to a real DOS machine connected via uplink. Quote:
also I just noticed in Descent testing with the uplink feature, when the real hardware is hosting, the DOSBox instance can't see it but when the DOSBox instance hosts, the real hardware can see it but can't connect
I believe the cause of this is due to packets being "looped back" when sent to the uplink client. A packet from dosbox gets forwarded to the uplink client, which writes it onto the network, but because of peculiarities in how npcap works, the injected packet is recaptured by the uplink client and uploaded back to the server. This looped back packet poisons the switch routing table which explains the behavior in the quote above.
I attempted to fix this with 963bbe2c78d0cf4d167a but it did not resolve the problem. From what I've read, this is because npcap is emulating legacy behavior from the older winpcap. The following are ways to disable it:
Supply PCAP_OPENFLAG_NOCAPTURE_LOCAL to pcap_open(). This appears to not be an option since gopacket does not provide any way to do it.
Use the PacketSetLoopbackBehavior() function in libpacket. This does not appear to be an option since it requires an adapter handle, and the handle is internal to npcap with no apparent way to access it.
It therefore appears that a different form of workaround will be necessary.
Brain dumping what I discovered recently while investigating a bug that thebaratusii reported:
When testing the new uplink functionality with a Windows-based client, Baratus found that a DOSbox client couldn't connect to a real DOS machine connected via uplink. Quote:
I believe the cause of this is due to packets being "looped back" when sent to the uplink client. A packet from dosbox gets forwarded to the uplink client, which writes it onto the network, but because of peculiarities in how npcap works, the injected packet is recaptured by the uplink client and uploaded back to the server. This looped back packet poisons the switch routing table which explains the behavior in the quote above.
I attempted to fix this with 963bbe2c78d0cf4d167a but it did not resolve the problem. From what I've read, this is because npcap is emulating legacy behavior from the older winpcap. The following are ways to disable it:
PCAP_OPENFLAG_NOCAPTURE_LOCAL
topcap_open()
. This appears to not be an option since gopacket does not provide any way to do it.PacketSetLoopbackBehavior()
function in libpacket. This does not appear to be an option since it requires an adapter handle, and the handle is internal to npcap with no apparent way to access it.It therefore appears that a different form of workaround will be necessary.