Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Linux Broadcast packet routing

1,193 views
Skip to first unread message

Arimus

unread,
Feb 23, 2010, 10:24:49 AM2/23/10
to
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.

So does anyone have any ideas?

TIA,

Richard.

Arimus

unread,
Feb 23, 2010, 1:08:48 PM2/23/10
to
On Feb 23, 3:24 pm, Arimus <arimus...@googlemail.com> wrote:

> 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

That last line should of course be 10.16.z.z :)

Tauno Voipio

unread,
Feb 24, 2010, 2:42:30 AM2/24/10
to


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

unread,
Feb 24, 2010, 3:33:22 AM2/24/10
to
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.

Tauno Voipio

unread,
Feb 24, 2010, 10:10:46 AM2/24/10
to


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

Rick Jones

unread,
Feb 24, 2010, 3:04:45 PM2/24/10
to
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...

David Schwartz

unread,
Feb 26, 2010, 5:29:35 AM2/26/10
to
On Feb 23, 11:42 pm, 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.

Another solution is a helper application on the Linux router boxes. It
listens for broadcasts on the LAN and, if appropriate, relays them to
the radio net's broadcast address. You can look at the source code for
any DHCP relay application for examples.

By the way, packets to a subnet's broadcast address are called
"directed broadcast" packets. If you search something like 'linux
forward "directed broadcast"' you will find a wealth of information.

DS

0 new messages