[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linrad] Re: Testing MAP65 v0.8



Rick and all,

Well, it seems I'm learning more about computer networking than I ever wanted to know... ;-)

Why did you use a mask of 224.0.0.0 instead of 240.0.0.0 in your multicast route statement on the Linux box?
(Your: # route add -net 224.0.0.0 netmask 224.0.0.0 dev eth1 statement.)

My mistake when typing it into the email message. I had it right when the tests were made.

Unfortunately neither of the switches you tested with had the horsepower (i.e. were managed switches) to control the multicast traffic, though they will segment the unicast traffic.

Yes, this is exactly what I discovered.

You asked some more good questions, and I will follow up on them soon.

In the meantime, I've realized that there is really no reason to use multicasting for the Linrad --> MAP65 connection. I could just as well "unicast" the UDP data stream between the two machines, using a crossover cable and explicit private-LAN (192.168.x.x) addresses on each end, and have none of the problems I've been worrying about. This solution causes the data go where I want it to go, and nowhere else.

The other option that I'm beginning to think very attractive is running both Linrad and MAP65 in a single machine. TIMF2 data could go from Linrad to MAP65 over the loopback (lo) interface -- or by way of shared memory, or ???

	-- Joe, K1JT

#############################################################
This message is sent to you because you are subscribed to
 the mailing list <linrad@xxxxxxxxxxxxxxxxxxxxx>.
To unsubscribe, E-mail to: <linrad-off@xxxxxxxxxxxxxxxxxxxxx>
To switch to the DIGEST mode, E-mail to <linrad-digest@xxxxxxxxxxxxxxxxxxxxx>
To switch to the INDEX mode, E-mail to <linrad-index@xxxxxxxxxxxxxxxxxxxxx>
Send administrative queries to  <linrad-request@xxxxxxxxxxxxxxxxxxxxx>

LINRADDARNIL