danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
winternull has joined #openwrt-devel
<kabel>
hello guys, firewall3 enables all connection tracking helpers by default. As I understand this, they were historically disabled by kernel to load by default because of some issues, and openwrt then returned it to previous behavior with fw3 commit https://git.openwrt.org/?p=project/firewall3.git;a=commit;h=f50a524847a0ac74ef8cc74011d3cc46e9269c6b
<kabel>
jow: this was your work ^^ if I understand this correctly
borek has joined #openwrt-devel
<kabel>
jow: since you wrote that commit message, do you know which commit disabled it in kernel?
<jow>
kabel: yes, correct. We reimplemented former kernel behaviour in userspace to retain backwards compatibility.
<jow>
no idea, no
<jow>
I think wirh some major kernel bump, stuff ceased to work
<kabel>
jow: because we think this behavior is incorrect
<jow>
we offer various options to disable it
<jow>
a) most conntrack helpers are not shipped by default
<kabel>
or at least the SIP CT helper breaks SIP traffic, and shouldn't be enabled by default
<jow>
b) you can disable helper assignment globally
<jow>
c) you can restrict the list of helpers activated for a zone
<jow>
when the SIP CT helper breaks SIP traffic then it sounds like a kernel bug imho
<jow>
unless it's officially declareds broken, in this case we can just drop it
<kabel>
it is broken by design
<kabel>
I am told that it cannot work because it cannot have all the necessary information
<kabel>
I will try to find some information in english, cause now I only have some websites in czech language
<kabel>
anyway there are multiple articles on the net explaining why SIP ALG can break VoIP
Tapper has joined #openwrt-devel
<jow>
and you are sure that "SIP ALG" == "Linux nf_conntrack_sip" and not some random, known to be broken vendor implementation?
<stintel>
I do believe we don't enable helpers for wan zone by default
<jow>
Because that is a very broad statement, like "using HTTP is not secure"
<f00b4r0>
I'm using the sip CT helper with no problem at all
<f00b4r0>
(fwiw)
<jow>
stintel: yes we do, as this is what most people expect in a default NAT setup. NAT + all that arcane stuff to make things work despite NAT
<stintel>
hmmm
<stintel>
vague
<stintel>
ah, for traffic going out wan, yes
<f00b4r0>
jow: the CT helpers are enabled on the "lan" zones (where they have the info they need). There's no helper enabled by default for incoming traffic, AFAICT
<stintel>
but for zones with masq enabled, by default, there is no iifname eth1 jump helper_wan
<f00b4r0>
(at least in fw3)
<jow>
the secure use of helpers article is fine and I understand the rationale. But "carefully examine each related flow and hand-assign conntrack helpers" is simply unrealistic
<jow>
for a default firewall deployment anyway. People can still hand-assemble selected rules for optimal perofrmance and security
<jow>
kabel: do you have any actual real world problem with SIP, OpenWrt and the current OpenWrt default firewall configuration?
<jow>
Or is this just a discussion on principles?
<kabel>
jow: anyway I am told that most, if not all, SIP operators, at least in central europe, and most SIP applications today, can handle NAT on their own
<stintel>
I've used SIP without issues btw with the helpers enabled
<kabel>
jow: yes, the packet mangling by nf_conntrack_sip breaks SIP traffic for some of our users
<jow>
aha. Then please provide specific issue reports
<kabel>
jow: and I am wondering if it isn't time to change the behaviour and disable SIP by default
<jow>
Sure, why not
<jow>
we could disable auto_helper and instead use list helper ...
<jow>
then users can add/remove entries as needed
<jow>
we could also omit sip by default if it adds little value nowadays
<jow>
your initial messages soundes as if you want to disable conntrack helper assignment in general
<kabel>
I think disabling auto_helper and list helpers by would be better. When I was debugging this issue, it escalated to me reading sources of fw3 to find how to disable it. I was grepping "sip" and "5060" in /etc and couldn't find anything
<f00b4r0>
fwiw i can't make sense of the intermedia.com article. What it describes does not apply
<kabel>
no, I am not proposing disabling all the helpers
<jow>
maybe a better solution would be not shipping the sip helper kmod by default then
<jow>
also saves space
<jow>
it could be moved from the core netfilter kmods into the conntrack-extra package
<kabel>
f00b4r0: that's just one article I found, I have some other, for example this one (but in czech) https://www.802.cz/sip-alg/
<kabel>
f00b4r0: it doesn't matter. No impelemnetation of SIP ALG can work correctly, becuase it simply can't have all the information to work correctly (source: trust me :D)
<f00b4r0>
forgive me if I don't :)
<kabel>
anyway I think we are going to disable it by default on TurrisOS and see if customers complain
<jow>
well the recurring point in all these articles you make is "considering how poorly implemented the service is"
<jow>
is nf_conntrack_sip poorly implemented?
<jow>
if yes, is nf_conntrack_sip in *current kernel versions* still poorly implemented?
<jow>
what means "poorly implemented" ?
<jow>
"poorly implemented" to me does not meant "can't possibly be correctly implemented due to inherent protocol limitations"
<jow>
is nf_conntrack_sip truncating sip control packages? Is it removing parts of the payload? Is it randomly dropping packages?
<jow>
or is it just "some SIP ALGs behave poorly, all SIP ALGs are bad" ?
<kabel>
well, nf_conntrack_sip was breaking user's communication just yesterday, so it 100% isn't correctly implemented, even if perfect implementatin was possible
<f00b4r0>
<aside>from the blackhole.sk article: "VoIP is dependent on your connection speed, so spend a little extra to prevent packet loss.". No it's not. it's highly dependent on latency, meaning SQM is far more important that connection speed. I had SIP working on a 512kbps line no problem</aside>
<f00b4r0>
i'll try disabling the helpers, see what difference it makes (if any)
<kabel>
I am sorry, I don't currently have enough time to study it to such measures as to answer all this. Maybe I will find some time later. So for now let's leave it at state that we know it may has problems and that maybe in the future we shuld disable nf_conntract_sip by default. Anyway, discovering where the iptables rule was coming from escalated to me reading sources of fw3,
<kabel>
which I think is a little extreme. So maybe disabling auto_helper and listing the helpers in default config in /etc/config/firewall is something worth doing...
<jow>
kabel: you could also purge the entry from /usr/share/firewall3/helpers.conf (path from memory, might differ slightly)
<kabel>
jow: I don't want to touch /usr/share on user's routers
<jow>
kabel: or even better, move the sip kmod into a separate package (or move into conntrack-extra for now), I guess we all would benefit from that and it wouldn't require large changes to the defaults
<kabel>
jow: I think we may just disable the sip helper on TurrisOS by default and see if some people complain
<jow>
ok
<kabel>
just one question: To disable it, is it sufficient to add 'list helper' to lan zone with list of helpers that should be enabled? Will the presence of the list definition prevent auto_helper?
<kabel>
jow: or do I need to disbale auto_helper in default?
<stintel>
I have auto_helper 0 in defaults
<stintel>
I'm using fw4 though, have not tested this in fw3
<jow>
kabel: specifying a list helper ... with fw3 overrides auto_helper
<f00b4r0>
which suggests that SIP ALG problems are usually an implementation problem
<f00b4r0>
(and then go on to claim that Mikrotik's works :)
<f00b4r0>
he also mentions that for apps that are NAT aware, ALG can only break if the router-chosen port differs from the phone-chosen one, which (he says) is very rare
<jow>
f00b4r0: maybe if multiple phones are behind a single nat and all defaulting to the same outbound port?
<jow>
then initiaitinga session at the same time
winternull_ has joined #openwrt-devel
<f00b4r0>
yeah, that would be rather unfortunate (and a poor implementation on the phone side too :)
<jow>
but afair modern SIP servers handle this as well, by considering the IP packet source port instead of the SIP announced one
<f00b4r0>
the video is very interesting
<jow>
poor implementation = cheap implementation
<jow>
so highly likely to exist
<f00b4r0>
yeah but the linux kernel implementation should be free of such flaws, and if not can/should be fixed
SlimeyX has quit [Ping timeout: 480 seconds]
SlimeyX_ is now known as SlimeyX
winternull__ has joined #openwrt-devel
winternull has quit [Ping timeout: 480 seconds]
<f00b4r0>
he makes an interesting point about the relationship between UDP timeout and SIP helper timeout
<jow>
hmm, our timeouts are very short, wouldn't surprise me if they'd clash
<f00b4r0>
"if the router session timeout expires before the server session timeout, the server would send data to an expired session (closed return port)"
<f00b4r0>
32mn into the vid
winternull_ has quit [Ping timeout: 480 seconds]
<mangix>
Oh no
* mangix
grabs popcorn
<jow>
nbd: how is the vlan aliasing working in netifd? config bridge-vlan; option vlan 123; option alias foo; ... and later config interface ...; option device brname.foo ?
<jow>
nbd: also it appears the vid might be symbolic in config device sections as well? so config device; option type 8021ad; option ifname br-blah; option vid foo; option name vlanfoo would resolve foo to a numeric ID through the bridge-vlan alias foo of br-blah?
<jow>
and finally, what's the use case for having multiple aliases per bridge-vlan?
<\x>
lets say a gretap @tap.200
<\x>
i think
<jow>
?
<nbd>
jow: yes, using brname.foo works, option vid foo in vlan device sections as well
<jow>
ok and assuming I do have list alias foo ; list alias bar I can then refer to either brname.foo or brname.bar ?
<jow>
kabel: may I PM?
Ansuel has joined #openwrt-devel
Ansuel has quit []
<kabel>
jow: yes of course
<kabel>
jow: but I need to leave now, so I will respond later
<jow>
thanks
Tapper has quit [Ping timeout: 480 seconds]
robimarko_ has joined #openwrt-devel
robimarko has quit [Ping timeout: 480 seconds]
borek has quit [Read error: Connection reset by peer]
borek has joined #openwrt-devel
borek1 has joined #openwrt-devel
borek has quit [Read error: No route to host]
borek1 is now known as borek
borek has quit [Remote host closed the connection]
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openwrt-devel
arnd__ has quit []
arnd has joined #openwrt-devel
Tapper has joined #openwrt-devel
valku has joined #openwrt-devel
<nbd>
jow: yes, listing multiple aliases works. the device name it creates will still have the vlan number instead of the alias name
<jow>
nbd: okay, so basename.<alias> ifnames will only be encountered in the config file itself, not as netdev names in the system
<nbd>
right
<nbd>
the main point of using aliases is to make it possible to specify the vlan id in only a single place
<nbd>
to make it easier to change
<jow>
I figured. Still wonder about the use case for multiple aliases
<jow>
to map multiple logical names to the same vlan?
<nbd>
yes
<nbd>
btw. it seems that in the next few days i will finally get around to writing my first piece of code in ucode
<nbd>
i will write the unetd admin scripts in ucode
<stintel>
ugh don't get me started, apparently people gave up trying to get it upstream but meanwhile $vendors have already deployed it in the field
<jow>
nbd: great. Let me know how it goes
<nbd>
will do
<nbd>
my goal with unetd is to be able to create a fully peer-to-peer wireguard network between a number of openwrt hosts with a very small number of shell commands
<jow>
blogic told me a little bit about it - sounds interesting. A little bit like Tinc, but with less deployment hassle
<nbd>
yeah. it already works if you create a json file that describes all participating nodes and copy that to every node
<nbd>
next step is to configure only the master key, at least one address to connect to, and the local node's private key
<nbd>
and then you can push out network configs signed by the master key
<nbd>
as long as one node has a public ip, it can already deal with double-nat scenarios
<nbd>
so with the admin scripts you can later simply make one router your master, and adding another one can be done with a one-line command
<nbd>
which will ssh into the other router, generate a key there, put in the master pubkey along with the basic config, and send the public key back to the master
SherlockDomes has joined #openwrt-devel
<SherlockDomes>
Hi all, I was just wondering how everyone here works on a project that has ongoing development with OpenWRT? On a desktop you'd change code, run make then run it and repeat the process. Doing this via OpenWRT is quite convoluted, as you're required to push got git, then run make package/<pkgname>/compile, etc. You could just edit in the build_dir but you run the risk of wiping all your changes if someone runs
<SherlockDomes>
make /package/<pkgname>/clean. In summary my question is how can you take advantage of OpenWRTs toolchain, sysroot, target heads and libraries without having to go through the package Makefile and pushing to git route? Thanks
<jow>
SherlockDomes: CONFIG_SRC_TREE_OVERRIDE
<jow>
SherlockDomes: it's a menuconfig option in the advanced developer section
<jow>
then git clone your project somewhere on disk
<jow>
followed by ln -s /path/to/local/clone/.git package/..../mypackage/git-src
<jow>
then package/mypackage/{clean,compile}
<SherlockDomes>
Thanks jow, the problem with that method is you have to continually commit changes. How do you make small changes and test them pre-commit? Is that possible?
<jow>
it'll ignore whatever Git source is specified in the repo and resolve the repo through thegit-src symlink
<jow>
hm, never bothered
<jow>
I just have some "git commit -sam xxx" commit on top which I continously amend with git --commit -a --amend
<jow>
*git commit -a --amend
<jow>
when I'm done I turn it into a proper commit
<SherlockDomes>
Interesting approach. Indeed
<SherlockDomes>
Ok great, thanks Jow as always. Much appreciated.
<nbd>
SherlockDomes: if you only do {clean,compile} once after setting up git-src, you can just edit files in the package build dir directly and commit from there
<jow>
nbd: clean is not wiping it?
<nbd>
that way you don't have to clean the package on every build, and you don't have to commit for every change
<nbd>
jow: i'm saying you don't run clean on subsequent builds
<jow>
or did you mean to run package/mypackage/compile without /clean?
<jow>
ah, right
<nbd>
and adding NO_DEPS=1 or QUILT=1 on the build command line makes it even faster
<SherlockDomes>
nbd, I've worked like that in the past, problem is it is to easy for it to get cleaned. Sometimes building other packages trigger it getting cleaned.
<jow>
SherlockDomes: so there you go, src tree override + git-src symlink plus /compile only and an occasional commit / commit --amend to save your work
<SherlockDomes>
I never figured out why, but I'm pretty sure I've seen a package get cleaned because something else changed.
<SherlockDomes>
Yeah the combination should work, cheers nbd and jow.
<jow>
I usually have the file of interest open in my editor, if it get accidentially cleaned/revereted I can just ctrl-z, ctrl-s to undo the file reload and re-save the previos contents
<jow>
I rarely lose work this way
<SherlockDomes>
interesting, ok cheers guys
<mrnuke_>
robimarko_: are you still taking PRs on your ipq807x branch on github? Has the code moved to a better (more upstream) place?
goliath has quit [Quit: SIGSEGV]
<f00b4r0>
nbd: if you need beta testers for unetd I'm definitely interested. I run exactly the kind of setup you describe with 5 participating router nodes interconnecting their respective lans
<f00b4r0>
(actually, there's an extra linux, non-openwrt node in there, but that's irrelevant ;)
<robimarko_>
mrnuke_: Yeah, cant get more upstream for now
<robimarko_>
mrnuke_: Managed to get decent amount of stuff upstream, now gotta backport it to 5.15
<robimarko_>
Clean up the target a bit and then I want to make a PR for the target to be added to OpenWrt
<nbd>
f00b4r0: are you interested in routing over wireguard only, or do you want to bridge the LANs?
<f00b4r0>
I'm routing. Each location has a dedicated LAN. I'm using a B class per location (10.x/16 where x is also a VLAN id)
<nbd>
okay
<nbd>
just asking, because unetd supports the bridging use case as well (via vxlan)
<f00b4r0>
interesting. Bridging felt to me like a planning headache, so I chose to avoid that :)
<nbd>
with unetd it's easy. you simply tell it to add a tunnel and add some nodes as members and put the tunnel device name in the interface section in /etc/config/network
<nbd>
it'll flood broadcast/multicast/unknown-unicast frames to all peers
<nbd>
so it works without having a central relay
<f00b4r0>
sure but what's the benefit over routing, which keeps the chatter between routers under control?
<nbd>
i guess the only benefit is if you need l2 for some special cases
<f00b4r0>
i'm not using a star topology mind you, each router knows all of its peers
<f00b4r0>
i see
<nbd>
e.g. when i want to access my test network remotely, i want to be able to access the router's LAN side via l2
<nbd>
in case i quickly need to use custom or weird ip/subnet settings
<f00b4r0>
makes sense.
<f00b4r0>
extra points if unetd can coexist with manual config; the gory details are: I have one peer that lives on a metered LTE which changes IP every 12h, in order to avoid dealing with this on every other router (and having the keepalive data usage multiplied by 5), this one peer connects to an intermediary linux box (a VPS) which the other routers all connect to. Clearly not something common but it'd be cool if this could still work :)
<nbd>
for each entry in unetd you can announce arbitrary ip addresses or subnets
<f00b4r0>
(correcting myself above I really mean 10.x.y.z/16 where x is per location and y is the VLAN id at that location - then I have some local routing rules to (dis)allow accesses from one LAN to the other)
<nbd>
should work. unetd will set up subnet routes / allowed ip entries for all nodes, and it's up to your firewall rules to decide which source can access which subnet
<f00b4r0>
excellent; that's how I do it
<f00b4r0>
i currently setup wireguard to route the entire location 10.x/16 and then filter locally through firewall zones. I also configure dnsmasq servers for convenient name resolution (each location has a dedicated "zone" in the form "locationname.lan")
<nbd>
btw. unetd will also create a hosts file containing entries for each peer
<nbd>
and each peer gets an auto-generated ipv6 address on the wireguard interface
<f00b4r0>
nice
<nbd>
(derived from the pubkey)
<nbd>
deterministic
<f00b4r0>
in case you wonder how I know how to reach the location's dns, it's because each wireguard interface has a dedicated address in the form 172.16.2.x where 'x' is per location, same as the 10.x. So over the wireguard network I don't have to worry about how the local LANs are addressed nor what the router's LAN IP is :)
<f00b4r0>
i didn't look into moving all that to ipv6, could prove interesting, but so far not needed
<nbd>
you get the ipv6 address for free, but you can simply put ipv4 addresses/subnets in the config
<f00b4r0>
sounds perfect
<nbd>
it also integrates with netifd, so you define an interface section for the unetd connection in /etc/config/network, and it'll look up the ip addresses that belong to the entry that you provided the key for
<nbd>
and that gets passed to netifd as locally configured ip addresses