**** BEGIN LOGGING AT Tue Mar 30 02:59:56 2021 Mar 30 03:54:10 Grommish: do we have rust now? Mar 30 04:19:32 Grommish: any luck? What was wrong with the usual "DEPENDS:= +SURICATA_ENABLE_NFLOG:libnetfilter-log" for example? Mar 30 04:22:42 guidosarducci: I'd assume nothing other than I didn't fully understand the deps wiki? :) It's why I ask Mar 30 04:23:02 ashkan: Depends on the target, but probably Mar 30 04:23:29 ashkan: If it isn't a supported target, it's easy enough to add Mar 30 04:24:11 guidosarducci: I will string them out. I appreciate the correction! :) Mar 30 04:28:21 Grommish cool, nice to see Suricata finally makes it to packages Mar 30 04:34:38 Grommish: some thoughts on your pr though, isn't it a bit harsh to delete the entire log directory on service start ? :D Mar 30 04:34:48 ashkan: I doubt the use-case will be super high. Most Opennwrt machine won't have the grunt to actually use it Mar 30 04:35:12 ashkan: Probably, although it's in /tmp anyway Mar 30 04:36:28 ashkan: For testing purposes I clear everything out.. it can't be merged until rust is, and rust is still draft.. so I"m not concerned overall about it getting used before hand :) But I need a better way to check the pidfile.. I've been chasing down things and not really paying attention Mar 30 04:36:40 ashkan: certainly any comments, suggestions, edits, are welcome Mar 30 04:42:02 Grommish: I may be wrong but those ones who run suricata most def need the logs to be there and rotated even transfered to some SIEM stuff . most devices provide usb and sd slots for extra storage. Mar 30 04:42:49 ashkan: You are not wrong :) and it won't stay that way. log_dir is/will be a configuration setting Mar 30 04:43:11 ashkan: I'm just trying to 1) settle out the dependancies and 2) see if ebpf will work on x86 Mar 30 04:43:42 Grommish: maybe also add a define Package/suricata6/conffiles section ? cause otherwise the config files won't be included in the backups Mar 30 04:44:50 ashkan: Gotcha. :) Let me finish this build real quick because I'll need to push other changes anyway Mar 30 04:47:09 ashkan: Something to keep in mind.. I don't know Suricata, I don't know rust, and I don't really know programming, so pointing out things like that isn't a bad thing :D Mar 30 04:47:39 I'm just persistent Mar 30 04:53:10 Grommish: as long as you can keepup with the community high standards :D Mar 30 04:55:23 Grommish: looking at my own old pr I'm doing a weird [ -f /var/run/suricata.pid -a -z $(pgrep suricata) ] before removing the PID file https://github.com/ashkanj/packages/blob/suricata-stable/net/suricata/files/suricata.init#L21 Mar 30 04:56:34 not sure but maybe that was because to prevent randomly deleting the pid file when the service was running fine Mar 30 04:57:09 Well, what I was seeing is that the pidfile wouldn't get removed and the service would just deathloop Mar 30 04:57:34 Grommish: yep I saw that too Mar 30 04:58:10 Grommish: Freebsd does that too https://github.com/freebsd/freebsd-ports/blob/master/security/suricata/files/suricata.in#L61 Mar 30 05:00:41 Grommish: but I'm talking about a situation when someone triggers start service multiple times in a row. IDK maybe I did something wrong or this is not the case anymore Mar 30 05:02:17 ashkan: This is how I'm currently doing it: https://github.com/Itus-Shield/packages/blob/suricata6/net/suricata6/files/etc/init.d/suricata Mar 30 05:03:49 I need to work on it, but that's on-device work.. meh. But, service suricata start/stop should keep the system from loading multiple times Mar 30 05:04:09 My issue is that it didn't tell me anywhere but the logs that the pidfile was present and assumed it was already running Mar 30 05:04:11 Grommish: I think that could be trouble some, I can look into it if it compiles without bleeding :D Mar 30 05:04:35 ashkan: what target arch? Mar 30 05:04:56 Grommish: also consider a reload service as it definately needed when rules get updated https://openwrt.org/docs/guide-developer/procd-init-scripts#reloading_service_setup Mar 30 05:05:21 a USR2 signal did the job back then Mar 30 05:05:40 ashkan: Yes, and I need to fake a script to setup suricata-update on the device eventually Mar 30 05:05:51 Grommish: X86 ? Mar 30 05:06:06 ashkan: I mean, what would you be testing on target wise Mar 30 05:06:21 if its x86_64, then you're fine for rust, suricata and libhtp Mar 30 05:06:22 Grommish: I can always spare a qemu machine :D Mar 30 05:06:48 mips, mipsel, mips64, aarch64 and arm (I think) are also good Mar 30 05:13:18 Grommish: I used to test it on an ubnt er-pro router which I don't have anymore and I doubt it would run on anything without a serious cpu Mar 30 05:13:52 runs on the er10x Mar 30 05:14:26 how well is tbd Mar 30 05:15:28 I may be able to benchmark it on a rb750gr3 as well Mar 30 05:37:19 Grommish: I don't seem to find the libhtp in your mentioned repo https://github.com/Itus-Shield/packages/ how do you compile yours ? Mar 30 05:45:01 ashkan: https://github.com/Itus-Shield/packages/commit/143a4fba3c4fa0c9778fe44b6d81c2305d574933 Mar 30 05:46:14 Grommish: and where's the rust ? Mar 30 05:46:44 ashkan: https://github.com/Itus-Shield/packages/commit/01d416a0a95daf1a490c7b01016ce788e7e58953 Mar 30 06:03:52 Grommish: Depends on: PACKAGE_zlib ~> this makes suricata invisible in the menuconfig unless you select the zlib package Mar 30 06:31:55 ashkan: zlip is a dependancy of libhtp which is a dep of suricata Mar 30 06:32:01 err zlib Mar 30 06:32:12 It complains about circular if you add it both places Mar 30 06:33:06 besides, I wouldn't set a dependancy in the menuconfig for zlib, where do you see that? Mar 30 06:34:48 Grommish: suricata didn't show up in the menuconfig until I selected zlib manually Mar 30 06:35:12 You've got something else going on then Mar 30 06:35:31 because zlib isn't even a Suricata dep in the Makefile I use, because it's imported from libhtp Mar 30 06:35:52 it's a clean base just pulled from openwrt Mar 30 06:36:28 Oh, I see what happened Mar 30 06:37:51 My last patch removed the + from the +zlib, but not the zlib part >_<.. Mar 30 06:38:35 Actuallyk I just haven't pushed my last run Mar 30 06:39:07 But, since it isn''t working, I"m holding off on it Mar 30 09:00:32 Grommish: https://pastebin.com/YVFy0bqG Mar 30 09:01:55 ashkan: You're building for X86_64, yes? Mar 30 09:02:19 Grommish: yep Mar 30 09:02:32 ashkan: I fixed issues with that.. One sec Mar 30 09:10:26 ashkan: Actually Mar 30 09:10:47 ashkan: I had issues with x86_64, but your issue looks like it isn't using the staging_dir Mar 30 09:10:57 ashkan: "/usr/lib64/ccache/c++" Mar 30 09:11:07 Nothing should be pointing to the HOST Mar 30 09:11:52 that should say something like /home/xxx/openwrt/staging_dir/host/usr/lib64/ccache/c++ .. either host or hostpkg Mar 30 09:15:12 BUt gimme about 20 minutes and I'll push a rust change Mar 30 09:15:44 because there was an issue with x86_64-unknown-linux-musl and x86_64-openwrt-linux-musl Mar 30 09:17:41 err.. x86_64 was reporting as -pc-linux in some places and unknown-linux in others, and then openwrt-linux in rust itself Mar 30 10:40:55 ashkan: I pushed updates for rust and suricata.. Including the stuff you were asking/commenting about.. Let me know if I missed any Mar 30 17:39:34 Grommish: Mar 30 17:39:36 make[3] -C package/rust host-compile Mar 30 17:39:37 ERROR: package/rust [host] failed to build. Mar 30 17:58:57 Grommish: https://pastebin.com/HVyyUhh2 Mar 30 19:43:46 Heh. This time I won't be bumping 5.10 to 5.10.27. Mar 30 19:44:39 Not confident enough to manually refresh patches to the bowels of switchdev (net/bridge/br_switchdev.c). Mar 30 19:56:01 ha - funny you should mention that - I'm looking it how spiky it is as well - hhmmmmm! :-) Mar 30 19:57:09 ldir: Welcome to the party, pal. :P Mar 30 19:57:11 I'm also trying to work out what I think about https://forum.openwrt.org/t/opening-taxi-app-oom-reaper-kills-dnsmasq/91052 Mar 30 19:57:47 Ouch. Is dnsmasq leaking…? Mar 30 19:58:38 that has 2 aspects I don't understand/like - 1) how does linux account for memory of forked processes (ie fork only instead of the usual fork/exec) Mar 30 19:58:57 Oh, adblock, I see. That can increase memory usage by *a lot*. Mar 30 19:59:33 is it 'just' a case that add a bit of swap and linux won't worry that it can't potentially page things out. Mar 30 20:00:03 that solves the OOM, which I regard as the smaller problem... the larger problem implied is... Mar 30 20:01:02 a malicious/rogue process on your network can occupy all 20 TCP DNS processing slots (processes!) with something like netcat and denial of service DNS over TCP Mar 30 20:01:23 or am I misunderstanding. Mar 30 20:04:18 rsalvaterra: oh and I should ask...have I just rapidly reversed away from the Nakatomi building in a hail of bullets? :-D Mar 30 20:04:41 You got the reference right! :D Mar 30 20:05:05 Classic Christmas movie :-) Mar 30 20:05:29 Best villain ever! Mar 30 20:06:45 https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q1/014907.html is Simon's view on the issue... and I'm not convinced but then I probably don't understand - and I certainly don't have a magic answer. Mar 30 20:10:15 Wait, dnsmasq forks itself for a new TCP connection when the previous instance is busy…? Mar 30 20:10:38 Did I understand correctly, or am I totally out to lunch (dinner, at this time)? Mar 30 20:12:30 AFAIUI and this goes back to the dawn of dnsmasq time, tcp queries are handled by child processes, I think this is to prevent the stateless UDP main process from blocking due to stateful TCP. Mar 30 20:13:02 Jesus…! So it desperately need a proper event loop… Mar 30 20:13:07 *needs Mar 30 20:13:12 but that is VERY simplistic understanding of a rumour Mar 30 20:26:01 Maybe… I'm not at all familiar with the internals of the thing. But it could use something like libevent/libev… Mar 30 20:26:22 Speaking of libevent… Mar 30 20:26:39 * rsalvaterra wonders if it already implements io_uring support… Mar 30 20:27:04 Hah! Nope. https://github.com/libevent/libevent/issues/1019 Mar 30 20:35:10 ashkan: Are you using MUSL? MUSL is dynamically linked, and I"m showing -static-libstdc++" in your log Mar 30 20:37:15 guidosarducci: The eBPF error in Suricata has to do with the Clang version, I'm being told. I think I'm going to end up having to learn another system. But. mangix, mangix loves Clang and I'm hoping with help ;p Mar 30 20:39:27 ashkan: You should know that it takes a bloody long time to compile Rust toolchain the first time. My basic rebuild without a clean is < 5 minutes.. about 15 with a clean.. On the initial rust build, it took 2 hours just for the rust toolchain Mar 30 20:42:52 ashkan: Do me a favor.. go into menuconfig / lang and select Rust.. I was having issues with that before. Just select it and then build the toolchain separately via make -j1 V=sc package/feeds/packages/rust/host/{clean,compile} Mar 30 20:43:05 ashkan: It works, just isnt ready for repo time for sure Mar 30 20:46:01 ashkan: You should end up with dl/rust-1.50.0-x86_64-openwrt-linux-musl-install.tar.xz Mar 30 20:46:01 and dl/rust-1.50.0-x86_64-unknown-linux-gnu-install.tar.xz once you're done Mar 30 21:33:40 Hi! Mar 30 21:34:05 Can anyone help me understand the MBR used by the u-boot bootloader? It's the MBR of a router. Mar 30 21:34:05 I look at the values in hex, but I can't figure out the structure. Mar 30 21:34:05 Thanks! Mar 30 21:34:05 Adam Mar 30 21:43:55 Why do all columns 0 and 8 start with 0x10? Mar 30 21:43:55 Why is there only real data in columns 3 and 11? Mar 30 21:43:55 Why is there 0x01 in columns 2 and 10 from row 0x00000010? Mar 30 21:43:57 Thanks for your help! Mar 30 21:43:59 0x00000000 10 00 00 FF 00 00 00 00 10 00 00 FD 00 00 00 00 |................| Mar 30 21:44:01 0x00000010 10 00 01 87 00 00 00 00 10 00 01 85 00 00 00 00 |................| Mar 30 21:44:03 0x00000020 10 00 01 83 00 00 00 00 10 00 01 81 00 00 00 00 |................| Mar 30 21:56:00 hadam88: embedded devices normally do not have an MBR Mar 30 21:56:04 MBR is PC specific Mar 30 21:57:01 normally every SoC family uses a difefernt way to load the inital code from flash and expects a different format Mar 30 22:36:16 Hauke: could you please merge two lantiq dsl related PRs? https://github.com/openwrt/openwrt/pull/3524 and https://github.com/openwrt/openwrt/pull/3660 , both are only single small pathes, and I'd say ready to go, it should only take a momemnt of your time! Mar 31 00:13:45 ldir: you're on the right track regarding dnsmasq: it's a memory accounting issue at root, usually manifesting with large blocklists. I was burned by this a few years back and worked through the details, but never had time or knowledge of dnsmasq internals to follow up with the right solution. All the "fixes" I've seen proposed are kludges that just move goalposts without resolving anything. Let me try to reload my memory Mar 31 00:13:45 and post a suggestion to the ML. Or if you know the internals and want to try some changes let me know. Mar 31 02:17:03 Grommish_: can you post your log of the eBPF error? Also curious about the clang version requirement, since it's been quite featureful for years. Mar 31 02:21:54 guidosarducci: I only know what the Suricata folks have told me. That the error issue was referencing the clang --version Mar 31 02:44:21 guidosarducci: I'll look into it more eventually **** ENDING LOGGING AT Wed Mar 31 02:59:56 2021