OpenWrt Forum Archive

Topic: davidc502 1900ac 3200acm builds

The content of this topic has been archived between 26 Feb 2018 and 7 May 2018. Unfortunately there are posts – most likely complete pages – missing.

Post #2226
starcms
6 Jun 2017, 00:59
klapidus wrote:

I have a wrt1900ac v1 and have found that I have the reboot issue with the 4.9 kernel. I then went to the 4.4 kernel and things seemed to work fine but when I went to install packages like ipset, there was a dependency for the 4.9 kernel. Is this something that can be or already has been fixed?

What repos are you using?  If you are using @david's repos (the default), you shouldn't have this problem (they should be set to download the correct packages unless maybe @david forgot to edit it on the 4.4 kernel version).  If you are using the LEDE snapshot repos, the snapshot branch is based on kernel 4.9.   So any packages that have a dependency on the kernel version (such as ipset) will not install on @david's version running kernel 4.4 (actually even if you are running @david's kernel 4.9, any packages with a dependency on the kernel can't be installed from the LEDE snapshot repo, because the kernels differs very slightly even though they are the same version number)

In LuCi, go to system, software, configuration tab, and make sure the distro feeds look like this (this should be the default settings for @david's r4222 running kernel 4.4:


src/gz reboot_core https://davidc502sis.dynamic-dns.net/snapshots/Kernel_4.4/r4222/targets/mvebu/generic/packages
src/gz reboot_base https://davidc502sis.dynamic-dns.net/snapshots/Kernel_4.4/r4222/packages/arm_cortex-a9_vfpv3/base
src/gz reboot_luci https://davidc502sis.dynamic-dns.net/snapshots/Kernel_4.4/r4222/packages/arm_cortex-a9_vfpv3/luci
src/gz reboot_packages https://davidc502sis.dynamic-dns.net/snapshots/Kernel_4.4/r4222/packages/arm_cortex-a9_vfpv3/packages
src/gz reboot_routing https://davidc502sis.dynamic-dns.net/snapshots/Kernel_4.4/r4222/packages/arm_cortex-a9_vfpv3/routing
src/gz reboot_https://davidc502sis.dynamic-dns.net/snapshots/Kernel_4.4/r4222/packages/arm_cortex-a9_vfpv3/telephony
src/gz reboot_darkmatter https://davidc502sis.dynamic-dns.net/snapshots/Kernel_4.4/r4222/packages/arm_cortex-a9_vfpv3/darkmatter

However, all packages with a dependency on the kernel version are in reboot_core (such as ipset).   So if you want to be able to install ipset, but still keep the majority of packages up to date with the LEDE snapshot/master branch, you can set it to this (this is how I personally keep it) and you won't have any issues either (doing this keeps reboot_core pointing to the default setting @david's repo so that packages depending on the kernel version can still be installed, and the rest to the LEDE snapshot repos so you can get the latest versions that are published between @david's releases.  darkmatter also keeps pointing to @david's because there is no corresponding repo on the LEDE servers).:

src/gz reboot_core https://davidc502sis.dynamic-dns.net/snapshots/Kernel_4.4/r4222/targets/mvebu/generic/packages
src/gz reboot_base https://downloads.lede-project.org/snapshots/packages/arm_cortex-a9_vfpv3/base
src/gz reboot_luci https://downloads.lede-project.org/snapshots/packages/arm_cortex-a9_vfpv3/luci
src/gz reboot_packages https://downloads.lede-project.org/snapshots/packages/arm_cortex-a9_vfpv3/packages
src/gz reboot_routing https://downloads.lede-project.org/snapshots/packages/arm_cortex-a9_vfpv3/routing
src/gz reboot_telephony https://downloads.lede-project.org/snapshots/packages/arm_cortex-a9_vfpv3/telephony
src/gz reboot_darkmatter https://davidc502sis.dynamic-dns.net/snapshots/Kernel_4.4/r4222/packages/arm_cortex-a9_vfpv3/darkmatter

Edit: Those both had a typo. If you saw this post before I posted this note, please re-copy and paste them.

(Last edited by starcms on 6 Jun 2017, 01:22)

Post #2227
klapidus
6 Jun 2017, 04:02
starcms wrote:
klapidus wrote:

I have a wrt1900ac v1 and have found that I have the reboot issue with the 4.9 kernel. I then went to the 4.4 kernel and things seemed to work fine but when I went to install packages like ipset, there was a dependency for the 4.9 kernel. Is this something that can be or already has been fixed?

What repos are you using?  If you are using @david's repos (the default), you shouldn't have this problem (they should be set to download the correct packages unless maybe @david forgot to edit it on the 4.4 kernel version).  If you are using the LEDE snapshot repos, the snapshot branch is based on kernel 4.9.   So any packages that have a dependency on the kernel version (such as ipset) will not install on @david's version running kernel 4.4 (actually even if you are running @david's kernel 4.9, any packages with a dependency on the kernel can't be installed from the LEDE snapshot repo, because the kernels differs very slightly even though they are the same version number)

In LuCi, go to system, software, configuration tab, and make sure the distro feeds look like this (this should be the default settings for @david's r4222 running kernel 4.4:




However, all packages with a dependency on the kernel version are in reboot_core (such as ipset).   So if you want to be able to install ipset, but still keep the majority of packages up to date with the LEDE snapshot/master branch, you can set it to this (this is how I personally keep it) and you won't have any issues either (doing this keeps reboot_core pointing to the default setting @david's repo so that packages depending on the kernel version can still be installed, and the rest to the LEDE snapshot repos so you can get the latest versions that are published between @david's releases.  darkmatter also keeps pointing to @david's because there is no corresponding repo on the LEDE servers).:



Edit: Those both had a typo. If you saw this post before I posted this note, please re-copy and paste them.

Thank you for that....I unfortunately in my haste to get things working again went back to what I was using and did not look at how the repo was configured.  I'll give it a try again and see how it goes. I had to remove the links because it would not let me post.

Post #2228
starcms
6 Jun 2017, 05:42
klapidus wrote:

Thank you for that....I unfortunately in my haste to get things working again went back to what I was using and did not look at how the repo was configured.  I'll give it a try again and see how it goes. I had to remove the links because it would not let me post.

It should have been configured by default as shown in the first set I posted, regardless if you saved settings or not when you "upgraded" builds (.bin file) or if you flashed the 4.4 kernel build from scratch (.img file).  But as I said, it's possible @david made an oversight when he compiled the 4.4 build and didn't change the defaults from the ones in the kernel 4.9 build.  Or you had manually saved/copied the ones from kernel 4.9 build and pasted them into the kernel 4.4 build (why you would do this, I don't know smile )

(Last edited by starcms on 6 Jun 2017, 05:47)

Post #2229
tapper
6 Jun 2017, 09:29

Hi can any one let me know how to fix dns crypt not comming up on boot pleas
I looked at the link posted befor but can't work out what to change.

Post #2230
starcms
6 Jun 2017, 10:45
tapper wrote:

Hi can any one let me know how to fix dns crypt not comming up on boot pleas
I looked at the link posted befor but can't work out what to change.


The bug only exists in version 1.9.5-2.  If you are running 1.9.5-4 like you said you were, then I don't have any idea.  It should be starting automatically on boot.  Are you sure you have the boot/init.d script enabled?  Are you seeing any log entries regarding dnscrypt?  Any log entries regarding an entropy warning?  If you do have log entries regarding an entropy warning, install the package haveged.

(Last edited by starcms on 6 Jun 2017, 11:04)

Post #2233
zabolots
6 Jun 2017, 15:54
davidc502 wrote:

If possible will start building new images tonight.

I just want to thank you for including special builds for WRT1900ACv1 owners with the 4.4.x kernel due to the incompatibility with the 4.9.x kernel.

I really wish someone would be able to find and fix the issue, but until then, these 4.4.x builds are a lifesaver, especially since now even DD-WRT is on the 4.9.x kernel series!

Post #2234
davidc502
6 Jun 2017, 16:32
zabolots wrote:
davidc502 wrote:

If possible will start building new images tonight.

I just want to thank you for including special builds for WRT1900ACv1 owners with the 4.4.x kernel due to the incompatibility with the 4.9.x kernel.

I really wish someone would be able to find and fix the issue, but until then, these 4.4.x builds are a lifesaver, especially since now even DD-WRT is on the 4.9.x kernel series!

No problem, I'll continue building them for V1 owners. As someone who has owned V1, I wouldn't want to be left behind.

Keep in mind, it will probably take me an extra day or so to complete the kernel 4.4.x builds.

*EDIT* There may be some weeks where I won't build a 4.4.x because it's going to depend on if the number of changes warrants a new build.

(Last edited by davidc502 on 6 Jun 2017, 16:35)

Post #2235
btrv
6 Jun 2017, 16:42

Is there a fundamental / long term issue running 4.9 on 1900ACv1 or are the 4.4 builds just needed until the issue gets debugged and resolved?

Post #2236
davidc502
6 Jun 2017, 16:54
btrv wrote:

Is there a fundamental / long term issue running 4.9 on 1900ACv1 or are the 4.4 builds just needed until the issue gets debugged and resolved?

I have not been told any details. However, the feeling is it could be a while.

Has anyone else heard anything?

Post #2237
tapper
6 Jun 2017, 17:03
starcms wrote:
tapper wrote:

Hi can any one let me know how to fix dns crypt not comming up on boot pleas
I looked at the link posted befor but can't work out what to change.


The bug only exists in version 1.9.5-2.  If you are running 1.9.5-4 like you said you were, then I don't have any idea.  It should be starting automatically on boot.  Are you sure you have the boot/init.d script enabled?  Are you seeing any log entries regarding dnscrypt?  Any log entries regarding an entropy warning?  If you do have log entries regarding an entropy warning, install the package haveged.

Hi I don't have any log entries regarding an entropy warning. What happens is when i reboot dnsmasq starts then dnscrypt starts but then stops. I will post a log.
https://www.dropbox.com/s/mkdjho0fzylee … g.txt?dl=0
You will see where i have started it up again.

Post #2238
puppinoo
6 Jun 2017, 17:11
starcms wrote:
puppinoo wrote:
starcms wrote:

radio2 is actually meant to be used for radar detection (DFS).  You should leave it off.

Thanks a lot for advice.
Sorry if I go offtopic but since I dunno when I'll upgrade cause this davidc build seems to works fine I read about the wpad issue. Can I just unistall the full version and install the mini without reconfigure anything or additional operations are needed to make it work?

Thanks and regards.

Yes, just do:

opkg update
opkg remove wpad
opkg install wpad-mini
reboot

That's it.  No reconfiguration of anything needed.  And that's not off topic at all.

EDIT: forget what I just written. dnsmasq-full is there. Do I have to remove the default package and install this one without the risk to break anything?
Can you paste a working configuration if it's not issue?

Thanks a lot. Your help is really useful.
And in fact if you don't mind  I ask you for more.
I'm trying to configure dnscrypt for DNSSEC supporting resolvers.
So far they don't work.
if I choose a non DNSSEC resolver like cisco or the default one it works.
I read I'd need to install dnsmasc-full but there is no such package with that name... I tried to add option dnssec and using 'd0wn-it-ns1' resolver in config/dhcp -> dnssmasq but I receive this error
"cannot read /usr/share/dnsmasq/trust-anchors.conf"
can you advice how I can solve?

Thanks

(Last edited by puppinoo on 6 Jun 2017, 17:17)

Post #2239
kkowrt
6 Jun 2017, 23:12

Did anything change about the ntfs driver in the current build? Getting these errors while trying to auto mount a 4 TB ntfs drive (using block mount or when hotplugging):

Wed Jun  7 00:08:32 2017 kern.err kernel: [   20.874419] ntfs: (device sdb1): parse_ntfs_boot_sector(): Volume size (3TiB) is too large for this architecture.  Maximum supported is 2TiB.  Sorry.
Wed Jun  7 00:08:32 2017 kern.err kernel: [   20.887885] ntfs: (device sdb1): ntfs_fill_super(): Unsupported NTFS filesystem.

That worked fine before. Manually using ntfs-3g works as well.

It seems that somehow the system is not defaulting to ntfs-3g for ntfs drives. This leads to the above error and it also leads (at least in my case) to drives which cannot be shared by samba (for that to work properly they seemingly have to be mounted via ntfs-3g).
Anyone knows how to force use of the ntfs-3g driver? And yes, kmod-fs-ntfs is installed.

(Last edited by kkowrt on 6 Jun 2017, 23:24)

Post #2240
starcms
7 Jun 2017, 04:33
puppinoo wrote:
starcms wrote:
puppinoo wrote:

Thanks a lot for advice.
Sorry if I go offtopic but since I dunno when I'll upgrade cause this davidc build seems to works fine I read about the wpad issue. Can I just unistall the full version and install the mini without reconfigure anything or additional operations are needed to make it work?

Thanks and regards.

Yes, just do:

opkg update
opkg remove wpad
opkg install wpad-mini
reboot

That's it.  No reconfiguration of anything needed.  And that's not off topic at all.

EDIT: forget what I just written. dnsmasq-full is there. Do I have to remove the default package and install this one without the risk to break anything?
Can you paste a working configuration if it's not issue?

Thanks a lot. Your help is really useful.
And in fact if you don't mind  I ask you for more.
I'm trying to configure dnscrypt for DNSSEC supporting resolvers.
So far they don't work.
if I choose a non DNSSEC resolver like cisco or the default one it works.
I read I'd need to install dnsmasc-full but there is no such package with that name... I tried to add option dnssec and using 'd0wn-it-ns1' resolver in config/dhcp -> dnssmasq but I receive this error
"cannot read /usr/share/dnsmasq/trust-anchors.conf"
can you advice how I can solve?

Thanks

You are wayyyy overthinking this.  You shouldn't have dnsmasq-full installed.  If I were you, I would start over with a fresh install of @david's build.  It seems you have installed some things that shouldn't be installed.

dnsmasq-full is not required for DNSSEC if you are using dnscrypt.  You also don't have to add any option to /etc/config/dhcp for DNSSEC if you are using dnscrypt.  Just follow the normal directions for setting up dnscrypt; it doesn't matter if your resolver supports DNSSEC or not, dnscrypt will automatically take care of it.

(Last edited by starcms on 7 Jun 2017, 04:59)

Post #2241
starcms
7 Jun 2017, 04:42
tapper wrote:
starcms wrote:
tapper wrote:

Hi can any one let me know how to fix dns crypt not comming up on boot pleas
I looked at the link posted befor but can't work out what to change.


The bug only exists in version 1.9.5-2.  If you are running 1.9.5-4 like you said you were, then I don't have any idea.  It should be starting automatically on boot.  Are you sure you have the boot/init.d script enabled?  Are you seeing any log entries regarding dnscrypt?  Any log entries regarding an entropy warning?  If you do have log entries regarding an entropy warning, install the package haveged.

Hi I don't have any log entries regarding an entropy warning. What happens is when i reboot dnsmasq starts then dnscrypt starts but then stops. I will post a log.
https://www.dropbox.com/s/mkdjho0fzylee … g.txt?dl=0
You will see where i have started it up again.

Actually, dnscrypt is trying to start the first time way before dnsmasq, near the top of the log you posted.  For some reason, it appears that dnscrypt is loading too early on your router, before it has acquired a WAN IP, and therefore unable to download any certificates.   I'm guessing the reason it starts, stops, and starts again after dnsmasq starts is because you edited /etc/rc.local to get it to start automatically.


First, make sure you delete anything you have added to /etc/rc.local, make sure the dnscrypt-proxy init.d script is enabled, reboot it, check the log.  That should get it working.


Then, if it still doesn't start automatically, try editing /etc/init.d/dnscrypt-proxy and changing START=50 (the very first line) to START=75, and if that doesn't work, try START=99.  Let me know if that gets it starting automatically. 

Did you change the START values on any of the other init.d scripts?  Because dnsmasq should have START=19 and network should be START=20, so with dnscrypt at START=50, it should start at the proper time.  But try setting dnscrypt to 75 or 99 and see if that works...



And finally, if you still can't get it to work after any of that, just disable the dnscrypt-proxy init.d script and add /etc/init.d/dnscrypt-proxy start to /etc/rc.local.

(Last edited by starcms on 7 Jun 2017, 05:10)

Post #2242
listerwrt
7 Jun 2017, 10:13
davidc502 wrote:
btrv wrote:

Is there a fundamental / long term issue running 4.9 on 1900ACv1 or are the 4.4 builds just needed until the issue gets debugged and resolved?

I have not been told any details. However, the feeling is it could be a while.

Has anyone else heard anything?

I've heard very little which makes me think the same thing. I think I remember sera mentioning that it had issues supporting DSA but I can't find it now to back that up and I don't even know if it's in LEDE or relevant to our reboot issues.

Judging from the amount of views/posts in the main thread (before the Armada 385 models released) I'm surprised there aren't more people talking about this issue. Surely they can't all have retired them in favour of newer models in the series?

(Last edited by listerwrt on 7 Jun 2017, 11:32)

Post #2243
zabolots
7 Jun 2017, 13:37
listerwrt wrote:
davidc502 wrote:
btrv wrote:

Is there a fundamental / long term issue running 4.9 on 1900ACv1 or are the 4.4 builds just needed until the issue gets debugged and resolved?

I have not been told any details. However, the feeling is it could be a while.

Has anyone else heard anything?

I've heard very little which makes me think the same thing. I think I remember sera mentioning that it had issues supporting DSA but I can't find it now to back that up and I don't even know if it's in LEDE or relevant to our reboot issues.

Judging from the amount of views/posts in the main thread (before the Armada 385 models released) I'm surprised there aren't more people talking about this issue. Surely they can't all have retired them in favour of newer models in the series?

FYI, I don't think it's just LEDE. The latest DD-WRT build for the WRT1900AC moved to the 4.9.x kernel and that has the same random reboot issue on the v1 as LEDE does.

Post #2244
starcms
7 Jun 2017, 15:43

@david,

As you know I've been running your builds for a very long time now, and never had an issue on my WRT1200AC V1.  However, today I noticed this very odd entry in my log.  However, after the log entries below, the router was still running without issue for over 2 hours until I happened to check to log and reboot it just to be on the safe side. No devices got disconnected, new devices were able to connect, everything was still working perfectly.  I find the message near the top saying "hostapd was not tainted" to be interesting.

What is very odd is that the log entry occurred after the router had been up for almost 3 days.  I hadn't changed anything in those 3 days.  This is on your latest build. 

You can see at the very same second, before all the kernel warnings, a device disconnected.  Nothing else is logged immediately before or after.  So my guess would be the kernel warnings were initiated by hostapd, but afterwards hostapd continued to function normally (even before I rebooted it).  Was it a one time thing that exposed a bug or glitch in the kernel that finally showed itself after hundreds of hours of running in total?  That would be my guess.  Do you have any insight you can add?

Wed Jun  7 08:10:29 2017 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED xx:xx:xx:xx:xx:xx
Wed Jun  7 08:10:29 2017 kern.warn kernel: [214340.121411] ------------[ cut here ]------------
Wed Jun  7 08:10:29 2017 kern.warn kernel: [214340.126218] WARNING: CPU: 1 PID: 2483 at compat-wireless-2017-01-31/net/mac80211/agg-tx.c:347 ___ieee80211_stop_tx_ba_session+0x1c0/0x1dc [mac80211]
Wed Jun  7 08:10:29 2017 kern.warn kernel: [214340.139674] Modules linked in: pppoe ppp_async pppox ppp_generic nf_nat_pptp nf_conntrack_pptp nf_conntrack_ipv6 iptable_nat ipt_REJECT ipt_MASQUERADE xt_time xt_tcpudp xt_tcpmss xt_statistic xt_state xt_recent xt_policy xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_helper xt_esp 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 ums_usbat ums_sddr55 ums_sdd
Wed Jun  7 08:10:29 2017 kern.warn kernel: [214340.211631]  nf_conntrack_snmp nf_conntrack_sip nf_conntrack_rtcache nf_conntrack_proto_gre nf_conntrack_irc nf_conntrack_h323 nf_conntrack_broadcast ts_kmp nf_conntrack_amanda mwifiex_sdio mwifiex iptable_mangle iptable_filter ipt_ah ipt_ECN ip_tables crc_ccitt fuse sch_cake em_nbyte act_ipt cls_basic sch_prio sch_pie sch_gred em_meta sch_dsmark sch_teql em_cmp act_police em_text sch_codel sch_sfq sch_fq sch_red act_connmark nf_conntrack act_skbedit act_mirre
Wed Jun  7 08:10:29 2017 kern.warn kernel: [214340.289049] CPU: 1 PID: 2483 Comm: hostapd Not tainted 4.9.30 #0
Wed Jun  7 08:10:29 2017 kern.warn kernel: [214340.295167] Hardware name: Marvell Armada 380/385 (Device Tree)
Wed Jun  7 08:10:29 2017 kern.warn kernel: [214340.301212] [<c0016010>] (unwind_backtrace) from [<c0012220>] (show_stack+0x10/0x14)
Wed Jun  7 08:10:29 2017 kern.warn kernel: [214340.309080] [<c0012220>] (show_stack) from [<c020f9dc>] (dump_stack+0x7c/0x9c)
Wed Jun  7 08:10:29 2017 kern.warn kernel: [214340.316423] [<c020f9dc>] (dump_stack) from [<c00291c4>] (__warn+0xbc/0xec)
Wed Jun  7 08:10:29 2017 kern.warn kernel: [214340.323415] [<c00291c4>] (__warn) from [<c0029298>] (warn_slowpath_null+0x1c/0x24)
Wed Jun  7 08:10:29 2017 kern.warn kernel: [214340.331136] [<c0029298>] (warn_slowpath_null) from [<bf124b88>] (___ieee80211_stop_tx_ba_session+0x1c0/0x1dc [mac80211])
Wed Jun  7 08:10:29 2017 kern.warn kernel: [214340.342207] [<bf124b88>] (___ieee80211_stop_tx_ba_session [mac80211]) from [<bf124f50>] (__ieee80211_stop_tx_ba_session+0x2c/0x40 [mac80211])
Wed Jun  7 08:10:29 2017 kern.warn kernel: [214340.355100] [<bf124f50>] (__ieee80211_stop_tx_ba_session [mac80211]) from [<bf123c6c>] (ieee80211_sta_tear_down_BA_sessions+0x38/0x6c [mac80211])
Wed Jun  7 08:10:29 2017 kern.warn kernel: [214340.368339] [<bf123c6c>] (ieee80211_sta_tear_down_BA_sessions [mac80211]) from [<bf11b638>] (ieee80211_sta_eosp+0x1e4/0x51c [mac80211])
Wed Jun  7 08:10:29 2017 kern.warn kernel: [214340.380705] [<bf11b638>] (ieee80211_sta_eosp [mac80211]) from [<bf11e36c>] (__sta_info_destroy+0xc/0x28 [mac80211])
Wed Jun  7 08:10:29 2017 kern.warn kernel: [214340.391327] [<bf11e36c>] (__sta_info_destroy [mac80211]) from [<bf11e3f8>] (sta_info_destroy_addr_bss+0x2c/0x44 [mac80211])
Wed Jun  7 08:10:29 2017 kern.warn kernel: [214340.402640] [<bf11e3f8>] (sta_info_destroy_addr_bss [mac80211]) from [<bf0e4dec>] (nl80211_del_station+0xe8/0xf0 [cfg80211])
Wed Jun  7 08:10:29 2017 kern.warn kernel: [214340.414018] [<bf0e4dec>] (nl80211_del_station [cfg80211]) from [<c03c617c>] (genl_rcv_msg+0x288/0x310)
Wed Jun  7 08:10:29 2017 kern.warn kernel: [214340.423454] [<c03c617c>] (genl_rcv_msg) from [<c03c5530>] (netlink_rcv_skb+0x58/0xb4)
Wed Jun  7 08:10:29 2017 kern.warn kernel: [214340.431406] [<c03c5530>] (netlink_rcv_skb) from [<c03c5ee0>] (genl_rcv+0x20/0x34)
Wed Jun  7 08:10:29 2017 kern.warn kernel: [214340.439008] [<c03c5ee0>] (genl_rcv) from [<c03c4f34>] (netlink_unicast+0x138/0x1fc)
Wed Jun  7 08:10:29 2017 kern.warn kernel: [214340.446786] [<c03c4f34>] (netlink_unicast) from [<c03c53a0>] (netlink_sendmsg+0x2f0/0x310)
Wed Jun  7 08:10:29 2017 kern.warn kernel: [214340.455176] [<c03c53a0>] (netlink_sendmsg) from [<c0380238>] (sock_sendmsg+0x14/0x24)
Wed Jun  7 08:10:29 2017 kern.warn kernel: [214340.463130] [<c0380238>] (sock_sendmsg) from [<c03807c8>] (___sys_sendmsg+0x184/0x228)
Wed Jun  7 08:10:29 2017 kern.warn kernel: [214340.471170] [<c03807c8>] (___sys_sendmsg) from [<c0381564>] (__sys_sendmsg+0x40/0x64)
Wed Jun  7 08:10:29 2017 kern.warn kernel: [214340.479124] [<c0381564>] (__sys_sendmsg) from [<c000ed40>] (ret_fast_syscall+0x0/0x3c)
Wed Jun  7 08:10:29 2017 kern.warn kernel: [214340.487185] ---[ end trace def41b7bd46a6c69 ]---

(Last edited by starcms on 7 Jun 2017, 16:03)

Post #2245
btrv
7 Jun 2017, 16:01
davidc502 wrote:
btrv wrote:

Is there a fundamental / long term issue running 4.9 on 1900ACv1 or are the 4.4 builds just needed until the issue gets debugged and resolved?

I have not been told any details. However, the feeling is it could be a while.

Has anyone else heard anything?

Is the current V1 build a 4.4 or 4.9 build? - it's listed under 4.9.  Is there a 4.4 build you would recommend as the most stable / worth sticking with until things get settled.

Post #2247
puppinoo
7 Jun 2017, 20:28
starcms wrote:
puppinoo wrote:
starcms wrote:

Yes, just do:

opkg update
opkg remove wpad
opkg install wpad-mini
reboot

That's it.  No reconfiguration of anything needed.  And that's not off topic at all.

EDIT: forget what I just written. dnsmasq-full is there. Do I have to remove the default package and install this one without the risk to break anything?
Can you paste a working configuration if it's not issue?

Thanks a lot. Your help is really useful.
And in fact if you don't mind  I ask you for more.
I'm trying to configure dnscrypt for DNSSEC supporting resolvers.
So far they don't work.
if I choose a non DNSSEC resolver like cisco or the default one it works.
I read I'd need to install dnsmasc-full but there is no such package with that name... I tried to add option dnssec and using 'd0wn-it-ns1' resolver in config/dhcp -> dnssmasq but I receive this error
"cannot read /usr/share/dnsmasq/trust-anchors.conf"
can you advice how I can solve?

Thanks

You are wayyyy overthinking this.  You shouldn't have dnsmasq-full installed.  If I were you, I would start over with a fresh install of @david's build.  It seems you have installed some things that shouldn't be installed.

dnsmasq-full is not required for DNSSEC if you are using dnscrypt.  You also don't have to add any option to /etc/config/dhcp for DNSSEC if you are using dnscrypt.  Just follow the normal directions for setting up dnscrypt; it doesn't matter if your resolver supports DNSSEC or not, dnscrypt will automatically take care of it.


big_smile

https://image.ibb.co/hWUD5v/dnssec.png

Post #2248
starcms
7 Jun 2017, 21:22
puppinoo wrote:

big_smile

https://image.ibb.co/hWUD5v/dnssec.png

Congrats!  Told you it was easy smile

Post #2249
puppinoo
7 Jun 2017, 21:29
starcms wrote:
puppinoo wrote:

big_smile

https://image.ibb.co/hWUD5v/dnssec.png

Congrats!  Told you it was easy smile

hehe... it was a bit tricky cause I needed it to work behind a VPN.
If anyone interested now it's much easier with latest OpenVPN version cause 2.4 supports selective push ignore.
I just had to add this directive so I can ignore dns server pushed buit still accept the redirect gateway.

pull-filter ignore "dhcp-option DNS "
( option pull_filter 'ignore "dhcp-option DNS "' for LEDE syntax )
So you can reroute your traffic but still use a DNS server of your choice.

Thanks for help.

(Last edited by puppinoo on 7 Jun 2017, 21:30)

Post #2250
eliaspizarro
7 Jun 2017, 21:41

I read this forum but i think there is no anwser for the problem: wlan1 (2.4Ghz) signal drops randomly.

Model: WRT1200ac V2
Firmware: Lede Reboot SNAPSHOT r4222-7142cb4 / LuCI Master (git-17.145.19303-ee6110b)

system log

Wed Jun  7 16:28:44 2017 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED 00:4f:78:01:e8:16
Wed Jun  7 16:28:44 2017 daemon.info hostapd: wlan1: STA 00:4f:78:01:e8:16 IEEE 802.11: disassociated
Wed Jun  7 16:28:45 2017 daemon.info hostapd: wlan1: STA 00:4f:78:01:e8:16 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Wed Jun  7 16:29:29 2017 daemon.info hostapd: wlan1: STA 00:4f:78:01:e8:16 IEEE 802.11: authenticated
Wed Jun  7 16:29:29 2017 daemon.info hostapd: wlan1: STA 00:4f:78:01:e8:16 IEEE 802.11: associated (aid 2)
Wed Jun  7 16:29:30 2017 daemon.notice hostapd: wlan1: AP-STA-CONNECTED 00:4f:78:01:e8:16
Wed Jun  7 16:29:30 2017 daemon.info hostapd: wlan1: STA 00:4f:78:01:e8:16 RADIUS: starting accounting session 483F85DE27B868DD
Wed Jun  7 16:29:30 2017 daemon.info hostapd: wlan1: STA 00:4f:78:01:e8:16 WPA: pairwise key handshake completed (RSN)
Wed Jun  7 16:29:52 2017 daemon.info hostapd: wlan1: STA 00:4f:78:01:e8:16 WPA: group key handshake completed (RSN)
Wed Jun  7 16:29:52 2017 daemon.info hostapd: wlan1: STA 20:82:c0:3f:27:47 WPA: group key handshake completed (RSN)
Wed Jun  7 16:31:14 2017 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED 00:4f:78:01:e8:16
Wed Jun  7 16:31:14 2017 daemon.info hostapd: wlan1: STA 00:4f:78:01:e8:16 IEEE 802.11: disassociated
Wed Jun  7 16:31:15 2017 daemon.info hostapd: wlan1: STA 00:4f:78:01:e8:16 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Wed Jun  7 16:32:04 2017 daemon.info hostapd: wlan1: STA 00:4f:78:01:e8:16 IEEE 802.11: authenticated
Wed Jun  7 16:32:04 2017 daemon.info hostapd: wlan1: STA 00:4f:78:01:e8:16 IEEE 802.11: associated (aid 2)
Wed Jun  7 16:32:04 2017 daemon.notice hostapd: wlan1: AP-STA-CONNECTED 00:4f:78:01:e8:16
Wed Jun  7 16:32:04 2017 daemon.info hostapd: wlan1: STA 00:4f:78:01:e8:16 RADIUS: starting accounting session B14B7DB15180E11A
Wed Jun  7 16:32:04 2017 daemon.info hostapd: wlan1: STA 00:4f:78:01:e8:16 WPA: pairwise key handshake completed (RSN)

Kernel Log

[ 5149.572385] br-lan: port 3(wlan1) entered blocking state
[ 5149.577739] br-lan: port 3(wlan1) entered disabled state
[ 5149.583228] device wlan1 entered promiscuous mode
[ 5154.588516] ieee80211 phy1: change: 0x100
[ 5154.601575] ieee80211 phy1: change: 0x40
[ 5154.775071] ieee80211 phy1: change: 0x40
[ 5154.945073] ieee80211 phy1: change: 0x40
[ 5155.115076] ieee80211 phy1: change: 0x40
[ 5155.285063] ieee80211 phy1: change: 0x40
[ 5155.455116] ieee80211 phy1: change: 0x40
[ 5155.625070] ieee80211 phy1: change: 0x40
[ 5155.795057] ieee80211 phy1: change: 0x40
[ 5155.965057] ieee80211 phy1: change: 0x40
[ 5156.135054] ieee80211 phy1: change: 0x40
[ 5156.305050] ieee80211 phy1: change: 0x40
[ 5156.475066] ieee80211 phy1: change: 0x100
[ 5156.552999] ieee80211 phy1: change: 0x100
[ 5156.565046] ieee80211 phy1: change: 0x42
[ 5156.687082] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
[ 5156.693534] br-lan: port 3(wlan1) entered blocking state
[ 5156.698880] br-lan: port 3(wlan1) entered forwarding state
[ 5560.231540] device wlan0 left promiscuous mode
[ 5560.236068] br-lan: port 2(wlan0) entered disabled state
[ 5560.427289] ieee80211 phy0: change: 0x40
[ 5560.497253] ieee80211 phy0: change: 0x100
[ 5560.987295] ieee80211 phy0: change: 0xffffffff
[ 5561.066451] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 5561.073825] br-lan: port 2(wlan0) entered blocking state
[ 5561.079179] br-lan: port 2(wlan0) entered disabled state
[ 5561.084739] device wlan0 entered promiscuous mode
[ 5561.089527] br-lan: port 2(wlan0) entered blocking state
[ 5561.094889] br-lan: port 2(wlan0) entered forwarding state
[ 5561.520470] br-lan: port 2(wlan0) entered disabled state
[ 5566.101077] ieee80211 phy0: change: 0x100
[ 5566.114166] ieee80211 phy0: change: 0x40
[ 5566.310125] ieee80211 phy0: change: 0x40
[ 5566.490131] ieee80211 phy0: change: 0x100
[ 5566.568697] ieee80211 phy0: change: 0x100
[ 5566.580126] ieee80211 phy0: change: 0x42
[ 5566.717136] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 5566.723606] br-lan: port 2(wlan0) entered blocking state
[ 5566.728945] br-lan: port 2(wlan0) entered forwarding state
[ 5927.475841] device wlan1 left promiscuous mode
[ 5927.480357] br-lan: port 3(wlan1) entered disabled state
[ 5927.550783] ieee80211 phy1: change: 0x40
[ 5927.604784] ieee80211 phy1: change: 0x100
[ 5929.107729] ieee80211 phy1: change: 0xffffffff
[ 5929.171949] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
[ 5929.178967] br-lan: port 3(wlan1) entered blocking state
[ 5929.184309] br-lan: port 3(wlan1) entered disabled state
[ 5929.189825] device wlan1 entered promiscuous mode
[ 5934.260786] ieee80211 phy1: change: 0x100
[ 5934.273845] ieee80211 phy1: change: 0x42
[ 5934.395650] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
[ 5934.402112] br-lan: port 3(wlan1) entered blocking state
[ 5934.407468] br-lan: port 3(wlan1) entered forwarding state

Some info about wlan1:

config wifi-device 'radio1'
        option type 'mac80211'
        option hwmode '11g'
        option path 'soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0'
        option country 'CL'
        option channel '6'
        option htmode 'HT20'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option mode 'ap'
        option macaddr '62:38:e0:06:35:7c'
        option ssid 'GuaiFai'
        option encryption 'psk2+ccmp'
        option key '**************************'
        option network 'lan'
        option disassoc_low_ack '0'

(Last edited by eliaspizarro on 7 Jun 2017, 21:42)