PR
https://github.com/vyos/vyos-1x/pull/2893

@c-po This would be the commits from https://gitlab.isc.org/isc-projects/dhcp/-/merge_requests/67 and 2 of mine to fix the issues with that PR, plus add support for ARPHRD_NONE

Update:
It is completely different issue

Can you share your patch?

Digging into it a little, @c-po mentioned in Slack about trying https://gitlab.isc.org/isc-projects/dhcp/-/merge_requests/67 (the stalled PR). I had to fix a few things which I left as a comment on that PR just in case some else stumbles on it.

Pr for 1.5: https://github.com/vyos/vyos-1x/pull/2887

Related?

PR https://github.com/vyos/vyos-1x/pull/2883

https://github.com/vyos/vyos-1x/pull/2881

@Viacheslav Yes I will create a PR somewhere coming weeks.

https://github.com/vyos/vyos-1x/pull/2877

In T5249#174317, @jestabro wrote:

@adestis
https://vyos.dev/T5976

+1 on excluding disabled mappings

@adestis
https://vyos.dev/T5976

In my eyes this could break many configs / setups, as there are a lot of people that like to "archive their past configs" just like this. (Essentially just disabling config parts instead of deleting)

Imo this shouldn't affect disabled mappings, but just if there are/going to be 2 active mapping with the same IP.

The cause could be due to wrong calculations for bandwidth/ceil class default T5974

Just as a temporary solution before a long term one is figured out, I did implement this as a post-boot script. For any one who stumbles on this

Looks good:

vyos@r1# tc class show dev eth1
class htb 1:1 root rate 1Gbit ceil 1Gbit burst 1375b cburst 1375b
class htb 1:64 parent 1:1 leaf 8005: prio 0 rate 100Mbit ceil 100Mbit burst 15337b cburst 1600b
class htb 1:65 parent 1:1 leaf 8006: prio 7 rate 750Mbit ceil 900Mbit burst 130968b cburst 1462b
[edit]
vyos@r1#

PR: https://github.com/vyos/vyos-1x/pull/2873

In general for the whole world, it would be better to tell the ISP that this is bad practice and they should either assign customers a /56 prefix as minimum allocation.

https://github.com/vyos/vyos-1x/pull/2871

Just putting together a PR for vyos-build to integrate it.

In T5835#172989, @dylanneild wrote:

@sdev Quick question on this issue.

In order to make miniupnpd work with the VyOS firewall as it is presently configured (dedicated ip and ip6 tables), I've had to make a fork of miniupnpd. This is due to the miniupnpd folks effectively declaring that inet tables are "the way it's all going" and effectively removing any ip and ip6 table use in the daemon.

I've tested with the stock miniupnpd to try to implement all rules in a single inet chain, but this creates a problem where, per my comment above, the default-action drop steps on the miniupnpd table, and I'm back to square one.

Using my fork of miniupnpd, I've tested extensively and can see everything working with VyOS IPv4. Rules can be added, checked, and removed without issue. Secure mode works, etc. The fork itself is a fairly small patch; it just reverts some calls in the nftables code to use NFTPROTO_IPV4 rather than NFPROTO_INET for filter and NAT rule changes so as to target the correct table variants.

I can test IPv6 pinhole, which I think can still work using the ip6 tables as-is (my patch doesn't change this at all), but I'd have to setup some tunnelling to validate it as I don't have native IPv6 at my house.

So, my question is: how open is VyOS to using forks of packages as opposed to just pulling them in from Debian?

If not at all, this patch may be at a dead-end unless someone has a clean way to avoid the default-action drop using only priorities (the nftables documentation maintains this can't work)? I considered using meta marking but that would also involve patching miniupnpd to apply the marks to rules matched by it's firewall additions and then modifying VyOS to not apply the default drop when the mark is matched; but that seems a lot less clean.

+1 for this to further VyOS use in service provider networks, and hopefully as a foundation for providing Metro Ethernet capabilities.