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
[email protected]
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
[email protected]
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
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
