Forwarding broadcast traffic

Forwarding broadcast traffic

[Jon Masters]

Hello,
	I have a brain-dead application here which relies on broadcast
traffic for client/server discovery and I have a question with regard
to forwarding broadcast traffic.

A small part of my local LAN looks like this:

                 REST OF LAN
                      |
                      | (router eth1)
                      |
                 masquerading
                router (kernel 2.2.14)
                      |
                      | (router eth0)
                      |
                   desktop (private IP)
                    boxen  (kernel 2.4.2)

* upgrading the router is not a problem[0].

I wish to have the router forward certain broadcast traffic coming
from either side out to the other (as well as itself).

e.g. on desktop a broadcast udp packet (with a specified port) needs to
go not only to itself and the router but also the "REST OF LAN" part
too - and vice versa. Removing the router is not an option.

I know this isn't a *nice* idea and ordinarily I wouldn't be jumping up
and down suggesting one throws broadcast traffic around however I need
to do this for various reasons and the solution appears to be
non-obvious at least to me[1].

I have considered the idea of creating a transparent bridge however I
would really rather not do that here for various reasons.

I have posted this message to groups elsewhere however I have not yet
had any useful responses beyond basic instruction of IP forwarding,
etc. which is not what I need here :P

Any ideas? I think this one has come up before but I could not find a
helpful answer in my archives.

Appreciate your time,
			--jcm

P.S. My lkml feed at home is great but here it is not so could you
     please CC me on replies thanks.

[0] Yeah, yeah, I know 2.2.14 is old but it's an old router and when I
    move that box over to Debian I'll upgrade the kernel at the same
    time :P
[1] either due to general stupidity or tiredness, or both.

Re: Forwarding broadcast traffic

[Jeremy Jackson]

Jon Masters wrote:

> Hello,
>         I have a brain-dead application here which relies on broadcast
> traffic for client/server discovery and I have a question with regard
> to forwarding broadcast traffic.

try bridging instead if ip forwarding.  use netfilter too if you want

>
>
> A small part of my local LAN looks like this:
>
>                  REST OF LAN
>                       |
>                       | (router eth1)
>                       |
>                  masquerading
>                 router (kernel 2.2.14)
>                       |
>                       | (router eth0)
>                       |
>                    desktop (private IP)
>                     boxen  (kernel 2.4.2)
>
> * upgrading the router is not a problem[0].
>
> I wish to have the router forward certain broadcast traffic coming
> from either side out to the other (as well as itself).
>
> e.g. on desktop a broadcast udp packet (with a specified port) needs to
> go not only to itself and the router but also the "REST OF LAN" part
> too - and vice versa. Removing the router is not an option.
>
> I know this isn't a *nice* idea and ordinarily I wouldn't be jumping up
> and down suggesting one throws broadcast traffic around however I need
> to do this for various reasons and the solution appears to be
> non-obvious at least to me[1].
>
> I have considered the idea of creating a transparent bridge however I
> would really rather not do that here for various reasons.
>
> I have posted this message to groups elsewhere however I have not yet
> had any useful responses beyond basic instruction of IP forwarding,
> etc. which is not what I need here :P
>
> Any ideas? I think this one has come up before but I could not find a
> helpful answer in my archives.
>
> Appreciate your time,
>                         --jcm
>
> P.S. My lkml feed at home is great but here it is not so could you
>      please CC me on replies thanks.
>
> [0] Yeah, yeah, I know 2.2.14 is old but it's an old router and when I
>     move that box over to Debian I'll upgrade the kernel at the same
>     time :P
> [1] either due to general stupidity or tiredness, or both.
> -

Re: Forwarding broadcast traffic

[Jon Masters]

Jeremy Jackson wrote:

> try bridging instead if ip forwarding.  use netfilter too if you want

I mentioned bridging before - I don't want some kind of transparent
bridge, really so what I would need is for the router to be contactable
in the same way as before and for regular traffic to pass normally but
with a special arrangement for certain broadcast traffic.

Is it possible to selectively bridge broadcast traffic in the way I have
described?

Normally of course I'd have the router either being a standard router or
a bridge but in this case some kind of hybrid arrangement would be
preferable.

Thanks for your help,
			--jcm

Re: Forwarding broadcast traffic

[Jeremy Jackson]

Jon Masters wrote:

> Jeremy Jackson wrote:
>
> > try bridging instead if ip forwarding.  use netfilter too if you want
>
> I mentioned bridging before - I don't want some kind of transparent
> bridge, really so what I would need is for the router to be contactable
> in the same way as before and for regular traffic to pass normally but
> with a special arrangement for certain broadcast traffic.
>
> Is it possible to selectively bridge broadcast traffic in the way I have
> described?
>
> Normally of course I'd have the router either being a standard router or
> a bridge but in this case some kind of hybrid arrangement would be
> preferable.
>
> Thanks for your help,
>                         --jcm

Well it you give the server an ip alias address that's on the subnet
of the clients, bridge the two segments together,
but use netfilter to drop all packets that aren't your
broadcasts, it might do the trick.  I'm not to familiar with
bridging, but i'm confident that 2.4's netfilter can do it...
you can filter/route based on pretty much *any* data
in the packet, by manually specifying an arbitrary offset
in the headers and bit pattern if necessary IIRC.

if you know which port IP port it's easy.

Can you be more specific... is this an IP broadcast?
or ethernet only like IPX or NetBEUI?
perhaps subnetting with "invalid" netmasks could
cause broadcast to reach entire supernet even
though subnets are on diff segments (in case of IP)

Re: Forwarding broadcast traffic

[Joel Jaeggli]

> Is it possible to selectively bridge broadcast traffic in the way I have
> described?

Take a look at how your router handles broadcast dhcp requests cisco at
least have a dhcp helper functionality which is essentially just what
you're asking for (selective forwarding of broadcast traffic.

if you really want to do this in a standard fashion though it sounds like
an application for multicast...

joelja

> Normally of course I'd have the router either being a standard router or
> a bridge but in this case some kind of hybrid arrangement would be
> preferable.
>
> Thanks for your help,
> 			--jcm
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

-- 
--------------------------------------------------------------------------
Joel Jaeggli				       joelja@darkwing.uoregon.edu
Academic User Services			     consult@gladstone.uoregon.edu
     PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E
--------------------------------------------------------------------------
It is clear that the arm of criticism cannot replace the criticism of
arms.  Karl Marx -- Introduction to the critique of Hegel's Philosophy of
the right, 1843.

Re: Forwarding broadcast traffic

[Eric Lammerts]

On Sat, 3 Mar 2001, Jon Masters wrote:
> e.g. on desktop a broadcast udp packet (with a specified port) needs to
> go not only to itself and the router but also the "REST OF LAN" part
> too - and vice versa. Removing the router is not an option.

Write an application that creates 2 sockets listening on the same port
but different interfaces (using the SO_BINDTODEVICE socket option, see
the dhcp source for an example). Then forward any packet you receive
on one socket to the other side. If you need to keep the source ip
intact, you may have to use a raw socket for the sending part.

You could adapt a DHCP relay program to do this stuff instead of
writing it from scratch.

Eric

-- 
Eric Lammerts <eric@lammerts.org> | "An NT server can be run by
http://www.lammerts.org           |  an idiot, and usually is."