T
Taqi Jaffri
Hello,
I am part of an Undergraduate team at Stanford, and we
are implementing a multi-hop adhoc wireless network for
WindowsXP as our Senior Project.
<i'll give a short intro here, if you're in a hurry
please skip the the actual question two paragraphs down>
Every node on this multi-hop network can act as a
repeater, and thus multi-hop connectivity is achieved for
nodes that are out of range of each other, but can see a
common 'intermediate' node through which their MAC frames
are routed. Denizens of this newsgroup might know this as
solving the classic 'hidden node problem'.
Now, if every node acts as a repeater (flood-routing),
the traffic would quickly become untenable as the number
of nodes in the network increases. For this reason, we
are using the Layer2 Minimum Spanning Tree protocol to
configure the nodes into a loop-free graph. For better
performance, we are implementing the recent Rapid
Spanning Tree version of the protocol (IEEE 802.1w). This
is a straight implementation of what Layer2 bridges
already do, but for windows/wireless. The rest of our
project is security and analysis related (including our
own simulator).
Question:
With all these node-bridges set up, we have a problem
with the fact that Winsock first tries to use ARP to get
the hardware address of the hidden node, when e.g. we try
to ping it. Ideally, this ARP request should also get
multi-hopped to the hidden node but we prefer not to do
this for lack of time (if somebody is interested in why
this is different, email me). Without being multi-hopped,
this ARP request obviously fails, since the source node
is not in range of the hidden node and thus never hears a
RARP. So I need some way to force Winsock to __always mac-
bradcast IP packets__ i.e. never send out an ARP request.
Solution tried:
It works if I use the 'arp' utility in windows to set
the 'address' of the hidden node to mac-broadcast, i.e.
ff-ff-ff-ff-ff. Winsock uses this address to broadcast
the frame, the designated node on the particular segment
the source happens to be on picks it up and repeats it
(by looking at the IP packet inside the frame). The fact
that RSTP has configured the nodes into a spanning tree
ensures that the message gets there. The nodes also
maintain forwarding databases just like regular Layer2
bridges, and so the response from the hidden node is
actually sent right back on the source path (without mac-
broadcasting on each hop).
The major problem with this approach is that I would
have to add an arp entry for EVERY POSSIBLE IP ADDRESS in
the subnet (we are using linklocal) in the arp database
of every node. This is because I dont see a way
to 'wildcard' the above entry i.e. arp -s 169.254.*.* ff-
ff-ff-ff-ff-ff does not work. But that perhaps explains
best what I want to do.
Anybody see something I am missing here? I am frustrated
because our project is supposed to be protocol,
performance, and security related... but here I am
mucking around with Windows implementation nightmares.
Any help will be fully credited in our (already
extensive) credits list.
Best,
/t.
(email me at tjaffri-AT-stanford.eedeeyou)
I am part of an Undergraduate team at Stanford, and we
are implementing a multi-hop adhoc wireless network for
WindowsXP as our Senior Project.
<i'll give a short intro here, if you're in a hurry
please skip the the actual question two paragraphs down>
Every node on this multi-hop network can act as a
repeater, and thus multi-hop connectivity is achieved for
nodes that are out of range of each other, but can see a
common 'intermediate' node through which their MAC frames
are routed. Denizens of this newsgroup might know this as
solving the classic 'hidden node problem'.
Now, if every node acts as a repeater (flood-routing),
the traffic would quickly become untenable as the number
of nodes in the network increases. For this reason, we
are using the Layer2 Minimum Spanning Tree protocol to
configure the nodes into a loop-free graph. For better
performance, we are implementing the recent Rapid
Spanning Tree version of the protocol (IEEE 802.1w). This
is a straight implementation of what Layer2 bridges
already do, but for windows/wireless. The rest of our
project is security and analysis related (including our
own simulator).
Question:
With all these node-bridges set up, we have a problem
with the fact that Winsock first tries to use ARP to get
the hardware address of the hidden node, when e.g. we try
to ping it. Ideally, this ARP request should also get
multi-hopped to the hidden node but we prefer not to do
this for lack of time (if somebody is interested in why
this is different, email me). Without being multi-hopped,
this ARP request obviously fails, since the source node
is not in range of the hidden node and thus never hears a
RARP. So I need some way to force Winsock to __always mac-
bradcast IP packets__ i.e. never send out an ARP request.
Solution tried:
It works if I use the 'arp' utility in windows to set
the 'address' of the hidden node to mac-broadcast, i.e.
ff-ff-ff-ff-ff. Winsock uses this address to broadcast
the frame, the designated node on the particular segment
the source happens to be on picks it up and repeats it
(by looking at the IP packet inside the frame). The fact
that RSTP has configured the nodes into a spanning tree
ensures that the message gets there. The nodes also
maintain forwarding databases just like regular Layer2
bridges, and so the response from the hidden node is
actually sent right back on the source path (without mac-
broadcasting on each hop).
The major problem with this approach is that I would
have to add an arp entry for EVERY POSSIBLE IP ADDRESS in
the subnet (we are using linklocal) in the arp database
of every node. This is because I dont see a way
to 'wildcard' the above entry i.e. arp -s 169.254.*.* ff-
ff-ff-ff-ff-ff does not work. But that perhaps explains
best what I want to do.
Anybody see something I am missing here? I am frustrated
because our project is supposed to be protocol,
performance, and security related... but here I am
mucking around with Windows implementation nightmares.
Any help will be fully credited in our (already
extensive) credits list.
Best,
/t.
(email me at tjaffri-AT-stanford.eedeeyou)