Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[REGRESSION BUG] Incorrect Mask Endianess for adapter address since 1.30 #525

Closed
NULL0B opened this issue Jul 21, 2021 · 7 comments
Closed

[REGRESSION BUG] Incorrect Mask Endianess for adapter address since 1.30 #525

NULL0B opened this issue Jul 21, 2021 · 7 comments
Labels

Comments

@NULL0B
Copy link

@NULL0B NULL0B commented Jul 21, 2021

Hello, consider the following test npcap-sdk-1.10\Examples-pcap\iflist which gives the output in npcap 1.20:
(I only show a subset of virtual adapters but it happens to all of them)

npcap-sdk-1.10\Examples-pcap\Debug>iflist.exe

\Device\NPF_{1DBD961D-D2BE-464B-93D1-068948A5611D}
        Description: Microsoft Corporation
        Loopback: no
        Address Family: #2
        Address Family Name: AF_INET
        Address: 172.29.240.1
        Netmask: 255.255.240.0
        Broadcast Address: 255.255.255.255

\Device\NPF_{6072A7DC-C5DA-4888-916D-95413AAD5874}
        Description: Oracle
        Loopback: no
        Address Family: #2
        Address Family Name: AF_INET
        Address: 192.168.56.1
        Netmask: 255.255.255.0
        Broadcast Address: 255.255.255.255

\Device\NPF_{64568D6B-BBD7-42FB-A63F-1EC581156A01}
        Description: Microsoft Corporation
        Loopback: no
        Address Family: #2
        Address Family Name: AF_INET
        Address: 172.25.144.1
        Netmask: 255.255.240.0
        Broadcast Address: 255.255.255.255

\Device\NPF_{9238A586-502C-4DCF-B512-A64165D828A8}
        Description: Microsoft
        Loopback: no
        Address Family: #2
        Address Family Name: AF_INET
        Address: 192.168.0.199
        Netmask: 255.255.255.0
        Broadcast Address: 255.255.255.255

\Device\NPF_{AF74E326-22BC-44A1-942B-26B6093C0F7D}
        Description: Microsoft
        Loopback: no
        Address Family: #2
        Address Family Name: AF_INET
        Address: 192.168.100.15
        Netmask: 255.255.255.0
        Broadcast Address: 255.255.255.255

\Device\NPF_{C5691C35-41FC-459F-8514-E12FC1AA6C21}
        Description: Microsoft Corporation
        Loopback: no
        Address Family: #2
        Address Family Name: AF_INET
        Address: 172.17.112.1
        Netmask: 255.255.240.0
        Broadcast Address: 255.255.255.255

\Device\NPF_{F64ED30B-FCB1-4017-9C9A-AC133B75ABCB}
        Description: Microsoft Corporation
        Loopback: no
        Address Family: #2
        Address Family Name: AF_INET
        Address: 172.24.96.1
        Netmask: 255.255.240.0
        Broadcast Address: 255.255.255.255

\Device\NPF_{FC00E547-FD8A-43B4-B35C-7EC6FFFD9EE0}
        Description: Microsoft Corporation
        Loopback: no
        Address Family: #2
        Address Family Name: AF_INET
        Address: 172.28.32.1
        Netmask: 255.255.240.0
        Broadcast Address: 255.255.255.255

Now consider the same output but for npcap 1.30+ (Excaclty 1.50 but tested in all)

npcap-sdk-1.10\Examples-pcap\Debug>iflist.exe


\Device\NPF_{1DBD961D-D2BE-464B-93D1-068948A5611D}
        Description: Hyper-V Virtual Ethernet Adapter
        Loopback: no
        Address Family: #2
        Address Family Name: AF_INET
        Address: 172.29.240.1
        Netmask: 0.240.255.255
        Broadcast Address: 255.31.240.1

\Device\NPF_{6072A7DC-C5DA-4888-916D-95413AAD5874}
        Description: VirtualBox Host-Only Ethernet Adapter
        Loopback: no
        Address Family: #2
        Address Family Name: AF_INET
        Address: 192.168.56.1
        Netmask: 0.255.255.255
        Broadcast Address: 255.168.56.1

\Device\NPF_{64568D6B-BBD7-42FB-A63F-1EC581156A01}
        Description: Hyper-V Virtual Ethernet Adapter #5
        Loopback: no
        Address Family: #2
        Address Family Name: AF_INET
        Address: 172.25.144.1
        Netmask: 0.240.255.255
        Broadcast Address: 255.31.144.1

\Device\NPF_{C5691C35-41FC-459F-8514-E12FC1AA6C21}
        Description: Hyper-V Virtual Ethernet Adapter #4
        Loopback: no
        Address Family: #2
        Address Family Name: AF_INET
        Address: 172.17.112.1
        Netmask: 0.240.255.255
        Broadcast Address: 255.31.112.1

\Device\NPF_{F64ED30B-FCB1-4017-9C9A-AC133B75ABCB}
        Description: Hyper-V Virtual Ethernet Adapter #3
        Loopback: no
        Address Family: #2
        Address Family Name: AF_INET
        Address: 172.24.96.1
        Netmask: 0.240.255.255
        Broadcast Address: 255.31.96.1

\Device\NPF_{FC00E547-FD8A-43B4-B35C-7EC6FFFD9EE0}
        Description: Hyper-V Virtual Ethernet Adapter #2
        Loopback: no
        Address Family: #2
        Address Family Name: AF_INET
        Address: 172.28.32.1
        Netmask: 0.240.255.255
        Broadcast Address: 255.31.32.1

Greetings

@NULL0B NULL0B changed the title [REGRESSION BUG] Incorrect Mask Endianess since 1.30 [REGRESSION BUG] Incorrect Mask Endianess for adapter address since 1.30 Jul 21, 2021
@guyharris
Copy link

@guyharris guyharris commented Jul 22, 2021

Netmask and broadcast address.

@guyharris
Copy link

@guyharris guyharris commented Jul 22, 2021

The addresses in the structure returned by pcap_findalldevs() should be in network byte order; PacketAddAdapterNPF() is doing

		((struct sockaddr_in *)Subnet)->sin_addr.S_un.S_addr = ul = 0xffffffff << (32 - pAddr->OnLinkPrefixLength);
		((struct sockaddr_in *)Broadcast)->sin_addr.S_un.S_addr = ~ul | ((struct sockaddr_in *)IfAddr)->sin_addr.S_un.S_addr;

which generates a netmask in host byte order (i.e., if you load the netmask as a 32-bit value, the uppermost 8 bits are the most significant bytes of the address, with the upper bits being 1 and the lower bits being 0).

It should do

		((struct sockaddr_in *)Subnet)->sin_addr.S_un.S_addr = ul = htonl(0xffffffff << (32 - pAddr->OnLinkPrefixLength));

to convert it from host order to network order.

@NULL0B
Copy link
Author

@NULL0B NULL0B commented Jul 22, 2021

The addresses in the structure returned by pcap_findalldevs() should be in network byte order; PacketAddAdapterNPF() is doing

		((struct sockaddr_in *)Subnet)->sin_addr.S_un.S_addr = ul = 0xffffffff << (32 - pAddr->OnLinkPrefixLength);
		((struct sockaddr_in *)Broadcast)->sin_addr.S_un.S_addr = ~ul | ((struct sockaddr_in *)IfAddr)->sin_addr.S_un.S_addr;

which generates a netmask in host byte order (i.e., if you load the netmask as a 32-bit value, the uppermost 8 bits are the most significant bytes of the address, with the upper bits being 1 and the lower bits being 0).

It should do

		((struct sockaddr_in *)Subnet)->sin_addr.S_un.S_addr = ul = htonl(0xffffffff << (32 - pAddr->OnLinkPrefixLength));

to convert it from host order to network order.

Wouldn't be nice If shift in opposite direction instead?

@guyharris
Copy link

@guyharris guyharris commented Jul 22, 2021

Wouldn't be nice If shift in opposite direction instead?

No, it wouldn't, because that would put it in the opposite byte order from the host byte order, which is not guaranteed to be network byte order.

@dmiller-nmap
Copy link
Contributor

@dmiller-nmap dmiller-nmap commented Jul 24, 2021

Thanks everyone for the report and diagnosis. I'll get a fix in this week and we'll discuss whether to move up the Npcap release schedule for this and a few other issues.

@NULL0B
Copy link
Author

@NULL0B NULL0B commented Jul 24, 2021

Wouldn't be nice If shift in opposite direction instead?

No, it wouldn't, because that would put it in the opposite byte order from the host byte order, which is not guaranteed to be network byte order.

But npcap is compiled only for little endian architectures so I asume this is in mind. Any way the use that function is an elegant solution.

@dmiller-nmap
Copy link
Contributor

@dmiller-nmap dmiller-nmap commented Sep 9, 2021

Fixed in Npcap 1.55 release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants