Re: [Wireshark-dev] Npcap 0.04 call for test
2015-08-24 3:38 GMT+02:00 Yang Luo : > Hi list, > > In latest 0.04 r6 version, I have used 0x02, 0x00, 0x00, 0x00 for an IPv4 > packet and 0x18, 0x00, 0x00, 0x00 for an IPv6 packet (tell me if you have > better value for IPv6). The driver can return NdisMediumNull now for > loopback interface. Wireshark seems to work now, one little issue is that > in the "Characteristics" tab in loopback interface's "Interface Details", > "Media supported" and "Medium in use" shows (0x) instead of a > understandable string, this is because that the source code lacks the -1 to > string mapping. > > Latest installer is at: > https://svn.nmap.org/nmap-exp/yang/NPcap-LWF/npcap-nmap-0.04-r6.exe > > Cheers, > Yang > Hi Yang, any reason for not using NdisMediumLoopback that is defined since Vista according to https://msdn.microsoft.com/en-us/library/windows/hardware/ff565910%28v=vs.85%29.aspx ? Maybe it would make sense to switch to DLT_LOOPBACK in that case (in that case the packet type must be put in network order). Note that Wireshark would still display the raw value: I'm gonna update the array. Any reason for not making the NULL/loopback mode default instead of the fake ethernet header? Cheers, Pascal. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Npcap 0.04 call for test
On Aug 24, 2015, at 1:19 AM, Pascal Quantin wrote: > any reason for not using NdisMediumLoopback that is defined since Vista > according to > https://msdn.microsoft.com/en-us/library/windows/hardware/ff565910%28v=vs.85%29.aspx > ? Maybe it would make sense to switch to DLT_LOOPBACK You mean DLT_LOOP rather than DLT_LOOPBACK (that's what OpenBSD, which introduced DLT_LOOP, calls it). > in that case (in that case the packet type must be put in network order). Yes, that's what's different about DLT_LOOP - the address family value is in network byte order rather than host byte order. Note that, if all packets are IPv4 or IPv6 packets, you could also use NdisMediumIP, if that means "received and transmitted packets begin with an IP header and have no link-layer header", and map that to DLT_RAW. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Npcap 0.04 call for test
2015-08-24 10:19 GMT+02:00 Pascal Quantin : > 2015-08-24 3:38 GMT+02:00 Yang Luo : > >> Hi list, >> >> In latest 0.04 r6 version, I have used 0x02, 0x00, 0x00, 0x00 for an >> IPv4 packet and 0x18, 0x00, 0x00, 0x00 for an IPv6 packet (tell me if >> you have better value for IPv6). The driver can return NdisMediumNull now >> for loopback interface. Wireshark seems to work now, one little issue is >> that in the "Characteristics" tab in loopback interface's "Interface >> Details", "Media supported" and "Medium in use" shows (0x) instead >> of a understandable string, this is because that the source code lacks the >> -1 to string mapping. >> >> Latest installer is at: >> https://svn.nmap.org/nmap-exp/yang/NPcap-LWF/npcap-nmap-0.04-r6.exe >> >> Cheers, >> Yang >> > > Hi Yang, > > any reason for not using NdisMediumLoopback that is defined since Vista > according to > https://msdn.microsoft.com/en-us/library/windows/hardware/ff565910%28v=vs.85%29.aspx > ? Maybe it would make sense to switch to DLT_LOOPBACK in that case (in that > case the packet type must be put in network order). > Note that Wireshark would still display the raw value: I'm gonna update > the array. > Any reason for not making the NULL/loopback mode default instead of the > fake ethernet header? > > Cheers, > Pascal. > > BTW for the "Medium in use" value (that corresponds to OID_GEN_PHYSICAL_MEDIUM) should not you report NdisPhysicalMediumUnspecified instead of -1? ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Npcap 0.04 call for test
2015-08-24 10:28 GMT+02:00 Guy Harris : > > On Aug 24, 2015, at 1:19 AM, Pascal Quantin > wrote: > > > any reason for not using NdisMediumLoopback that is defined since Vista > according to > https://msdn.microsoft.com/en-us/library/windows/hardware/ff565910%28v=vs.85%29.aspx > ? Maybe it would make sense to switch to DLT_LOOPBACK > > You mean DLT_LOOP rather than DLT_LOOPBACK (that's what OpenBSD, which > introduced DLT_LOOP, calls it). > Yeas that's what I meant. Sorry for the typo. > > > in that case (in that case the packet type must be put in network order). > > Yes, that's what's different about DLT_LOOP - the address family value is > in network byte order rather than host byte order. > > Note that, if all packets are IPv4 or IPv6 packets, you could also use > NdisMediumIP, if that means "received and transmitted packets begin with an > IP header and have no link-layer header", and map that to DLT_RAW. > Correct, but I was finding the NdisMediumLoopback type maybe more representative as there can be other interfaces using raw IP (liek MBIM USB class). At least with such DLT we have no doubt regarding the fact that it is a loopback capture :) Pascal. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Npcap 0.04 call for test
On Aug 24, 2015, at 1:32 AM, Pascal Quantin wrote: > 2015-08-24 10:28 GMT+02:00 Guy Harris : > >> Note that, if all packets are IPv4 or IPv6 packets, you could also use >> NdisMediumIP, if that means "received and transmitted packets begin with an >> IP header and have no link-layer header", and map that to DLT_RAW. > > Correct, but I was finding the NdisMediumLoopback type maybe more > representative as there can be other interfaces using raw IP (liek MBIM USB > class). At least with such DLT we have no doubt regarding the fact that it is > a loopback capture :) Using the LINKTYPE_/DLT_ value to determine *anything* other than the format of the data at the beginning of the packet is an error. In particular, using it to determine the interface type is an error. You might, for example, have: LINKTYPE_ETHERNET/DLT_EN10MB as the link-layer header type for packets captured from an 802.11 interface that's not in monitor mode (and, yes, the data at the beginning of the packet will be an Ethernet header); LINKTYPE_ETHERNET/DLT_EN10MB as the link-layer header type for packets captured from a loopback device on Linux (and, yes, the data at the beginning of the packet will be an Ethernet header); LINKTYPE_NULL/DLT_NULL as the link-layer header type for packets captured from a loopback device on a BSD-flavord-but-not-OpenBSD system; LINKTYPE_LOOP/DLT_LOOP as the link-layer header type for packets captured from a loopback device on OpenBSD; LINKTYPE_IPNET/DLT_IPNET as the link-layer header type for packets captured from a loopback device on Solaris; etc.. If you want to know whether a device is a loopback device, check the PCAP_IF_LOOPBACK flag in the flags member of the pcap_if_t structure supplied for the device in a pcap_findalldevs() or pcap_findalldevs_ex() call. And, yes, if Npcap isn't setting that flag for the loopback device, it must be changed to do so. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Npcap 0.04 call for test
2015-08-24 10:29 GMT+02:00 Pascal Quantin : > > > 2015-08-24 10:19 GMT+02:00 Pascal Quantin : > >> 2015-08-24 3:38 GMT+02:00 Yang Luo : >> >>> Hi list, >>> >>> In latest 0.04 r6 version, I have used 0x02, 0x00, 0x00, 0x00 for an >>> IPv4 packet and 0x18, 0x00, 0x00, 0x00 for an IPv6 packet (tell me if >>> you have better value for IPv6). The driver can return NdisMediumNull now >>> for loopback interface. Wireshark seems to work now, one little issue is >>> that in the "Characteristics" tab in loopback interface's "Interface >>> Details", "Media supported" and "Medium in use" shows (0x) instead >>> of a understandable string, this is because that the source code lacks the >>> -1 to string mapping. >>> >>> Latest installer is at: >>> https://svn.nmap.org/nmap-exp/yang/NPcap-LWF/npcap-nmap-0.04-r6.exe >>> >>> Cheers, >>> Yang >>> >> >> Hi Yang, >> >> any reason for not using NdisMediumLoopback that is defined since Vista >> according to >> https://msdn.microsoft.com/en-us/library/windows/hardware/ff565910%28v=vs.85%29.aspx >> ? Maybe it would make sense to switch to DLT_LOOPBACK in that case (in that >> case the packet type must be put in network order). >> Note that Wireshark would still display the raw value: I'm gonna update >> the array. >> Any reason for not making the NULL/loopback mode default instead of the >> fake ethernet header? >> >> Cheers, >> Pascal. >> >> > BTW for the "Medium in use" value (that corresponds to > OID_GEN_PHYSICAL_MEDIUM) should not you report > NdisPhysicalMediumUnspecified instead of -1? > > Please discard this last email: I mixed "medium in use" with "physical medium" which is properly reported as unspecified. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Npcap 0.04 call for test
Hi Pascal, "Medium in use" value corresponds to OID_GEN_MEDIA_IN_USE, not OID_GEN_PHYSICAL_MEDIUM, Just below "Medium in use" text, you can see "Physical medium" line, this one is related to OID_GEN_PHYSICAL_MEDIUM, and it's a "Unspecified" for Npcap Loopback Adapter, which I think is a suitable value. I personally think data returned by OID_GEN_MEDIA_IN_USE should be identical with the one returned by OID_GEN_MEDIA_SUPPORTED for our loopback condition based on MSDN explanation, and it's "media" instead of "medium", so I think the display string should be modified to "Media in use" instead of "Medium in use". Cheers, Yang On Mon, Aug 24, 2015 at 4:29 PM, Pascal Quantin wrote: > > > 2015-08-24 10:19 GMT+02:00 Pascal Quantin : > >> 2015-08-24 3:38 GMT+02:00 Yang Luo : >> >>> Hi list, >>> >>> In latest 0.04 r6 version, I have used 0x02, 0x00, 0x00, 0x00 for an >>> IPv4 packet and 0x18, 0x00, 0x00, 0x00 for an IPv6 packet (tell me if >>> you have better value for IPv6). The driver can return NdisMediumNull now >>> for loopback interface. Wireshark seems to work now, one little issue is >>> that in the "Characteristics" tab in loopback interface's "Interface >>> Details", "Media supported" and "Medium in use" shows (0x) instead >>> of a understandable string, this is because that the source code lacks the >>> -1 to string mapping. >>> >>> Latest installer is at: >>> https://svn.nmap.org/nmap-exp/yang/NPcap-LWF/npcap-nmap-0.04-r6.exe >>> >>> Cheers, >>> Yang >>> >> >> Hi Yang, >> >> any reason for not using NdisMediumLoopback that is defined since Vista >> according to >> https://msdn.microsoft.com/en-us/library/windows/hardware/ff565910%28v=vs.85%29.aspx >> ? Maybe it would make sense to switch to DLT_LOOPBACK in that case (in that >> case the packet type must be put in network order). >> Note that Wireshark would still display the raw value: I'm gonna update >> the array. >> Any reason for not making the NULL/loopback mode default instead of the >> fake ethernet header? >> >> Cheers, >> Pascal. >> >> > BTW for the "Medium in use" value (that corresponds to > OID_GEN_PHYSICAL_MEDIUM) should not you report > NdisPhysicalMediumUnspecified instead of -1? > > > ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe > ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Npcap 0.04 call for test
2015-08-24 11:39 GMT+02:00 Yang Luo : > Hi Pascal, > > "Medium in use" value corresponds to OID_GEN_MEDIA_IN_USE, not > OID_GEN_PHYSICAL_MEDIUM, Just below "Medium in use" text, you can see > "Physical medium" line, this one is related to OID_GEN_PHYSICAL_MEDIUM, > and it's a "Unspecified" for Npcap Loopback Adapter, which I think is a > suitable value. > Yes agreed, that's why I sent a follow up email after realizing my mistake. > > I personally think data returned by OID_GEN_MEDIA_IN_USE should be > identical with the one returned by OID_GEN_MEDIA_SUPPORTED for our loopback > condition based on MSDN explanation, and it's "media" instead of "medium", > so I think the display string should be modified to "Media in use" instead > of "Medium in use". > Media is the plural form of medium. "media supported" could list several medium, while only one can be in use at a given time. So the current wording seems OK to me. Note that I updated the list of enum (so as to support loopback value) in https://code.wireshark.org/review/#/c/10225/ > Cheers, > Yang > > > On Mon, Aug 24, 2015 at 4:29 PM, Pascal Quantin > wrote: > >> >> >> 2015-08-24 10:19 GMT+02:00 Pascal Quantin : >> >>> 2015-08-24 3:38 GMT+02:00 Yang Luo : >>> Hi list, In latest 0.04 r6 version, I have used 0x02, 0x00, 0x00, 0x00 for an IPv4 packet and 0x18, 0x00, 0x00, 0x00 for an IPv6 packet (tell me if you have better value for IPv6). The driver can return NdisMediumNull now for loopback interface. Wireshark seems to work now, one little issue is that in the "Characteristics" tab in loopback interface's "Interface Details", "Media supported" and "Medium in use" shows (0x) instead of a understandable string, this is because that the source code lacks the -1 to string mapping. Latest installer is at: https://svn.nmap.org/nmap-exp/yang/NPcap-LWF/npcap-nmap-0.04-r6.exe Cheers, Yang >>> >>> Hi Yang, >>> >>> any reason for not using NdisMediumLoopback that is defined since Vista >>> according to >>> https://msdn.microsoft.com/en-us/library/windows/hardware/ff565910%28v=vs.85%29.aspx >>> ? Maybe it would make sense to switch to DLT_LOOPBACK in that case (in that >>> case the packet type must be put in network order). >>> Note that Wireshark would still display the raw value: I'm gonna update >>> the array. >>> Any reason for not making the NULL/loopback mode default instead of the >>> fake ethernet header? >>> >>> Cheers, >>> Pascal. >>> >>> >> BTW for the "Medium in use" value (that corresponds to >> OID_GEN_PHYSICAL_MEDIUM) should not you report >> NdisPhysicalMediumUnspecified instead of -1? >> >> >> >> ___ >> Sent via:Wireshark-dev mailing list >> Archives:https://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev >> mailto:wireshark-dev-requ...@wireshark.org >> ?subject=unsubscribe >> > > > ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe > ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Npcap 0.04 call for test
Hi Pascal, On Mon, Aug 24, 2015 at 4:19 PM, Pascal Quantin wrote: > > > Hi Yang, > > any reason for not using NdisMediumLoopback that is defined since Vista > according to > https://msdn.microsoft.com/en-us/library/windows/hardware/ff565910%28v=vs.85%29.aspx > ? Maybe it would make sense to switch to DLT_LOOPBACK in that case (in that > case the packet type must be put in network order). > I knew there's a type named NdisMediumLoopback, MSDN said it "Specifies an NDIS loopback network.". I didn't use this value because I think NdisMediumLoopback provided by Microsoft doesn't mean what we understood it, like UNIX/Linux's loopback. In fact, NDIS never see or handle the loopback traffic, loopback packets like ICMP ones sent by "ping 127.0.0.1" never goes to NDIS layer. They are handled in TCP/IP stack (see http://stackoverflow.com/questions/18164876/is-it-possible-to-capture-localhost-packets-127-0-0-1-as-destination-in-ndis-l?rq=1). Npcap used dirty ways (WFP) to make this happen. So I think NdisMediumLoopback means something else that Microsoft wants it to mean, however I didn't find much information about it except MSDN explanation and didn't know what actually it is used for. Another reason is that the original WinPcap (wpcap.dll) doesn't support the mapping from NdisMediumLoopback to DLT_LOOP, but it has the mapping from NdisMediumNull to DLT_NULL. So there are two ways now: 1) NdisMediumNull - DLT_NULL way, 2) NdisMediumLoopback - DLT_LOOP way, will there be a third way like 3) NdisMediumLoopback - DLT_NULL? I didn't see any necessary connections between NdisMediumLoopback and DLT_LOOP except the shared word "loop"? > Note that Wireshark would still display the raw value: I'm gonna update > the array. > Any reason for not making the NULL/loopback mode default instead of the > fake ethernet header? > I didn't make it default because Nmap (and Nping) doesn't work under DLT_NULL mode. I think I have tried possble modifications, see: http://seclists.org/nmap-dev/2015/q3/209 for details. I had a rough analysis and found that at least Nping lacks the code to handle the DLT_NULL traffic. It seems to just view the received response as an Ethernet packet. And I doubt whether other tools like NetScanTools can handle this right. Cheers, yang ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Npcap 0.04 call for test
Hi Pascal, On Mon, Aug 24, 2015 at 5:46 PM, Pascal Quantin wrote: > > >> I personally think data returned by OID_GEN_MEDIA_IN_USE should be >> identical with the one returned by OID_GEN_MEDIA_SUPPORTED for our loopback >> condition based on MSDN explanation, and it's "media" instead of "medium", >> so I think the display string should be modified to "Media in use" instead >> of "Medium in use". >> > > Media is the plural form of medium. "media supported" could list several > medium, while only one can be in use at a given time. So the current > wording seems OK to me. > Note that I updated the list of enum (so as to support loopback value) in > https://code.wireshark.org/review/#/c/10225/ > > I knew that media is the plural form of medium:). And I rechecked the MSDN about OID_GEN_MEDIA_IN_USE (see: https://msdn.microsoft.com/en-us/library/windows/hardware/ff569607(v=vs.85).aspx), it said "*As a query, the OID_GEN_MEDIA_IN_USE OID specifies a complete list of the media types that the NIC currently uses.*". So I think that in Microsoft' point of view, "multiple" media can be in use at a given time (this looks weird for me too). But in practice, I didn't see "multiple" media are ever returned on the OID_GEN_MEDIA_IN_USE or OID_GEN_MEDIA_SUPPORTED request. Cheers, Yang ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Npcap 0.04 call for test
Le 24 août 2015 12:19 PM, "Yang Luo" a écrit : > > Hi Pascal, > > On Mon, Aug 24, 2015 at 4:19 PM, Pascal Quantin wrote: >> >> >> >> Hi Yang, >> >> any reason for not using NdisMediumLoopback that is defined since Vista according to https://msdn.microsoft.com/en-us/library/windows/hardware/ff565910%28v=vs.85%29.aspx ? Maybe it would make sense to switch to DLT_LOOPBACK in that case (in that case the packet type must be put in network order). > > > I knew there's a type named NdisMediumLoopback, MSDN said it "Specifies an NDIS loopback network.". I didn't use this value because I think NdisMediumLoopback provided by Microsoft doesn't mean what we understood it, like UNIX/Linux's loopback. In fact, NDIS never see or handle the loopback traffic, loopback packets like ICMP ones sent by "ping 127.0.0.1" never goes to NDIS layer. They are handled in TCP/IP stack (see http://stackoverflow.com/questions/18164876/is-it-possible-to-capture-localhost-packets-127-0-0-1-as-destination-in-ndis-l?rq=1). Npcap used dirty ways (WFP) to make this happen. So I think NdisMediumLoopback means something else that Microsoft wants it to mean, however I didn't find much information about it except MSDN explanation and didn't know what actually it is used for. > > Another reason is that the original WinPcap (wpcap.dll) doesn't support the mapping from NdisMediumLoopback to DLT_LOOP, but it has the mapping from NdisMediumNull to DLT_NULL. So there are two ways now: 1) NdisMediumNull - DLT_NULL way, 2) NdisMediumLoopback - DLT_LOOP way, will there be a third way like 3) NdisMediumLoopback - DLT_NULL? I didn't see any necessary connections between NdisMediumLoopback and DLT_LOOP except the shared word "loop"? Thanks for the clarification. I did not find any NdisMediumNull definition in ntddndis.h file (I assume this is something you defined locally for convenience), that's why I suggested the NdisMediumLoopback value without double checking its exact meaning. > >> >> Note that Wireshark would still display the raw value: I'm gonna update the array. >> Any reason for not making the NULL/loopback mode default instead of the fake ethernet header? > > > I didn't make it default because Nmap (and Nping) doesn't work under DLT_NULL mode. I think I have tried possble modifications, see: http://seclists.org/nmap-dev/2015/q3/209 for details. > I had a rough analysis and found that at least Nping lacks the code to handle the DLT_NULL traffic. It seems to just view the received response as an Ethernet packet. And I doubt whether other tools like NetScanTools can handle this right. > > Cheers, > yang > > ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org ?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Npcap 0.04 call for test
2015-08-24 12:30 GMT+02:00 Yang Luo : > Hi Pascal, > > On Mon, Aug 24, 2015 at 5:46 PM, Pascal Quantin > wrote: > >> >> >>> I personally think data returned by OID_GEN_MEDIA_IN_USE should be >>> identical with the one returned by OID_GEN_MEDIA_SUPPORTED for our loopback >>> condition based on MSDN explanation, and it's "media" instead of "medium", >>> so I think the display string should be modified to "Media in use" instead >>> of "Medium in use". >>> >> >> Media is the plural form of medium. "media supported" could list several >> medium, while only one can be in use at a given time. So the current >> wording seems OK to me. >> Note that I updated the list of enum (so as to support loopback value) in >> https://code.wireshark.org/review/#/c/10225/ >> >> > I knew that media is the plural form of medium:). And I rechecked the MSDN > about OID_GEN_MEDIA_IN_USE (see: > https://msdn.microsoft.com/en-us/library/windows/hardware/ff569607(v=vs.85).aspx), > it said "*As a query, the OID_GEN_MEDIA_IN_USE OID specifies a complete > list of the media types that the NIC currently uses.*". So I think that > in Microsoft' point of view, "multiple" media can be in use at a given time > (this looks weird for me too). But in practice, I didn't see "multiple" > media are ever returned on the OID_GEN_MEDIA_IN_USE or > OID_GEN_MEDIA_SUPPORTED request. > I amended https://code.wireshark.org/review/#/c/10225/ with the rename. > > Cheers, > Yang > > > ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe > ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Npcap 0.04 call for test
Hi Pascal, I think you would like to add the link types that WinPcap defined but NDIS doesn't define, see: https://github.com/wireshark/winpcap/blob/master/Common/Packet32.h from Line: 76. Comments said that these are "Custom linktype: NDIS doesn't provide an equivalent". And it seems that Npcap loopback adapter will continue to use the "NdisMediumNull - DLT_NULL" pair for now. On Mon, Aug 24, 2015 at 7:00 PM, Pascal Quantin wrote: > > > 2015-08-24 12:30 GMT+02:00 Yang Luo : > >> Hi Pascal, >> >> On Mon, Aug 24, 2015 at 5:46 PM, Pascal Quantin > > wrote: >> >>> >>> I personally think data returned by OID_GEN_MEDIA_IN_USE should be identical with the one returned by OID_GEN_MEDIA_SUPPORTED for our loopback condition based on MSDN explanation, and it's "media" instead of "medium", so I think the display string should be modified to "Media in use" instead of "Medium in use". >>> >>> Media is the plural form of medium. "media supported" could list several >>> medium, while only one can be in use at a given time. So the current >>> wording seems OK to me. >>> Note that I updated the list of enum (so as to support loopback value) >>> in https://code.wireshark.org/review/#/c/10225/ >>> >>> >> I knew that media is the plural form of medium:). And I rechecked the >> MSDN about OID_GEN_MEDIA_IN_USE (see: >> https://msdn.microsoft.com/en-us/library/windows/hardware/ff569607(v=vs.85).aspx), >> it said "*As a query, the OID_GEN_MEDIA_IN_USE OID specifies a complete >> list of the media types that the NIC currently uses.*". So I think that >> in Microsoft' point of view, "multiple" media can be in use at a given time >> (this looks weird for me too). But in practice, I didn't see "multiple" >> media are ever returned on the OID_GEN_MEDIA_IN_USE or >> OID_GEN_MEDIA_SUPPORTED request. >> > > I amended https://code.wireshark.org/review/#/c/10225/ with the rename. > > >> >> Cheers, >> Yang >> >> >> >> ___ >> Sent via:Wireshark-dev mailing list >> Archives:https://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev >> mailto:wireshark-dev-requ...@wireshark.org >> ?subject=unsubscribe >> > > > ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe > ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Npcap 0.04 call for test
2015-08-24 13:18 GMT+02:00 Yang Luo : > Hi Pascal, > > I think you would like to add the link types that WinPcap defined but NDIS > doesn't define, see: > https://github.com/wireshark/winpcap/blob/master/Common/Packet32.h from > Line: 76. Comments said that these are "Custom linktype: NDIS doesn't > provide an equivalent". And it seems that Npcap loopback adapter will > continue to use the "NdisMediumNull - DLT_NULL" pair for now. > Thanks for the link Yang, I was not aware of those defines. I also added them to the patch. Pascal. > > > On Mon, Aug 24, 2015 at 7:00 PM, Pascal Quantin > wrote: > >> >> >> 2015-08-24 12:30 GMT+02:00 Yang Luo : >> >>> Hi Pascal, >>> >>> On Mon, Aug 24, 2015 at 5:46 PM, Pascal Quantin < >>> pascal.quan...@gmail.com> wrote: >>> > I personally think data returned by OID_GEN_MEDIA_IN_USE should be > identical with the one returned by OID_GEN_MEDIA_SUPPORTED for our > loopback > condition based on MSDN explanation, and it's "media" instead of "medium", > so I think the display string should be modified to "Media in use" instead > of "Medium in use". > Media is the plural form of medium. "media supported" could list several medium, while only one can be in use at a given time. So the current wording seems OK to me. Note that I updated the list of enum (so as to support loopback value) in https://code.wireshark.org/review/#/c/10225/ >>> I knew that media is the plural form of medium:). And I rechecked the >>> MSDN about OID_GEN_MEDIA_IN_USE (see: >>> https://msdn.microsoft.com/en-us/library/windows/hardware/ff569607(v=vs.85).aspx), >>> it said "*As a query, the OID_GEN_MEDIA_IN_USE OID specifies a complete >>> list of the media types that the NIC currently uses.*". So I think that >>> in Microsoft' point of view, "multiple" media can be in use at a given time >>> (this looks weird for me too). But in practice, I didn't see "multiple" >>> media are ever returned on the OID_GEN_MEDIA_IN_USE or >>> OID_GEN_MEDIA_SUPPORTED request. >>> >> >> I amended https://code.wireshark.org/review/#/c/10225/ with the rename. >> >> >>> >>> Cheers, >>> Yang >>> >>> >>> >>> ___ >>> Sent via:Wireshark-dev mailing list >>> Archives:https://www.wireshark.org/lists/wireshark-dev >>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev >>> mailto:wireshark-dev-requ...@wireshark.org >>> ?subject=unsubscribe >>> >> >> >> >> ___ >> Sent via:Wireshark-dev mailing list >> Archives:https://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev >> mailto:wireshark-dev-requ...@wireshark.org >> ?subject=unsubscribe >> > > > ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe > ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Npcap 0.04 call for test
Hi Guy, I have looked at all occurrences of PCAP_IF_LOOPBACK in Npcap's wpcap.dll code at https://github.com/nmap/npcap/search?utf8=%E2%9C%93&q=PCAP_IF_LOOPBACK, it seems that this property is never effectively used inside wpcap.dll's code. In Wireshark's WinPcap official trunk, it is totally unused except some prints. See: https://github.com/wireshark/winpcap/search?utf8=%E2%9C%93&q=PCAP_IF_LOOPBACK. So currently PCAP_IF_LOOPBACK is never set in any pcap_if_t struct for WinPcap and Npcap. And It seems to work fine without setting it. Where would Wireshark use this PCAP_IF_LOOPBACK for? I know Nmap does use IPHelper API to list the interfaces and get the loopback type, PCAP_IF_LOOPBACK appears in Nmap's code but it is used in other unimportant places. Cheers, Yang On Mon, Aug 24, 2015 at 4:46 PM, Guy Harris wrote: > > On Aug 24, 2015, at 1:32 AM, Pascal Quantin > wrote: > > > 2015-08-24 10:28 GMT+02:00 Guy Harris : > > > >> Note that, if all packets are IPv4 or IPv6 packets, you could also use > NdisMediumIP, if that means "received and transmitted packets begin with an > IP header and have no link-layer header", and map that to DLT_RAW. > > > > Correct, but I was finding the NdisMediumLoopback type maybe more > representative as there can be other interfaces using raw IP (liek MBIM USB > class). At least with such DLT we have no doubt regarding the fact that it > is a loopback capture :) > > Using the LINKTYPE_/DLT_ value to determine *anything* other than the > format of the data at the beginning of the packet is an error. In > particular, using it to determine the interface type is an error. > > You might, for example, have: > > LINKTYPE_ETHERNET/DLT_EN10MB as the link-layer header type for > packets captured from an 802.11 interface that's not in monitor mode (and, > yes, the data at the beginning of the packet will be an Ethernet header); > > LINKTYPE_ETHERNET/DLT_EN10MB as the link-layer header type for > packets captured from a loopback device on Linux (and, yes, the data at the > beginning of the packet will be an Ethernet header); > > LINKTYPE_NULL/DLT_NULL as the link-layer header type for packets > captured from a loopback device on a BSD-flavord-but-not-OpenBSD system; > > LINKTYPE_LOOP/DLT_LOOP as the link-layer header type for packets > captured from a loopback device on OpenBSD; > > LINKTYPE_IPNET/DLT_IPNET as the link-layer header type for packets > captured from a loopback device on Solaris; > > etc.. > > If you want to know whether a device is a loopback device, check the > PCAP_IF_LOOPBACK flag in the flags member of the pcap_if_t structure > supplied for the device in a pcap_findalldevs() or pcap_findalldevs_ex() > call. > > And, yes, if Npcap isn't setting that flag for the loopback device, it > must be changed to do so. > ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe > ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Npcap 0.04 call for test
On Aug 24, 2015, at 6:08 AM, Yang Luo wrote: > I have looked at all occurrences of PCAP_IF_LOOPBACK in Npcap's wpcap.dll > code at > https://github.com/nmap/npcap/search?utf8=%E2%9C%93&q=PCAP_IF_LOOPBACK, it > seems that this property is never effectively used inside wpcap.dll's code. In fad-win32.c, pcap_add_if_win32() is used by pcap_findalldevs(), and pcap_add_if_win32() calls add_or_find_if() in inet.c, and add_or_find_if() uses PCAP_IF_LOOPBACK. That shows up in the GitHub search done with the URL you specify. > In Wireshark's WinPcap official trunk, it is totally unused except some > prints. See: > https://github.com/wireshark/winpcap/search?utf8=%E2%9C%93&q=PCAP_IF_LOOPBACK. That's because Wireshark's WinPcap official trunk only includes the WinPcap driver, the WinPcap packet.dll DLL, and the WinPcap routines that aren't already part of the official libpcap source - fad-win32.c and inet.c are both part of the official libpcap source: https://github.com/the-tcpdump-group/libpcap/blob/master/fad-win32.c https://github.com/the-tcpdump-group/libpcap/blob/master/inet.c > So currently PCAP_IF_LOOPBACK is never set in any pcap_if_t struct for > WinPcap and Npcap. That should be fixed. > And It seems to work fine without setting it. Where would Wireshark use this > PCAP_IF_LOOPBACK for? 1) WinPcap *itself* uses it to ensure that loopback interfaces sort after non-loopback interfaces, so that if a machine has both "real" and loopback interfaces active, the default interface won't end up being a loopback interface; 2) Wireshark uses it to flag interfaces as being loopback interfaces in some places (see the uses of the "loopback" flag in the if_info_t structure). ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Npcap 0.04 call for test
Hi, Npcap 0.04 r7 is released. 1) One change is that PCAP_IF_LOOPBACK is set for "Npcap Loopback Adapter" in DLT_NULL mode in Npcap 0.04 r7. So if you install Npcap with DLT_NULL mode checked, you can see "Npcap Loopback Adapter" is listed in the last row of Wireshark UI. 2) Another change is that I have included the 802.1Q VLAN capture support provided by Nobori's Win10Pcap. You will see the "VLAN Support" option in the installation and it's checked by default. I didn't test it because I didn't have a network that can send me VLAN tagged traffic, hope any test about this feature or any ideas about how to test it. Latest installer is at: https://svn.nmap.org/nmap-exp/yang/NPcap-LWF/npcap-nmap-0.04-r7.exe Cheers, Yang On Tue, Aug 25, 2015 at 1:12 AM, Guy Harris wrote: > > On Aug 24, 2015, at 6:08 AM, Yang Luo wrote: > > > I have looked at all occurrences of PCAP_IF_LOOPBACK in Npcap's > wpcap.dll code at > https://github.com/nmap/npcap/search?utf8=%E2%9C%93&q=PCAP_IF_LOOPBACK, > it seems that this property is never effectively used inside wpcap.dll's > code. > > In fad-win32.c, pcap_add_if_win32() is used by pcap_findalldevs(), and > pcap_add_if_win32() calls add_or_find_if() in inet.c, and add_or_find_if() > uses PCAP_IF_LOOPBACK. > > That shows up in the GitHub search done with the URL you specify. > > > In Wireshark's WinPcap official trunk, it is totally unused except some > prints. See: > https://github.com/wireshark/winpcap/search?utf8=%E2%9C%93&q=PCAP_IF_LOOPBACK > . > > That's because Wireshark's WinPcap official trunk only includes the > WinPcap driver, the WinPcap packet.dll DLL, and the WinPcap routines that > aren't already part of the official libpcap source - fad-win32.c and inet.c > are both part of the official libpcap source: > > > https://github.com/the-tcpdump-group/libpcap/blob/master/fad-win32.c > > https://github.com/the-tcpdump-group/libpcap/blob/master/inet.c > > > So currently PCAP_IF_LOOPBACK is never set in any pcap_if_t struct for > WinPcap and Npcap. > > That should be fixed. > > > And It seems to work fine without setting it. Where would Wireshark use > this PCAP_IF_LOOPBACK for? > > 1) WinPcap *itself* uses it to ensure that loopback interfaces sort after > non-loopback interfaces, so that if a machine has both "real" and loopback > interfaces active, the default interface won't end up being a loopback > interface; > > 2) Wireshark uses it to flag interfaces as being loopback interfaces in > some places (see the uses of the "loopback" flag in the if_info_t > structure). > ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe > ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
