Leonardo Pappagallo wrote:
> hi Jan
> 
> I have created a net with machines that belong to different IP range, as it
> is showned below:
> 
> 
> #
> # Examplary TDMA configuration file
> #
> 
> # Primary master
> 
> master:
> ip 192.0.0.229
> cycle 4000
> slot 2 500
> slot 0 3500 1/5
> 
> # Slave A
> slave:
> ip 192.0.1.244
> slot 2 1000
> slot 0 3500 2/5
> 
> # Slave B
> slave:
> ip 192.0.1.241
> slot 2 1500
> slot 0 3500 3/5
> 
> # Slave C
> slave:
> ip 192.0.0.205
> slot 2 2000
> slot 0 3500 4/5
> 
> # Slave D
> slave:
> ip 192.0.1.235
> slot 2 2500
> slot 0 3500 5/5
> 
> Into file rtnet.conf I have utilized the same NETMASK="255.255.255.0" for
> all machines.
> 

If both hosts with 192.168.0.x and 192.168.1.x share the same physical
network segment, I don't see the reason for setting this particular netmask.

> when I send an IP/UDP packet type whit address "192.0.1.255" or "192.0.0.255",
> this packet is received from all machines.
> 
> Is possible to do this with RTnet?

Aah, I think I'm starting to understand: you want to send broadcast
packets separately to both groups, don't you? Yes this will not work as
usual as RTnet does not explicitly match the target IP address of
incoming packets with the receivers address and mask - this has been
removed during the routing system revision. All packets a node receives
physically are also being delivered. Typically, we do not need such an
extra check and we can save the required operations here.

Two options:
1. Filter at application level, which means that you will have to live
   with an additional unneeded task wakeup here.
2. Reintroduce the filter at protocol level (as an optional feature
   e.g. - patches will be welcome). But note that this will still let
   the node receive the packet physically! You only save a fraction of
   the overhead when the NIC does not do the filtering.

A real solution would be multicasting. But, unfortunately, we are still
lacking this feature and there are currently no resources in sight to
fill this gap.

Jan

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to