UPnP && bridged interfaces



  • Dear All

    I am not sure if I am the only one bitten by this one, but the forum entries about UPnP seem to be only concerned about XBox/PS3-Problems. Thus my question.

    I have an embedded setup with four physical interfaces. WAN (copper) is connected to a cablemodem. OPT1 (copper) and OPT2 (wireless) are briged to LAN (copper). LAN is connected to a HomePNA device which connects my office to the firewall. OPT1 is connected to a Sonos (www.sonos.com) music system. Wireless is for a bunch of client-devices.

    Sonos is using a special UPnP dialect to control its devices from a wireless controller (which is connected over their own special wireless system) or from a PC with their desktop software. And there comes the problem. Altough the pfSense-Box is configured to bridge the interfaces LAN/OPT1/OPT2 it seems that L2-broadcasts (like UPnP) are not bridged thru to the other interfaces. This make me unable to control my Sonos from my desktop/mobile PCs.

    Is there a way to have pfSense bridge thru L2-Broadcasts (like UPnP)?

    Thank you for any help.

    Regards
    Roman



  • Can you get the 'multicast' address of your sonos and post it here?



  • @ermal:

    Can you get the 'multicast' address of your sonos and post it here?

    Is seems they are using 239.255.255.250.190 for finding each other and commands are afterwards sent directly to the ip-address of the devices.

    Here an example of an initial communication:

    04:24:39.837553 00:21:e9:61:9c:34 > 01:00:5e:7f:ff:fa, ethertype IPv4 (0x0800), length 166: 192.168.2.248.49156 > 239.255.255.250.19
    00: UDP, length 124
            0x0000:  4500 0098 6fa9 0000 0411 9311 c0a8 02f8  E…o...........
            0x0010:  efff fffa c004 076c 0084 1757 4d2d 5345  .......l...WM-SE
            0x0020:  4152 4348 202a 2048 5454 502f 312e 310d  ARCH.*.HTTP/1.1.
            0x0030:  0a48 4f53 543a 2032 3339 2e32 3535 2e32  .HOST:.239.255.2
            0x0040:  3535 2e32 3530 3a31 3930 300d 0a4d 414e  55.250:1900..MAN
            0x0050:  3a20 2273 7364 703a 6469 7363 6f76 6572  :."ssdp:discover
            0x0060:  220d 0a4d 583a 2031 0d0a 5354 3a20 7572  "..MX:.1..ST:.ur
            0x0070:  6e3a 7363 6865 6d61 732d 7570 6e70 2d6f  n:schemas-upnp-o
            0x0080:  7267 3a64 6576 6963 653a 5a6f 6e65 506c  rg:device:ZonePl
            0x0090:  6179 6572 3a31 0d0a                      ayer:1..

    04:24:40.037050 00:0e:58:12:d1:96 > 00:21:e9:61:9c:34, ethertype IPv4 (0x0800), length 402: 192.168.2.249.1096 > 192.168.2.248.49156
    : UDP, length 360
            0x0000:  4500 0184 0000 4000 4011 b227 c0a8 02f9  E.....@.@..'....
            0x0010:  c0a8 02f8 0448 c004 0170 079c 4854 5450  .....H...p..HTTP
            0x0020:  2f31 2e31 2032 3030 204f 4b0d 0a43 4143  /1.1.200.OK..CAC
            0x0030:  4845 2d43 4f4e 5452 4f4c 3a20 6d61 782d  HE-CONTROL:.max-
            0x0040:  6167 6520 3d20 3138 3030 0d0a 4558 543a  age.=.1800..EXT:
            0x0050:  0d0a 4c4f 4341 5449 4f4e 3a20 6874 7470  ..LOCATION:.http
            0x0060:  3a2f 2f31 3932 2e31 3638 2e32 2e32 3439  ://192.168.2.249
            0x0070:  3a31 3430 302f 786d 6c2f 7a6f 6e65 5f70  :1400/xml/zone_p
            0x0080:  6c61 7965 722e 786d 6c0d 0a53 4552 5645  layer.xml..SERVE
            0x0090:  523a 204c 696e 7578 2c20 5550 6e50 2f31  R:.Linux,.UPnP/1
            0x00a0:  2e30 2c20 536f 6e6f 7320 5550 6e50 2f39  .0,.Sonos.UPnP/9
            0x00b0:  2e31 2d36 3631 3330 0d0a 5354 3a20 7572  .1-66130..ST:.ur
            0x00c0:  6e3a 7363 6865 6d61 732d 7570 6e70 2d6f  n:schemas-upnp-o
            0x00d0:  7267 3a64 6576 6963 653a 5a6f 6e65 506c  rg:device:ZonePl
            0x00e0:  6179 6572 3a31 0d0a 5553 4e3a 2075 7569  ayer:1..USN:.uui
            0x00f0:  643a 5249 4e43 4f4e 5f30 3030 4535 3831  d:RINCON_000E581
            0x0100:  3244 3139 3630 3134 3030 3a3a 7572 6e3a  2D19601400::urn:
            0x0110:  7363 6865 6d61 732d 7570 6e70 2d6f 7267  schemas-upnp-org
            0x0120:  3a64 6576 6963 653a 5a6f 6e65 506c 6179  :device:ZonePlay
            0x0130:  6572 3a31 0d0a 582d 5249 4e43 4f4e 2d42  er:1..X-RINCON-B
            0x0140:  4f4f 5453 4551 3a20 3330 0d0a 582d 5249  OOTSEQ:.30..X-RI
            0x0150:  4e43 4f4e 2d48 4f55 5345 484f 4c44 3a20  NCON-HOUSEHOLD:.
            0x0160:  4848 4944 5f79 6952 4851 3768 554e 4131  HHID_yiRHQ7hUNA1
            0x0170:  6745 4971 4643 7a34 466d 5878 5533 3464  gEIqFCz4FmXxU34d
            0x0180:  0d0a 0d0a                                ....



  • After investigateing a little bit more I found out that after restarting the pfSense the communication over the bridge is working for a limited time but at a certain point in time it stops to work. I have no timing data yet, but for a few hours it works at least. Seems I need to have a cron to reboot the pfSense… :-/



  • Can you try adding a firewall rule with protocol any and destination that ip? (at least on 2 interfaces involved)



  • @ermal:

    Can you try adding a firewall rule with protocol any and destination that ip? (at least on 2 interfaces involved)

    Altough I have no filtering active on the bridge?



  • What do you mean by no filtering active on the bridge?

    What i want to be sure of is that the bridge is forwarding packets to the recipients. In a setup like this it is most likely that some of the devices might not have completed the multicast registration properly. Is this traffic passing across tcp/udp/igmp?!


Log in to reply