Some help with broadcasts through a Linux system
Dan Kaminsky
>
>It seems that Linux feels that it should not have to forward the broadcast
>datagrams.
>
>Does anyone have any clues?
Richard--
In the same boat you are--been here for the past few months. Here's the
scoop:
Linux cannot forward broadcasts--this violates the rules of subnets or
some garbage like that. There's nothing, for instance, like the UDPHELPer
of some of 3Com routers.
The "Samba" solution is for all client machines to contact the WINS
server and then for inter-subnet browsing to occur.
Not the greatest solution when you don't have *access* to the other
machines, which are stuck on using NetBIOS Broadcasts.
There's already something in place for a WINS Proxy, which according to
the conf:
# WINS Proxy - Tells Samba to answer name resolution queries on
# behalf of a non WINS capable client, for this to work there must be
# at least one WINS Server on the network. The default is NO.
What we don't have, as far as I can tell, is a way to answer name
resolution queries for a WINS client who can't hear the broadcasts that the
Samba server can.
The WINS server actually *does* give you a list of workgroups, mind you.
But the Windows client tries to access the workgroups via the broadcast
method, and since (obviously) the Windows client isn't on the same broadcast
address as the workgroups that the WINS server is claiming exist, an error
pops up.
I've been working on a solution. No, it's not as easy as just setting
the server :-)
Dan Kaminsky
general. It's probably a setting over in the kernel.
Boy I wish I wasn't so dependant upon Caldera for Novell for Linux. I could
actually recompile my kernel.
----- Original Message -----
From: Richard Sharpe <sha...@ns.aus.com>
To: Dan Kaminsky <eff...@best.com>
Cc: <samba-t...@samba.org>
Sent: Wednesday, February 03, 1999 5:06 AM
Subject: Re: Some help with broadcasts through a Linux system
>Hi again,
>
>OK, what I did not make clear was that I was trying to use directed
>broadcasts, not the local broadcasts address (255.255.255.255).
>
>That is, in the context of the following diagram:
>
>
> 172.30.0.0/24 16.153.112.0/24
> --------------------[Linux]---------------------
>
>If from 172.30.0.120 I ping 16.153.112.255, I would expect to see the
>broadcast on the other interface.
>
>Linux seems to be stoping it, and I cannot find a switch to prevent it from
>stopping it.
>
>This is screwing up my attempts to test out 'remote announce' in Samba.
>
>
>
>Regards
>-------
>Richard Sharpe, sha...@ns.aus.com, NIC-Handle:RJS96
>NS Computer Software and Services P/L,
>Ph: +61-8-8281-0063, FAX: +61-8-8250-2080,
>Samba (Team member), Linux, Apache, Digital UNIX, AIX, C, ...
>
Dan Kaminsky
>Correct. You don't forward broadcasts. Imagine what ping 255.255.255.255
would
>do if you did
>
>Alan
A little more information, since I've been pulling the Dan "Broken Record"
Kaminsky routine in my last couple of emails.
The following comes from RFC922:
BROADCASTING INTERNET DATAGRAMS IN THE PRESENCE OF SUBNETS
====
..
- Broadcast to all hosts on a remote hardware network: It is
occasionally useful to send a broadcast to all hosts on a
non-local network; for example, to find the latest version of a
hostname database, to bootload a host on a subnet without a
bootserver, or to monitor the timeservers on the subnet. This
case is the same as local-network broadcasts; the datagram is
routed by normal mechanisms until it reaches a gateway attached
to the destination hardware network, at which point it is
broadcast. This class of broadcasting is also known as
"directed broadcasting", or quaintly as sending a "letter bomb"
[1].
..
For reasons of performance or security, a gateway may choose not to
forward broadcasts; especially, it may be a good idea to ban
broadcasts into or out of an autonomous group of networks.
========
My point is, while one *usually* doesn't want to forward and/or bridge
broadcasts, the authors of the broadcasts standards foresaw that it could be
at least useful. For issues of what Richard is trying to do with Directed
Broadcasts, there's really no other way to do it.
Hurm. I think I need more sleep, but then don't we all? :-)
Yours Truly,
Dan Kaminsky
DoxPara Research
Nicolas Williams
But 16.153.112.255 (assuming there's a 16.153.112/24 network) is a
*directed* broadcast.
Commercial routers usually make directed broadcast forwarding an
option.
The forwarding of UDP broadcasts to the all-1s address (255.255.255.255)
is almost never desirable, except for some specific UDP services with
well-known ports allocated to them. To enable the forwarding of all-1s
broadcasts to such services it is usually best to use a UDP helper; UDP
helpers can be implemented in userland and, in fact, are best left to
user-level processes.
The forwarding of directed broadcasts, when turned on for ALL services
(possibly including ICMP echo requests and the like) then the
implementation of it is best left to the kernel; otherwise it's best
left to a user-land UDP helper.
Having said all of that, it is rarely desirable for a multi-homed host
to do any IP forwarding whatsoever, except when such a host is meant to
be used as a router.
My 2 cents.
Nico
On Wed, Feb 03, 1999 at 11:48:54PM +1100, Alan Cox wrote:
> > However, when I ping 16.153.112.255 from 172.30.0.120, 172.30.0.1 responds,
> > and I see nothing on the 16.153.112.0/24 subnet.
>
> Correct
>
> > It seems that Linux feels that it should not have to forward the broadcast
> > datagrams.
>
Luke Kenneth Casson Leighton
> Richard Sharpe wrote:
> >
> > Hi,
> >
> > I am having problems getting broadcasts through a Linux system.
> >
> > Here is the config:
> >
> > 172.30.0.0/24 16.153.112.0/24
> > ----------------[Linux Box]------------------
> >
> > I have it set up with ip_forward=1.
> >
> > However, when I ping 16.153.112.255 from 172.30.0.120, 172.30.0.1 responds,
> > and I see nothing on the 16.153.112.0/24 subnet.
> >
> > The linux box is running a 2.0.36 kernel.
> >
> > It seems that Linux feels that it should not have to forward the broadcast
> > datagrams.
>
> Which is the correct behaviour.
> If you want to forward your netbios datagram broadcasts you have to do
> more than just forwarding because the data contains ip-addresses too.
>
> I've solved this problem by writing a patch for Samba which 'glues'
> the subnets of my linux firewall together. You can find the code
> at http://malt-whisky.student.utwente.nl/nbfw/ . The code is not
i would discourage anyone from doing this. use a WINS server instad.
Luke Kenneth Casson Leighton
> resolution queries for a WINS client who can't hear the broadcasts that the
> Samba server can.
if your network neighbourhood is set up correctly (with all clients that
you have control over having the same wins server OR one and only one
client per broadcast-isolated subnet - windows or samba - having wins
proxy switched on) then there is no need to hear broadcasts that the samba
server can hear.
> The WINS server actually *does* give you a list of workgroups, mind you.
it does no such thing.
ok.
it's been two years since i answered browser-related questions. i gave up
because i was answering the same questions all the time. i did so because
i was developing nmbd and wanted to make sure that if people didn't have
browsing working it wasn't anything to do with nmbd itself.
can i recommend to people that they refer to the samba archives dating
back two to three years, there are several examples of the kinds of setups
being described here. the solution and the understanding required are
still the same.
luke
Luke Kenneth Casson Leighton
richard,
"remote announce" should be used to announce samba servers as being in
completely different workgroups from the one they are in, or for
announcements to utterly remote subnets which contain clients that do not
use the same wins server as the samba server doing the remote announce.
under the latter circumstances the remote clients are expected to have a
"lmhosts" file or a static entry in their own (remote) wins server
database which allows them to resolve the remotely announced server.
remote announce should DEFINITELY not be used on:
- the local subnet
- to servers using the same WINS server
luke
Dan Kaminsky
Uhm, sorry, we don't always have power to control everybody else on the
network. Sometimes it's a power thing, or a legacy thing, or whatnot, but
sometimes we can't force everybody else to use us for WINS services.
Furthermore, using WINS is saying that your server will never go down. A
number of shops can't use WINS because for most of its history it was only
available on NT, and believe you me, NT goes down. Even Samba WINS doesn't
yet have fault tolerance.
There are environments where netbios broadcasts, though somewhat noisy,
simply *work*. Diff'rent Strokes, Diff'rent Folks. This isn't like, say,
putting up a root user TFTP server :-)
Gerald Carter
>
> Even Samba WINS doesn't yet have fault tolerance.
True, but since I initially brought up WINS replication, I
had to add this.
I run a 19.18p4 as a WINS server and it **never** goes
down. I have no problem with the current state of things.
It does make my boss a little nervous though. :)
jerry
________________________________________________________________________
Gerald ( Jerry ) Carter
Engineering Network Services Auburn University
je...@eng.auburn.edu http://www.eng.auburn.edu/users/cartegw
"...a hundred billion castaways looking for a home."
- Sting "Message in a Bottle" ( 1979 )
Jeremy Allison
>
> Hi again,
>
> OK, what I did not make clear was that I was trying to use directed
> broadcasts, not the local broadcasts address (255.255.255.255).
>
> That is, in the context of the following diagram:
>
> 172.30.0.0/24 16.153.112.0/24
> --------------------[Linux]---------------------
>
> If from 172.30.0.120 I ping 16.153.112.255, I would expect to see the
> broadcast on the other interface.
>
> Linux seems to be stoping it, and I cannot find a switch to prevent it from
> stopping it.
I think that's an anti-SMURF security measure
(little blue horrors, I *hate* em, and don't get
me started on Father Abraham.... :-).
It's done to stop directed broadcasts of ICMP
packets - the dreaded SMURF attack.
Jeremy.
--
--------------------------------------------------------
Buying an operating system without source is like buying
a self-assembly Space Shuttle with no instructions.
--------------------------------------------------------
Luke Kenneth Casson Leighton
>
> But 16.153.112.255 (assuming there's a 16.153.112/24 network) is a
> *directed* broadcast.
>
> Commercial routers usually make directed broadcast forwarding an
> option.
this is a non-issue. a WINS server, not "remote announce" should be used.
Luke Kenneth Casson Leighton
> >i would discourage anyone from doing this. use a WINS server instad.
>
> Uhm, sorry, we don't always have power to control everybody else on the
> network. Sometimes it's a power thing, or a legacy thing, or whatnot, but
> sometimes we can't force everybody else to use us for WINS services.
then you fall into the category where "remote announce" is appropriate
for you. remember that everyone on the remote subnet will *still* have to
resolve the netbios name of the samba server somehow, and that *still*
means either a static entry in ther remote WINS server or DNS or an entry
in each and every remote client's lmhosts file.
> Furthermore, using WINS is saying that your server will never go down. A
> number of shops can't use WINS because for most of its history it was only
> available on NT, and believe you me, NT goes down. Even Samba WINS doesn't
> yet have fault tolerance.
>
> There are environments where netbios broadcasts, though somewhat noisy,
> simply *work*. Diff'rent Strokes, Diff'rent Folks. This isn't like, say,
> putting up a root user TFTP server :-)
that's why "mixed" and "hybrid" exists, which is a combination of
broadcast and point-to-point NetBIOS resolution.
Tony Hoyle
>
> >If you want to forward your netbios datagram broadcasts you have to do
> >more than just forwarding because the data contains ip-addresses too.
> >
> >I've solved this problem by writing a patch for Samba which 'glues'
> >the subnets of my linux firewall together. You can find the code
> >at http://malt-whisky.student.utwente.nl/nbfw/ . The code is not
> >exercise for the reader ;)
>
> Ooh! Ooh! If I was a dog, i'd be wagging my tail and thumping it against
> the ground. Oh joyous day!
Don't jump too much it only patches against 2.2.0beta4...
:-(
Tony
------------------------------------------------------------------------------------
If Bill Gates had a dime for every time a Windows box crashed...
... Oh, wait a minute, he already does.
------------------------------------------------------------------------------------
t...@magenta-logic.com http://falklands.magenta-logic.com
------------------------------------------------------------------------------------
Dan Kaminsky
----- Original Message -----
From: Luke Kenneth Casson Leighton <lk...@switchboard.net>
To: Dan Kaminsky <eff...@best.com>
Cc: Multiple recipients of list <samba-t...@samba.org>
Sent: Wednesday, February 03, 1999 11:06 AM
Subject: Re: Some help with broadcasts through a Linux system
>On Wed, 3 Feb 1999, Dan Kaminsky wrote:
>
>> >i would discourage anyone from doing this. use a WINS server instad.
>>
>> Uhm, sorry, we don't always have power to control everybody else on the
>> network. Sometimes it's a power thing, or a legacy thing, or whatnot,
but
>> sometimes we can't force everybody else to use us for WINS services.
>
>then you fall into the category where "remote announce" is appropriate
>for you. remember that everyone on the remote subnet will *still* have to
>resolve the netbios name of the samba server somehow, and that *still*
>means either a static entry in ther remote WINS server or DNS or an entry
>in each and every remote client's lmhosts file.
Luke:
That's how it works now. That's not how it should work. The "heh I'm
here" broadcast should be routed just like the packet that sent this email
is.
At least that's how it should work.
>> Furthermore, using WINS is saying that your server will never go down. A
>> number of shops can't use WINS because for most of its history it was
only
>> available on NT, and believe you me, NT goes down. Even Samba WINS
doesn't
>> yet have fault tolerance.
>>
>> There are environments where netbios broadcasts, though somewhat noisy,
>> simply *work*. Diff'rent Strokes, Diff'rent Folks. This isn't like,
say,
>> putting up a root user TFTP server :-)
>
>that's why "mixed" and "hybrid" exists, which is a combination of
>broadcast and point-to-point NetBIOS resolution.
Yup. So don't give us broadcasters so much flack :-)
Alan Cox
^^^^^^
bridge or route.. different stuff
As far as I know you can't ask Linux 2.2 to forward directed broadcasts
but you'd need to confirm that with ANK. Its been a while since I was involved
in IP internals
Gerald Carter
>
> That's how it works now. That's not how it should work.
> The "heh I'm here" broadcast should be routed just
> like the packet that sent this email is.
Are you saying that "wins proxy" should forward
registration requests and not just resolution
requests?
I seem got have gotten lost in this thread somehow.
Dan Kaminsky
[WARNING: DAN LOVES SEMANTICS. BEWARE.]
Actually isn't there a bit of ambiguity there? When one bridges two network
segments together, all packets on segment A exist on segment B. When one
creates a route from segment A to segment B, only those packets from one
segment destined for the other will travel the route. Broadcasts throw this
rule out the window, since all packets of a certain type are destined for
the other network yet the same packet is utilized on both network.
One might argue that by this logic, one doesn't route multicast packets, one
bridges them, except for the fact that multicasted packets will only go to
those connected networks that are known a priori to require the packet.
Bridged broadcasts just fly around.
The key terminological determinant here, I think, is can we envision a
difference between *routing* a broadcast packet vs. *bridging* the broadcast
packet. Routing would imply a priori knowledge, i.e. the router, seeing a
broadcast packet requesting computer FOO, would send the broadcast to the
last known subnet of computer FOO. Bridging implies a lack of intelligence,
as some people will say using broadcasts implies anyways.
Thank you. We now return you to your regularly scheduled SMB packets.
Alan Cox
> segments together, all packets on segment A exist on segment B. When one
No. There are filter rules and an anti loop layer. See IEE802.1. Better yet
spend the money on beer and believe me. A repeater does the above
> last known subnet of computer FOO. Bridging implies a lack of intelligence,
> as some people will say using broadcasts implies anyways.
I think your terminology is a little inaccurate, the point rather ruined by
that but once you get into layer 3 switches the actual thrust of the comments
is quite valid.
Anyway the only question is "Can you set Linux 2.2 to forward letter bombs".
The answer is I dont know
Dan Kaminsky
>I think that's an anti-SMURF security measure
>(little blue horrors, I *hate* em, and don't get
>me started on Father Abraham.... :-).
>
>It's done to stop directed broadcasts of ICMP
>packets - the dreaded SMURF attack.
>
>Jeremy.
Banning all directed broadcasts because of abuse is the Windows method of
network security...it's hard to hack something if it's impossible to do in
the first place.
This isn't exactly a bad idea, when you think about it. Can you imagine the
carnage on IRC, land of "How do I get my machine working, my root password
is newbie"? Phear.
This is annoying. The only way I can see to keep the net smurf free would
be to only allow directed broadcasts from trusted IP's that are in the ARP
cache(therefore unspoofable?).
Hurm. Bridged/Routed Broadcasts are much less of a sticky problem than
this.
Dan Kaminsky
>> Ooh! Ooh! If I was a dog, i'd be wagging my tail and thumping it
against
>> the ground. Oh joyous day!
>
>Don't jump too much it only patches against 2.2.0beta4...
>
>:-(
>
>Tony
I'd bring it up to date myself if I could get it to compile(both source
trees are sitting unpacked in my downloaded source directory right now :-).
There can't be *THAT* many differences relevant to this patch between Beta 4
and Final. Besides, I'm *trying* to learn this accursedly massive code base
:-)
Unfortunately, as I said before, it doesn't want to compile. To wit:
Compiling smbd-fw.c to smbd-fw.o
smbd/smbd-fw.c: In function `find_ip_in_forward_list':
smbd/smbd-fw.c:60: dereferencing pointer to incomplete type
smbd/smbd-fw.c:64: dereferencing pointer to incomplete type
smbd/smbd-fw.c:64: dereferencing pointer to incomplete type
smbd/smbd-fw.c:66: dereferencing pointer to incomplete type
smbd/smbd-fw.c:70: dereferencing pointer to incomplete type
smbd/smbd-fw.c:70: dereferencing pointer to incomplete type
smbd/smbd-fw.c:70: dereferencing pointer to incomplete type
smbd/smbd-fw.c:70: dereferencing pointer to incomplete type
smbd/smbd-fw.c:71: dereferencing pointer to incomplete type
Any ideas? The author says that some other problem is caused by my version
of GCC(2.7.2.3) but alas I know of no non-dangerous way to change compiler
versions.
Richard Sharpe
with respect to directed broadcasts (subnet directed broadcasts), I have
now determined that Linux does not allow them.
The code is in linux/net/ipv4/ip_input.c. All broadcasts are dropped when
it comes time to check forwarding.
I have a hacked up version that allows directed broadcasts that I will be
testing soon so I can check out remote announce stuff ...
Tony Hoyle
> I'd bring it up to date myself if I could get it to compile(both source
> trees are sitting unpacked in my downloaded source directory right now :-).
> There can't be *THAT* many differences relevant to this patch between Beta 4
> and Final. Besides, I'm *trying* to learn this accursedly massive code base
> :-)
>
> Unfortunately, as I said before, it doesn't want to compile. To wit:
>
> Compiling smbd-fw.c to smbd-fw.o
> smbd/smbd-fw.c: In function `find_ip_in_forward_list':
> smbd/smbd-fw.c:60: dereferencing pointer to incomplete type
> smbd/smbd-fw.c:64: dereferencing pointer to incomplete type
> smbd/smbd-fw.c:64: dereferencing pointer to incomplete type
> smbd/smbd-fw.c:66: dereferencing pointer to incomplete type
> smbd/smbd-fw.c:70: dereferencing pointer to incomplete type
> smbd/smbd-fw.c:70: dereferencing pointer to incomplete type
> smbd/smbd-fw.c:70: dereferencing pointer to incomplete type
> smbd/smbd-fw.c:70: dereferencing pointer to incomplete type
> smbd/smbd-fw.c:71: dereferencing pointer to incomplete type
>
> Any ideas? The author says that some other problem is caused by my version
> of GCC(2.7.2.3) but alas I know of no non-dangerous way to change compiler
> versions.
I use the same version. IMHO if a program won't compile under GCC
2.7.2.3 it is
buggy anyway - most people have this version.
Mine gave up because I didn't have a special patch in the kernel, and I
stopped
there - there *must* be a simpler solution that doesn't involve patching
everything
in sight.
I'm going to need this functionality at some point so it is something
that I'm actively
thinking about...
Dan Kaminsky
----- Original Message -----
From: Alan Cox <al...@lxorguk.ukuu.org.uk>
To: Multiple recipients of list <samba-t...@samba.org>
Sent: Wednesday, February 03, 1999 2:09 PM
Subject: Re: Some help with broadcasts through a Linux system
>> Actually isn't there a bit of ambiguity there? When one bridges two
network
>> segments together, all packets on segment A exist on segment B. When one
>
>No. There are filter rules and an anti loop layer. See IEE802.1. Better yet
>spend the money on beer and believe me. A repeater does the above
Hurm, I think it's time to admit you probably know more about the subject
than I do :-) Besides, spend the money on beer? Works for me :-)
>> last known subnet of computer FOO. Bridging implies a lack of
intelligence,
>> as some people will say using broadcasts implies anyways.
>
>I think your terminology is a little inaccurate, the point rather ruined by
>that but once you get into layer 3 switches the actual thrust of the
comments
>is quite valid.
Layer 3 switches. Hurm, can I study Layer 3 switches while drinking said
beer?
>Anyway the only question is "Can you set Linux 2.2 to forward letter
bombs".
>The answer is I dont know
Can't, but a code hack has been written by Richard last I checked.
Damn. Smurfing really makes this rather useful technique almost unusable...
Alan Cox
That would be cool to see
> Damn. Smurfing really makes this rather useful technique almost unusable...
Not neccessarily. Suggested current practice - and eventually common 8) is
that now traffic shaping is becoming deployed on big routers, PC's whatever
that ICMP is limited to a small percentage (4 from memory) of traffic when
there is other stuff that needs sending.
Alan
Dan Kaminsky
----- Original Message -----
From: Alan Cox <al...@lxorguk.ukuu.org.uk>
To: Dan Kaminsky <eff...@best.com>
Cc: <al...@lxorguk.ukuu.org.uk>; <samba-t...@samba.org>
Sent: Thursday, February 04, 1999 5:57 PM
Subject: Re: Some help with broadcasts through a Linux system
>> Can't, but a code hack has been written by Richard last I checked.
>
>That would be cool to see
Heh, do you know of any open source apps that do *anything* with broadcast
packets? I'd like to try my hand at patching the source to redir to move
255.255.255.255 packets around--might be a good lesson, I think.
>> Damn. Smurfing really makes this rather useful technique almost
unusable...
>
>Not neccessarily. Suggested current practice - and eventually common 8) is
>that now traffic shaping is becoming deployed on big routers, PC's whatever
>that ICMP is limited to a small percentage (4 from memory) of traffic when
>there is other stuff that needs sending.
This would mitigate problems but not eliminate them. Pretty much every
windows machine will respond to the contents of an nbtstat--fake repeated
requests from a victim IP, and poof...no ICMP involved either.
Of course, nbtstat gives a little less data than, say, 50K ping :-)
>Alan
Alan Cox
routed
> packets? I'd like to try my hand at patching the source to redir to move
rwhod, rup. None useful 8)
> This would mitigate problems but not eliminate them. Pretty much every
> windows machine will respond to the contents of an nbtstat--fake repeated
> requests from a victim IP, and poof...no ICMP involved either.
Ouch. I hadnt realised you could start nbstat wars.
> Of course, nbtstat gives a little less data than, say, 50K ping :-)
True, now can you start domain master fights between remote sites with spoofing ?
Dan Kaminsky
>> Of course, nbtstat gives a little less data than, say, 50K ping :-)
>
>True, now can you start domain master fights between remote sites with
spoofing ?
I seem to remember that you can "tickle" a zone to have it have a browser
election...
Dan Kaminsky
Cc: Multiple recipients of list <samba-t...@samba.org>
Sent: Sunday, February 07, 1999 3:24 PM
Subject: Re: Some help with broadcasts through a Linux system
>dan, something else occurred to me: is there anything to stop you from
>configuring all your clients to use the remote subnet's WINS server? they
>can't exactly stop you from doing that, after all! if they _do_ complain
>then you can make a case for having a campus-wide WINS service and this
>being one good example.
Nope, can't demand that. Maybe next year? We'll see.