Sending packets via a Dialup Adapter

NTDEV
1

All,

I have written a IPSEC VPN client for windows 2K/XP. The kernel components consist of an NDIS NIC driver and Protocol driver. In particular, I use the protocol driver to send and receive UDP and ESP traffic via ethernet frames for IPSEC key management and transport data.

Binding the protocol driver to ethernet drivers is no problem and I can send and receive packets without issue. The problem I am experiencing is when I try to communicate via the dialup adapter. In my protocol driver inf, I allow my lower edge to bind with ndiswanip which works well for receiving traffic but sending the packets that is giving me trouble.

I spent some time searching this list and see a lot of information about using a passthrough driver to filter traffic but not much on generating traffic. After digging around a bit it would appear to me that the whole MS dialup adapter is wired up like a Christmas Tree.

In any case, this is what I have noticed through my own experimentation …

For dialup network interfaces, there are two MAC addresses that are reported via normal API mechanisms. The one reported by the ndiswanip and the one reported using the IP Helper API. The NDIS MAC address appears to be generated at boot time with the first two octets being random and the next four octets always set to 20:52:41:53. The address reported by the IP Helper API is always 00:53:45:00:00:00. However, when sniffing other traffic that passes to and from the ndiswanip adapter, the MAC addresses used are variants on the dialup interface instance and the ndis reported MAC address. Im not sure what MS’entric importance of these addresses are but Im sure it would threaten national security if they documented it.

Right, for example …

The source MAC address in frames sent from the ndiswanip adapter are always prefixed using the first 3 octets of the NDIS MAC address ( ie … XX:XX:20 ) and the last three octets are always 0x00, the dialup interface instance, and 0x00 ( ie … 00:01:00 if this was the first dialup connection ). The destination MAC address simply has the 3rd octet set to the dialup interface instance. So, if the NDIS mac address is 11:22:20:52:41:53 and a pacet is sent from the ndiswanip adapter with the first dialer instance, the source MAC address would be 11:22:20:00:01:00 and the destination MAC address would be 00:00:01:00:00:00. If the dialup connection is restarted, the instance would increment to 2 and the source MAC address would be 11:22:20:00:02:00 and the destination MAC address would be 00:00:02:00:00:00.

Back to my problem …

I setup a test case where I can initially predict these mysterious MAC addresses and actually send and receive traffic via ndiswanip interface without issue. But when the connection is shut down and then brought back up, the dialup instance gets incremented and then Im back to where I started. How do I query this dialup instace id so I can predict the appropriate source and destination mac addresses to use over time? And the holy grail, once I have the id how do I correlate an interface index ( or IP address) to it.

So … all you NDIS GURUs out there, how does a protocol driver send and receive traffic reliably via a dialup adapter? Cisco and checkpoint do it, why can’t I?

Can’t wait to hear some responses.

-Matthew

2

Hi Matthew,

When a dialup line becomes available, you should be getting an
NDIS_STATUS_WAN_LINE_UP status indication in your ProtocolStatus
function. The StatusBuffer parameter is an NDIS_WAN_LINE_UP structure
which contains RemoteAddress and LocalAddress fields. The RemoteAddress
field seems to correspond to the destination MAC address for sending
packets out over a dialup line. If I understand your question, you
should be able to use this information to keep your MAC address
information updated.

Check out “ProtocolStatus”, “NDIS_WAN_LINE_UP” and “NDIS_WAN_LINE_DOWN”
in the DDK for more info.

Hope that helps,
Wendy

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-259162-
xxxxx@lists.osr.com] On Behalf Of xxxxx@shrew.net
Sent: Monday, August 14, 2006 9:14 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Sending packets via a Dialup Adapter

All,

I have written a IPSEC VPN client for windows 2K/XP. The kernel
components
consist of an NDIS NIC driver and Protocol driver. In particular, I
use
the protocol driver to send and receive UDP and ESP traffic via
ethernet
frames for IPSEC key management and transport data.

Binding the protocol driver to ethernet drivers is no problem and I
can
send and receive packets without issue. The problem I am experiencing
is
when I try to communicate via the dialup adapter. In my protocol
driver
inf, I allow my lower edge to bind with ndiswanip which works well for
receiving traffic but sending the packets that is giving me trouble.

I spent some time searching this list and see a lot of information
about
using a passthrough driver to filter traffic but not much on
generating
traffic. After digging around a bit it would appear to me that the
whole
MS dialup adapter is wired up like a Christmas Tree.

In any case, this is what I have noticed through my own
experimentation
…

For dialup network interfaces, there are two MAC addresses that are
reported via normal API mechanisms. The one reported by the ndiswanip
and
the one reported using the IP Helper API. The NDIS MAC address appears
to
be generated at boot time with the first two octets being random and
the
next four octets always set to 20:52:41:53. The address reported by
the IP
Helper API is always 00:53:45:00:00:00. However, when sniffing other
traffic that passes to and from the ndiswanip adapter, the MAC
addresses
used are variants on the dialup interface instance and the ndis
reported
MAC address. Im not sure what MS’entric importance of these addresses
are
but Im sure it would threaten national security if they documented it.

Right, for example …

The source MAC address in frames sent from the ndiswanip adapter are
always prefixed using the first 3 octets of the NDIS MAC address ( ie
…
XX:XX:20 ) and the last three octets are always 0x00, the dialup
interface
instance, and 0x00 ( ie … 00:01:00 if this was the first dialup
connection ). The destination MAC address simply has the 3rd octet set
to
the dialup interface instance. So, if the NDIS mac address is
11:22:20:52:41:53 and a pacet is sent from the ndiswanip adapter with
the
first dialer instance, the source MAC address would be
11:22:20:00:01:00
and the destination MAC address would be 00:00:01:00:00:00. If the
dialup
connection is restarted, the instance would increment to 2 and the
source
MAC address would be 11:22:20:00:02:00 and the destination MAC address
would be 00:00:02:00:00:00.

Back to my problem …

I setup a test case where I can initially predict these mysterious MAC
addresses and actually send and receive traffic via ndiswanip
interface
without issue. But when the connection is shut down and then brought
back
up, the dialup instance gets incremented and then Im back to where I
started. How do I query this dialup instace id so I can predict the
appropriate source and destination mac addresses to use over time? And
the
holy grail, once I have the id how do I correlate an interface index (
or
IP address) to it.

So … all you NDIS GURUs out there, how does a protocol driver send
and
receive traffic reliably via a dialup adapter? Cisco and checkpoint do
it,
why can’t I?

Can’t wait to hear some responses.

-Matthew

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

3

Matthew,

AFAIK the only ‘protocol’ that NDISWAN is expecting to have send packets on
it (or at least the WANIP virtual adapter) is TCPIP.SYS via WANARP.SYS. As
you have divined by observation, the agreement that WANARP and NDISWAN have
with respect to MAC addresses is rather more involved. This single binding
provides for *many* logical ‘interfaces’ (connections) via WANARP and the
MAC address happens to carry the multiplexing/demultiplexing ‘token’ private
value used by WANARP and NDISWAN to in part sort all this out.

You might want to look at other means for generating an IP packet (like TDI)
and let TCPIP/WANARP figure out how to get it into the correct RAS
connection.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

4

Wendy,

This sounds like a very promising suggestion. I will look into this ASAP. Thanks!

David,

I tried every thing I could think of to get ESP to pass through the stack using more traditional APIs/Interfaces with absolutely no luck. Not sure if I checked into TDI though. I will read through the docks and see if this offers any prospects. Thanks!

5

Wendy, this did the trick!!! Thanks so much! I can now bind and interact with the dialup adapter for both send and receive without any problems at all ( that I can tell ). Your a saint!

6

Are you taking care on NDIS_WAN_LINE_UP/_DOWN indications? They report the
PPP connections being made/shutdown, and the set of 2 pseudo-MAC addresses -
local and remote - to be used for this particular connection.

Note that Ethernet ARP cannot work on PPP - it has IPCP instead, and the
result of IPCP state machine is passed as “protocol specific data” in
NDIS_WAN_LINE_UP.

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

----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Tuesday, August 15, 2006 5:13 AM
Subject: [ntdev] Sending packets via a Dialup Adapter

> All,
>
> I have written a IPSEC VPN client for windows 2K/XP. The kernel components
consist of an NDIS NIC driver and Protocol driver. In particular, I use the
protocol driver to send and receive UDP and ESP traffic via ethernet frames for
IPSEC key management and transport data.
>
> Binding the protocol driver to ethernet drivers is no problem and I can send
and receive packets without issue. The problem I am experiencing is when I try
to communicate via the dialup adapter. In my protocol driver inf, I allow my
lower edge to bind with ndiswanip which works well for receiving traffic but
sending the packets that is giving me trouble.
>
> I spent some time searching this list and see a lot of information about
using a passthrough driver to filter traffic but not much on generating
traffic. After digging around a bit it would appear to me that the whole MS
dialup adapter is wired up like a Christmas Tree.
>
> In any case, this is what I have noticed through my own experimentation …
>
> For dialup network interfaces, there are two MAC addresses that are reported
via normal API mechanisms. The one reported by the ndiswanip and the one
reported using the IP Helper API. The NDIS MAC address appears to be generated
at boot time with the first two octets being random and the next four octets
always set to 20:52:41:53. The address reported by the IP Helper API is always
00:53:45:00:00:00. However, when sniffing other traffic that passes to and from
the ndiswanip adapter, the MAC addresses used are variants on the dialup
interface instance and the ndis reported MAC address. Im not sure what
MS’entric importance of these addresses are but Im sure it would threaten
national security if they documented it.
>
> Right, for example …
>
> The source MAC address in frames sent from the ndiswanip adapter are always
prefixed using the first 3 octets of the NDIS MAC address ( ie … XX:XX:20 )
and the last three octets are always 0x00, the dialup interface instance, and
0x00 ( ie … 00:01:00 if this was the first dialup connection ). The
destination MAC address simply has the 3rd octet set to the dialup interface
instance. So, if the NDIS mac address is 11:22:20:52:41:53 and a pacet is sent
from the ndiswanip adapter with the first dialer instance, the source MAC
address would be 11:22:20:00:01:00 and the destination MAC address would be
00:00:01:00:00:00. If the dialup connection is restarted, the instance would
increment to 2 and the source MAC address would be 11:22:20:00:02:00 and the
destination MAC address would be 00:00:02:00:00:00.
>
> Back to my problem …
>
> I setup a test case where I can initially predict these mysterious MAC
addresses and actually send and receive traffic via ndiswanip interface without
issue. But when the connection is shut down and then brought back up, the
dialup instance gets incremented and then Im back to where I started. How do I
query this dialup instace id so I can predict the appropriate source and
destination mac addresses to use over time? And the holy grail, once I have the
id how do I correlate an interface index ( or IP address) to it.
>
> So … all you NDIS GURUs out there, how does a protocol driver send and
receive traffic reliably via a dialup adapter? Cisco and checkpoint do it, why
can’t I?
>
> Can’t wait to hear some responses.
>
> -Matthew
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer