Re: Question about changing Npcap loopback interface's MTU to 65536

[Yang Luo <hsluoyb () gmail com>]

On Fri, Aug 21, 2015 at 10:28 PM, Pascal Quantin <pascal.quantin () gmail com>
wrote:

> 2015-08-21 16:02 GMT+02:00 Yang Luo <hsluoyb () gmail com>:
>
> > Hi Pascal,
> >
> > On Fri, Aug 21, 2015 at 9:20 PM, Pascal Quantin <pascal.quantin () gmail com
> > > wrote:
> >
> > > Hi Yang,
> > >
> > > 2015-08-21 14:46 GMT+02:00 Yang Luo <hsluoyb () gmail com>:
> > >
> > > > 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.


> [image: Inline image 1]
> > 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.


> > [image: Inline image 2]
> >
> >
> >
> > > Cheers,
> > > Pascal.
> > >
> > >
> > > ___________________________________________________________________________
> > > Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> > > Archives:    https://www.wireshark.org/lists/wireshark-dev
> > > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> > >              mailto:wireshark-dev-request () wireshark org
> > > ?subject=unsubscribe
> >
> >
> >
> > ___________________________________________________________________________
> > Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> > Archives:    https://www.wireshark.org/lists/wireshark-dev
> > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> >              mailto:wireshark-dev-request () wireshark org
> > ?subject=unsubscribe
>
>
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> Archives:    https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request () wireshark org
> ?subject=unsubscribe

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