[Vadim Smirnov]

Да, любопытно, я такой список интерфейсов наблюдаю, только если сначала сбриджить два адаптера, а затем в свойствах моста отключить их от моста. Похоже не все так гладко с этой конфигурацией на Windows 7…

Тем не менее, в качестве основы для решения поставленой задачи, я бы рекомендовал взять мост построеный на WinpkFilter:
https://www.ntkernel.com/bridging-networks-with-windows-packet-filter/
Код на GitHub:
https://github.com/wiresock/ndisapi/tree/master/examples/ethernet_bridge
и в нем отдельно обработать SIP трафик. Мне кажется так и проще и надежней с учетом не до конца предсказуемого поведения встроенного моста Windows.

[Vadim Smirnov]

Если я правильно понимаю, то имеем две сетевые карты обьединенные Windows Bridge? Или мост организован чем-то еще, например построен на этом примере https://github.com/wiresock/ndisapi/tree/master/examples/ethernet_bridge?

Я только что попробовал обьединить две сетевые карты на Win7 32bit с помощью Windows Bridge и дело в том что после обьединения WinpkFilter больше не видит адаптеры “под” мостом, поэтому мне непонятно как получилось запустить passthru на одном из них. Ниже вывод listadapters без моста и с включенным мостом:

C:\Program Files\WinpkFilter\bin\i386>listadapters
The following network interfaces are available to MSTCP:
1) WAN Network Interface (BH).
        Internal Name:   \DEVICE\NDISWANBH
        Current MAC:     C23720524153
        Medium:  0x00000003
        Current MTU:     1500
        Current adapter mode = 0x0
2) WAN Network Interface (IP).
        Internal Name:   \DEVICE\NDISWANIP
        Current MAC:     C23720524153
        Medium:  0x00000003
        Current MTU:     1500
        Current adapter mode = 0x0
Number of active WAN links: 0
3) WAN Network Interface (IPv6).
        Internal Name:   \DEVICE\NDISWANIPV6
        Current MAC:     C23720524153
        Medium:  0x00000003
        Current MTU:     1500
        Current adapter mode = 0x0
Number of active WAN links: 0
4) Local Area Connection 2.
        Internal Name:   \DEVICE\{952D0F1E-B3CE-4BEF-9DFE-515F24CA8A0E}
        Current MAC:     02004C4F4F50
        Medium:  0x00000000
        Current MTU:     1500
        Current adapter mode = 0x0
5) Local Area Connection.
        Internal Name:   \DEVICE\{C06C019F-D330-41DB-A35B-0B27382DE884}
        Current MAC:     00155D01780A
        Medium:  0x00000000
        Current MTU:     1500
        Current adapter mode = 0x0

Current system wide MTU decrement = 0

Default adapter startup mode = 0x0
C:\Program Files\WinpkFilter\bin\i386>listadapters
The following network interfaces are available to MSTCP:
1) Network Bridge.
        Internal Name:   \DEVICE\{F66FC5CF-6953-47C8-86F6-1A3B5771E620}
        Current MAC:     02004C4F4F50
        Medium:  0x00000000
        Current MTU:     1500
        Current adapter mode = 0x0
2) WAN Network Interface (BH).
        Internal Name:   \DEVICE\NDISWANBH
        Current MAC:     C23720524153
        Current MAC:     C23720524153
        Medium:  0x00000003
        Current MTU:     1500
        Current adapter mode = 0x0
3) WAN Network Interface (IP).
        Internal Name:   \DEVICE\NDISWANIP
        Current MAC:     C23720524153
        Medium:  0x00000003
        Current MTU:     1500
        Current adapter mode = 0x0
Number of active WAN links: 0
4) WAN Network Interface (IPv6).
        Internal Name:   \DEVICE\NDISWANIPV6
        Current MAC:     C23720524153
        Medium:  0x00000003
        Current MTU:     1500
        Current adapter mode = 0x0
Number of active WAN links: 0

Current system wide MTU decrement = 0

Default adapter startup mode = 0x0
C:\Program Files\WinpkFilter\bin\i386>

К слову, в отличии от Windows 7, на Windows 10 это возможно…

Так что пожалуйста побольше деталей и желательно описать задачу, а то сложно советовать, не зная, что хочется в итоге получить.

[Vadim Smirnov]

WinpkFilter 3.2.8.1 update:

1. Windows 10 HLK tests passed
2. RAS_LINK ProtocolBuffer size extended to 2048 bytes (Windows Vista had 600 bytes buffer, while Windows 10 has 1200 bytes)
3. Fixed task offload issue specific to certain 10 Gbps network interfaces which could cause packet loss and thus network performance degradation
4. Updated and slightly extended NDISAPI.DLL
5. Added Bluetooth media type for NDIS Lightweight Filter driver type

If you are eligible for a free update, please send the following details to [email protected] tо receive an update instruction:

Your order ID.
An approximate date of purchasing.

[Vadim Smirnov]

Александр,

Если программа упадет и процесс завершится, то драйвер перейдет в режим “пропускать все” и сессия продолжится (возможна потеря некоторого числа пакетов). Хуже если программа намертво зависнет, тогда сеть может оказаться заблокированной, так что для обеспечения надежности стоит предусмотреть механизм самоконтороля и аварийного завершения.

Примеры для Delphi в целом несколько простоваты, для начала можно взять passthru, но при этом сразу рекомендую его немного изменить для работы с блоками пакетов (аналогичный пример на С называется packthru), это существенно улучшит производительность. В остальном каких то больших трудностей я не вижу, добавить дополнительные пакеты в UDP сессию относительно несложно.

[Vadim Smirnov]

Примера для C#, к сожалению нет, в следующих версиях соответствующие функции будут добавлены к ndisapi.dll, но ничего не мешает сделать сейчас:

//
// Function recalculates IP checksum
//
void
CNdisApi::RecalculateIPChecksum(
	PINTERMEDIATE_BUFFER pPacket
)
{
	unsigned short word16;
	unsigned int sum = 0;
	unsigned int i = 0;
	PUCHAR buff;

	iphdr_ptr pIpHeader = (iphdr_ptr)&pPacket->m_IBuffer[sizeof(ether_header)];

	// Initialize checksum to zero
	pIpHeader->ip_sum = 0;
	buff = (PUCHAR)pIpHeader;

	// Calculate IP header checksum
	for (i = 0; i < pIpHeader->ip_hl * sizeof(DWORD); i = i + 2)
	{
		word16 = ((buff[i] << 8) & 0xFF00) + (buff[i + 1] & 0xFF);
		sum = sum + word16;
	}

	// keep only the last 16 bits of the 32 bit calculated sum and add the carries
	while (sum >> 16)
		sum = (sum & 0xFFFF) + (sum >> 16);

	// Take the one's complement of sum
	sum = ~sum;

	pIpHeader->ip_sum = htons((unsigned short)sum);
}

//
// Function recalculates ICMP checksum
//
void
CNdisApi::RecalculateICMPChecksum(
	PINTERMEDIATE_BUFFER pPacket
)
{
	unsigned short word16, padd = 0;
	unsigned int i, sum = 0;
	PUCHAR buff;
	DWORD dwIcmpLen;
	icmphdr_ptr pIcmpHeader = NULL;
	iphdr_ptr pIpHeader = (iphdr_ptr)&pPacket->m_IBuffer[sizeof(ether_header)];

	// Sanity check
	if (pIpHeader->ip_p == IPPROTO_ICMP)
	{
		pIcmpHeader = (icmphdr_ptr)(((PUCHAR)pIpHeader) + sizeof(DWORD)*pIpHeader->ip_hl);
	}
	else
		return;

	dwIcmpLen = ntohs(pIpHeader->ip_len) - pIpHeader->ip_hl * 4;

	if ((dwIcmpLen / 2) * 2 != dwIcmpLen)
	{
		padd = 1;
		pPacket->m_IBuffer[dwIcmpLen + pIpHeader->ip_hl * 4 + sizeof(ether_header)] = 0;
	}

	buff = (PUCHAR)pIcmpHeader;
	pIcmpHeader->checksum = 0;

	// make 16 bit words out of every two adjacent 8 bit words and 
	// calculate the sum of all 16 bit words
	for (i = 0; i< dwIcmpLen + padd; i = i + 2) {
		word16 = ((buff[i] << 8) & 0xFF00) + (buff[i + 1] & 0xFF);
		sum = sum + (unsigned long)word16;
	}

	// keep only the last 16 bits of the 32 bit calculated sum and add the carries
	while (sum >> 16)
		sum = (sum & 0xFFFF) + (sum >> 16);

	// Take the one's complement of sum
	sum = ~sum;

	pIcmpHeader->checksum = ntohs((unsigned short)sum);
}

//
// Function recalculates TCP checksum
//
void
CNdisApi::RecalculateTCPChecksum(
	PINTERMEDIATE_BUFFER pPacket
)
{
	tcphdr_ptr pTcpHeader = NULL;
	unsigned short word16, padd = 0;
	unsigned int i, sum = 0;
	PUCHAR buff;
	DWORD dwTcpLen;

	iphdr_ptr pIpHeader = (iphdr_ptr)&pPacket->m_IBuffer[sizeof(ether_header)];

	// Sanity check
	if (pIpHeader->ip_p == IPPROTO_TCP)
	{
		pTcpHeader = (tcphdr_ptr)(((PUCHAR)pIpHeader) + sizeof(DWORD)*pIpHeader->ip_hl);
	}
	else
		return;

	dwTcpLen = ntohs(pIpHeader->ip_len) - pIpHeader->ip_hl * 4;//pPacket->m_Length - ((PUCHAR)(pTcpHeader) - pPacket->m_IBuffer);

	if ((dwTcpLen / 2) * 2 != dwTcpLen)
	{
		padd = 1;
		pPacket->m_IBuffer[dwTcpLen + pIpHeader->ip_hl * 4 + sizeof(ether_header)] = 0;
	}

	buff = (PUCHAR)pTcpHeader;
	pTcpHeader->th_sum = 0;

	// make 16 bit words out of every two adjacent 8 bit words and 
	// calculate the sum of all 16 vit words
	for (i = 0; i< dwTcpLen + padd; i = i + 2) {
		word16 = ((buff[i] << 8) & 0xFF00) + (buff[i + 1] & 0xFF);
		sum = sum + (unsigned long)word16;
	}

	// add the TCP pseudo header which contains:
	// the IP source and destination addresses,

	sum = sum + ntohs(pIpHeader->ip_src.S_un.S_un_w.s_w1) + ntohs(pIpHeader->ip_src.S_un.S_un_w.s_w2);
	sum = sum + ntohs(pIpHeader->ip_dst.S_un.S_un_w.s_w1) + ntohs(pIpHeader->ip_dst.S_un.S_un_w.s_w2);

	// the protocol number and the length of the TCP packet
	sum = sum + IPPROTO_TCP + (unsigned short)dwTcpLen;

	// keep only the last 16 bits of the 32 bit calculated sum and add the carries
	while (sum >> 16)
		sum = (sum & 0xFFFF) + (sum >> 16);

	// Take the one's complement of sum
	sum = ~sum;

	pTcpHeader->th_sum = htons((unsigned short)sum);
}

//
// Function recalculates UDP checksum
//
void
CNdisApi::RecalculateUDPChecksum(
	PINTERMEDIATE_BUFFER pPacket
)
{
	udphdr_ptr pUdpHeader = NULL;
	unsigned short word16, padd = 0;
	unsigned int i, sum = 0;
	PUCHAR buff;
	DWORD dwUdpLen;

	iphdr_ptr pIpHeader = (iphdr_ptr)&pPacket->m_IBuffer[sizeof(ether_header)];

	// Sanity check
	if (pIpHeader->ip_p == IPPROTO_UDP)
	{
		pUdpHeader = (udphdr_ptr)(((PUCHAR)pIpHeader) + sizeof(DWORD)*pIpHeader->ip_hl);
	}
	else
		return;

	dwUdpLen = ntohs(pIpHeader->ip_len) - pIpHeader->ip_hl * 4;//pPacket->m_Length - ((PUCHAR)(pTcpHeader) - pPacket->m_IBuffer);

	if ((dwUdpLen / 2) * 2 != dwUdpLen)
	{
		padd = 1;
		pPacket->m_IBuffer[dwUdpLen + pIpHeader->ip_hl * 4 + sizeof(ether_header)] = 0;
	}

	buff = (PUCHAR)pUdpHeader;
	pUdpHeader->th_sum = 0;

	// make 16 bit words out of every two adjacent 8 bit words and 
	// calculate the sum of all 16 vit words
	for (i = 0; i< dwUdpLen + padd; i = i + 2) {
		word16 = ((buff[i] << 8) & 0xFF00) + (buff[i + 1] & 0xFF);
		sum = sum + (unsigned long)word16;
	}

	// add the UDP pseudo header which contains:
	// the IP source and destination addresses,

	sum = sum + ntohs(pIpHeader->ip_src.S_un.S_un_w.s_w1) + ntohs(pIpHeader->ip_src.S_un.S_un_w.s_w2);
	sum = sum + ntohs(pIpHeader->ip_dst.S_un.S_un_w.s_w1) + ntohs(pIpHeader->ip_dst.S_un.S_un_w.s_w2);

	// the protocol number and the length of the UDP packet
	sum = sum + IPPROTO_UDP + (unsigned short)dwUdpLen;

	// keep only the last 16 bits of the 32 bit calculated sum and add the carries
	while (sum >> 16)
		sum = (sum & 0xFFFF) + (sum >> 16);

	// Take the one's complement of sum
	sum = ~sum;

	pUdpHeader->th_sum = ntohs((unsigned short)sum);
}

[Vadim Smirnov]

Если пакет был изменен, то надо по меньше мере пересчитать контрольные суммы. Это делается? Если нет, то пакет с неверной контрольной суммой может быть просто отброшен стеком на принимающей стороне.

[Vadim Smirnov]

You must process the packet before calling

Ndisapi.SendPacketToAdapter(driverPtr, ref request);

The call above injects the packet into the network flow and processing does not make any sense after this point.

If I understand you right then you are working over bandwidth limiter solution for outgoing traffic. So, instead of SendPacketToAdapter you should put packet into the queue (List<INTERMEDIATE_BUFFER> an example). A different thread can pop packets from the queue and call SendPacketToAdapter for them when time passes or queue reaches some predefined limit.

[Vadim Smirnov]

Just add Console.ReadKey() before forwarding packet to the network interface. Below is a part of PassThru C# sample with Console.ReadKey() added.

Please note, that all the networking for the selected network interface will be frozen while console waits for the input…

while (packetsCount > 0)
{
	manualResetEvent.WaitOne();

	while (Ndisapi.ReadPacket(driverPtr, ref request))
        {
        	--packetsCount;

                buffer = (INTERMEDIATE_BUFFER)Marshal.PtrToStructure(bufferPtr, typeof(INTERMEDIATE_BUFFER));

                WriteToConsole(buffer, bufferPtr);

                if (buffer.m_dwDeviceFlags == Ndisapi.PACKET_FLAG_ON_SEND)
		{
			Console.ReadKey();
	                Ndisapi.SendPacketToAdapter(driverPtr, ref request);
		}
                else
                        Ndisapi.SendPacketToMstcp(driverPtr, ref request);
        }

        manualResetEvent.Reset();
}

[Vadim Smirnov]

WinpkFilter 3.2.7.6 update:

• Fixed Hyper-V switch issue: enabling filter driver for virtual switch and at the same time for the network interface below it, could result incorrect send/receive operation counting and thus prevent the filter from correct detach. Under some circumstances it could result DRIVER_POWER_STATE_FAILURE.

Driver version in version resource was also updated according the request above.

If you are eligible for a free update, please send the following details to [email protected] tо receive an update instruction:

Your order ID.
An approximate date of purchasing.

[Vadim Smirnov]

Yes, NDIS LWF drivers were rebuilt to switch off the debug output, but besides this driver has not changed (and other drivers were not changed at all). If you have any reason to have the resource changed in the onsite build I could consider doing this. However, the onsite build is mostly used for demo and test purposes so I never thought that it can be important.

[Vadim Smirnov]

Hmm, I don’t think you can alter Windows native bridge behavior, however you can try an alternative network bridging approach suggested here https://www.ntkernel.com/bridging-networks-with-windows-packet-filter/. It should work for your setup.

If your task is connecting RNDIS USB device to laptop network then you can also use NAT approach instead bridge. I have had such experience in the past with USB connected NetTalk DUO device.

And the last, you can try to play around OID_GEN_CURRENT_PACKET_FILTER by setting it directly for underlying USB RNDIS miniport. WinpkFilter driver allows you to bind above and below Windows native Ethernet Bridge, so you can bind to USB RNDIS miniport directly even with enabled bridging. And then try try set different filter for USB RNDIS by using CNdisApi:SetHwPacketFilter. Al least you can find out if setting different packet filter can help here.

[Vadim Smirnov]

It looks that problem is specific to the particular host, not to Windows 10 in general. There are two possibilities: first, something is screwed in this particular Windows installation and you may try system restore or you have some kind of security software installed which prevents third-party drivers from being installed…

[Vadim Smirnov]

I have tested VirtNet on Windows 10 x86 1511 and Windows 10 x64 1607. In both cases driver was installed using Device Manager and installation worked as intended.

I suspect you have tryed to install x86 driver build on x64 platform or vide versa. This would explain an error message you have got.

[Vadim Smirnov]

Hmm, probably driver package have to be updated to support Windows 10. We will check and update the package if necessary.

[Vadim Smirnov]

Question: What happens if, for whatever reason, all 1000 buffers are filled before a receiver calls ReadPacket(hDriver, &Request)?

First, I have to note that part of this buffers (10% or 100 packets) is reserved and never placed into the adapter queue. So if packets queue grows up to 900 buffers (an example, if user mode application stops reading packets from the driver) then the driver stops placing followed packets into the queue. Instead it checks packets against loaded static filters and current adapter mode, if the packet should be passed then it is passed, if it should be dropped OR PLACED INTO THE QUEUE then is is DROPPED. Such driver behaviour allows to avoid network lock if user mode application is hangs. An example, in case of remote debugging you can set the static filter to pass TCP port 3389 (RDP) and even if you stop the filtering application in debugger (causing driver queue grow up to maximum size) you still won’t loose the RDP connection. Although, please note that all other network activity (except allowed explicitely by static filters) will be blocked.

[Author]

Posts