Detect PPPoE Broadband Connection - restated

Here is the problem restated for these newsgroups:

I need to detect that a user has an active PPPoE connection
for Broadband, such as would be the case for a DSL connection.

For example, under Network Connection applet:

Type: "LAN or High-Speed Internet"
Device Name: <Name of PHYSICAL adapter in system>

Type: "Broadband"
Device Name: "WAN Minport (PPPOE)"

How can I reliably *programatically* - e.g. Win32 API - detect
that the "broadband device" is active? It does NOT seem to appear
in the system the same as a "physical" network adapter, such as
a good ol' wired NIC.

(Thread started in NG microsoft.public.win32.programmer.networks)

Thanks,
Mark

bburgin
Wed Mar 03 23:42:41 CST 2004

------=_NextPart_0001_15CBDB7B
Content-Type: text/plain
Content-Transfer-Encoding: 7bit



Mark,

The OID OID_GEN_PHYSICAL_MEDIUM is marked as optional, but in practice, I
think that most if not all miniports support this OID - especially newer
miniports. Furthermore, I think that cable modems and ADSL modems will
report appropriate values, like NdisPhysicalMediumCableModem,
NdisPhysicalMediumPhoneLine or NdisPhysicalMediumDSL. Perhaps this will
help.

Bryan S. Burgin
bburgin@microsoft.com

This posting is provided "AS IS" with no warranties, and confers no rights.
------=_NextPart_0001_15CBDB7B
Content-Type: text/x-rtf
Content-Transfer-Encoding: 7bit

{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fnil\fprq2\fcharset0 MS Sans Serif;}}
\viewkind4\uc1\pard\f0\fs20
\par
\par Mark,
\par
\par The OID OID_GEN_PHYSICAL_MEDIUM is marked as optional, but in practice, I think that most if not all miniports support this OID - especially newer miniports. Furthermore, I think that cable modems and ADSL modems will report appropriate values, like NdisPhysicalMediumCableModem, NdisPhysicalMediumPhoneLine or NdisPhysicalMediumDSL. Perhaps this will help.
\par
\par Bryan S. Burgin
\par bburgin@microsoft.com
\par
\par This posting is provided "AS IS" with no warranties, and confers no rights.
\par }
------=_NextPart_0001_15CBDB7B--

Mark
Thu Mar 04 04:53:02 CST 2004


Thanks for the replies.

What about the RAS family of API calls, such as
the RASENTRY structure 'RasEnumEntries()' ???

Any solution that is reliable for 9x as well as 2k/XP???


Mark

>
> Here is the problem restated for these newsgroups:
>
> I need to detect that a user has an active PPPoE connection
> for Broadband, such as would be the case for a DSL connection.
>
> For example, under Network Connection applet:
>
> Type: "LAN or High-Speed Internet"
> Device Name: <Name of PHYSICAL adapter in system>
>
> Type: "Broadband"
> Device Name: "WAN Minport (PPPOE)"
>
> How can I reliably *programatically* - e.g. Win32 API - detect
> that the "broadband device" is active? It does NOT seem to appear
> in the system the same as a "physical" network adapter, such as
> a good ol' wired NIC.
>
> (Thread started in NG microsoft.public.win32.programmer.networks)
>
> Thanks,
> Mark

Thomas
Thu Mar 04 08:53:06 CST 2004

The article "How can I detect if my internet connection is active at this
moment?" at ndis.com may also be helpful.

See http://www.ndis.com/faq/QA05040101.htm

Thomas F. Divine
http://www.pcausa.com

"Mark Holiday" <mholiday@nycap.NO-SPAM.rr.com> wrote in message
news:iUD1c.113971$n62.4875@twister.nyroc.rr.com...
>
> Thanks for the replies.
>
> What about the RAS family of API calls, such as
> the RASENTRY structure 'RasEnumEntries()' ???
>
> Any solution that is reliable for 9x as well as 2k/XP???
>
>
> Mark
>
> >
> > Here is the problem restated for these newsgroups:
> >
> > I need to detect that a user has an active PPPoE connection
> > for Broadband, such as would be the case for a DSL connection.
> >
> > For example, under Network Connection applet:
> >
> > Type: "LAN or High-Speed Internet"
> > Device Name: <Name of PHYSICAL adapter in system>
> >
> > Type: "Broadband"
> > Device Name: "WAN Minport (PPPOE)"
> >
> > How can I reliably *programatically* - e.g. Win32 API - detect
> > that the "broadband device" is active? It does NOT seem to appear
> > in the system the same as a "physical" network adapter, such as
> > a good ol' wired NIC.
> >
> > (Thread started in NG microsoft.public.win32.programmer.networks)
> >
> > Thanks,
> > Mark
>
>
>

Stephan
Thu Mar 04 14:23:03 CST 2004

[Re-posted from microsoft.public.win32.programmer.networks due to FUP2
by OP]

Such an adapter (PPPoE) is an NDIS Miniport driver that implements a
virtual network device (as opposed to a physical device). Such devices
have the NCF_VIRTUAL bit set in their "Characteristics", see e.g.
INetCfgComponent::GetCharacteristics().

Note, however, that there are various virtual network adapters, which
are not necessarily doing PPPoE.

See also the BindView sample in the DDK (snetcfg sample in earlier
DDKs) for how to use the INetCfg interface.

Stephan
---
On Wed, 03 Mar 2004 08:56:51 GMT, "Mark Holiday"
<mholiday@nycap.NO-SPAM.rr.com> wrote:

>Here is the problem restated for these newsgroups:
>
>I need to detect that a user has an active PPPoE connection
>for Broadband, such as would be the case for a DSL connection.
>
>For example, under Network Connection applet:
>
>Type: "LAN or High-Speed Internet"
>Device Name: <Name of PHYSICAL adapter in system>
>
>Type: "Broadband"
>Device Name: "WAN Minport (PPPOE)"
>
>How can I reliably *programatically* - e.g. Win32 API - detect
>that the "broadband device" is active? It does NOT seem to appear
>in the system the same as a "physical" network adapter, such as
>a good ol' wired NIC.
>
>(Thread started in NG microsoft.public.win32.programmer.networks)
>
>Thanks,
>Mark

Maxim
Thu Mar 04 17:59:26 CST 2004

> The OID OID_GEN_PHYSICAL_MEDIUM is marked as optional, but in practice, I
> think that most if not all miniports support this OID - especially newer
> miniports.

Am I right that this OID is used by WZC service to distinguish between 802.11
and usual Ethernet?

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Thomas
Thu Mar 04 19:46:19 CST 2004

That should be the case...

However, a better test is to make a "safe" mandatory OID_802_11_XYZ query
that soes not require that the adapter be associated (e.g.,
OID_802_11_SUPPORTED_RATES). If it is successful, then you have found your
802.11 adapter.

OID OID_GEN_PHYSICAL_MEDIUM does work as you hope as far as I can tell. Even
identifies (most) 802.11 adapters on Windows 2000.

Good luck, Max.

Thomas F. Divine
http://www.rawether.net


"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:eMfqLRkAEHA.1468@tk2msftngp13.phx.gbl...
> > The OID OID_GEN_PHYSICAL_MEDIUM is marked as optional, but in practice,
I
> > think that most if not all miniports support this OID - especially newer
> > miniports.
>
> Am I right that this OID is used by WZC service to distinguish between
802.11
> and usual Ethernet?
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
> http://www.storagecraft.com
>
>

Maxim
Fri Mar 05 08:22:34 CST 2004

> However, a better test is to make a "safe" mandatory OID_802_11_XYZ query

OK. Let's imagine the following: I have an IM driver, which must filter IP
traffic only, and must not ever touch the OID set/queries done by WZC. In this
case, I want to have the following bindings:

Tcpip -> MyIMMiniport
MyIMProtocol -> RealMiniport
WZC (does it use NDISUIO? or not?) -> RealMiniport

I must prevent WZC from understanding the upper edge of my IM as one more
802.11 adapter. In this case, I will need to fail some 802.11 OIDs properly, so
that WZC will not even touch the upper egde of my IM, and will talk to real
miniport only.

So, the question is - how to fail them properly, to hide the "802.11" nature of
the underlying adapter from WZC?

Or just patch the UpperBind values in the registry to prevent anybody except
TCP/IP from binding to my IM's upper edge? Maybe use "ndis5_ip" value in the
INF file?

Otherwise, the IM's power management will hinder the flow of "set OID" requests
from WZC to the miniport during awaken, and the miniport will enter some
idiotic state where it fails all operations with "media disconnected" status,
and NdisReset does not help. It seems to need several OID requests from WZC to
go up and indicate the media connect, and this sequence was broken by IM's
power management.

Well, this is more a WinCE issue then Windows one :-) (WinCE PASSTHRU has
absolutely defunct power management paths which hang the machine on awaken.
Another WinCE's issue is that "Turn Wireless Off" facility uses power
management to explicitly power the miniport down - never saw such facilities in
Windows), but I think that "802.11 support in IMs" topic can be a headache in
Windows too.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Thomas
Fri Mar 05 09:53:55 CST 2004


"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:eSZhfzrAEHA.232@TK2MSFTNGP10.phx.gbl...
> > However, a better test is to make a "safe" mandatory OID_802_11_XYZ
query
>
> OK. Let's imagine the following: I have an IM driver, which must filter IP
> traffic only, and must not ever touch the OID set/queries done by WZC. In
this
> case, I want to have the following bindings:
>
> Tcpip -> MyIMMiniport
> MyIMProtocol -> RealMiniport
> WZC (does it use NDISUIO? or not?) -> RealMiniport
>
> I must prevent WZC from understanding the upper edge of my IM as one more
> 802.11 adapter. In this case, I will need to fail some 802.11 OIDs
properly, so
> that WZC will not even touch the upper egde of my IM, and will talk to
real
> miniport only.
>

Altering OID OID_GEN_PHYSICAL_MEDIUM would be one step in "hiding" the
802.11 capability of your virtual miniport. It is simple enough to do, and
if sufficient you are done.

The topic "NDIS IEEE 802.11 Notes" at NDIS.COM includes a log of WZC
operations at startup:

http://www.ndis.com/papers/ieee802_11_notes.htm

You should probably fail the first few "mandatory" queries as unimplemented
when passed to your virtual adapter. For example, fail
OID_802_11_AUTHENTICATION_MODE query, etc.

Good luck,

Thomas F. Divine
http://www.rawether.net


> So, the question is - how to fail them properly, to hide the "802.11"
nature of
> the underlying adapter from WZC?
>
> Or just patch the UpperBind values in the registry to prevent anybody
except
> TCP/IP from binding to my IM's upper edge? Maybe use "ndis5_ip" value in
the
> INF file?
>
> Otherwise, the IM's power management will hinder the flow of "set OID"
requests
> from WZC to the miniport during awaken, and the miniport will enter some
> idiotic state where it fails all operations with "media disconnected"
status,
> and NdisReset does not help. It seems to need several OID requests from
WZC to
> go up and indicate the media connect, and this sequence was broken by IM's
> power management.
>
> Well, this is more a WinCE issue then Windows one :-) (WinCE PASSTHRU has
> absolutely defunct power management paths which hang the machine on
awaken.
> Another WinCE's issue is that "Turn Wireless Off" facility uses power
> management to explicitly power the miniport down - never saw such
facilities in
> Windows), but I think that "802.11 support in IMs" topic can be a headache
in
> Windows too.
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
> http://www.storagecraft.com
>
>

Thomas
Fri Mar 05 10:27:53 CST 2004

You might need to filter OID_GEN_SUPPORTED_LIST to remove 802.11 OIDs as
well.

Thomas F. Divine
http://www.pcausa.com

"Thomas F. Divine [DDK MVP]" <tdivine@NOpcausaSPAM.com> wrote in message
news:%232b%23UosAEHA.1420@TK2MSFTNGP11.phx.gbl...
>
> "Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
> news:eSZhfzrAEHA.232@TK2MSFTNGP10.phx.gbl...
> > > However, a better test is to make a "safe" mandatory OID_802_11_XYZ
> query
> >
> > OK. Let's imagine the following: I have an IM driver, which must filter
IP
> > traffic only, and must not ever touch the OID set/queries done by WZC.
In
> this
> > case, I want to have the following bindings:
> >
> > Tcpip -> MyIMMiniport
> > MyIMProtocol -> RealMiniport
> > WZC (does it use NDISUIO? or not?) -> RealMiniport
> >
> > I must prevent WZC from understanding the upper edge of my IM as one
more
> > 802.11 adapter. In this case, I will need to fail some 802.11 OIDs
> properly, so
> > that WZC will not even touch the upper egde of my IM, and will talk to
> real
> > miniport only.
> >
>
> Altering OID OID_GEN_PHYSICAL_MEDIUM would be one step in "hiding" the
> 802.11 capability of your virtual miniport. It is simple enough to do, and
> if sufficient you are done.
>
> The topic "NDIS IEEE 802.11 Notes" at NDIS.COM includes a log of WZC
> operations at startup:
>
> http://www.ndis.com/papers/ieee802_11_notes.htm
>
> You should probably fail the first few "mandatory" queries as
unimplemented
> when passed to your virtual adapter. For example, fail
> OID_802_11_AUTHENTICATION_MODE query, etc.
>
> Good luck,
>
> Thomas F. Divine
> http://www.rawether.net
>
>
> > So, the question is - how to fail them properly, to hide the "802.11"
> nature of
> > the underlying adapter from WZC?
> >
> > Or just patch the UpperBind values in the registry to prevent anybody
> except
> > TCP/IP from binding to my IM's upper edge? Maybe use "ndis5_ip" value in
> the
> > INF file?
> >
> > Otherwise, the IM's power management will hinder the flow of "set OID"
> requests
> > from WZC to the miniport during awaken, and the miniport will enter some
> > idiotic state where it fails all operations with "media disconnected"
> status,
> > and NdisReset does not help. It seems to need several OID requests from
> WZC to
> > go up and indicate the media connect, and this sequence was broken by
IM's
> > power management.
> >
> > Well, this is more a WinCE issue then Windows one :-) (WinCE PASSTHRU
has
> > absolutely defunct power management paths which hang the machine on
> awaken.
> > Another WinCE's issue is that "Turn Wireless Off" facility uses power
> > management to explicitly power the miniport down - never saw such
> facilities in
> > Windows), but I think that "802.11 support in IMs" topic can be a
headache
> in
> > Windows too.
> >
> > --
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > maxim@storagecraft.com
> > http://www.storagecraft.com
> >
> >
>
>