Davidc502- wrt1200ac wrt1900acx wrt3200acm wrt32x builds

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.

1 Like

@xvello

I went ahead and cranked up snmp, and did a snmp-walk of all the OID's. I don't remember every single one, but it looks like all the OID's are there.

Perhaps some of the values have changed, so have you done a fresh snmp-walk of your router using datadog, so that it can get a look?

@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:

openssl req -x509 -newkey rsa:2048 -sha256 -days 3650 -nodes -keyout /etc/uhttpd.key -out /etc/uhttpd.crt -subj /CN=192.168.2.1 -addext subjectAltName=IP:192.168.2.1

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.

1 Like

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.

Post build -- If you are seeing issues, feel free to post those issues here. However, depending on what the issue is, it will probably need to go to flyspray - https://bugs.openwrt.org/index.php?do=tasklist&project=2

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.

Thanks,

David

5 Likes

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

2 Likes

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 ?

System

Hostname

OpenWrt

Model

Linksys WRT1200AC

Architecture

ARMv7 Processor rev 1 (v7l)

Firmware Version

OpenWrt SNAPSHOT r10077-f54611b06d / LuCI Master (f138fc93)

Kernel Version

4.14.120

Local Time

Mon Jun 17 09:01:35 2019

Uptime

10h 2m 0s

Load Average

0.05, 0.24, 0.14

It's now in master. Not enabled yet by default. You'll have to manually switch to it via the new config option. Good luck and happy testing!

2 Likes

@Shrieram,

Try changing the mode to Wifi Access Point.

1 Like

There are a bunch of people who P.M.'d last night and want to be testers. I will be responding to your requests tonight.

Thank you for volunteering.

David

1 Like

@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.

1 Like

@shm0

I would say this is due to the hardware limitation of the wrt series; none have sfp ports.

thoughts?

1 Like

I will post the log that contains the information about the exception in a few minutes.
//edit
here it is:

Mon Jun 17 16:56:31 2019 kern.warn kernel: [   21.843169] ------------[ cut here ]------------
Mon Jun 17 16:56:31 2019 kern.warn kernel: [   21.847856] WARNING: CPU: 0 PID: 482 at net/netfilter/core.c:398 0xc05f5c64
Mon Jun 17 16:56:32 2019 kern.warn kernel: [   21.854878] Modules linked in: pppoe ppp_async pppox ppp_generic nf_conntrack_netlink iptable_nat ipt_REJECT ipt_MASQUERADE xt_time xt_tcpudp xt_tcpmss xt_statistic xt_state xt_recent xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_helper xt_ecn xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_HL xt_DSCP xt_CT xt_CLASSIFY slhc nfnetlink nf_reject_ipv4 nf_nat_ipv4 nf_log_ipv4 nf_conntrack_rtcache nf_conncount iptable_raw iptable_mangle iptable_filter ipt_ECN ip_tables crc_ccitt act_connmark sch_tbf sch_ingress sch_hfsc em_u32 cls_u32 cls_tcindex cls_route cls_matchall cls_fw cls_flow cls_basic act_skbedit act_mirred mwlwifi mac80211 cfg80211 compat cryptodev ip6table_nat ip6t_NPT ip6t_MASQUERADE nf_nat_ipv6 nf_nat nf_conntrack nf_defrag_ipv6
Mon Jun 17 16:56:32 2019 kern.warn kernel: [   21.926916]  nf_defrag_ipv4 ip6t_rt ip6t_mh ip6t_ipv6header ip6t_hbh ip6t_frag ip6t_eui64 ip6t_ah nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 ifb authenc gpio_button_hotplug
Mon Jun 17 16:56:32 2019 kern.warn kernel: [   21.947925] CPU: 0 PID: 482 Comm: kworker/u4:3 Not tainted 4.19.50 #0
Mon Jun 17 16:56:32 2019 kern.warn kernel: [   21.954399] Hardware name: Marvell Armada 380/385 (Device Tree)
Mon Jun 17 16:56:32 2019 kern.warn kernel: [   21.960351] Workqueue: netns 0xc059ba1c
Mon Jun 17 16:56:32 2019 kern.warn kernel: [   21.964211] Function entered at [<c010f450>] from [<c010b134>]
Mon Jun 17 16:56:32 2019 kern.warn kernel: [   21.970073] Function entered at [<c010b134>] from [<c06c100c>]
Mon Jun 17 16:56:32 2019 kern.warn kernel: [   21.975936] Function entered at [<c06c100c>] from [<c012762c>]
Mon Jun 17 16:56:32 2019 kern.warn kernel: [   21.981798] Function entered at [<c012762c>] from [<c0127760>]
Mon Jun 17 16:56:32 2019 kern.warn kernel: [   21.987660] Function entered at [<c0127760>] from [<c05f5c64>]
Mon Jun 17 16:56:32 2019 kern.warn kernel: [   21.993522] Function entered at [<c05f5c64>] from [<c05f5dcc>]
Mon Jun 17 16:56:32 2019 kern.warn kernel: [   21.999384] Function entered at [<c05f5dcc>] from [<c059af90>]
Mon Jun 17 16:56:32 2019 kern.warn kernel: [   22.005246] Function entered at [<c059af90>] from [<c059bbc0>]
Mon Jun 17 16:56:32 2019 kern.warn kernel: [   22.011108] Function entered at [<c059bbc0>] from [<c013ee28>]
Mon Jun 17 16:56:32 2019 kern.warn kernel: [   22.016970] Function entered at [<c013ee28>] from [<c013f2cc>]
Mon Jun 17 16:56:32 2019 kern.warn kernel: [   22.022832] Function entered at [<c013f2cc>] from [<c0144cdc>]
Mon Jun 17 16:56:32 2019 kern.warn kernel: [   22.028694] Function entered at [<c0144cdc>] from [<c01010e8>]
Mon Jun 17 16:56:32 2019 kern.warn kernel: [   22.034556] Exception stack(0xdec8bfb0 to 0xdec8bff8)
Mon Jun 17 16:56:32 2019 kern.warn kernel: [   22.039634] bfa0:                                     00000000 00000000 00000000 00000000
Mon Jun 17 16:56:32 2019 kern.warn kernel: [   22.047854] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Mon Jun 17 16:56:32 2019 kern.warn kernel: [   22.056074] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000
Mon Jun 17 16:56:32 2019 kern.warn kernel: [   22.062847] ---[ end trace c6aa12c803781f21 ]---

About the sfp patch.
Can someone else confirm that the patch fails to apply?
Turris Omnia has an sfp slot.

I just finished a new build here and that patch applies fine.

Yes, and also the clearfog devices have sfp.

Edit: the only thing that stands out to me is I do not have any of ppp stuff running.

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.

1 Like

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.

1 Like

I'm still needing more volunteers especially with the 1900ac Version 1/V1. Currently I have zero (0) folks signed up to try the new kernel for the V1.

I'm looking for 1900ac V1 owners.

Just message me and let me know you are interested, and I'll send you the link to the downloads.

Thanks,

David

1 Like