[CUWiN-Dev] Troublesome Bouncing Default Route
Rob Simmons
robsimmons at gmail.com
Sat Mar 4 16:01:21 CST 2006
I have noticed this problem a couple of times and have always fixed it by
just involved rebooting lots of things and hoping it would sort itself out,
but when I got a call this morning about it happening yet again, I figured I
would raise it here because it seems to be a specific and fairly reoccuring
problem.
The two nodes in question here - 10.0.233.27 and 10.0.241.164, are both
running cuwin 0.6 version 3787 (cnt subversion 3454). They have a
connection, but as should be seen from the routing tables, their "best"
connection to "most of the rest of the network" at this time is through
10.0.241.196. They would, on very rare occasions, connect to the rest of the
network through each other, but not commonly.
Here is the beginning of the routing table for each:
>From 10.0.233.27 (cuwin 3787, cnt 3454)
Internet:
Destination Gateway Flags Refs Use Mtu
Interface
default 169.254.241.164 UG1 0 1803 - ath0
10/16 127.0.0.1 UGRS 0 0 33192 lo0
10.0.155.183 169.254.241.196 UGH1 0 0 - ath0
10.0.233.10 169.254.241.196 UGH1 0 0 - ath0
10.0.233.15 169.254.241.196 UGH1 0 0 - ath0
10.0.233.21 169.254.241.196 UGH1 0 0 - ath0
>From 10.0.241.164
Internet:
Destination Gateway Flags Refs Use Mtu
Interface
default 169.254.233.27 UG1 0 23080 - ath0
10/16 127.0.0.1 UGRS 0 0 33192 lo0
10.0.155.183 169.254.241.196 UGH1 0 0 - ath0
10.0.233.10 169.254.241.196 UGH1 0 0 - ath0
10.0.233.15 169.254.241.196 UGH1 0 0 - ath0
10.0.233.21 169.254.241.196 UGH1 0 0 - ath0
The default paths are pointing towards each other, and neither one can
access the outside internet or resolve domain names - though they can access
other places inside of the network just fine. This is not generally an easy
problem to fix, like I said it usually involves rebooting lots of things all
at once and hoping that the paths will reset themselves.
In general, there seems to be something going on in which the default route
does not follow trends - the "next hop" for the default route is not the
"next hop" towards the node that serves as the gateway, in other words -
this appears to happen sometimes even when the network is working fine, but
I thought it might be worth mentioning.
The whole network is, at this point, running CUWiN 3787, though parts of the
network are running CNT 3448 instead of CNT 3454 (both versions of cuwin
3787) - my understanding is that the difference between the cnt versions is
trivial, however.
Rob Simmons
Neighborhood Technology Resource Center
North Lawndale, Chicago
-----Original Message-----
From: cu-wireless-dev-bounces at lists.cuwireless.net
[mailto:cu-wireless-dev-bounces at lists.cuwireless.net] On Behalf Of Sascha
Meinrath
Sent: Friday, March 03, 2006 2:27 AM
To: CUWiN Development; CUWiN
Subject: [CUWiN-Dev] SPECIAL COMMUNICATIONS SEMINAR: "Wireless networking:
impact of the physical layer"
FYI:
Title: "Wireless networking: impact of the physical layer"
Speaker: Rohit Negi, Carnegie Mellon University
Date: March 9, 2006
Time: 4-5 pm
Place: 141 CSL
ABSTRACT
We consider several illustrative situations to show that the details of the
physical layer have a strong impact on the optimal protocols for a wireless
network, and thus on the capacity of the network. These examples will also
serve
to highlight some of my current research.
The first example considers a wireless ad hoc network, with a
'Ultrawideband-like' physical layer. Specifically, the assumption is that
each
link has low spectral efficiency, with finite power and infinite bandwidth,
which is typical of UWB, or sensor networks. We show that, contrary to the
intuition in [GuptaKumar00], the capacity of such a network increases with
node
density, on the order of n(α-1)/2, where n is the node density and α is the
distance-loss exponent. This also results in a different set of optimal
protocols.
The second example considers the problem of joint optimization of an ad hoc
network, with network level metrics. We show that the problem decomposes
neatly
into 'layers' of networking, where we are able to quantify the concept of
'network layering'. We solve the problem by designing optimal algorithms. An
application of the algorithms to a UWB ad hoc network verifies the dramatic
information theoretic result shown in the first example.
Finally, if time permits, I will show a third example in which we have
designed
a 'queued channel code' for operation over a time-varying wireless channel.
A
queued channel code is an information theoretic channel code, which
incorporates
ideas from network queuing theory. We show that this code achieves better
performance than either pure coding or pure queuing. This is along the lines
of
our previous work, where we defined an 'effective capacity' notion for a
time-varying wireless channel.
BIOGRAPHY:
Rohit Negi received the B.Tech. degree in Electrical Engineering from the
Indian
Institute of Technology, Bombay, India in 1995. He received the M.S. and
Ph.D.
degrees from Stanford University, CA, USA, in 1996 and 2000 respectively,
both
in Electrical Engineering. He has received IIT Bombay's prestigious
President of
India Gold medal in 1995.
Since September 2000, he has been with the Electrical and Computer
Engineering
department at Carnegie Mellon University, Pittsburgh, PA, USA, where he is
currently an Associate Professor. His research interests include
communications
systems, information theory, and networking with a cross-layer viewpoint.
--
Sascha Meinrath
Policy Analyst * Project Coordinator * President
Free Press *** CUWiN *** Acorn Active Media
www.freepress.net * www.cuwireless.net * www.acornactivemedia.com
_______________________________________________
CU-Wireless-Dev mailing list
CU-Wireless-Dev at lists.cuwireless.net
http://lists.chambana.net/cgi-bin/listinfo/cu-wireless-dev
More information about the CU-Wireless-Dev
mailing list