Upnp not working on bridged interface ?
df last edited by
Hello, i've been making tests with the only upnp device i have laying around, a ps3.
I'm running 1.2.1-embedded on an alix 2D3 (three VR0 NIC's) with a CM9 (ath 5112).
My OPT1 (refered here as WLAN) was first bridged to LAN, and i tried to add UPNP service.
For this i first added LAN to UPNP's listen interface, than added both LAN and WLAN, but the PS3 wasn't happy.
No signs of any UPNP pickups in logs.
I than un-bridged WLAN and gave it a static ip outside of LAN's net, and enabled DHCP, and kept UPNP enabled on both LAN and WLAN, and started the PS3 network connectivity test again, and this time it worked.
After playing around a couple hours with this setup i came to the conclusion that when you have a bridge UPNP isn't picking up packets coming from the bridge at all ?
Could there be a way to fix this and make UPNP work on WLAN when it's bridged to LAN ?
Best regards to everyone !
databeestje last edited by
you might need to add a firewall rule on both the lan and the bridge interface to allow from lan subnet to 184.108.40.206/32 for upnp on the xbox 360 to work.
df last edited by
my test upnp-enabled units are one PS3, one PSP, ne XBOX360..
If i connect the xbox or ps3 via ethernet on vr0 (LAN), upnp works as expected, the xbox and ps3 reports successfull config.
I have added the rule you mentioned, both on WAN and WLAN.
If i try to add upnp on WLAN i see a message in logs saying upnp was started on LAN but no WLAN, since WLAN has no ip address (remember it's bridged to LAN ..)
If i unbridge WLAN, and set it to a static IP, upnp works fine.
Conclusion, upnp listens to LAN but not bridge0 (?)'
So basicaly, my rules are now :
On Lan: allow all proto from any source,port to any source,port
On Wlan (OPT1): allow all proto from any source,port to any source, port
And as you advised:
On Lan: allow all proto from any source, port to 220.127.116.11/32,anyport
On Wlan: allow all proto from any source,port to 18.104.22.168/32,anyport …
Note, i upddated my setup to 1.2.1-rel and 1.2.2-rel, but this issue is still not fixed.