srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
<neggles>
Grommish: i have acquired additional octeons
<neggles>
because i am a masochist
<Grommish>
neggles: :D
<neggles>
this time it's juniper SRXes
<neggles>
two of which have the same SoC as the shield in
<Grommish>
neggles: Question.. cargo rustc vs cargo build.. cargo rustc is basically cargo build with the ability to pass args, correct?
<Grommish>
neggles: Someone on the Itus boards was looking to sell their device. I think they found it and then didn't know what to do with it.. wanted $100 for it and I had to tell him not only pass, but he really should be more realistic :D
<neggles>
conveniently the u-boot on these isn't locked
<Grommish>
neggles: It's on the Shields either
<neggles>
am i going to try to put openwrt on a juniper octeon? yes. why? I hate myself, is why.
<Grommish>
I just can't figure out how/why to build a new one
<neggles>
iirc there's a buildroot tree for it
<neggles>
but if your current one has the features you want/need why bother
<Grommish>
neggles: It's got everything as far as I can tell.. aside from the fact the three kernels are hard-coded for filename
<neggles>
Grommish: that's an octeon thing
<Grommish>
neggles: but it's setable in uboot :D
<neggles>
you can change the values in env vars yeah
<Grommish>
neggles: and there are bootoct and other aliases in tehre too
<Grommish>
but it's based on the GPIO position of the front switch as to which filename it loads
<neggles>
yes, you should be running with `bootoctlinux`
<neggles>
ah that's just their custom bootcmd script
<neggles>
on cargo rustc vs cargo build, i believe so, but there seems to be some other minor semantic differences
<neggles>
but it only passes those args to the final compiler invocation, not dependencies
<neggles>
if you want to pass to all the compiler invocations you need to set build.rustflags in config.toml or the RUSTFLAGS env var
<Grommish>
I need to put in $(FPIC).. woudl that go into RUSTFLAGS?
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<Grommish>
with the -C flags?
amaumene has quit [Ping timeout: 480 seconds]
<neggles>
I guess?
<neggles>
seems like yes
<neggles>
only one way to find out really :P
<Grommish>
You say that, but it's a 2 hours rebuild ;p
<Grommish>
So I'm exploring all my options first hehe
<neggles>
and, you can change the filenames by editing the `bridge`, `gateway`, and `router` env vars i'd say
<neggles>
interesting that bootcmd loads a 4th separate filename
<Grommish>
OpenWrt only recognizes the Router slot anyway
<Grommish>
and the partitioning is ludicris
<neggles>
i imagine they've got a preboot script that checks the gpios for the switch to determine which command to run
<Grommish>
It's in the stage1
amaumene has joined #openwrt-devel
<Grommish>
But both files are on /dev/mmcblk1p1 (vfat) with the kernel images
<Grommish>
So it isn't like they are hard to get to.. When i looked previously, because the device was a Rhino-board it made it more trouble that it was worth
<Grommish>
if not impossible
amaumene has quit [Read error: Connection reset by peer]
amaumene has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
felix has quit []
felix has joined #openwrt-devel
amaumene has quit [Ping timeout: 480 seconds]
amaumene has joined #openwrt-devel
minimal has joined #openwrt-devel
amaumene has quit [Read error: Connection reset by peer]
<dansan>
Well, 2 - 3 times a second. That's probably not "several"
IvanSB has joined #openwrt-devel
<IvanSB>
hi... I've some security problem and I've tried to report it through email and I see infra.openwrt.org refusing the email...
Misanthropos has quit [Ping timeout: 480 seconds]
ekathva has quit [Ping timeout: 480 seconds]
\x has joined #openwrt-devel
<jow>
dansan: it calls request_module() for something
<jow>
dansan: and modprobe does not provide it
<jow>
maybe triggered by some not understood network protocol
<ynezz>
IvanSB: feel free to send it to ynezz@true.cz and I'll forward it
amaumene has quit [Quit: amaumene]
<IvanSB>
ynezz, seems infra.openwrt.org is running some kind of graylisting. It seems it finally got accepted. THX
<jow>
that github issue? can't reproduce it
<IvanSB>
jow, talking about me?
<jow>
would be helpful if you would provide your complete configuration (installed packages, /etc/config/dhcp, customizations etc.)
<jow>
yes
<IvanSB>
jow, it seems "timerized"
<jow>
specific version
<IvanSB>
or triggered from outside
<IvanSB>
jow, I was writing a followup
<jow>
firewall too, to rule out cache poisoning/dns rebind issues
<IvanSB>
jow, router resolve properly for a while... then not and it seems that when it doesn't resolve it start to be unstable (even web interface or ifconfig)
<jow>
check conntrack
<jow>
maybe firewall is misconfigured and your router participates in a DNS amplification attack
<IvanSB>
jow, if it was a poisoning issue, would the router start to be unresponsive and ifconfig return very slowly?
<jow>
if it's flooded with udp connections filling conntrack then yes
<jow>
things being very slowly usually is caused by ram exhaustion
<IvanSB>
jow, what should I provide? firewall rules are default excluding ssh/imap forward
<jow>
iptables-save, cat /proc/net/nf_conntrack, uci show
<jow>
opkg list-installed
<jow>
find /overlay
<jow>
top -bn1
<IvanSB>
jow, I'm to ignorant to completely exclude what you're talking about, but I'd tend to exclude it. As said unbound resolves properly... just dnsmasqd doesn't
<jow>
(when the issue occurs)
<IvanSB>
load is slow
<IvanSB>
I noticed the problem since the web interface was SLOW and the first thing I lookad at was load/memory
<IvanSB>
jow, I'm still willing to provide all the info but I'd think it's something else... mainly because unbound was working as expected... dnsmasqd is running on 53, unbound on 5353... unbound resolve correctly... and dnsmasqd is querying unbound
<jow>
as you said unbound is unrelated
<jow>
I don't care about it
<jow>
general slowness/sluggishness hints at memory exhaustion
<jow>
unbound consumes a lot of memory
<IvanSB>
yeah but why dnsmasqd is resolving wrong... when it is asking to unbound that is resolving right?
<jow>
dnsmasq in tcp mode as well
<jow>
dnsmasq providing wrong replies hints at cache corruption
<jow>
cache corruption could be caused by poisoning if e.g. dnsmasq is accidentially exposed to wan
<jow>
which could be caused by misconfigured firewall
<jow>
could also be malware in the internal mnetwork
<jow>
could be partiocipating in a botnet doing dns amplification attacks
<jow>
could be a genuine dnsmasq bug corrupting internal memory
<rsalvaterra>
All that could be seen with tcpdump, no?
<rsalvaterra>
(Request floods, at least.)
<jow>
12:25 < IvanSB> yeah but why dnsmasqd is resolving wrong... when it is asking to unbound that is resolving right?
<jow>
dnsmasq and unbound resolve DNS differently
<jow>
and the way you described the configuration in your mail, dnsmasq was not using unbound to resolve
<jow>
but it resolved itself, using 8.8.8.8
<IvanSB>
jow, no... that was a test... previously it was set to localhost#5353
<jow>
but even if dnsmasq is configured to use unbound as upstream, if dnsmasq is accidentially exposed to wan it is still vulnerable to DDoS, cache corruption etc.
<jow>
so please provide the data, anything else is just wasting time on speculation
goliath has joined #openwrt-devel
<IvanSB>
jow, what to exclude dnsmasqd is exposed to outside?
<jow>
iptables-save
<jow>
uci show dhcp
<jow>
uci show firewall
<IvanSB>
here?
<jow>
pastebin.com
<IvanSB>
K
<rsalvaterra>
Speaking of dnsmasq… I just had two new dnsmasq instances started for no reason at all…?! o_O
<jow>
rsalvaterra: TCP DNS requests cause dnsmasq to fork
mattytap has joined #openwrt-devel
<jow>
rsalvaterra: and having hotplug scripts will spawn one additional instance as well
<rsalvaterra>
Right, they got killed meanwhile.
<rsalvaterra>
I wonder if I sould just disable TCP… although the DNS spec specifically requires it…
<rsalvaterra>
*should
<IvanSB>
jow, I'm preparing all you asked
<jow>
rsalvaterra: that dnsmasq/TCP forking issue is a problem atm. It consumes a lot of resources and allows easy DoS
<jow>
and somehow we don't overcommit memory anymore (?) which worsens the problem
<rsalvaterra>
jow: I do overcommit… ;)
<jow>
you tuned sysctl explicitly?
<rsalvaterra>
vm.overcommit_memory = 1
<jow>
ok
<jow>
yeah makes sense
<rsalvaterra>
I advice against doing it by default, though.
* rsalvaterra
thinks he knows what he's doing, but he's probably wrong.
<jow>
I'd say that a DNS proxy forking for each (TCP) request is simply broken by design (for an embedded appliance)
<rsalvaterra>
I also think the multi-gen LRU patch set will help a lot with the memory management in future kernels.
<jow>
it should be single process or a number of pre-spawned workers, then doing IO multiplexing using epoll() or similar
<rsalvaterra>
(I have a Linux 5.15 branch with them, staging for OpenWrt in the future.)
<jow>
anything else will just lead to unbound ressource growth and remote DoS potential
<rsalvaterra>
Why not using something like libevent2 to process the TCP requests?
<rsalvaterra>
Should be WAY faster than forking and much faster than threading…
<aiyion>
We haven't got a script that emits suggestions on who to cc for a patch in openwrt/projects, do we?
<aiyion>
Usually when I fixed something in openwrt there was already some core-member involved in the process, so I had never to care about, what to do with the delegate field in patchworks:
<jow>
IvanSB: the next time you notice the problem, capture the contents of /proc/net/nf_conntrack and "top -bn1"
<jow>
also check "logread" for dnsmasq related errors
<aiyion>
Feels weird to ask around, whether someone is interested in reviewing/merging it?
<IvanSB>
jow, logread was fine. I'll check /proc/net/nf_conntrack top has always been fine. top processes are generally hostapd, unbounf and uhttpd with load no more than 5%
<IvanSB>
jow, as said... just running ifconfig takes forever when this things happen... but eg ssh is totally smooth, load is low... but eg. restarting dnsmasqd may fail
ekathva has joined #openwrt-devel
<IvanSB>
jow, starting the vpn is fine too..
<IvanSB>
jow, anyway thanks... I'll check nf_conntrack if it happens again
Tapper has quit [Ping timeout: 480 seconds]
ekathva_ has joined #openwrt-devel
srslypascal is now known as Guest1874
srslypascal has joined #openwrt-devel
ekathva has quit [Ping timeout: 480 seconds]
Guest1874 has quit [Ping timeout: 480 seconds]
ecloud has quit [Ping timeout: 480 seconds]
tizbac has joined #openwrt-devel
<tizbac>
Hi, i'm building some packages for openwrt which are BIG, two questions, 1. How i make the single packages build with multiple threads ( using cmake ) , 2. They are checked out from GIT, why on every toplevel make they build from scratch?
ecloud has joined #openwrt-devel
srslypascal is now known as Guest1878
srslypascal has joined #openwrt-devel
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
Guest1878 has quit [Ping timeout: 480 seconds]
aiyion has quit [Remote host closed the connection]
aiyion has joined #openwrt-devel
srslypascal is now known as Guest1883
srslypascal has joined #openwrt-devel
MAbeeTT2 has joined #openwrt-devel
<rsalvaterra>
5.10.105 was a fun bump… I don't remember the last time I had to get so deep in the low level arch files… :P
<dansan>
jow: Thanks for the help! Sorry, I had to run for a bit.
srslypascal has joined #openwrt-devel
<dansan>
So I believe we have a fun little bug here! My boss wanted me to nuke the default password and leave it's WiFi wide open out of the box. So I didn't set the key, but I left encryption=psk2, so the WiFi interface never came up. After I fix that and wait a little while, the spam stops
ecloud has quit [Ping timeout: 480 seconds]
<Slimey>
heh
kenny has quit []
ecloud has joined #openwrt-devel
kenny has joined #openwrt-devel
Misanthropos has joined #openwrt-devel
Borromini has joined #openwrt-devel
Ansuel has joined #openwrt-devel
<Ansuel>
Hi
<IvanSB>
jow, happened again 40min ago. conntrak seems fine and top as well. ifconfig and dig started to get really slow... had time to dump conntrack and top and rebooted. This time I didn't see github getting resolved to strange IP... but maybe I didn't wait enough and just dump the log and reboot
valku has joined #openwrt-devel
ekathva__ has joined #openwrt-devel
ekathva_ has quit [Ping timeout: 480 seconds]
<ynezz>
hauke: where should I send fix for upstream wireless backports?
<Ansuel>
net-next ?
<ynezz>
do you've some link to that information? I've quickly checked but couldn't find that
<f00b4r0>
out of curiosity, can the "hostapd: nl80211: kernel reports: key addition failed" messages be safely ignored in 21.02.2? I see conflicting arguments on the forum
<Ansuel>
isn't that a failed auth ?
<f00b4r0>
that's hard to tell from the logs. It seems to relate to 802.11r
<f00b4r0>
i notice this in a pattern where a STA bounces from 2.4 to 5GHz on the same SSID. Not sure if the bouncing is a cause or a consequence here.