Messages

[both]

Then, to get the TV working I have to run:

Code Select Expand

udpbroadcastrelay --id 1 --port 1900 --dev lan.20 --dev lan.30 --multicast 239.255.255.250 --msearch dial -d -s 1.1.1.2

Just curious: have you set up firewall rules such that source:port (which should be unicast, IMHO) of those packets can be reached accross the networks?

To get the Roku to work I have to run:

Code Select Expand

udpbroadcastrelay --id 1 --port 1900 --dev lan.20 --dev lan.30 --multicast 239.255.255.250 -d

I tried running both commands with a different ID number but this caused a multicast flood.

When running both commands with different IDs, both instances receive all the the traffic to 230.355.255.250:1900. This includes traffic from the other instance, respectively. Thus, packets sent by one instance are received by the other instance and will be re-sent on all configured interfaces by the other instance (if not filtered by --msearch). This results in the two instances playing ping-pong with packets containing the --msearch string, effectively flooding the networks.

The clean way to get this working would be to have only one instance and let the result of --msearch decide whether source address/port is to be preserved or replaced instead of completely discard the packet.

I just digged through this thread, and found more contradicting suggestions:

Code Select Expand


mDNS (Chromecast/Apple Bonjour)
224.0.0.251:5353                 -s1.1.1.1
224.0.0.251:5353 224.0.0.51:5353 -s1.1.1.1
224.0.0.251:5353
224.0.0.1:5353

SSDP (UPnp/DLNA Media)
239.255.255.250:1900
239.255.255.250:1900 -s1.1.1.1


So it seems you are not the only one having this problem. You're just the first one who did a systematic analysis of the problem.

PS:
To be honest, I have a hard time to understand what this 1.1.1.1/1.1.1.2 is good for and how it is supposed to get things working.

Without this mangling, the receiver will respond to the original unicast address:port. As long as receiver can do unicast with the original address:port (check firewall rules), communication should work, IMHO. All is good.

OTOH: having this -s mangling in place, UDPBR would put its own interface-address (which would be UNICAST) (and port with 1.1.1.1) into the packet. Unless it also listens to this address:port and remembers to forward traffic to the address:port which were sitting in the original packet, I don't see how this is supposed to work. Have just done a quick glance on the source and I don't think UDPBR is currently doing this forwarding.

So, if I understand things correctly, this -s option is only good for breaking things. Please correct me if I am wrong.

Please double-check that both sides can properly do unicast-communication for the ports/protocols they need to the other side.

Please help me get a better understanding about the topic by confirming and/or correcting some questions:

- UDPBR obsoletes Avahi, IGMP-proxy, mDNS and SSDP (if setup correctly)

- UDPBR obsoletes pimd in the simple case when there is only one router

- For proper operation, multicast depends on IGMP reports to join/leave MC-groups. Is UDPBR involved in this IGMP thing, or is this handled by the kernel?

- UDPBR does NOT depend on the setting of ip_mroute in the kernel, because it actively copies the packets in user-land?

(Edit: typo)

Perhaps because it's RTP and not UDP?

Not sure I understand what you try to tell me :)

You are about the video data? IIUC, tcpdump says this is UDP:

Code Select Expand


IP (tos 0x0, ttl 10, [DF], UDP)  192.168.12.101.47386 > 239.255.1.2.5004: UDP

And this is consistent with Wikipedia, where it is stated that RTP runs over UDP.

But maybe I simply misunderstood your reply?

Hi,

me also need some help to get multicast working across VLANs.

As a test, I'd want to serve an video, like this:

Code Select Expand


cvlc  BigBuckBunny_320x180.mp4  --sout "#rtp{dst=239.255.1.2,port=5004,ttl=10,mux=ts,sap,name=Bunny}" --no-sout-all --sout-keep --loop


Being on the same VLAN, I can see this video with:

Code Select Expand


vlc rtp://239.255.1.2:5004


When server and client are on the same VLAN, tcpdump shows me:

• SSDP and mDNS, advertising all kinds of services
• IGMP queries and reports, which show that the clent has actually joined the 239.255.1.2 group
• the video data on 239.255.1.2:5004

So I set up udpbroadcastrealy like this:

Code Select Expand


udpbroadcastrelay --id  2 --dev re2 --dev re2_vlan10 --dev re2_vlan12 --port 5353 --multicast 224.0.0.251 -s 1.1.1.1 -f
udpbroadcastrelay --id  1 --dev re2 --dev re2_vlan10 --dev re2_vlan12 --port 1900 --multicast 239.255.255.250 -s 1.1.1.2 -f
udpbroadcastrelay --id 20 --dev re2 --dev re2_vlan10 --dev re2_vlan12 --port 5004 -f


All the interfaces have firewall rules to pass everything. Even set "Allow IP options", which is advised to be set so that IGMP messages can be passed.

AFAICS, SSDP, mDNS and the video stream should be forwarded across the VLANs. But unfortunately, I don't see anything.

Any idea what I might be doing wrong here?

Can I advise udpbroadcastrelay to tell what it is receiving?

Thanks!

This looks promising.

But it works only with the webgui accessible?

I am looking for a way to configure from the WAN side without exposing the webgui to the WAN.

So the idea was to log in via ssh to do the config

Thanks, that was it!

Sorry, I don't understand...

How can I activate the privileges?

The account is enabled, and it is member of "admins" group.

Hi,

I created a user for ssh acces and have populated its authorized_keys file.

When I try to log in, I get this message:

This account is currently not available.

So, how would I activate this account?

Thanks for the info.

It appears that DSA keys are inherently insecure, so it's better not to activate them.

I think API would be even better than CLI.

Do you have any pointer to the API? Don't need to be polished docs. Just something where I could start looking into it would be great!

Hello,

I cant login to opnsense via ssh because of:

   userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes [preauth]

have I missed some important weakness of DSA algorithm?

Hello,

is it possible to configure opnsense on the shell (when logged in via ssh?)

if so, how?

Its on the https://opnsense.org/ page, the "Read MOre" buttons. If touched by the mouse-pointer, they disappear and slowly come back from north-east-north position.

This is with various firefox versions on ubuntu and opensuse systems.

Yes, I upgraded to 15.7.22. That was a little surprise, since I expected 15.7.21.  8)

Hello,

I am new here, coming from pfsense.

My first install (OPNsense-15.7.18-nano-amd64 on APU.1d4) went pretty flawlessly.

Just thought, I'd drop a note and some suggestions.

I found it very convenient, that the initial config will use default values after the countdown runs out. This helps  if you don't have a rs232 cable. It would be great, when before the countdown, there would shown, what the defaults would be chosen when the countdown finishes.

The homepage (opnsense.org): The buttons are jumping around. While this is a nice visual effect, it makes a bad user experience. I find myself constantly "hunting" the buttons.

WebConfigurator: The design of the web configurator wastes lots of vertical spacing. Nowadays, Laptop-screens tend to be very low. On my laptop (1360x768) the "interface status" of two interfaces takes three pages to scroll down. Judging from the font size, it all would fit onto one screen.

I find it somewhat strange that "Reboot" and "shutdown" are located in the "diagnostics" menu. I constantly find myself searching them in the "system" menu

Thanks!