GNUmoon has quit [Remote host closed the connection]
ekathva has joined #openwrt-devel
GNUmoon has joined #openwrt-devel
ekathva has quit [Quit: Leaving]
<dwmw2_gone>
rsalvaterra: hm, you had link flapping as well, didn't you?
<dwmw2_gone>
effectively, by taking the VPN up and down?
<dwmw2_gone>
Do you definitely not see openconnect growing as you use it?
<dwmw2_gone>
In your pastebin it definitely looks like openconnect had a lead.
<dwmw2_gone>
leka.
<dwmw2_gone>
le...ffs
<dwmw2_gone>
l e a k
<dwmw2_gone>
But we may already have fixed that by the time we finished testing and pushed to master.
<dwmw2_gone>
Would definitely be good if you could run in valgrind though.
<rsalvaterra>
dwmw2_gone: I basically assumed the leak was caused by some preliminary patch, while we were testing, but I'll get to valgrind soon, but not on this 128 MiB RAM machine. :)
<rsalvaterra>
However, I haven't seen any suspicious memory growth during normal usage.
dedeckeh has joined #openwrt-devel
vlad__ has quit [Quit: Page closed]
schwicht_ has joined #openwrt-devel
schwicht has quit [Read error: Connection reset by peer]
<dwmw2_gone>
I don't remember *fixing* such a leak as we refined that patch. But maybe.
robimarko_ has joined #openwrt-devel
minimal has joined #openwrt-devel
linusw___ has quit []
robimarko has quit [Ping timeout: 480 seconds]
pepe2k has quit [Remote host closed the connection]
<rsalvaterra>
It feels a lot like a hack, but I don't know a better way to do it (and setting option mtu 'whatever' doesn't work for the openconnect proto).
<jow>
rsalvaterra: wonder why the generic mtu handling does not work. it should
<rsalvaterra>
jow: There's nothing setting the MTU in the proto plugin. Maybe that's the issue? That's how WireGuard does it, at least.
<dwfreed>
afaict in my cursory search, there's nothing that allows shell proto plugins to tell netifd to set the device MTU
<dwfreed>
unless your proto makes a tunnel device
<rsalvaterra>
I'll hack it here and see how it goes. OpenConnect itself is pulling the MTU value from its rear, at least for some protocols.
<jow>
dwfreed: but netifd should apply the mtu when claiming the netdev
<jow>
or at least it should be possible to apply an mtu to arbitrary netdevs through config device sections
<rsalvaterra>
dwfreed: Yep, this protocol creates a tunnel device.
<dwfreed>
rsalvaterra: I mean via proto_add_tunnel
<dwfreed>
which afaics, you're not using
<rsalvaterra>
Oh, that's not the case, indeed.
<jow>
config device; option ifname ...; option mtu 1234
<dwfreed>
interface name is often not going to be fixed
<dwfreed>
also MTU value may need to come from the VPN itself
<rsalvaterra>
dwfreed: Right, that's another issue.
<rsalvaterra>
Should we allow the user to specify the MTU in the interface and then let the VPN script override it if it receives a new one?
<rsalvaterra>
I just tested and it definitely doesn't work when doing it in the proto script: netifd: ibm (9916): ip: SIOCSIFMTU: No such device
<rsalvaterra>
I wonder if this is related to the protocol flags…
<rsalvaterra>
user ${unprivileged_openconnect_user} <- Also nice, but we're not quite there yet. :)
<dwfreed>
what about tap vpns?
<rsalvaterra>
Uh… does OpenConnect do tap?
<dwfreed>
I mean, the only difference is l2 vs l3
<rsalvaterra>
That's a world of difference. :)
<dwfreed>
I mean, from openconnect's perspective, it really doesn't need to care, other than setting the tap device's mac address appropriately, which is probably pushed by the VPN server
<dwmw2_gone>
indeed, openconnect is only tun
<dwmw2_gone>
(it can also shovel packets over a UDP socket or any other fd you give it, of course)
<rsalvaterra>
Sure, but I don't see anything in the vpnc-script prepared for L2 setup.
<dwmw2_gone>
But not tap and Ethernet
<rsalvaterra>
dwmw2_gone: Thanks for clarifying. :)
<rsalvaterra>
What I do wonder is if it's a good idea to share the VPN script with vpnc… Wouldn't it be better for OpenConnect to have its own (in OpenWrt, at least)?
matoro has joined #openwrt-devel
<rsalvaterra>
dwmw2_gone: Correct me if I'm wrong, but OpenConnect won't tear down the interface at exit time when invoked with -i, right? We have to manage it ourselves, for sure.
<dwmw2_gone>
right
<rsalvaterra>
Got it.
<dwmw2_gone>
I specifically designed OpenConnect to use the *same* script as vpnc
<dwmw2_gone>
because that does a whole bunch of the platform-specific crap for setting up interfaces, routes, DNS etc.
<dwmw2_gone>
Leaves OpenConnect to do the simple work of shovelling packets from A to B
<dwmw2_gone>
Of course, the original vpnc is fairly much dead these days. We've talked about adding IKE support to OpenConnect, since we *already* do the ESP side (faster than the kernel does in some cases)
<rsalvaterra>
Uh… wouldn't that be invading *swan territory? :P
Kali_ has quit [Quit: leaving]
<dwmw2_gone>
Only slightly.
<dwmw2_gone>
This is just the roaming client side.
<dwmw2_gone>
Hell, now we did PPP we could also do L2TP support ;)
<rsalvaterra>
Oh, God, the bloat… :P
* rsalvaterra
runs
<rsalvaterra>
dwmw2_gone: Is SIGINT the preferred way to orderly bring down OpenConnect?
<rsalvaterra>
It's how we're doing it in the netifd proto script, at least… proto_kill_command "$config" 2
<dwmw2_gone>
SIGINT / SIGTERM
<dwmw2_gone>
performs a clean shutdown by logging the session off, disconnecting from the gateway, and running the vpnc-script to restore the net‐
<dwmw2_gone>
SIGHUP disconnects from the gateway and runs the vpnc-script, but does not log the session off; this allows for reconnection later using
<dwmw2_gone>
work configuration.
<dwmw2_gone>
--cookie.
<dwmw2_gone>
IF you're running OpenConnect in a mode where it always has the actual password and can log in again, use SIGINT.
<rsalvaterra>
Pretty much our use case. SIGINT it is.
<dwmw2_gone>
If you need some kind of human interaction / SAML / OTP token and you've temporarily stored the actual auth cookie for the session, you can use SIGHUP so that the cookie remains valid.
<dwmw2_gone>
As more people move to SAML for auth, that other mode will need to be supported.
<dwmw2_gone>
With NetworkManager we have a separation of auth and connection phases. Auth runs in the user's desktop session, connection uses the resulting cookie and runs as an unprivileged user.
<rsalvaterra>
That… will probably require quite a bit of plumbing to be supported in OpenWrt…
<rsalvaterra>
Ugh, we don't enable tun support for ip in BusyBox by default. *facepalm*
<rsalvaterra>
If we want to create the tunnel in advance…
<rsalvaterra>
… either openconnect will have to depend on ip(-tiny, hopefully), or we'll have to enable support for tunnels in BusyBox's ip utility.
<dwmw2_gone>
It might be only a few lines of code to add --create-tun and --destroy-tun options to openconnect main.c itself?
<rsalvaterra>
Invoking openconnect just for creating the tunnel? I think that's a bit overreaching in terms of scope…
<rsalvaterra>
I'd rather add an ip-tiny dependency. People interested in running OpenConnect on their routers will probably already have beefy devices.
<rsalvaterra>
Hackers can always enable tun support in BusyBox.
<dwmw2_gone>
you shouldn't need to precreate the tun device just to set the MTU though.
<dwmw2_gone>
And you can't anyway, since for many cases openconnect will *detect* the MTU (and test it)
<dwmw2_gone>
you only need to precreate in order to run openconnect unprivileged.
<dwmw2_gone>
so you can make that optional and run openconnect as root (or with CAP_NET_ADMIN perhaps), if you couldn't precreate
<rsalvaterra>
Yeah… just setting the MTU in the vpnc-script is a lot less of a headache, I think.
<rsalvaterra>
One thing it would probably make things more predictable… if we don't get an MTU from the server, is it possible just to set the envvar to the value passed with --mtu=?
<rsalvaterra>
If we don't receive an MTU and don't pass --mtu=, just set it to 1400, as it is today.
<rsalvaterra>
How about it?
<dwmw2_gone>
it's a better default than 1500 I suppose
<rsalvaterra>
Is it 1500? At least for array, the value I'm getting is 1400.
<rsalvaterra>
(Which is the same value the official client sets.)
<dwmw2_gone>
I think OpenWrt is defaulting to 1500 if *nothing* sets it.
<dwmw2_gone>
OpenWrt is protocol-specific but it's generally around 1400.
<rsalvaterra>
Oh, you mean without explicitely using the envvar to set the MTU with ip link, I see.
<mrnuke>
Machine model: Qualcomm Technologies, Inc. IPQ807x/AP-HK07
<mrnuke>
slh: ^ Does that answer your question?
<mrnuke>
I did not take the board completely out. I'm afraid I'd mess up the antennas
<slh>
not quite, because it still leaves the question between ipq8072 (not supportable) and ipq8072a (supportable) open, at least the FCC images for the engenius equivalent suggest ipq8072
<mrnuke>
Okay, devicetree compatible is " Machine model: Qualcomm Technologies, Inc. IPQ807x/AP-HK07" . How do I find out exact SOC model (I have root shell)
<mrnuke>
"qcom,ipq807x-hk07qcom,ipq807x" I'm sorry. I mis-pasted
<slh>
easiest option would be checking the wireless firmware blobs under /lib/firmware/, if you only have HK1.2 or HK2.0 firmware blobs
<slh>
if you have both, dmesg might provide some clues
<slh>
something like "Skip QCA8074V1 in V2 platform" would be great to read