Messages

There's actually 2 different broadcasts in play here on port 987 (it's different for 2nd screen vs. remote play). I just did another capture to be sure of what I saw per application. And just to be clear, the only SSDP traffic I see on either interface is just UPnP.

2nd screen is the application that does a network broadcast I'd expect (so for example if the network is 192.168.1.0/24, the broadcast address is 192.168.1.255), and at the OpnSense box I see up to 5 of those when UDPR is off. Their remote play application is the one that does a wide open 255.255.255.255 (I see it once from the OpnSense box). I agree, it's a bit strange but that's what is being done (and to be honest I've mostly just been testing the 2nd screen app so far, figured that'd be the simpler of the two).

The packet data themselves contain the same thing, even reference the same "device-discovery-protocol-version", so it's a little funny they do broadcasts differently. In any case, I haven't found another way to send these broadcasts across different networks until your plugin existed, though I admit I'm not exactly fully familiar with OpnSense yet.

BTW, thanks a ton for your work on this.

I'm guessing this is thrown because 255.255.255.255 is technically outside the "official" multicast range? Either way, I think it'd be nice to have some kind of feedback in the web UI if the daemon can't be started for some reason. The most I can see from there is that it failed to start in the system log files but it doesn't tell me why.

Correct,  that's not multicast it's broadcast.

Thanks for clarifying, so if it's broadcast, users are meant to leave that field blank? I mean I know it's labeled "multicast addresses" but it wasn't super clear to me what should be done in that case.

UDPR itself does not need rules as it bypasses the fw. The only rule(s) needed are for the server to respond back to the client which does not go via UDPR.

This where I'm confused. I'm actually seeing 2 broadcasts on the vlan interface in the firewall log live view, one in the OUT direction (which is allowed through, "let out anything from firewall host itself") and one in the IN direction (which is being blocked via a default deny rule). The IN is what I needed an additional rule for. Both broadcasts are from the same IP on LAN. If I disable the rule, the PS4 Second Screen application doesn't find my PS4. It's only when I re-enable it that it works.

I also have a rule allowing broadcast traffic back from the VLAN to LAN, and that was enabled the entire time while testing all this.

forget the broadcast address, the source address, leave them blank, just put the port and lan interfaces and try that. you'll likely as not need firewall rules too, but First just see if it fires up.

Thanks marjohn56, this put me on the right track. It works beautifully now - can control my Logitech server from within my guest VLAN.

I was having this issue too. If I try to use the multicast address of 255.255.255.255 (port 987, PS4 device discovery but only sometimes), it'd silently fail and I had no idea if it was actually running or not. Restarting it from shell, or starting the binary manually with the same options (thanks to the config file for making it a copy/paste ordeal) gave me the

Code Select Expand

IP_ADD_MEMBERSHIP on rcv: Invalid argument message. It wasn't until I saw this part of the thread and got rid of the multicast option that it was able to start up successfully. I suppose it probably won't matter to me if I leave it like that but I like to be explicit in my rules.

I'm guessing this is thrown because 255.255.255.255 is technically outside the "official" multicast range? Either way, I think it'd be nice to have some kind of feedback in the web UI if the daemon can't be started for some reason. The most I can see from there is that it failed to start in the system log files but it doesn't tell me why.

Just wanted to share something that confused me as it might help others with their firewall rules. My home network is set up with my primary LAN network (most trusted devices) having access to all VLAN machines. My firewall rules for this are on the LAN interface. However, broadcasts weren't getting through to the VLAN and I couldn't figure out why (source and multicast addresses were left blank, so the broadcasts still appeared to be coming from the original machine). I discovered I needed an additional rule on my VLAN interface to specifically allow broadcasts from my LAN network, despite that rule already being in place on my LAN interface. It seems the source interface's rules aren't being looked at in the event the firewall box itself is generating the traffic or something? I understand why if that's the case, it's just something to be aware of for this plugin.

Hopefully this helps someone else.