Joe Taylor wrote:

My earlier problem with dropped multicast packets seems to be fixed in MAP65 v0.8. However, when running the Linrad-MAP65 combination on two separate computers I still have some network-related problems. Perhaps someone on this list who knows much more than I about networking can help.

My computer network looks like this:

        ADSL      10 Mb/s  --> Computer_A
DSL --> Modem --> Ethernet --> Computer_B
                  Hub            |
                           --> Computer_C

Three computers are connected to a 10 Mb/s Ethernet Hub.

Have you considered replacing the hub with a 100 Mbps full-duplex Ethernet switch? There are many advantages in this over a hub.

Computer_A is my XYL's machine. Computer_B runs Windows 2000 Pro, and Computer_C runs Linux (presently the Kubuntu 6.06 distribution). In addition to the connections of all three machines to the hub, a crossover cable makes a direct 100 Mb/s connection between computers B and C.

The ethernet interfaces on B and C appear to be configured correctly. On Linux they appear as eth0 and eth1 (occasionally they boot up as eth0 and eth2, I don't know why???).

This is configurable, generally, and should be fixed if you intend to use interface based static routes. Check here for more info on iftab (/etc/iftab):

Connections to the Hub are assigned dynamic IP addresses;

I assume these addresses are in the 192.168.1.x range?

I assigned hard-coded addresses and for the direct inter-machine connection
between B and C.

I can use the 100 Mb/s direct line for many purposes. I can ping over it in either direction; I can ssh into Linux from Windows; I can use Cygwin/X (as described above) to display Linux X programs on the Windows screen.

However, I cannot seem to persuade Windows 2000 Pro to accept multicast packets over the direct line. When I run Linrad on computer C and MAP65 on B, the multicast traffic is always received over the slow line, through the Hub. This uses most of the 10 Mb/s link's bandwidth, and my wife can't read her email when I'm on the air. This is NOT GOOD.

An Ethernet switch would eliminate this, as traffic passing between two machines (B-C) does not use any bandwidth, nor is it seen, by any other machines. Internet access by machine A would be unaffected by a transfer occurring between machines B and C. Machine A would not see the traffic, nor would there be any contention for bandwidth on it's connection because of the B-C traffic.

By default the multicast traffic generated by Computer_C goes to eth0. I can use the Linux "route" command to explicitly tell the system to use eth0:

# route add -net netmask dev eth0

This works fine (but of course, still sends the heavy multicast traffic through the hub). If I remove this routing instruction and instead enter

# route add -net netmask dev eth1

the multicast data are not received by MAP65 running on the other machine.

If I unplug the crossover cable from the Windows machine and instead plug it into a laptop running Win/XP, the laptop receives the multicast packets without a problem.

Thus, it would seem that the problem must be in my setup of the Win2k machine -- the one with two ethernet interfaces. Can anyone shed any light on this situation for me?

Would there be sufficient bandwidth in a 100baseTx connection (100 Mbps full-duplex) to handle both of the networking streams, i.e. the hub and the direct stream? If so, replacing the inefficient hub with a faster switch, thus confining network traffic to only the ports of the involved machines, might solve the issue. This might allow you to eliminate the direct connection between machines B and C.

As to W2k the unicast and multicast routes are handled in separate tables, check here for more info:

Hope some of this is of some use :)

Rick Kunath, k9ao

This message is sent to you because you are subscribed to
 the mailing list <>.
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to  <[EMAIL PROTECTED]>

Reply via email to