Date: Wed, 1 Apr 1998 23:01:41 -0300 (EST) From: Joao Carlos Mendes Luis <jonny@coppe.ufrj.br> To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Cc: jonny@coppe.ufrj.br, cshenton@it.hq.nasa.gov, gurney_j@resnet.uoregon.edu, hasty@rah.star-gate.com, multimedia@FreeBSD.ORG Subject: Re: The FreeBSD lounge... Message-ID: <199804020201.XAA15139@gaia.coppe.ufrj.br> In-Reply-To: <199803310746.JAA22240@labinfo.iet.unipi.it> from Luigi Rizzo at "Mar 31, 98 09:46:22 am"
next in thread | previous in thread | raw e-mail | index | archive | help
#define quoting(Luigi Rizzo) // > I'm right now connected through a modem, and I have a MBone tunnel // > established. And I'm pretty sure I don't have an ethernet card. :) // // ok, now (after some more hacking) I know why it did not work for me. // The ppp server has the ethernet on a /24 net and the ppp address // assigned to my machine is also within the same /24 net. ppp works fine, // (provided i turn arp proxy on for the ppp address), but mrouted ignores // interfaces with potentially conflicting addresses as in my case. I can // make things work by making the tests in mrouted less restrictive but // Bill Fenner claims that there are reasons for that restriction and i // trust his word. I had this problem too, but now I'm using another access server, in another subnet. Have you tried to make an IP alias and use it as the "local" IP in mrouted tunnel ? This would probably fool mrouted. The best way of course would be to have multicast support native in the access server. Does somebody know if any access server supports this ? Would FreeBSD suport multicast over serial lines ? Also, a BIG problem I had was that mrouted was looping all data received from the tunnel back through the serial line. (Maybe this answers my previous question. :) ) That's why mrouted accepted to make the tunnel, as it wants two or more vifs to run. If I try to disable the tun0 vif, it refuses to run. And it does not accpet to bind to the ds0 interface. :) What would be the right way to tell mrouted that I want a tunnel just to have internal access, not routing through ? As a kludge I tried to add a firewall rule, to drop all multicast packets over tun0 interface, but this did not work. The drop rule is not a real drop, but a deny, and the programs received a socket error on trying to send anything. :( But I found an interesting workaround. Instead of droping, I used a divert rule. There was no process listenning to the divert socket, so the packet was dropped, as I wanted initially. :) The very interesting effect is that tcpdump still sees the outgoing packets, my modem SD led could finally turn off. Jonny -- Joao Carlos Mendes Luis jonny@gta.ufrj.br +55 21 290-4698 jonny@coppe.ufrj.br Universidade Federal do Rio de Janeiro UFRJ/COPPE/CISI PGP fingerprint: 29 C0 50 B9 B6 3E 58 F2 83 5F E3 26 BF 0F EA 67 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-multimedia" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804020201.XAA15139>