How to find actual media type of adapter?
Norman Diamond
adapters and Bluetooth adapters can act like Ethernet adapters. So far, so
good -- if a user wants to access another computer's resource via whatever
network it's connected through, the user can do so.
However, how can an application program find the actual media type of each
network adapter? We want to know if it's really a wired Ethernet adapter,
or WiFi, or Bluetooth, or in some cases USB[*], or modem or whatever. The
reason is that by administrative fiat, the program is supposed to adjust its
behaviour according to the actual media type.
From the kind of information that's returned by APIs such as
GetAdaptersInfo, I can't find how to get the actual media type. Please,
anyone who knows how, please say.
Down in the NDIS stack the information is known though I can't quite seem to
find it there either. If there's an IOCTL that is callable from
applications and is guaranteed to return this kind of information then it's
probably good enough. But I can't find any way to do it.
[* If a wired or WiFi or Bluetooth adapter is connected by plugging into a
USB port then it's still a wired or WiFi or Bluetooth adapter. If
ActiveSync has set up an imitation Ethernet connection to a Windows CE
device then we want to know that this is a USB connection.]
Kellie Fitton
The following WMI class should help you out:
Win32_NetworkAdapter
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/wmi/win32_networkadapter.asp
Kellie.
Norman Diamond
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/wmi/win32_networkadapter.asp
the AdapterTypeID member has the same meaning as in some of the APIs.
Possible values include 9 for wireless and 10 for infrared wireless. I
don't see any distinct value for Bluetooth. I don't see any reasonable
value for the simulated Ethernet adapter which ActiveSync creates for a
connection to a Windows CE device.
I have to guess that Bluetooth might map onto 9 and will be
indistinguishable from WiFi. I don't have any guess for simulated Ethernet
adapters -- except that they might be mapped onto 0 because a simulated
Ethernet adapter usually looks like an Ethernet adapter.
Is there any real way for an application program, using a socket that is
connected through some network adapter, to learn the real type of medium
that the adapter uses?
"Kellie Fitton" <KELLIE...@YAHOO.COM> wrote in message
news:1147408180.2...@j73g2000cwa.googlegroups.com...
Jeffrey Tan[MSFT]
Thanks for your post!
Based on my experience, Win32_NetworkAdapter has provided the best
information regarding network adapter. I suspect there is any Win32 API for
distinguishing between bluetooth and wifi.
Do you see any information regarding this difference in your OS UI? For
example, do you get this information in device manager?
Thanks
Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Norman Diamond
details, and of course different devices are controlled by different drivers
(different executable files). From this a human reader can guess what kind
of media are involved (Bluetooth, WiFi, wired, dial-up, etc.). I'm not
quite sure that this is the way for a program to detect it though.
""Jeffrey Tan[MSFT]"" <je...@online.microsoft.com> wrote in message
news:SY4Puuad...@TK2MSFTNGXA01.phx.gbl...
Pavel A.
maybe we could propose some idea for you.
Even if the physical adapter device is a true, real ethernet, the underlying
network can be wi-fi, or cable or whatever.
The physical medium type can be obtained from NDIS layer,
maybe this is available via WMI (MSNDIS... classes).
And USB is not a medium type at all, technically it is a bus.
the medium still is ethernet or wi-fi or whatever.
--PA
"Norman Diamond" <ndia...@community.nospam> wrote in message news:e0JbXgXd...@TK2MSFTNGP04.phx.gbl...
Pavel A.
> As far as I can tell, in page
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/wmi/win32_networkadapter.asp
> the AdapterTypeID member has the same meaning as in some of the APIs.
> Possible values include 9 for wireless and 10 for infrared wireless. I
> don't see any distinct value for Bluetooth.
> indistinguishable from WiFi. I don't have any guess for simulated Ethernet
> adapters -- except that they might be mapped onto 0 because a simulated
> Ethernet adapter usually looks like an Ethernet adapter.
Dear Norman,
The values you're talking about here, are NDIS_MEDIUM enum
defined in ntddndis.h.
NdisMediumWirelessWan = 9 ( 0-based)
NdisMediumIrda = 10 ( 0-based)
Now, in this enum, NdisMediumWirelessWan does not mean wi-fi (802.11);
also there is no value for bluetooth.
This enum corresponds to OID_GEN_MEDIA_SUPPORTED
and WMI class MSNdis_MediaInUse. It's meaning is the L2 type of data frame.
The next enum, NDIS_PHYSICAL_MEDIUM is used to distinguish the
real physical medium for all netcards that use 802.3 data
frame, or are - as you call it - "simulated Ethernet".
NdisPhysicalMediumUnspecified = 0 (true ethernet or unknown)
NdisPhysicalMediumWirelessLan = 1 (this stands for wi-fi)
NdisPhysicalMediumBluetooth = 10 ( bluetooth)
This enum corresponds to OID_GEN_PHYSICAL_MEDIUM
and WMI class MSNdis_PhysicalMediumType.
Hope this clears up things a little.
> I don't see any reasonable
> value for the simulated Ethernet adapter which ActiveSync creates for a
> connection to a Windows CE device.
This is yet another driver type called "Remote NDIS".
Currently AFAIK MSFT supports only USB version of RNDIS. The
NdisPhysicalMedium
of such driver probably depends on it's real medium type - that
can very well be "unspecified". In this case there is no generic way to
detect physical medium on the *network* side.
However detecting if the *computer* side connection is USB it is quite easy
when you know the PNPDeviceID of the adapter (for example from
enumarating instances of Win32_NetworkAdapter or SetupDi)
Regards,
--PA
Pavel A.
> This enum corresponds to OID_GEN_MEDIA_SUPPORTED
> and WMI class MSNdis_MediaInUse. It's meaning is the L2 type of data frame.
Of course this should be OID_GEN_MEDIA_IN_USE
--PA
Jeffrey Tan[MSFT]
pavel_a has provided the detailed information regarding your problem, you
may give it a check.
It seems this information can only be obtained from Network Devices driver
kit, not from Win32 API. Thanks
Norman Diamond
news:BC96E651-51B6-4740...@microsoft.com...
> "Norman Diamond" wrote:
>> As far as I can tell, in page
>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/wmi/win32_networkadapter.asp
>> the AdapterTypeID member has the same meaning as in some of the APIs.
>> Possible values include 9 for wireless and 10 for infrared wireless. I
>> don't see any distinct value for Bluetooth.
>
> ntddndis.h.
> NdisMediumWirelessWan = 9 ( 0-based)
> NdisMediumIrda = 10 ( 0-based)
> Now, in this enum, NdisMediumWirelessWan does not mean wi-fi (802.11);
> also there is no value for bluetooth.
So that MSDN page was really useless for me. Thank you for confirming that,
and let's continue.
> The next enum, NDIS_PHYSICAL_MEDIUM is used to distinguish the real
> physical medium for all netcards that use 802.3 data frame, or are - as
> you call it - "simulated Ethernet".
> NdisPhysicalMediumUnspecified = 0 (true ethernet or unknown)
> NdisPhysicalMediumWirelessLan = 1 (this stands for wi-fi)
> NdisPhysicalMediumBluetooth = 10 ( bluetooth)
> This enum corresponds to OID_GEN_PHYSICAL_MEDIUM
Yes, that's what I need! In MSDN I couldn't find NDIS_PHYSICAL_MEDIUM but
could find OID_GEN_PHYSICAL_MEDIUM. But OID_GEN_PHYSICAL_MEDIUM
seems to be available only at the driver level and only in Windows CE. I
need to get this information at the application level and get it in both
Windows CE and Windows XP.
> and WMI class MSNdis_PhysicalMediumType.
That will take some studying, to see how WMI gets it from the driver.
>> I don't see any reasonable value for the simulated Ethernet adapter
>> which ActiveSync creates for a connection to a Windows CE device.
>
> This is yet another driver type called "Remote NDIS". Currently AFAIK MSFT
> supports only USB version of RNDIS. The NdisPhysicalMedium of such driver
> probably depends on it's real medium type - that can very well be
> "unspecified". In this case there is no generic way to detect physical
> medium on the *network* side.
>
> However detecting if the *computer* side connection is USB it is quite
> easy when you know the PNPDeviceID of the adapter (for example from
> enumarating instances of Win32_NetworkAdapter or SetupDi)
I'll have to think about that. If there's a USB cable running all the way
to the device then there's no physical medium on the network side, and we
want to recognize this as a USB connection. If there's a USB connection to
a WiFi or Bluetooth adapter then we want to recognize that the physical
medium is WiFi or Bluetooth. ActiveSync 4.1 no longer operates over WiFi
but it still operates over Bluetooth, and we want to know if Bluetooth is
being used, even though the endpoint on the computer side is a USB port.
Your other message asked why we want to know. I don't think I'm allowed to
answer that, but but can give a hint. ActiveSync 3.8 operated over WiFi but
4.1 doesn't. The top-level basic reason is for security, but at the next
level the reason is by administrative decision. Even though it's
technically possible to make an ActiveSync program that will continue
operating over WiFi, the administrative decision was not to do it.
Arkady Frenkel
data
Arkady
"Norman Diamond" <ndia...@community.nospam> wrote in message
news:OiCz7R9d...@TK2MSFTNGP04.phx.gbl...
Pavel A.
if the sync functionality over LAN is removed.
I have not heard of RNDIS over BT, but BT by itself
has several emulation modes (aka profiles); among
them "LAN", "serial port", "modem".
So maybe the WinCE side uses the "serial port" mode,
and so does ActiveSync on PC side?
( then all this NDIS and WMI soup would be irrelevant )
Regards,
--PA
Norman Diamond
IOCTL_NDISUIO_NIC_STATISTICS. Either way, this brings us halfway to the
information that we need. Thank you.
"Arkady Frenkel" <ark...@hotmailxdotx.com> wrote in message
news:eWny3RAe...@TK2MSFTNGP02.phx.gbl...
Norman Diamond
I think that ActiveSync still produces an imitation Ethernet connection,
which I think is the RNDIS environment that you mention. So applications
can still communicate over sockets that look like Ethernet sockets, but we
hope to detect that the physical layer is Bluetooth. The application's
design spec prohibits the application from behaving the same way over
Bluetooth as it would over wired Ethernet or wired USB.
"Pavel A." <pav...@NOwritemeNO.com> wrote in message
news:B4DC91D0-55CC-48C3...@microsoft.com...
Arkady Frenkel
IOCTL_NDISUIO_QUERY_OID_VALUE because
IOCTL_NDIS_QUERY_GLOBAL_STATS absent there
Arkady
"Norman Diamond" <ndia...@community.nospam> wrote in message
news:Ozu$4pJeGH...@TK2MSFTNGP04.phx.gbl...
Pavel A.
> The application's
> design spec prohibits the application from behaving the same way over
> Bluetooth as it would over wired Ethernet or wired USB.
Why? If you need more security over BT, just do same encryption or whatever
over USB, and ignore the difference ?
--PA
Norman Diamond
> "Norman Diamond" wrote:
>> The application's design spec prohibits the application from behaving the
>> same way over Bluetooth as it would over wired Ethernet or wired USB.
>
> Why?
One of my earlier comments answered that as much as possible: I can't
exactly say what the reason is, but felt I could give a hint similar to a
hint that was already posted.
> If you need more security over BT, just do same encryption or whatever
> over USB, and ignore the difference ?
The difference is that your suggestion requires giving programmers the right
to set the level of security and avoid checking what the physical media is,
but the spec requires something different.
By the way, even if security were the only issue, remember what wireless
network "security" used to be like. Even if programmers had the right to
set the level of security, that level of security would not be delivered.
Jeffrey Tan[MSFT]
I am monitoring this thread.
I think your original question of distinguishing between different adapter
media has been answered, yes?
Do you still have any concern? Please feel free to tell me, thanks!
Norman Diamond
Thank you for monitoring. My original question is half answered. I think I
know which APIs to call in order to get a partial answer. (Due to frequent
shifts in priorities I haven't coded it yet though.)
The problem is that sometimes we don't get the actual type of the physical
medium.
For example if ActiveSync is using simulated serial ports over Bluetooth,
then an application can find out that its socket is connected through
ActiveSync and ActiveSync thinks that it's a serial connection, but we can't
find out that it's really Bluetooth.
If the application's socket is connected through a personal area network
then maybe we can distinguish Bluetooth from WiFi. Several MSDN pages give
lists of media types, and the MSDN pages don't all agree with each other
about whether Bluetooth can be distinguished from WiFi. So I can see where
to start some experiments, but I don't know the results yet.
""Jeffrey Tan[MSFT]"" <je...@online.microsoft.com> wrote in message
news:zzK21Yye...@TK2MSFTNGXA01.phx.gbl...
Jeffrey Tan[MSFT]
Thanks for your feedback!
Yes, I understand your current concern is that, in most situation, you can
determine the underlying media type without any problem. But when
ActiveSync is using simulated serial ports, you failed to distinguish
between the underlying media types. That why you say you got the partial
answer.
Based on my research, there is no way to obtain this level of information
from Win32 API level, so we have to obtain this information from NDIS
Network Devices driver kit. This newsgroup mainly focused on Win32
user-mode networking programming interface, and I do not have much
experience on driver mode networking programming, so I suspect you will get
more help from other driver gurus. Do you agree with me that there is no
user-mode programming interface to obtain this information? If you think it
is possible to obtain from some unknown Win32 user-mode programming
interfaece, I will try to give it a consulting for this issue, thanks.
I will wait for your further feedback. Thanks!