<neggles>
so really what's missing is the ability to handle a radio/device with multiple MACs
<neggles>
treating the MT7915DAN like one device, which it is, but also is not
ekathva has quit [Remote host closed the connection]
ekathva has joined #openwrt-devel
robimarko has joined #openwrt-devel
ekathva has quit [Ping timeout: 480 seconds]
minimal has joined #openwrt-devel
<rsalvaterra>
Does anyone have OpenConnect in client mode running in client mode in OpenWrt? I can't get it to run *at all*. No errors, no messages… no interface.
<rsalvaterra>
Noithing.
<rsalvaterra>
*Nothing
bluew has quit [Quit: Leaving]
<rsalvaterra>
Ugh… much redundancy.
<stintel>
only on corp managed Fedora using NM :)
<rsalvaterra>
Sure, but that's NM. No clunky configuration passed by environment variables to a script.
<rsalvaterra>
WTF, the interface name MUST be 'vpn'?! o_O
<rsalvaterra>
Wait, no. Something's different…
<jow>
rsalvaterra: I don't see anything in the script that would enforce "vpn" as name
<jow>
rsalvaterra: what's the relevant uci and what's reported by "ifstatus ..." ?
<rsalvaterra>
jow: There isn't, I misunderstood.
<rsalvaterra>
However, it seems to be necessary to specify the OpenConnect interface *before* the outgoing (wan, in my case) interface in /etc/config/network. Does this even make sense?
<jow>
nope
<jow>
but it might hint at a syntax error in wan if it ceases to work when you move it after
ekathva has joined #openwrt-devel
<jow>
double check "uci show network >/dev/null"
<rsalvaterra>
Since I *finally* got it to work, I'll get to debug it later. :)
<rsalvaterra>
First I need to kill the route setup and the dnsmasq config mangling from the vpnc-script (ad-hoc, of course, but I need this working).
<rsalvaterra>
Pushing a route to sending the whole 10.0.0.0/8 through the VPN is crazy.
<stintel>
beats pushing 120 /24 routes ... :)
<jow>
I recently signed up for strongvpn to test the wireguard config import feature
<jow>
or "push" rather, with wg it's not actually pushing
<rsalvaterra>
stintel: Can't argue with facts. But it also depends on how many hosts you need to access. :)
<rsalvaterra>
I need to access a grand total of… two.
<stintel>
very common in corp scenario though
<stintel>
my VPN routes everything but 192.168.0.0/23 over VPN
<stintel>
so if you want to be able to access anything local while connected to VPN, these are the subnets you can use
<stintel>
but since this stuff is corp managed (which basically means 3rd party with root access in my network), I throw that in isolated VLANs anyway and using something in 192.168.0.0/23 isn't a big issue
ekathva has quit [Ping timeout: 480 seconds]
ekathva has joined #openwrt-devel
robimarko_ has joined #openwrt-devel
<mattytap>
stintel: got my m300 in production now. Monitoring temps via mrtg. Load never gone over 0.35. Thanks
<stintel>
good to hear, enjoy :)
robimarko has quit [Ping timeout: 480 seconds]
ekathva has quit [Remote host closed the connection]
<rsalvaterra>
jow: Also, this thing of prefixing VPN interfaces with vpn- is rather silly. If I want my interface to be named vpn-whatever, I'll do it myself. (I personally don't like it).
<rsalvaterra>
And WireGuard doesn't do it, for example (thanks, zx2c4). :P
ekathva has joined #openwrt-devel
<jow>
rsalvaterra: you can't actually do it yourself unless the proto handler offers an option to override the ifname
<jow>
rsalvaterra: and vpn-foo would be an invalid uci section name
<rsalvaterra>
jow: I'm changing the netifd proto plugin itself. ;)
<rsalvaterra>
(openconnect.sh)
<jow>
I know, but I refer to the user configuration perspective
<rsalvaterra>
Right, it's set in stone, unless the proto itself is changed.
<jow>
one upside of the prefixes is that it increases the likelyhood of clashes
<jow>
*decreases
<jow>
imagine a dsa device and a vpn interface called "lan1"
<jow>
or even a non-dsa device and a vpn interface called eth0
<jow>
so directly deriving the netdev name from the uci section name is dangerous
<jow>
unless you add some kind of prefix or suffix
<rsalvaterra>
Well, I'm not thinking of sending this change upstream… ;)
<jow>
then stop complaining
<rsalvaterra>
… but it's just satisfy my personal naming OCD. :)
<rsalvaterra>
Now let's get some sane routes there…
rua has joined #openwrt-devel
T-Bone is now known as f00b4r0
noltari_ is now known as noltari
<stintel>
nbd: one of my wireless clients stopped responding after roaming to another bss, could see the client traffic on the wireless interface but the ping response didn't go back on the wired network... how to debug ?
<stintel>
that's probably what happened a couple of days ago with my phone too, didn't feel like debugging much then so I just rebooted both my APs
<Borromini>
quick question about that MAC fix: i suppose that would not cause stuff like disappearing APs on the EAP615?
<stintel>
no never seen that
<Borromini>
like I have two SSIDs on my 5 GHz radios
<Borromini>
ok.
<Borromini>
encountered it only once so far :)
<stintel>
anything in dmesg then ?
<Borromini>
not that i could see, was the AP for old crap (WPA2 and unmaintained Android) so took a while to notice - ie till my wife started complaining :^)
<stintel>
certainly not happy to hear that
<Borromini>
will keep an eye on it - anyway, gonna backport your patch to 22.03 for testing here locally
<Borromini>
anything i'd need to check?
<Borromini>
for your patch i mean
<stintel>
well that your 2.4GHz MAC is the same as before and 5GHz MAC is + 1
<Borromini>
k ty
<Borromini>
either way MT7915 is orders of magnitude more stable than that dreaded MT7613 :)
<Borromini>
i just sold two out of three of those to someone else (with stock reinstalled)
valku has quit [Quit: valku]
valku has joined #openwrt-devel
southey has quit []
foxtrot has joined #openwrt-devel
foxtrot is now known as Guest707
Monkeh has quit [Remote host closed the connection]
Monkeh has joined #openwrt-devel
Borromini has quit [Read error: No route to host]
<jow>
hmm, having issues with kmod-crypto-kpp here
<jow>
somehow kmod-crypto-lib-curve25519 depends on it, yet menuconfig fails to select kmod-crypto-kpp as =y
<hirnpfirsich>
Good evening ! There is a pending patch on the mailing lists which adds the "realtek-poe" package (handling PoE support on the "new" Realtek RTL8380M switches). AFAIK this package is not going to make it into "mainline", because it is not generic enough and only for specific switches (if i am reading the mailing lists correctly). I am currently hacking on support for
<hirnpfirsich>
"realtek-poe" for the "prometheus-node-exporter-lua" package. Question: Upstreaming this is impossible until the package ("realtek-poe") makes it into mainline, right ?
bluew has joined #openwrt-devel
<karlp>
yes and no, lua should make it pretty easy to just detect if the relevant realtek poe stuff actually exists.
<hirnpfirsich>
karlp: thanks for the answer :) I meant more from the point of view of the package maintainers. Every module for the prometheus-node-exporter-lua is a unique package. Adding another module to the tree, which relies on a package that is not available in the tree, is not going to be merged, right ?
<karlp>
you can still submit it though, and link to the other PR, and IMO, no, not impossible, just not preferable.
<stintel>
as long as there isn't a generic one I'd say try getting realtek-poe included in the packages feed
cmonroe_ has joined #openwrt-devel
dwfreed_ is now known as dwfreed
<schmars[m]>
Or check if it's feasible to integrate it into poemgr, which so far supports the Usw-flex but is meant to be generic
<hirnpfirsich>
karlp, stintel: thanks ! :) i'll finish my work and submit a PR. Even if it the PR does not make it into the feed, at least then it is documented somewhere
<hirnpfirsich>
schmars[m]: i did not build realtek-poe, nor do i have a strong opinion on the whole inclusion discussion. I just wanted to monitor my PoE ports :) I'll give the mailing list discussion some time
ekathva has quit [Remote host closed the connection]