IP Scheme

Using static IPv4 addresses (instead of DHCP served IP addresses) for the Silex USB servers, laptops, and ethernet cameras used with SCINI makes device power up faster and reduces our dependency on a DHCP serving router for debugging. It also seems to allow the Silex devices to connect with windows clients a lot faster.

The devices with assigned names should be entered into the laptops' hosts files, and the Silex device addresses can be entered manually in the virtual link software as broadcast devices [*].

[*]	Also, if having trouble connecting to a Silex device, make sure it's MAC address isn't listed as one of the "Favorites" in the virtual link software, these seems to mess up communications.

Here are the assigned addresses; the numbering scheme for future devices should be self evident:

IP Address	Hostname	Device
192.168.0.1		Usually the router/default gateway...
192.168.0.9	cam	Elphel 353 Camera
192.168.0.10	cam2	Elphel 353 Camera (SCINI #1)
192.168.0.100	manus	Bryan's IBM Thinkpad T30
192.168.0.101	milk	IBM Thinkpad T40; used as controls computer running windows XP
192.168.0.102	cream	IBM Thinkpad T41; used as video display and archiving computer
192.168.0.103	curd	Bob's Sony Vaio; used as navigation station running windows XP
192.168.0.201		Silex
192.168.0.202		Silex
192.168.0.203		Silex
192.168.0.204		Silex
192.168.0.205		Silex

Multicast Streaming

The elphel camera spits out multicast packets to the group address 232.0.0.1 by default. On Windows XP, the VLC video client correctly registers (via IGMP) for this group ip address, gets the packets, and displays the stream. Linux, however, doesn't always register correctly (perhaps a problem with our configuration?) and we have to give it some help with the smcroute utility (which should be installed as per software-overview); the mrouted utility does pretty much the same thing on different distributions and unix platforms. To join the group use:

$ sudo smcroute -j eth0 232.0.0.1

To leave:

$ sudo smcroute -l eth0 232.0.0.1

The cam2_play script will automatically attempt to leave and then rejoin the group; this is so that if the camera is reset or there is any kind of networking glitch and cam2_play is run again, the registration is cleared.

Note that if the video display has to be reset, so will the recording, and that the recording should be started after cam2_play is rerun so that the group is subscribed correctly.

To check which multicast addresses the kernel is trying to listen to, poke through the devices in /proc/net/; try listing ip_mr_cache and see if there are any entries.