Date: Fri, 19 Jun 1998 15:41:16 -0600 (MDT) From: Doug Russell <drussell@saturn-tech.com> To: questions@FreeBSD.ORG Subject: Routing/Bridging question.... Message-ID: <Pine.BSF.3.95.980619151100.18715A-100000@hobbes.saturn-tech.com>
next in thread | raw e-mail | index | archive | help
I'm looking for ideas on how to resolve the following situation: I have an 8mbps RADSL connection to my ISP using the Paradyne 5446 RTU endpoint at my end. This RTU does not have *ANY* idea about routing at all. The only configuration possible for this setup causes my entire class c to just appear at the RTU's ethernet port. (In other words, all incoming packets for my 207.229.19.0/24 network come on to the ethernet with the nhop destination being the actual destination machine.) From what we can tell, unbelieveably enough, there is no way to set even an nhop destination for ALL packets to a single address. This would all be great if my whole network actually WAS on this physical network, but the physical part of the network where the RTU is located is on a 16-ip subnet 207.229.19.176/28. Most of the rest of the network is located at my house, connected via ppp from a 2.2.6-STABLE machine (.178). Even if I use a second ethernet card in .178 on a different subnet (lets say 207.229.19...192 with a netmask of 255.255.255.252) setting the card to be .193, and the RTU to be .194, I still can't move any packets. I can SEND packets out from anywhere just fine (the routing tables are correct, etc.), but they don't get back in. Consider a ping from 207.229.19.180 to an outside address. (Say, my ISP's mail server.) The results go something like this: request goes from 180 -> 178 request is received by 178 (on the ed0) request is routed (correctly) and sent out on ed1 (193) to the RTU (194). ...hop...hop...hop... request is received by the destination, and a reply is sent back ...hop...hop...hop... reply appears in my RTU, which then goes to look up the MAC for .180. Not being on this network, 180 never responds, and never gets the packet. Watching a tcpdump -i ed1 verifies this, as you see messages right after you ping like: arp - who has 207.229.19.180 tell 10.10.10.19 (The RTU is known on my ISP's internal network as 10.10.10.19) If the RTU could send all traffic to an nhop destination of .193, everything would work just fine, but it doesn't have that capability. So... The question is... How do I magically make all these incoming packets "seen" by .193 as they come in? I can't realistically do a proxy arp entry for every address. Besides... I tried doing a proxy arp entry for .180 to test it, and although .180 can then be pinged from outside the network, as soon as you add the proxy arp entry, WinNT (on .180) pops up it's little IP address conflict error message, and refuses to transmit any packets until you remove the proxy arp entry. As a sidenote... Is there a way to specify a proxy arp entry on ONLY ONE INTERFACE? Can I somehow tell tcc (178/193) to only respond to the arp requests for 180's MAC on the 193 interface? This is basically crude bridging, but it would work. (It still isn't realistic, as I'd have to maintain a couple hundred proxy arp entries. Even with the auto option this would be a pain.) WinNT (amazingly enough) supports this idea in it's arp tables. You can specify what interface the proxy arp should be responded to on. My ISP says they have this same setup working on one other location using NT as the router box, running the updated routing and RAS manager / protocol suite. He sent over a copy of it, but we still couldn't get everything configured. I don't want to do it on NT anyway, and I can't imagine that there is actually something on NT that you can't do on FreeBSD. :) How else might I do this? Would it be relatively simple to hack the network drivers to run in promiscuous mode on ed1 and grab ALL incoming packets as it's own? (There is no other traffic on that 2-ip subnet, remember) I don't know enough about the underlying network structure and drivers to know without some serious source digging. I looked at drawbridge, but it seems to be tremendous overkill for what I'm needing. Taking a quick look at the drawbridge source leads me to believe that the necessary bridging components could be ripped out of it to create a smaller FreeBSD bridging-only package without all the extra firewalling code & associated setup. Has anyone tried something like this yet? (This seems like my mest bet, but it would require some fairly hefty coding & testing for what I'd like to be a quick local hack.) Did Luigi ever look any more at doing bridging? I'd love to be able to just add a linked option on my ifconfig lines or something. :) Is there a way to fudge this more easily using the ARP table? Feel free to traceroute, etc. though the network. It's live, and it may give you a better idea of what is going on. (Right now the rest of the network is connected via a dialup directly to my ISP.) etc. Any comments & suggestions would be helpful. I am stumped. Please cc all replies to me (drussell@saturn-tech.com) as I am only on -current, -stable, etc. Later...... <Doug> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.980619151100.18715A-100000>