Getting IP Address from NDIS_WAN_LINE_UP ??

As I read win2k DDK document, NDIS_WAN_LINE_UP structure has some usefull information
for my dirver. The structure is define as :
typedef struct _NDIS_WAN_LINE_UP {
IN ULONG LinkSpeed;
IN ULONG MaximumTotalSize;
IN NDIS_WAN_QUALITY Quality;
IN USHORT SendWindow;
IN UCHAR RemoteAddress[6];
IN OUT UCHAR LocalAddress[6];
IN ULONG ProtocolBufferLength;
IN PUCHAR ProtocolBuffer;
IN USHORT ProtocolType;
IN OUT NDIS_STRING DeviceName;
} NDIS_WAN_LINE_UP, *PNDIS_WAN_LINE_UP;
DDK said that ProtocolBuffer contains protocol-specific information supplied
by a higher-level component that makes connections through NDISWAN to
the appropriate protocol(s). For example, this buffer would contain an IP address
if the target protocol is IP . And I debug my driver, I found that ProtocolBufferLength always equals
to 28 bytes. How can I get IP address from ProtocolBuffer?
Thanks.

VOID
PtStatus(
IN NDIS_HANDLE ProtocolBindingContext,
IN NDIS_STATUS GeneralStatus,
IN PVOID StatusBuffer,
IN UINT StatusBufferSize
)
{
PADAPT pAdapt =(PADAPT)ProtocolBindingContext;
PNDIS_WAN_LINE_UP waninfo;
char temp[100];
//
// If we get a status indication before our miniport is initialized, ignore it
// If the SampleIM is not ON, we do not pass on the status indication
//
if(pAdapt->MiniportHandle != NULL &&
pAdapt->MPDeviceState == NdisDeviceStateD0 &&
pAdapt->PTDeviceState == NdisDeviceStateD0 )
{
NdisMIndicateStatus(pAdapt->MiniportHandle,
GeneralStatus,
StatusBuffer,
StatusBufferSize);
if (GeneralStatus == NDIS_STATUS_WAN_LINE_UP)
{
waninfo = (PNDIS_WAN_LINE_UP)StatusBuffer;
}
}
}
return;
}

yours brucie
brucie@263.net
(???r??z{e?˛???m?m?{]z???&j)@u?Ӣ?칻?&ޱ??i?Z?G?j)m?W???u?칻-E?"?Ǧm??(Z?X???,??&

Actually, you could simply take a look into that buffer.

This is for Windows NT 4.0 IndicatedIP = *((PULONG)
&pLineUp->ProtocolBuffer[4]);

This is for Windows 2000/XP IndicatedIP = *(((PULONG)(pLineUp ->
ProtocolBuffer)) + 2);

Regards,

Vadim


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Examine protocol buffer and you’ll see it. Note it is undocumented and can
be changed without notice in the future and in any SP. You have to do some
safety checking: always compare ProtocolBufferLength with known values and
examine IP address(es) for validity. There is more interesting info in this
buffer, for example subnet mask which can be also used for validity
checking.

This structure differs with NT and RAS version. Standard NT4 RAS differs
from w2k and also from NT4 with steelhead installed (steelhead and w2k
buffers are the same).

Best regards,

Michal Vodicka
Veridicom
(RKK - Skytale)
[WWW: http://www.veridicom.com , http://www.skytale.com]


From: iban[SMTP:brucie@263.net]
Reply To: NT Developers Interest List
Sent: Thursday, October 04, 2001 10:47 AM
To: NT Developers Interest List
Subject: [ntdev] Getting IP Address from NDIS_WAN_LINE_UP ??

As I read win2k DDK document, NDIS_WAN_LINE_UP structure has some usefull
information
for my dirver. The structure is define as :
typedef struct _NDIS_WAN_LINE_UP {
IN ULONG LinkSpeed;
IN ULONG MaximumTotalSize;
IN NDIS_WAN_QUALITY Quality;
IN USHORT SendWindow;
IN UCHAR RemoteAddress[6];
IN OUT UCHAR LocalAddress[6];
IN ULONG ProtocolBufferLength;
IN PUCHAR ProtocolBuffer;
IN USHORT ProtocolType;
IN OUT NDIS_STRING DeviceName;
} NDIS_WAN_LINE_UP, *PNDIS_WAN_LINE_UP;
DDK said that ProtocolBuffer contains protocol-specific information
supplied
by a higher-level component that makes connections through NDISWAN to
the appropriate protocol(s). For example, this buffer would contain an IP
address
if the target protocol is IP . And I debug my driver, I found that
ProtocolBufferLength always equals
to 28 bytes. How can I get IP address from ProtocolBuffer?
Thanks.

VOID
PtStatus(
IN NDIS_HANDLE ProtocolBindingContext,
IN NDIS_STATUS GeneralStatus,
IN PVOID StatusBuffer,
IN UINT StatusBufferSize
)
{
PADAPT pAdapt =(PADAPT)ProtocolBindingContext;
PNDIS_WAN_LINE_UP waninfo;
char temp[100];
//
// If we get a status indication before our miniport is initialized,
ignore it
// If the SampleIM is not ON, we do not pass on the status indication
//
if(pAdapt->MiniportHandle != NULL &&
pAdapt->MPDeviceState == NdisDeviceStateD0 &&
pAdapt->PTDeviceState == NdisDeviceStateD0 )
{
NdisMIndicateStatus(pAdapt->MiniportHandle,
GeneralStatus,
StatusBuffer,
StatusBufferSize);
if (GeneralStatus == NDIS_STATUS_WAN_LINE_UP)
{
waninfo = (PNDIS_WAN_LINE_UP)StatusBuffer;
}
}
}
return;
}

yours brucie
brucie@263.net
b???.???????&?v?‘?ׯj??؜’??'?Ӣ?칻?&ޱ??i?Z?G?j)m?W???u???b??(??
(


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

NT4 with steelhead is like w2k. Below code seems correct but it is nasty. I
prefer this way:

typedef struct _tag_LINE_UP_STD_PROTOCOL_BUFFER {
// LITTLE_HACK: it is undocumented contents of protocol buffer for IP
adapter type, standard NT 4.0 RAS
DWORD AdapterType; // 1 - client, 0 - server
DWORD IpAddress; // client IP address
DWORD Zero; // ???

} LINE_UP_STD_PROTOCOL_BUFFER, *PLINE_UP_STD_PROTOCOL_BUFFER;
//lint -esym(754, _tag_LINE_UP_STD_PROTOCOL_BUFFER::Zero) never referenced

typedef struct _tag_LINE_UP_STEELHEAD_PROTOCOL_BUFFER {
// LITTLE_HACK: it is undocumented contents of protocol buffer for IP
adapter type, w2k SteelHead
DWORD AdapterType; // 1 - client, 0 - server
DWORD ServerData; // -1 when client, some number on
server, numbers are equal for the same connections (1st, 2nd etc.)
IP_ADDR LocalIpAddress; // local IP address of current
connection
IP_ADDR SubnetMask; // subnet mask for current connection
IP_ADDR RemoteIpAddress; // remote IP address of current
connection
DWORD Unknown1; // ???
DWORD Unknown2; // ???

} LINE_UP_STEELHEAD_PROTOCOL_BUFFER, *PLINE_UP_STEELHEAD_PROTOCOL_BUFFER;

Best regards,

Michal Vodicka
Veridicom
(RKK - Skytale)
[WWW: http://www.veridicom.com , http://www.skytale.com]


From: Vadim Smirnov[SMTP:xxxxx@pcausa.com]
Reply To: NT Developers Interest List
Sent: Thursday, October 04, 2001 12:59 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Getting IP Address from NDIS_WAN_LINE_UP ??

Actually, you could simply take a look into that buffer.

This is for Windows NT 4.0 IndicatedIP = *((PULONG)
&pLineUp->ProtocolBuffer[4]);

This is for Windows 2000/XP IndicatedIP = *(((PULONG)(pLineUp ->
ProtocolBuffer)) + 2);

Regards,

Vadim


You are currently subscribed to ntdev as: xxxxx@rkk.cz
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

>This structure differs with NT and RAS version. Standard NT4

RAS differs
from w2k and also from NT4 with steelhead installed (steelhead

Did they change the NDISWAN code? Or NDISWAN/underlying miniport interaction?

Max


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

> ----------

From: Maxim S. Shatskih[SMTP:xxxxx@storagecraft.com]
Reply To: NT Developers Interest List
Sent: Friday, October 05, 2001 6:34 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Getting IP Address from NDIS_WAN_LINE_UP ??

>This structure differs with NT and RAS version. Standard NT4
>RAS differs
>from w2k and also from NT4 with steelhead installed (steelhead

Did they change the NDISWAN code? Or NDISWAN/underlying miniport
interaction?

NdisWan code. Steelhead contains a new ndiswan.sys, ndis.sys, wanarp.sys,
tcpip.sys and more. w2k seems to contain only steelhead code which is IMHO a
good decision.

Best regards,

Michal Vodicka
Veridicom
(RKK - Skytale)
[WWW: http://www.veridicom.com , http://www.skytale.com]


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

> NdisWan code. Steelhead contains a new ndiswan.sys, ndis.sys, wanarp.sys,

tcpip.sys and more. w2k seems to contain only steelhead code which is IMHO a
good decision.

Wow! Even NDIS.SYS and TCPIP.SYS? Amazing! So, Steelhead affects even LANs.

Max


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

> ----------

From: Maxim S. Shatskih[SMTP:xxxxx@storagecraft.com]
Reply To: NT Developers Interest List
Sent: Friday, October 05, 2001 11:48 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Getting IP Address from NDIS_WAN_LINE_UP ??

> NdisWan code. Steelhead contains a new ndiswan.sys, ndis.sys,
wanarp.sys,
> tcpip.sys and more. w2k seems to contain only steelhead code which is
IMHO a
> good decision.

Wow! Even NDIS.SYS and TCPIP.SYS? Amazing! So, Steelhead affects even
LANs.

I have to correct myself. What I wrote was right but for SP3 only. There
were several Steelhead updates and to use them, you had to install PPTP
fixes which contained updated ndis, ndiswan and tcpip. SP4 and above support
steelhead update and these modules aren’t updated. Necessary support is
probably already integrated in these drivers which are common for both
standard RAS and Steelhead. You can see steelhead modules as *.STE on SP4+
CDs. Most of them are user mode modules. Sorry, I played with it several
years before and my memory leaks faster than I expected…

Best regards,

Michal Vodicka
Veridicom
(RKK - Skytale)
[WWW: http://www.veridicom.com , http://www.skytale.com]


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

> standard RAS and Steelhead. You can see steelhead modules as *.STE on SP4+

CDs. Most of them are user mode modules. Sorry, I played with it several
years before and my memory leaks faster than I expected…

BTW - the greatest question on NT’s WAN support - what component does the PPP logon - seems to be still open.
Is it done by joint work of undocumented IOCTLs to NDISWAN + user mode DLLs from RRAS?

Max


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

> ----------

From: Maxim S. Shatskih[SMTP:xxxxx@storagecraft.com]
Reply To: NT Developers Interest List
Sent: Saturday, October 06, 2001 4:39 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Getting IP Address from NDIS_WAN_LINE_UP ??

BTW - the greatest question on NT’s WAN support - what component does the
PPP logon - seems to be still open.
Is it done by joint work of undocumented IOCTLs to NDISWAN + user mode
DLLs from RRAS?

Yes. There is a user mode service (RasMan on NT4) which communicates with
NdisWan via IOCTLs. It loads control protocol DLLs as RasChap.dll and
communicates with them using undocumented interface which is similar to
documented EAP interface. CP DLLs get all info about user name, password and
domain and create packets to send and process replies. They register CP
protocol number and so can get all necessary packets. NdisWan establishes
connections, sends and receives packets. Service uses IOCTLs to control it
and routes packets to CP DLLs. CP DLLs implement protocols. I forgot who
exactly logs-on user, probably service based on CP DLL result. This is
simplified, there are CPs which serve for other purposes and so on. You can
turn on PPP logging which gives very good picture about data flow (check KB
how to enable it). Also, NetMon is able to capture initial PPP handshake.
NDIS IM drivers don’t, they receive line up message only after successful
PPP handshake (not true on some w9x, probably because of a bug).

Best regards,

Michal Vodicka
Veridicom
(RKK - Skytale)
[WWW: http://www.veridicom.com , http://www.skytale.com]


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

> Yes. There is a user mode service (RasMan on NT4) which communicates with

NdisWan via IOCTLs. It loads control protocol DLLs as RasChap.dll and

Thanks for a great description!
Are CP DLLs documented?
Am I right that this whole “CP DLL” infrastructure was remade from scratch in Steelhead?

Max


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

> ----------

From: Maxim S. Shatskih[SMTP:xxxxx@storagecraft.com]
Reply To: NT Developers Interest List
Sent: Saturday, October 06, 2001 6:39 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Getting IP Address from NDIS_WAN_LINE_UP ??

Are CP DLLs documented?

AFAIK not. The documented way how to create a new control protocol is EAP.
CP interface works very similar way but necessary structures are different.
It is because EAP itself is CP which has “subprotocols” which you can
implement. There was RasEap.dll sometimes but know I don’t see it in my w2k
installation. It was implemented the same way as other CPs and routed
packets to next DLLs.

Am I right that this whole “CP DLL” infrastructure was remade from scratch
in Steelhead?

I don’t think so. What was changed is control service which has different
name but some common parts with NT4 RasMan (and common bugs). CP DLLs aren’t
changed too much, I would see it as an evolution :wink: Anyway, Steelhead is
much better than NT4 RAS (which couldn’t be worse :).

Ironically, I know much more about NT4 RAS because had a lot of problems
with it when implemented NDIS IM driver layered between NdisWan and TcpIp.
Steelhead fixed most of them and with w2k all problems were fixed at once
because I could use NDIS filter driver. So I don’t know too much about NT4
Steelhead and only a little about its w2k implementation.

Best regards,

Michal Vodicka
Veridicom
(RKK - Skytale)
[WWW: http://www.veridicom.com , http://www.skytale.com]


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com