Tim wrote:
Tim:
According to that diagram you have two devices with the same IP on the
same network (the router and box 1), that can't work. Change one of
them. Not sure which? A common practice is to have a .254 ending
address for routers (e.g. 192.168.1.254), though it's not a requirement.
Bob Goodwin:
http://users.wildblue.net/bobgoodwin/RF-Link.png
Now you have a device with a .255 ending address. That's a broadcast
address, which is an entirely different thing than what wireless does,
it's a networking issue. e.g. ping 192.168.1.255 should ping everything
on the LAN, and everything should respond back. Some things will treat
a .255 address as a broadcast one, other things won't; it can be a cause
for strange problems.
Ntp is working normally since I corrected the spelling error
in /etc/hosts. I am accustomed to seeing much lower delays, on the
order of 160 ms, and better offsets, usually near 1 ms, but it is
working and I don't think I need such great accuracy. I believe
I am limited by the system delays through Wildblue. Transit time to
and from the satellite must be on the order of a quarter of a second
in addition to various other system delays?
Satellite internet does introduce bigger delays, there is a large amount
of travel involved, at the very least. Shouldn't be a cause for
concern, though; NTP should take the delays into account.
My only "concern" is that the numbers are a lot different than what I am
accustomed to seeing!
Google produces a lot of interesting stuff on the subject of satellite
delays, ntp, etc.,
at least interesting to me. This guy seems a reasonable source and
explains where the five or six
hundred milliseconds I have observed are going. I figure 126 ms transit
time between earth and
the satellite assuming a 23,500 mile path length. With acknowledgments,
that quickly eats up
500 milliseconds. With the time servers I selected, at less than 200
miles, the delays via the
dial-up system were typically ~165 ms vs 600 - 700 ms now.
I realize that the actual path lengths can vary and are not known with
much accuracy. Also
Direcway/Hughes and Wildblue are different services but probably have
similar system delays.
--------------------------------
Here in the Lower 48 DirectWay is a pure satellite system, unlike its hybrid
predecessor which required a land line modem for all outbound traffic.
The biggest problem with DirectWay is the speed of light. The minimum one-way
distance to a geosynchronous satellite is still 23,500 miles, which is about 1/8
light-second. That means the absolute minimum time required for a full duplex
character echo from the distant end is at least 1/2 second (up & down outbound
followed by up & down return). To that time you must add in the arctangent
multipliers for each of the two look angles, and the absolute delays along any
terrestrial path segments.
Aside from the human interface difficulties this delay presents, it can have all
sorts of weird effects on protocols which expect ping times in the 100 msec
range. I remember how we had to change the cryptographic resync pattern from
10101010... to 11111111000000001111111100000000... for 50 kbps analog modems on
military satellite links. I can well imagine how HTTP acceleration and FTP might
be very adversely affected by such lengthy absolute delays.
If you are trying to connect to the Internet from someplace so remote that
satellite is your only means available, then I think DirectWay may be a
tolerable solution. As an engineer, however, I believe DirectWay's designers
must have been sitting on their collective brains when they packaged their
product exclusively for USB + Windows.
--Doc Savage
Fairview Heights, http://www.redhat.com/archives/psyche-list/2002-October/msg03812.html
IL
----------------------------------
I believe both the router and the bridge are set for dhcp.
That may or may not be a problem, depending on what your bridge's DHCP
server is doling out addresses to and to where (if it's the other side
of the network, and IPs aren't being duplicated, you should be okay).
i.e. If one doles out different IPs than the other, on the same subnet
range (e.g. 192.168.1.1 to 192.168.1.100 by one of them, and
192.168.1.101 to 192.168.1.253 on the other). Or, if the router's
passing out the 192.168.1.x addresses and the other one is doling out
the 10.0.0.x addresses.
The problem is when you have two DHCP servers on the same subnet, or
doling out the same IPs to interconnected subnets.
For whatever reason I haven't been able to get to the bridge setup
screen. That's an annoyance and I don't know why but it works
as it is, help from Linksys would require moving it back on to a
Windows computer and then I would have a language problem.
Some devices also have a telnet address. That gives you a simple
interface to the device, if you find the web interface doesn't get along
with your browser. If worst comes to worst, there should be a master
reset button on it.
Yes, but determining the addresses is my problem. The user information
provided
with the equipment specifies little. The web interface even had trouble
"getting along"
with WinXP, a requirement if you're going to deal with the tech support
people. My
problem is not that the system does not work, actually it is working
surprisingly well,
but that I don't fully understand how or why.
Some of the addresses on the diagram were gleaned from the etherape
display, e.g. the 192.168.1.255 for the router.
That may not be reading things correct, or if it is, you may strike some
problems (as I outlined above).
I'm still struggling to understand the addressing scheme. Dhcp creates
some unknowns,
how can I see the address assignments it's made? Applications like
Etherape provide some
data but you have to be able to interpret it ...
Bob Goodwin
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
