On Monday 20 September 2004 16:55, Jeff Gladnick wrote:
> Well we are considering a wifi router (802.11g) for every other gondola
> cabin. So that would provide a large coverage area. I don't have a lot
> of personal experience with that, my impression is that it can only make
> 3 "hops" along a line. For Gondola lines stretching to 15,000 feet
> long, this could become a problem, especially in inclement weather.
Increasing spacing between the routers might help.
As far as I understand (but I'm not at all an expert in Wifi technology...),
the 3-hops restriction *might* come from the fact that there can only be 3
independant networks coexisting (there are more channels, but most overlap).
The trick then is to make sure that
1. Routers are close enough to each other that each router can comfortably
"see" the next.
2. They are far enough that each can't see to hops ahead.
That way, the 3 hop restriction might be lifted... except for one detail: the
line moving into the other direction will be too close, and in addition to
seeing the previous and the next router, each router will also see up to 3
routers moving into the other direction. Not so good.
I also wonder how good Wifi technology is at preventing loops. Latency might
be big enough that packets might run eternally in circles along the gondola
line...
Hmm, I wonder whether it woldn't be feasible to somehow use the
suspension/traction cable as a (low bandwidth) data transmission medium. Some
clever hardware hacking would be needed to make this work (it's only one
wire, and unshielded, so data transmission rate would be pretty low).
Moreover, inside the station, the gondolas would be disconnected, but there
again you can use Wifi (i.e. gondolas listen for transmissions on the cable
when outside, and to transmissions of wifi when inside. Could be set up by
equipping each PC with 2 interfaces configured to 2 addresses on a same LAN).
A small codechange in udpreceiver would be needed in order to be able to join
the multicast group on more than one interface.
> So updating simultaneously can always be my goal, and updating once a
> day (if necessary) can always be the situation that I can live with.
>
> Hooking up the upper station of the gondola may or may not be an issue.
> Usually these places are several thousand feet up in the mountains, in
> cold freaking weather. I am not sure if resorts have network
> connections up there or not. We will have to check into this.
Aren't there communication links anyways hooking the upper station to the
valley station? After all, you probably have telephone and other amenities up
there. And in most skying resorts I've been, they run electric wires on top
of the support pillars (in the middle), in addition to the traction and
suspension cables (on the sides).
It might even be feasible to setup Wifi access points on the poles, rather
than inside the gondolas (which would remove the problems of access points
moving around: in that case, only the receivers move, but not the APs).
Potential problem: will they withstand the cold?
Alain
Hey, all.
I'm looking to image about 30 Dell desktops running Windows, and I think updcast
is the way to do it.
These Dell machines all the have Broadcom 4400 ethernet adapter (kernel module
b44) on board, which isn't available as an option (yet?) in Cast-o-matic, so I
assume I have to compile my own kernel, then add the bootloader, then.... and
so on.
I have a Linux fileserver with TFTP available, so it would be super if I could
do it via PXE. However, I have less than no experience with TFTP, PXE and
initrd, and while there are helpful bits of stuff around the archive, I'm
wondering if there's anything in the way of a more cohesive guide for putting
together such a setup.
I've seen udpcast in action at Acadia University, where Donald Teed (of some
udpcast-list [in]famy) has got it set up in a very slick way, and I have to
agree that it's super-cool.
Thanks in advance for any help.
Brandon
==========================================
Brandon W. Uhlman, Systems Administrator
South Shore Regional Library
Bridgewater, Nova Scotia
"It's the same great business sense that made
Disney say, 'Hey, you know who'd like a theme
park? The French!'" - Lewis Black
I am doing a little research for an R&D project, and I wanted to see if
I could use UDP cast to meet my needs. I just discovered it 15 minutes
ago, scoured the site for docs, and read everything i could. So please
bear with me :).
I will have to remotely control 15-30 PC's. All will be identical, and
each will have a wireless router attached to a lan card (on the
computer). Each PC will play video, and may take some basic I/O
fuctions in the near future.
The pc's will be located inside of a gondola, like at a ski resort.
There will be one computer at the bottom of the gondola line (in the
little lift shack) that will be controlling the whole system. This
computer will be hooked up to the internet, and can be accessed remotely
in order to update the entire system.
It is my impression, that the wifi network may not be able to be
completely in touch with each other at all times. Most gondola lines
are about 4000-8000 feet in length, but can get as high as 14000 feet
long in extreme cases. I understand that I may be limited to a few
"hops" over the wifi routers.
Questions:
1) Can UDP facilitate the updating of just certain files (all identical)
to all pc's on the network. Say, replace video1.mpg with video1.mpg (a
new file)
2) If some pc's are out of range of bottom wifi router, what will happen
when the update is attempted?
--
Jeff Gladnick
Try number 2... Smaller image this time..
Hiya..
I've built a custom ISO image to boot our HP DL360 servers to image
them. I've done this, because none of the images I've seen so far have
support for the HP/Compaq SmartArray 5i. I belive I've done everything
correctly, but I get a boot failure off the CD... Everything SEEMS to go
fine, and then I get an error relating to INITRD and the RAMDisk. I'm
using a custom 2.6.8 kernel with RAMDisk and ROMFS support compiled in.
wh-lnxdb1:~/cdimage # ls -l
total 5104
drwxr-xr-x 2 root root 4096 Aug 27 12:13 .
drwx------ 13 root root 4096 Aug 27 12:12 ..
-rw-r--r-- 1 root root 3484482 Aug 27 12:13 INITRD
-rw-r--r-- 1 root root 15324 Aug 27 11:40 ISOLINUX.BIN
-rw-r--r-- 1 root root 80 Aug 27 11:01 ISOLINUX.CFG
-rw-r--r-- 1 root root 1696890 Aug 27 11:40 LINUX
-r--r--r-- 1 root root 2048 Aug 27 11:01 boot.catalog
wh-lnxdb1:~/cdimage # cat ISOLINUX.CFG
default linux
label linux
kernel LINUX
append root=/dev/ram0 initrd=INITRD
wh-lnxdb1:~/cdimage # mkisofs -o /root/udpcast.iso -b ISOLINUX.BIN -c
boot.catalog -no-emul-boot -boot-load-size 4 -boot-info-table /root/cdimage
Size of boot image is 4 sectors -> No emulation
Total translation table size: 2048
Total rockridge attributes bytes: 0
Total directory bytes: 0
Path table size(bytes): 10
Max brk space used 4000
2592 extents written (5 Mb)
wh-lnxdb1:~/cdimage #
Please see attached image for the error I'm getting..
Does anyone have any thoughts on this?..
Thanks,
Richard.
--
Richard Whittaker, CISSP
System Manager,
NorthwesTel Inc.
Hi everybody,
i resolved my problem with udpcast and commercial version of ssh, and
i'm posting here the solution to save some time to anybody with the same
problem.
I found that ssh2 (3.2.9.1) needs a couple of options to work the way i
intended in the previous post:
for i in `seq 0 9`; do ssh -t -f machine$i "udp-receiver -f /dev/hda1";
done
where -t "allocate a tty even if a command is given" and -f forks the
process into background.
OK now i can clone that 73 machines classroom... ;-)
Thanks to everybody and expecially to Alain for writing udpcast (ghost?
what is it? ;-)
Ciao,
Matteo
Hi everybody.
I have to clone a large number of machines, so i installed udpcast on
the linux partition of my dual boot machines.
I'd like, from the server, to do something like this:
for i in `seq 0 9`; do ssh machine$i "udp-receiver -f /dev/hda1"; done
to start on every machine the udp-receiver and clone the windows
partition.
udp-receiver starts (i see it listening on port 9000), but when i start
cloning it exits...
I tried also putting the process in background, using nohup and using
the option --nokbd, but nothing changes.
Anybody tried somthing like this before or have any idea of what's going
wrong?
-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/
