Hi, long story told shortly: I am running a MythTV backend (with UPnP server) inside a XEN DomU. Everything works fine, except for the UPnP part. Before I migrated the server to the virtual machine, also that was working well (broadcasting to a PS3 on the local net, and also to other UPnP software clients). Now, the clients don''t see the server any more. My XEN/Shorewall setup is based on this guide: running Shorewall in a routed Dom0. Main difference is that I did not (yet) make a separate zone for the WLAN. Current environment: eth0: External interface (net) (to the Internet router), 192.168.200.1 eth1: Internal interface (loc), 192.168.100.1 eth4: UPnP server ($TEST_IF), 192.168.200.1 The internal address of the UPnP server is 192.168.100.3. Client used for testing: 192.168.100.222 (loc) After a lot of trial/error, and also a lot of googling, I''m stuck... I''m pretty sure I just overlooked one tiny detail, but can''t see it. Can anyone give me a hint, please? Sorry if this was handled earlier on the list, but my search didn''t turn it up. You''ll find a shorewall dump in the attachment. Cheers, Jens -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference
Tom Eastep
2009-Oct-13 01:06 UTC
Re: UPnP server inside a XEN DomU not talking to local net
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jens Rehaag wrote:> Hi, > > long story told shortly: I am running a MythTV backend (with UPnP > server) inside a XEN DomU. Everything works fine, except for the UPnP > part. Before I migrated the server to the virtual machine, also that was > working well (broadcasting to a PS3 on the local net, and also to other > UPnP software clients). Now, the clients don''t see the server any more. > > My XEN/Shorewall setup is based on this guide: running Shorewall in a > routed Dom0 <http://www.shorewall.net/XenMyWay-Routed.html>. Main > difference is that I did not (yet) make a separate zone for the WLAN. > > Current environment: > eth0: External interface (net) (to the Internet router), 192.168.200.1 > eth1: Internal interface (loc), 192.168.100.1 > eth4: UPnP server ($TEST_IF), 192.168.200.1 > The internal address of the UPnP server is 192.168.100.3. > Client used for testing: 192.168.100.222 (loc) > > After a lot of trial/error, and also a lot of googling, I''m stuck... I''m > pretty sure I just overlooked one tiny detail, but can''t see it. Can > anyone give me a hint, please? > > Sorry if this was handled earlier on the list, but my search didn''t turn > it up. > > You''ll find a shorewall dump in the attachment.Sorry -- I don''t understand your configuration at all. You say:> eth4: UPnP server ($TEST_IF), 192.168.200.1That isn''t the server -- that is an interface on the firewall. - From the dump:> Chain PREROUTING (policy ACCEPT 176 packets, 40630 bytes) > pkts bytes target prot opt in out sourcedestination> 0 0 UPnP all -- eth0 * 0.0.0.0/00.0.0.0/0> 0 0 UPnP all -- eth3 * 0.0.0.0/00.0.0.0/0> 26 6595 UPnP all -- eth1 * 0.0.0.0/00.0.0.0/0> 44 14522 UPnP all -- eth4 * 0.0.0.0/00.0.0.0/0> 0 0 UPnP all -- vnet0 * 0.0.0.0/00.0.0.0/0> 0 0 UPnP all -- vif10.0 * 0.0.0.0/00.0.0.0/0 Looks like you kept adding ''upnp'' to your interfaces until you ran out of interfaces??? This is also curious:> Chain eth0_masq (1 references) > pkts bytes target prot opt in out sourcedestination> 1 76 SNAT all -- * * 192.168.100.0/240.0.0.0/0 /* Masquerade Local Network */ to:192.168.200.1> 0 0 SNAT all -- * * 169.254.0.0/160.0.0.0/0 /* Masquerade Local Network */ to:192.168.200.1> 0 0 SNAT all -- * * 239.0.0.0/80.0.0.0/0 /* Masquerade Local Network */ to:192.168.200.1> 0 0 SNAT all -- * * 224.0.0.0/40.0.0.0/0 /* Masquerade Local Network */ to:192.168.200.1 What is all of this masquerading for? Clearly the multicast addresses in the ''source'' column are ridiculous which makes me think that you have an interface name in the SOURCE column of /etc/shorewall/masq. It looks to me like you have taken a server that depends on broadcast and have moved it to the other side of a router from its clients; that''s usually a losing strategy. Do you have any web references about how this whole thing is supposed to work? My experience with UPnP is in the classic case where linux-idg is running on a gateway which this doesn''t appear to be. - -Tom - -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrT0ocACgkQO/MAbZfjDLLS2gCeKyWDMpI/1TVSIjDI09pUgtmM q8wAoKN3CNYM2VQulQX0DUyhBqAWgqoa =LG3j -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference
Jens Rehaag
2009-Oct-13 14:06 UTC
Re: UPnP server inside a XEN DomU not talking to local net
Am 13.10.2009 um 03:06 schrieb Tom Eastep:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jens Rehaag wrote: >> Hi, >> >> long story told shortly: I am running a MythTV backend (with UPnP >> server) inside a XEN DomU. Everything works fine, except for the UPnP >> part. Before I migrated the server to the virtual machine, also >> that was >> working well (broadcasting to a PS3 on the local net, and also to >> other >> UPnP software clients). Now, the clients don''t see the server any >> more. >> >> My XEN/Shorewall setup is based on this guide: running Shorewall in a >> routed Dom0 <http://www.shorewall.net/XenMyWay-Routed.html>. Main >> difference is that I did not (yet) make a separate zone for the WLAN. >> >> Current environment: >> eth0: External interface (net) (to the Internet router), >> 192.168.200.1 >> eth1: Internal interface (loc), 192.168.100.1 >> eth4: UPnP server ($TEST_IF), 192.168.200.1 >> The internal address of the UPnP server is 192.168.100.3. >> Client used for testing: 192.168.100.222 (loc) >> >> After a lot of trial/error, and also a lot of googling, I''m >> stuck... I''m >> pretty sure I just overlooked one tiny detail, but can''t see it. Can >> anyone give me a hint, please? >> >> Sorry if this was handled earlier on the list, but my search didn''t >> turn >> it up. >> >> You''ll find a shorewall dump in the attachment. > > Sorry -- I don''t understand your configuration at all. > > You say: > >> eth4: UPnP server ($TEST_IF), 192.168.200.1 > > That isn''t the server -- that is an interface on the firewall.True - it''s the interface XEN created for the virtual machine that is running the MythTV / UPnP server, using Proxy ARP: #ADDRESS INTERFACE EXTERNAL HAVEROUTE PERSISTENT 192.168.200.10 $DMZ_IF $EXT_IF yes 192.168.100.3 $TEST_IF $INT_IF yes> > - From the dump: > >> Chain PREROUTING (policy ACCEPT 176 packets, 40630 bytes) >> pkts bytes target prot opt in out source > destination >> 0 0 UPnP all -- eth0 * 0.0.0.0/0 > 0.0.0.0/0 >> 0 0 UPnP all -- eth3 * 0.0.0.0/0 > 0.0.0.0/0 >> 26 6595 UPnP all -- eth1 * 0.0.0.0/0 > 0.0.0.0/0 >> 44 14522 UPnP all -- eth4 * 0.0.0.0/0 > 0.0.0.0/0 >> 0 0 UPnP all -- vnet0 * 0.0.0.0/0 > 0.0.0.0/0 >> 0 0 UPnP all -- vif10.0 * 0.0.0.0/0 > 0.0.0.0/0 > > Looks like you kept adding ''upnp'' to your interfaces until you ran out > of interfaces???Yes, only had it on eth1 originally, but added it to others as well as part of that trial/error process... now on eth4 only.> > This is also curious: > >> Chain eth0_masq (1 references) >> pkts bytes target prot opt in out source > destination >> 1 76 SNAT all -- * * 192.168.100.0/24 > 0.0.0.0/0 /* Masquerade Local Network */ to:192.168.200.1 >> 0 0 SNAT all -- * * 169.254.0.0/16 > 0.0.0.0/0 /* Masquerade Local Network */ to:192.168.200.1 >> 0 0 SNAT all -- * * 239.0.0.0/8 > 0.0.0.0/0 /* Masquerade Local Network */ to:192.168.200.1 >> 0 0 SNAT all -- * * 224.0.0.0/4 > 0.0.0.0/0 /* Masquerade Local Network */ to:192.168.200.1 > > What is all of this masquerading for? Clearly the multicast > addresses in > the ''source'' column are ridiculous which makes me think that you > have an > interface name in the SOURCE column of /etc/shorewall/masq.Yes, actually, I based it on your above mentioned document, which has "$EXT_IF $INT_IF 206.124.146.179". I replaced the IP address with 192.168.200.1. Those multicast addresses are also mostly leftovers from testing, I had added them manually to the routing table.> > It looks to me like you have taken a server that depends on broadcast > and have moved it to the other side of a router from its clients; > that''s > usually a losing strategy. Do you have any web references about how > this > whole thing is supposed to work? My experience with UPnP is in the > classic case where linux-idg is running on a gateway which this > doesn''t > appear to be.Not really: What I did was to move a service (MythTV with UPnP) that was running directly on the firewall earlier into a virtual machine, also on the firewall. That virtual machine is supposed to be part of the local zone, that''s why I thought linux-idg would not be needed (as I understood it was used to allow UPnP traffic between the net zone and the loc zone). All clients are in the loc zone. The reference I used when I set up the MythTV server directly on the firewall earlier can be found here: http://www.mythtv.org/wiki/UPnP The broadcast route mentioned under "Troubleshooting" was indeed needed when I ran the server on the firewall. Now, I have it on the virtual machine. All other broadcast addresses cleaned, server rebooted. I will take a closer look at linux-idg, and also at broadcasting in general. I have attached a new dump, should be cleaner. Cheers, Jens> > - -Tom > - -- > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \________________________________________________ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkrT0ocACgkQO/MAbZfjDLLS2gCeKyWDMpI/1TVSIjDI09pUgtmM > q8wAoKN3CNYM2VQulQX0DUyhBqAWgqoa > =LG3j > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart > your > developing skills, take BlackBerry mobile applications to market and > stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference
Jens Rehaag
2009-Oct-13 20:47 UTC
Re: UPnP server inside a XEN DomU not talking to local net
Hi, answering to my own message because I''ve found new facts: First of all, the UPnP packets didn''t leave the MythTV DomU earlier; their checksums were corrupted as mentioned in http://www.shorewall.net/XenMyWay-Routed.html . Using the setting described there, the checksums are now correct. Sorry for that; I should have checked that earlier. But my problem still remains: The UPnP packages (sent to 239.255.255.250) never reach eth1. I can see them inside the DomU, and also on eth4, but never on eth1. Same thing the other way: When I send broadcasts from a UPnP client connected to eth1 to search for UPnP servers, I can see those packages on eth1, but not on eth4. Both interfaces belong to the loc zone. So it seems that the problem comes down to finding a way to forward broadcast packages between eth1 and eth4. As suggested in http://www.shorewall.net/samba.htm, I am using action.Drop and action.Reject to make sure the packets don''t get dropped silently (did it for UPnP and broadcast packets), and I can''t find any traces in the log. Will linux-idg do the forwarding? Or is there some Shorewall rule I can use? Cheers, Jens Am 13.10.2009 um 16:06 schrieb Jens Rehaag:> > Am 13.10.2009 um 03:06 schrieb Tom Eastep: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Jens Rehaag wrote: >>> Hi, >>> >>> long story told shortly: I am running a MythTV backend (with UPnP >>> server) inside a XEN DomU. Everything works fine, except for the >>> UPnP >>> part. Before I migrated the server to the virtual machine, also >>> that was >>> working well (broadcasting to a PS3 on the local net, and also to >>> other >>> UPnP software clients). Now, the clients don''t see the server any >>> more. >>> >>> My XEN/Shorewall setup is based on this guide: running Shorewall >>> in a >>> routed Dom0 <http://www.shorewall.net/XenMyWay-Routed.html>. Main >>> difference is that I did not (yet) make a separate zone for the >>> WLAN. >>> >>> Current environment: >>> eth0: External interface (net) (to the Internet router), >>> 192.168.200.1 >>> eth1: Internal interface (loc), 192.168.100.1 >>> eth4: UPnP server ($TEST_IF), 192.168.200.1 >>> The internal address of the UPnP server is 192.168.100.3. >>> Client used for testing: 192.168.100.222 (loc) >>> >>> After a lot of trial/error, and also a lot of googling, I''m >>> stuck... I''m >>> pretty sure I just overlooked one tiny detail, but can''t see it. Can >>> anyone give me a hint, please? >>> >>> Sorry if this was handled earlier on the list, but my search >>> didn''t turn >>> it up. >>> >>> You''ll find a shorewall dump in the attachment. >> >> Sorry -- I don''t understand your configuration at all. >> >> You say: >> >>> eth4: UPnP server ($TEST_IF), 192.168.200.1 >> >> That isn''t the server -- that is an interface on the firewall. > > True - it''s the interface XEN created for the virtual machine that > is running the MythTV / UPnP server, using Proxy ARP: > > #ADDRESS INTERFACE EXTERNAL HAVEROUTE PERSISTENT > 192.168.200.10 $DMZ_IF $EXT_IF yes > 192.168.100.3 $TEST_IF $INT_IF yes > >> >> - From the dump: >> >>> Chain PREROUTING (policy ACCEPT 176 packets, 40630 bytes) >>> pkts bytes target prot opt in out source >> destination >>> 0 0 UPnP all -- eth0 * 0.0.0.0/0 >> 0.0.0.0/0 >>> 0 0 UPnP all -- eth3 * 0.0.0.0/0 >> 0.0.0.0/0 >>> 26 6595 UPnP all -- eth1 * 0.0.0.0/0 >> 0.0.0.0/0 >>> 44 14522 UPnP all -- eth4 * 0.0.0.0/0 >> 0.0.0.0/0 >>> 0 0 UPnP all -- vnet0 * 0.0.0.0/0 >> 0.0.0.0/0 >>> 0 0 UPnP all -- vif10.0 * 0.0.0.0/0 >> 0.0.0.0/0 >> >> Looks like you kept adding ''upnp'' to your interfaces until you ran >> out >> of interfaces??? > > Yes, only had it on eth1 originally, but added it to others as well > as part of that trial/error process... now on eth4 only. > >> >> This is also curious: >> >>> Chain eth0_masq (1 references) >>> pkts bytes target prot opt in out source >> destination >>> 1 76 SNAT all -- * * 192.168.100.0/24 >> 0.0.0.0/0 /* Masquerade Local Network */ to:192.168.200.1 >>> 0 0 SNAT all -- * * 169.254.0.0/16 >> 0.0.0.0/0 /* Masquerade Local Network */ to:192.168.200.1 >>> 0 0 SNAT all -- * * 239.0.0.0/8 >> 0.0.0.0/0 /* Masquerade Local Network */ to:192.168.200.1 >>> 0 0 SNAT all -- * * 224.0.0.0/4 >> 0.0.0.0/0 /* Masquerade Local Network */ to:192.168.200.1 >> >> What is all of this masquerading for? Clearly the multicast >> addresses in >> the ''source'' column are ridiculous which makes me think that you >> have an >> interface name in the SOURCE column of /etc/shorewall/masq. > > Yes, actually, I based it on your above mentioned document, which has > "$EXT_IF $INT_IF 206.124.146.179". > I replaced the IP address with 192.168.200.1. > > Those multicast addresses are also mostly leftovers from testing, I > had added them manually to the routing table. > >> >> It looks to me like you have taken a server that depends on broadcast >> and have moved it to the other side of a router from its clients; >> that''s >> usually a losing strategy. Do you have any web references about how >> this >> whole thing is supposed to work? My experience with UPnP is in the >> classic case where linux-idg is running on a gateway which this >> doesn''t >> appear to be. > > Not really: What I did was to move a service (MythTV with UPnP) that > was running directly on the firewall earlier into a virtual machine, > also on the firewall. That virtual machine is supposed to be part of > the local zone, that''s why I thought linux-idg would not be needed > (as I understood it was used to allow UPnP traffic between the net > zone and the loc zone). > All clients are in the loc zone. > The reference I used when I set up the MythTV server directly on the > firewall earlier can be found here: > http://www.mythtv.org/wiki/UPnP > The broadcast route mentioned under "Troubleshooting" was indeed > needed when I ran the server on the firewall. Now, I have it on the > virtual machine. All other broadcast addresses cleaned, server > rebooted. > I will take a closer look at linux-idg, and also at broadcasting in > general. > > I have attached a new dump, should be cleaner. > > Cheers, > Jens > > >> >> - -Tom >> - -- >> Tom Eastep \ When I die, I want to go like my Grandfather who >> Shoreline, \ died peacefully in his sleep. Not screaming like >> Washington, USA \ all of the passengers in his car >> http://shorewall.net >> \________________________________________________ >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.9 (GNU/Linux) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >> iEYEARECAAYFAkrT0ocACgkQO/MAbZfjDLLS2gCeKyWDMpI/1TVSIjDI09pUgtmM >> q8wAoKN3CNYM2VQulQX0DUyhBqAWgqoa >> =LG3j >> -----END PGP SIGNATURE----- >> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart >> your >> developing skills, take BlackBerry mobile applications to market >> and stay >> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >> http://p.sf.net/sfu/devconference >> _______________________________________________ >> Shorewall-users mailing list >> Shorewall-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/shorewall-users >> > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > <status_new.txt.gz> > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart > your > developing skills, take BlackBerry mobile applications to market and > stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference_______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference
Tom Eastep
2009-Oct-13 23:39 UTC
Re: UPnP server inside a XEN DomU not talking to local net
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jens Rehaag wrote:> Hi, > > answering to my own message because I''ve found new facts: > > First of all, the UPnP packets didn''t leave the MythTV DomU earlier; > their checksums were corrupted as mentioned > in http://www.shorewall.net/XenMyWay-Routed.html. Using the setting > described there, the checksums are now correct. Sorry for that; I should > have checked that earlier. > > But my problem still remains: The UPnP packages (sent to > 239.255.255.250) never reach eth1. I can see them inside the DomU, and > also on eth4, but never on eth1.Are you running a multicast router daemon on in Dom0 (mrouted, for example)? You need that if you want to route multicast.>Same thing the other way: When I send > broadcasts from a UPnP client connected to eth1 to search for UPnP > servers, I can see those packages on eth1, but not on eth4.And you never will. That is a key difference between a bridge and proxy arp; a bridge will pass broadcasts while a proxy arp router will not.> > Will linux-idg do the forwarding? Or is there some Shorewall rule I can use?Neither will work. - -Tom - -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrVD6sACgkQO/MAbZfjDLLc0gCeLtgCBqEf0+19Tu/5nke0vEEK 2PYAoJwWeay47VQtng9EbhN1i/lYXiDE =HkZf -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference
Jens Rehaag
2009-Oct-14 20:22 UTC
Re: UPnP server inside a XEN DomU not talking to local net
Hi, thanks for pointing me to mrouted. I had to use it in tunnel mode, as it refused to use eth4 (because it''s proxy ARP), but now multicast traffic is flowing between the DomU and clients connected to eth1 on Dom0. Cheers, Jens Am 14.10.2009 um 01:39 schrieb Tom Eastep:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jens Rehaag wrote: >> Hi, >> >> answering to my own message because I''ve found new facts: >> >> First of all, the UPnP packets didn''t leave the MythTV DomU earlier; >> their checksums were corrupted as mentioned >> in http://www.shorewall.net/XenMyWay-Routed.html. Using the setting >> described there, the checksums are now correct. Sorry for that; I >> should >> have checked that earlier. >> >> But my problem still remains: The UPnP packages (sent to >> 239.255.255.250) never reach eth1. I can see them inside the DomU, >> and >> also on eth4, but never on eth1. > > Are you running a multicast router daemon on in Dom0 (mrouted, for > example)? You need that if you want to route multicast. > > >> Same thing the other way: When I send >> broadcasts from a UPnP client connected to eth1 to search for UPnP >> servers, I can see those packages on eth1, but not on eth4. > > And you never will. That is a key difference between a bridge and > proxy > arp; a bridge will pass broadcasts while a proxy arp router will not. >> >> Will linux-idg do the forwarding? Or is there some Shorewall rule I >> can use? > > Neither will work. > > - -Tom > - -- > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \________________________________________________ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkrVD6sACgkQO/MAbZfjDLLc0gCeLtgCBqEf0+19Tu/5nke0vEEK > 2PYAoJwWeay47VQtng9EbhN1i/lYXiDE > =HkZf > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart > your > developing skills, take BlackBerry mobile applications to market and > stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean.-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference