[Shorewall-users] newer iproute2 revision in gentoo causes issues with activated traffic control
Hello I want to bring to your attention that at least gentoo stabilized iproute 4.14.x (4.4.0 was old stable) which obviously needs new parameters for tc command when enabled in shorewall. Are you already aware of this issue? Please refer also to this bug: https://bugs.gentoo.org/640766 No progress on this bug visible... Best regards -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Shorewall 5.2.0 Beta 1
Am 21.02.2018 um 01:38 schrieb Tom Eastep: 3) With the wide availability of ipset-based blacklisting, the need for the 'refresh' command has been largely eliminated. As a result, that command has been removed. Dear Tom, I use traffic shaping on multiple hosts, all connected via DSL, if an ip change occurs "shorewall refresh" reattaches the qdiscs... What would be the recommended way without "refresh" with 5.2? Best regards smime.p7s Description: S/MIME Cryptographic Signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] tc problem on new GENTOO kernel
Hi Tom, posting to the list because until know I am not shure what is to blame... - working config with kernel 4.18.14 (gentoo-sources-4.18.14) - introduced with gentoo-sources-4.18.15 tc rules are not loading anymore on startup, gentoo-sources-4.19.x also affected - set up a testenv on spare with simple config log output Setting up Traffic Control... RTNETLINK answers: Numerical result out of range ERROR: Command "tc qdisc add dev enp8s0 root handle 1: hfsc default 12" Failed seems tc is no longer working with these parameters... My first guess: regression in patchset (gentoo-sources), needs verification and further digging. Is anyone aware of some known bug? Best regards smime.p7s Description: S/MIME Cryptographic Signature ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] tc problem on new GENTOO kernel
Am 09.11.2018 um 17:46 schrieb Thomas Deutschmann: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, 1) We (Gentoo) don't patch anything tc-related in gentoo-sources. 2) The only change between gentoo-sources 4.18.14 and 4.18.15 was the addition of "linux-4.18.15.patch" (https://dev.gentoo.org/~mpagano/genpatches/patches-4.18-18.html). I guess Alexander hit https://lkml.org/lkml/2018/10/26/80 Thanks for clarification, hoping this gets addressed soon in the next kernel point release... ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] last missing Shorewall6 piece, ping6 from LAN to 'NET ?
Am 20.05.2021 um 13:04 schrieb tha...@letterboxes.org: So with this I end up with NAT'd IPv6. Which I thought you weren't supposed to do. yes, this is ugly and something to avoid when ever possible... But I guess if I'm going to have private internal IPv6 addresses, either static &/or delegated, then I have to do this somehow. It depends how ipv6 address space is delegated to you. Her in germany our biggest telco delegates dynamically a /56 subnet which is plenty space for almost everything. Because it is dynamically allocated via dhcp on every new connect, for static service allocation in internal nets we are forced to use ULA address space for internal services and delegate derived subnets from the provider global unicast delegation to clients for internet access. I keep thinking there's a routing solution that solves this, but I can't figure it out. And your NAT suggestion does fix it for now. When you recieve only a /64 subnet, this gets gets realy complicated and depends on every involved software which has to support subnets smaller than /64. In this situation you may be better off with a NAT solution. Best wishes ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
