Wireshark · Wireshark-dev: Re: [Wireshark-dev] Question about changing Npcap loopback interface's MTU to 65536

[Yang Luo <hsluoyb@xxxxxxxxx>]

On Fri, Aug 21, 2015 at 10:28 PM, Pascal Quantin <pascal.quantin@xxxxxxxxx> wrote:

2015-08-21 16:02 GMT+02:00 Yang Luo <hsluoyb@xxxxxxxxx>:

Hi Pascal,

On Fri, Aug 21, 2015 at 9:20 PM, Pascal Quantin <pascal.quantin@xxxxxxxxx> wrote:

Hi Yang,

2015-08-21 14:46 GMT+02:00 Yang Luo <hsluoyb@xxxxxxxxx>:

Hi list,

I have updated Npcap to 0.04-r4. This version modified "Npcap Loopback Adapter"'s MTU to 65536, so the maximum packet size is 65550 (65536 + eth_hdr_size).

But I found weird result in Wireshark's "Interface Details" dialog.

1) Npcap Loopback Adapter:

Transmit Buffer Space 1514

Receive Buffer Space 1514

Transmit Block Size 1

Receive Block Size 1

Maximum Packet Size 65550

Another Ethernet interface's result is normal:

2) Ethernet0:

Transmit Buffer Space 1550336

Receive Buffer Space 779264

Transmit Block Size 1514

Receive Block Size 1514

Maximum Packet Size 1514

In Linux, Wireshark doesn't have an "Interface Details" dialog, so I can't know what the expected result should be for a loopback interface. So I'd like to know what these numbers are and is the result of Npcap Loopback Adapter correct? It doesn't seem to affect the capture result.

The latest installer is at:

https://svn.nmap.org/nmap-exp/yang/NPcap-LWF/npcap-nmap-0.04-r4.exe

From what I can see in the source code ( https://code.wireshark.org/review/gitweb?p=wireshark.git;a=blob;f=ui/gtk/capture_if_details_dlg_win32.c;h=76b264646c8cc5eaf1ead6c388d869caed3ccf2f;hb=refs/heads/master ) the info is populated by calling the following Winpcap interfaces:
wpcap_packet_request_uint(adapter, OID_GEN_TRANSMIT_BUFFER_SPACE, &uint_value)
wpcap_packet_request_uint(adapter, OID_GEN_RECEIVE_BUFFER_SPACE, &uint_value)
wpcap_packet_request_uint(adapter, OID_GEN_TRANSMIT_BLOCK_SIZE , &uint_value)
wpcap_packet_request_uint(adapter, OID_GEN_RECEIVE_BLOCK_SIZE, &uint_value)

It seems that these 4 parameters come from the OID request to the adapter device, as loopback adapter actually is not an adapter and doesn't own meaningful values for these 4 params, I think I need to specify hard-coded values for them (65536 MTU can't be changed), so what's the best value to set? IMO I'll make them all 65550, so you will see:

1) Npcap Loopback Adapter:

Transmit Buffer Space 65550

Receive Buffer Space 65550

Transmit Block Size 65550

Receive Block Size 65550

Maximum Packet Size 65550

Is this assignment suitable?

I guess so... but I'm not an expert in this area. ANyway at least for Wiresahrk is is purely informative. For Nmap aor any other software using the sending functionality, will you be able to handle this 64k large sending buffer?

Yes, that's why I modified the MTU. I have confirmed that Nmap and Nping can send 64k large packets to loopback interface now.

 

 

 

wpcap_packet_request_uint is a wrapper on top of wpcap_packet_request which is defined here: https://code.wireshark.org/review/gitweb?p=wireshark.git;a=blob;f=caputils/capture_wpcap_packet.c;h=5b3ffc479d3f4cfb0bfc78eb6ec0a820c39f2f9e;hb=refs/heads/master
From what I can see, it seems to be only used for this dialog.
Note that the NDIS version also seems suspicious (it's reporting 5).

On my side (Win10 x64), it reports 6.3, like in the figure.

NDIS Driver Version 6.30

Indeed it does report 6.30 on my Windows 10 guest. But it reports 5.0 on my Windows 7 VM (which is what I used when doing the test).

I have confirmed this on my Win7 x86 VM. 5.0 means that the Microsoft Loopback Driver is developed using NDIS 5.0 technique. It has nothing to do with the NDIS version (6.0) of Npcap driver. So no worry about this.

 

 

Another problem is on the "Statistics" tab, the "Directed bytes received w/o errors" and "Broadcast bytes received w/o errors" are negative numbers.

Those are retrieved with the following OID requests: OID_GEN_DIRECTED_BYTES_RCV and OID_GEN_BROADCAST_BYTES_RCV. The returned value is expected to fit in an unsigned int (but is displayed as %d...).

OK.

 

 

 

Cheers,

Pascal.

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe