Re: Linux Broadcast packet routing

On 23.2.10 5:24 , Arimus wrote:
> Hi,
>
> Currently encountering a problem with handling broadcast (subnet
> broadcast rather than global broadcast):
>
> Setup:
> 3 terminals each connected to a linux based router. Each linux based
> router is connected to a radio net.
>
> The radio net exists on its own subnet address (172.17.32.0/24), and
> the terminals are on their own subnets (e.g 10.16.1.1 for the first
> router's terminal interface, 10.16.1.2 for the terminal, x.x.2.1 for
> the second router and so on).
>
> We've got some messaging software which can work out that, for
> instance, when sending from Terminal 1 to both terminals 2 and 3
> they're on a common radio subnet and so can send to 172.17.32.255
> instead of having to send two individual messages.
>
> The translation from 172.17.32.255 to terminal addresses on the
> receiving side is fine - however traffic from terminal 1 is not being
> routed out when sent as broadcast from router 1.
>
> Terminal 1> eth 10.16.x.x/16> router> slip 172.16.32.x/24> radio
>
> Terminal 2> eth 10.16.y.y/16> router> slip 172.16.32.x/24> radio
>
> Terminal 3> eth 10.16.y.y/16> router> slip 172.16.32.x/24> radio
>
> Its possible to broadcast ping 172.16.32.255 from any router to get to
> the other routers (or with the nat rule in place the terminals). The
> problem occurs when Terminal 1 tries sending to 172.16.32.255.
>
> On router 1 we see the packet come in on eth0 and then gets to the
> INPUT queue rather than being forwarded out to sl0 (172.16.32.1/24
> which has bcast address of 172.16.32.255).
>
> Reading various articles this in a way is expected behaviour as it
> appears linux does not route broadcast traffic between different
> subnets. Unfortunately for our purposes we need this ability.


Your problem is that the routers are not allowed to forward/NAT
the broadcasts of the radio subnet (172.16.32.255).

You need to set the routers bridging instead of routing so that
the final peer hosts are in the intended subnet 172.16.32.0/24.
Of course, you have to change the addresses of the peer hosts
to match.

--

Tauno Voipio
tauno voipio (at) iki fi

Arimus wrote:
> On 24 Feb, 07:42, Tauno Voipio <tauno.voi...@notused.fi.invalid>
> wrote:
>> Your problem is that the routers are not allowed to forward/NAT
>> the broadcasts of the radio subnet (172.16.32.255).
>>
>> You need to set the routers bridging instead of routing so that
>> the final peer hosts are in the intended subnet 172.16.32.0/24.
>> Of course, you have to change the addresses of the peer hosts
>> to match.
>>
>
> Thanks, not going to be easy to change the host ip addresses as the
> software they run is configured for a single ip address - and as the
> radios can operate on different nets each with their own 172.1x.y.z
> address the host addresses would have to be remapped every time the
> preset is changed breaking the software (I know the software is ****
> but we're stuck with it).
>
> R.


Is the software configured for addresses in the 10.x.y.z network?

Is there a sensible subnet for all the hosts running the software?

There may be a way out tunneling the network dictated by the
software and connecting the tunnel on the available carrier net.

--

Tauno Voipio

However, routers are permitted to forward IP multicast traffic, so if
the software you are stuck with can use IP multicast rather than
IPsubnet-local broadcast you might have a way forward there.

rick jones
--
a wide gulf separates "what if" from "if only"
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...