I'm using the datadog agent, and the network check fails because it's failing to access /proc/net/snmp. It also fails to list running processes, but I haven't dug up why.
The prometheus exporter also uses this pseudo-file, and others might. What's pretty troubling here is that /proc/net/snmp6 was not removed
I'm just briefly looking over what look like OID's for snmp6 and doesn't appear running processes is listed in the set. It could be why you can't find it.
Before I remove this patch, would you be willing to talk to the contributers of the patch OR put in a bug report that SNMP is not working properly since the patch?
There are a lot of people who use SNMP and I'm sure you are not the only one affected by this.
@treefiddy yeah I understand that lol. Multiple devices would be a pain. I also tried to disable https completely but sadly it won't allow me to log in if https is disabled. So I have to make a valid SSL cert.
I did it by using:
Change both IPs to your router's IP. Run this on your router if you have openssl installed or another pc with openssl. The command will generate the certificate and private key you need.
If you run it on another pc, you need to upload them to openwrt at services -> uHTTPd.
Then restart uhttpd: /etc/init.d/uhttpd restart.
Also install the certificate to windows trusted root CA store.
Restart Chrome and all the warnings should be gone.
At least that's how I did it.
From what I'm reading Kernel 4.19 is just around the corner. Since we know from experience kernel changes like this can cause inadvertent issues, I would like to ask for volunteers first.
If you are interested in being a tester for kernel 4.19, please send me a private message, and I will instant message you back with the link. Also, please provide what version of the hardware you have.
At this point, the kernel bump has not yet happened for master branch, but I will announce it when I see the change, and will begin building new images probably after that day or so.
So, if you I.M. me before the build is ready, I will confirm I have your request, and will message you again when the build is ready.
Fortunately we have experts who monitor this thread, that will likely be helpful in helping to determine if it should go to a bug report or not. Even if we don't hear an opinion stating one way or the the other, everyone can still report a bug because the worse thing that can happen is the case is closed.
I'm not really expecting many problems, but feel if there is going to be problems will likely be associated with the V1 hardware. So, v1 owners are especially welcome to test the new kernel out.
Dear treefiddy,
Hello and I hope that all is well. I just put up a Let's Encrypt Tutorial / How To for DuckDNS and I imagine you can modify those instructions to fit your DDNS preferred service if you wish to. Here is the link to the topic on the main OpenWrt Forum:
I hope that this helps as I know what it is like to struggle with the issue that you are dealing with. Hopefully this assists others as well. Happy Father's Day To All
Hi @davidc502, I installed the latest dc502 firmware on my Linksys wrt1200ac v2 [Caimen] and the 5ghz wifi doesn't seem to work at all. I did perform factory reset and tried changing the channel from 36 to >100 & vice versa. Nothing seem to help bring up the 5ghz wifi. Please find the screenshots. Can you help ?
@ParanoidZoid
The commit you linked about the config change.
By default all namespaces are toggled on now?
Cause the network namespace throws an expection on my system.
procd-ujail doesn't rely on the network (and user) namespace anyway.
I assume those can be safely disabled?
Seems to work fine, i can see that dnsmasq is in ujail now.
And the 4.19 bump in master works fine so far expect that patch
407-sfp-display-SFP-module-information.patch
fails to apply.
How does that exception manifest? I have been running with namespaces enabled for a couple of years on wrtpac devices (including network) and have not seen any issues.
Damn.
While merging the changes into my branch, something screwed and the result was a the same patch twice in my patch directory. I also did a git diff --name-only between the branches...
I apologize x)
But for the network namespace exception, i don't know.
Shouldn't the same patch twice have caused quilt to quit and the build process to stop?
And yes, all the namespaces are activated on !SMALL_FLASH devices. UTS, IPC, USER_NS, PID_NS, and NET_NS.
And yeah, I guess ujail doesn't rely on all of them (only UTS, IPC, & PID). The others are probably there for LXC support.
I also am not sure about the ppp stuff. I don't run it myself. However, just searching up "ppp reboots" shows that some users have experienced problems ever since the switch from 2.4.7 (in 18.06) to git commits (in 19.07 & Master).
EDIT: What processes were running above the "cut here" line? My bootup process only lasts around 15 seconds, with wlan0 enabling itself at 80 seconds due to DFS.
Now that the kernel 4.19 commit as gone in for mvebu today, anyone know what features/benefits we can expect? Don't think there is anything specific just curious.
For one, there are a lot of mvneta fixes and improvements (and in particular with <256MB RAM). Even though mvebu still runs swconfig, changes in mvneta still somewhat affect the switch.