Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!panix!not-for-mail From: Grant Edwards Newsgroups: comp.lang.python Subject: Re: Problem receiving UDP broadcast packets. Date: Wed, 20 Apr 2011 15:50:17 +0000 (UTC) Organization: PANIX Public Access Internet and UNIX, NYC Lines: 36 Message-ID: References: <4dae172e$0$65870$e4fe514c@news.xs4all.nl> <4dae1d82$0$81483$e4fe514c@news.xs4all.nl> NNTP-Posting-Host: dsl.comtrol.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: reader1.panix.com 1303314617 7664 64.122.56.22 (20 Apr 2011 15:50:17 GMT) X-Complaints-To: abuse@panix.com NNTP-Posting-Date: Wed, 20 Apr 2011 15:50:17 +0000 (UTC) User-Agent: slrn/pre0.9.9-102 (Linux) Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:3726 On 2011-04-20, Grant Edwards wrote: > On 2011-04-20, Heiko Wundram wrote: >> Am 20.04.2011 01:54, schrieb Grant Edwards: >>> I guess the problem is that I expected to receive a packet on an >>> interface anytime a packet was received with a destination IP address >>> that matched that of the the interface. Apprently there's some >>> filtering in the network stack based on the _source_ address as well >>> (that seems very counter-intuitive to me). >> >> Just to pitch in here (because nobody's mentioned it yet AFAICT): yes, >> there's a filtering done (at least under Linux, and I'd guess something >> similar on xBSD too) to packets based on the source address coming in on >> an interface, and it's called the reverse path filter and is on by >> default (the tunable on Linux is /proc/sys/net/ipv4/conf/*/rp_filter). > > Brilliant! While I had determined that such filtering took place, I'd > been unable to figure out if it was configurable. Bingo! Turning off reverse-path filtering solved my original problem (not receiving broadcasts sent to 255.255.255.255 because the source IP wasn't reachable via the receiving interface). It doesn't help with the "new" requirement of receiving subnet broadcasts that don't match the interface on which they're received, since it's destination IP filtering that's dropping those. Apparently that requirement is due to the fact that on some OSes (some flavors of BSD and Windows) applications can't broadcast to 255.255.255.255, they can only do subnet broadcasts. -- Grant Edwards grant.b.edwards Yow! I wish I was a at sex-starved manicurist gmail.com found dead in the Bronx!!