Page MenuHomeVyOS Platform

UDP Broadcast Packet Relay
Closed, ResolvedPublicFEATURE REQUEST

Description

This program listens for packets on a specified UDP broadcast port. When a packet is received, it sends that packet to all specified interfaces but the one it came from as though it originated from the original sender.

The primary purpose of this is to allow games on machines on separated local networks (Ethernet, WLAN) that use udp broadcasts to find each other to do so. Also SONOS uses broadcast to make the devices visble in the local subnet.

Proposal:

This works like a charm!

Configuration nodes:

 service {
     bcast-relay {
         id 1 {
             description Sonos
             interface br30
             interface br31
             interface br35
             port 1900
         }
         id 2 {
             description "Sonos MGMT"
             interface br30
             interface br35
             port 6969
         }
     }
}

Details

Difficulty level
Normal (likely a few hours)
Version
-
Why the issue appeared?
Will be filled on close

Related Objects

Event Timeline

c-po changed Difficulty level from Unknown (require assessment) to Normal (likely a few hours).

@UnicronNL could you please mirror https://github.com/c-po/vyos-bcast-relay.git to https://github.com/vyos/vyos-bcast-relay.git and set up a CI job? After this I can submit the appropriate merge requests for vyos-world abd vyos-build.

dmbaturin changed the task status from Open to In progress.Sep 8 2017, 9:36 AM
dmbaturin added a subscriber: dmbaturin.

I think before we call it finished, we should move those repos under vyos organization and give @c-po access to them (frankly, I also propose to add him to maintainers).

And now that I've actually looked into it... ;)

There are some bad practices that I think should be changed before we call it complete as well.

First, now that the Python configuration library and the templates convertor work, can we stop adding new Perl code? Those scripts are short at least.
There are some very good reasons to do that as well. For example, now that we are using systemd, why should we have start-stop-daemon? We should never had it right in Perl code to begin with.
Second, I'm strongly against mixing VyOS configuration code with applications it configures. Let's move that out of this, and if we are going to move the configuration code to vyos-1x package, it will come naturally. We can merge the bcast-relay and mDNS repeater into one package perhaps.

The features are appreciated, but let's add them in a fashion that will make VyOS easier to maintain, not harder.

just a thought - much of this is porting EdgeOS features, right? Those guys are still using perl, so any features they implement that VyOS wants is going to be perl by it's nature, surely?

This might not be the best avenue for this discussion, and I certainly don't have the standing to question the future direction of the project... but given that EdgeOS is still being actively developed, isn't there merit in staying using similar architectural decisions rather than striking off in a direction that'll need huge rewrites?

Or... maybe it's just sour grapes that I'm a perl guy, and just can't get my head around Python ;)

  • Jules

And now that I've actually looked into it... ;)

There are some bad practices that I think should be changed before we call it complete as well.

First, now that the Python configuration library and the templates convertor work, can we stop adding new Perl code? Those scripts are short at least.
There are some very good reasons to do that as well. For example, now that we are using systemd, why should we have start-stop-daemon? We should never had it right in Perl code to begin with.
Second, I'm strongly against mixing VyOS configuration code with applications it configures. Let's move that out of this, and if we are going to move the configuration code to vyos-1x package, it will come naturally. We can merge the bcast-relay and mDNS repeater into one package perhaps.

The features are appreciated, but let's add them in a fashion that will make VyOS easier to maintain, not harder.

good one!

@JulesT 99% of new EdgeOS code is proprietary. I see no reason to stick with it for the tiny open source bits they may release once in a while. EdgeOS could use their departure from Vyatta Core as a chance to rethink those decisions, but apparently due to time pressure they didn't... Now they are stuck with backporting UnionFS forever and never getting e.g. fully transactional commits or

I'm going to make a blog post today and I'll re-iterate the reasons for this rewrite. Also, in Python you never have to guess if function's default context is list or scalar, that's already easier to learn. ;)

Fine, dmbaturin.

As I say... I don't have the standing or the background to really question the approach. If you guys aren't really interested in commits that are perl-based, though, then I'm afraid I don't really have a lot to offer.

Still, though, you might find that there are more python guys around nowadays than perl, although my guess is that development types who also understand networking might skew a little harder into scripting/text mangling languages, I suppose.

Anyway... your project, your rules ;)

@JulesT I'm afraid Perl code is going to be around for quite a while, as many things need to be fixed before any rewrite of them can take place.
It's the code for new features that concerns me, not as much in the language as in the old approach that is not conductive to either automated testing or future implementation of transactional commit.

@dmbaturin You have some good points. Using "service" to start/stop a daemon should be the weapon of choice now. This could/should be changed to have a consitent system, but this inital commit is just a 1:1 EdgeOS copy.

We can merge the bcast-relay and mDNS repeater into one package perhaps.

I totally agree here, but I do not have an idea about your current pakage system. Having one package per "command/tree" does not make things easier. Adding a new package requires CI setup, a new repo unter the GitHub VyOS group etc.. Is there any plan maybe on migrating everything to just one "VyOS" package/repository? (Git supports merges of non related trees, so history won't be lost). This will have the benefit that commits are atomic. As an example when working on T157 I found that I need to touch two repos which means that you can get into an inconsitent state.

Just my 2ct ;)

@c-po The post I made yesterday (http://blog.vyos.net/vyos-development-digest-number-10), the vyos-1x package is pretty much that, the future single package for all config scripts and data. I would be reluctant to put things that are not VyOS-specific into it though. With small things such as the mDNS repeater things get shaky of course. Something like PMACCT is a clear case, merging it into another package would be insanity. Those relays are small enough to make one wonder if they really need their own packages.

I think, given their related functionality, one package for them both and their corresponding config scripts in vyos-1x would be a sensible compromise. I'll need to learn about their development cycle of course before my opinion is truly informed.

Well I think porting this to vyos-1x package would be a good lesson to learn the new system. Let me have a look...

This could be possibly used for targeted Wake-on-LAN packet relaying as well...

Just wondering, if it's possible to address this problem by just addint some firewall rule like
iptables -t mangle -j TEE ...
Did anyone did some digging into xtables-addons package to elaborate, whether it's possible to use firewall for this kind of things? I think, it should be much faster to do this things in kernel, than in userspace.

@Asteroza this program forwards UDP packets (Layer 3) on specific ports. Unfortunately WoL is Layer 2 based.

@mickvav Interesting Idea, I should give it a try ...

Rewrote the scripts using vyos-1x and Python. This is now functioning on my routers.

See the Used Guide at https://wiki.vyos.net/wiki/User_Guide#UDP_broadcast_relay

syncer edited projects, added VyOS 1.2 Crux (VyOS 1.2.0-rc1); removed VyOS 1.2 Crux.
syncer moved this task from Needs Triage to Finished on the VyOS 1.2 Crux (VyOS 1.2.0-rc1) board.