Hi Dale... sorry to hear you're still in this mess.
For some reason I thought the broadcast packets were being sent as
10.255.255.255 (according to the netmask) which would be the network's
proper broadcast address. With 255.255.255.255 as a destination address,
I can't see how they could travel both ways. Speaking of which, what is
the philosophycal difference between 255.255.255.255 and, say,
192.168.2.255 or 10.255.255.255?
Maybe you could research the bridging support in new versions of the
kernel. I don't know if it's solid enough, though, and I've never tried
it myself.
Or... what about a little cheating? Since you're hacking the kernel
routing code anyway, why not masquerade incoming 255.255.255.255
WAN-bound packets from the LAN as 10.255.255.255, and do the reverse to
LAN-bound packets from the WAN?
Dale Botkin wrote:
>
> Thanks to those of you who responded earlier. None of the suggestions
> worked, but they all seemed reasonable and did sort of lead to where I am
> now, which is better than before. 8-)
>
> OK, here's a quick recap:
>
> I have two Linux boxen to connect two groups of PCs across an intervening
> LAN/WAN. IP tunnelling works fine between the two nets - EXCEPT for the
> one thing I need, which is for UDP packets sent to 255.255.255.255 to
> appear on both sides of the tunnel. Here's a somewhat simplified diagram
> of the setup:
>
> LAN1 10.42.2.131 10.75.78.221 LAN2
> ==============| eth0 eth0 |==============
> 10.42.250.0/24|----GW1---------//-----------GW2----|10.75.250.0/24
> ==============|eth1 eth1|==============
> 10.42.250.1 10.75.250.1
>
> Hosts on LAN1 and LAN2 can communicate. I need broadcasts sent to
> 255.255.255.255 from LAN1 to show up on LAN2 and vice versa. Originally
> packets sent to 255.255.255.255 went NOWHERE past the gateways, no matter
> what I did. I had to hack net/ipv4/route.c in the kernel source to remove
> the lines that prevent any broadcast packets from being forwarded (look at
> line 1519 or so). Now the kernel will forward broadcasts.
>
> I entered host routes for 255.255.255.255 on both sides, so the routing
> tables look like so:
>
> on GW1:
> Destination Gateway Genmask Flags Metric Iface
> 255.255.255.255 10.75.78.221 255.255.255.255 UH 0 tunl0
> 10.42.2.0 0.0.0.0 255.255.255.0 U 0 eth0
> 10.42.250.0 0.0.0.0 255.255.255.0 U 0 eth1
> 10.75.250.0 10.75.78.221 255.255.255.0 UG 0 tunl0
> 127.0.0.0 0.0.0.0 255.0.0.0 U 0 lo
> 0.0.0.0 10.42.2.31 0.0.0.0 UG 0 eth0
>
> (GW2 looks the same but reversed, and of course the default route is
> different).
>
> If I ping 255.255.255.255 from anywhere, I get an answer from the opposite
> gateway - i.e., if I ping from LAN1 I get an answer from the eth0 address
> on GW2, ping from LAN2 gets an answer from GW1. If I add the host route
> with no gw and dev tunl0, pings to 255.255.255.255 result in an error
> message in syslog "kernel: tunl0: Packet with no target gateway!". Any
> other way I've tried results in no ping reply at all, and none of the
> things I've tried gets me where I need to be - seeing packets sent to
> 255.255.255.255 from LAN1 appear on LAN2 and vice versa.
>
> Bright ideas, anyone? Is there something I missed?
--
___THE___ One man alone cannot fight the future. USE LINUX!
\ \ / / _______________________________________________
\ V / |Juan Carlos Castro y Castro |
\ / |[EMAIL PROTECTED] |
/ \ |Linuxeiro, alvinegro, X-Phile e Carioca Folgado|
/ ^ \ |Diretor de Informática e Eventos Sobrenaturais |
/ / \ \ |da E-RACE CORPORATION |
~~~ ~~~ -----------------------------------------------
RACER
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
