What's new

[Solved] AC86U - possible memory leaks. AiProtection(dcd) crashing is guilty

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

PeterV

Regular Contributor
Hi.
I have an issue on my AC86U - after some period of time the cpu consumption by [usb-storage] process start growing
usb-storage.PNG
After that the dhcp (i.e. dnsmasq) is going to be unresponcible, due to I use diversion, which was dependent on usb performance, where blacklists are located.
The simple solution - it is to reboot the router, but owners of AC86 bery well know - some times it's stuck during reboot.
That's why I am trying to find another way to do something ...
And now is my question:
Is it possible to make a script with behavior similar to
Code:
eject /dev/sdb; sleep 1; eject -t /dev/sdb
on Ubuntu/Debian.
I know, I can to run
Code:
ejusb
, it will be similar to
Code:
eject
, but I don't know, is it exists some commands similar to
Code:
eject -t
.

P.S. It's independent from FW version. At least I faced with it on 384.8.2 and 384.9 ...

P.P.S.
System brief description:
  • AC86U with Merlin FW (384.8.2 and 384.9);
  • After FW installation/upgrade/downdgrade the usual reset was done (for both versions), including JFFS format and manual configuration the router (no any NVRAM or setting backup/restore).
  • USB3 usb stick
  • Entware
  • amtm, Diversion (with logging), Stubby, SkyNet, and FreshJR QOS was installed.
  • Swap enabled.
  • All asus services was disabled, except trendmicro security services.
  • So, no any, non router related services in-place.
  • Zabbix-agent is installed for monitoring purposes.
  • No any filesystems or read/write related errors in system log.
System behavior:
  • From 2 to 7 days of stable work with 0% of CPU consumption by system process named [usb_storage].
  • Some reasonable peaks at the scheduled task, like Diversion log rotation, statistics gathering and my backup scripts (no more that 1%).
  • Accidentally the CPU consumption by [usb_storage] peaks up to 2-2,5%% going to happen very often, at the time 100% not related to any scheduled tasks.
  • And later it’s not a peaks, but a stable CPU consumption (above 1%), not returned to the usual 0%.
  • In the same time iowait is growing up to 60-70%.
  • Fast workaround – disabling Diversion, it make the router at least responsible on the dhcp requests and from the interfaces (http and ssh), but don’t solve the issue.
  • Only reboot can solve, but, as I said – only for a limited, unpredictable period of time.
Under suspicion:
  • USB3 port. Checked, the same behavior on USB2
  • The USB stick. Can’t understand a reason … If it going to die – why reboot is helped? Will try with replacing by unused SSD drive, when appropriate adapter will be delivered.
  • Out of memory / active swap usage – possible, but in this case – no solution, except to limit some functionality, i.e. disable Diversion logging, or remove the Diversion tiself.
  • Router issue – the worst root cause.

Why I’ asking for the eject – insert SW functionality – it’s because the AC86U has well know bag with reboot -accidentally, unpredictable it will stuck during reboot form the cron, shell, etc …
 
Last edited:
Apologies, but I don't speak Linux, maybe someone who does can offer you an answer. I have been using my 86U since November with no issues. I rarely reboot unless it's necessary. When I do I haven't had any problems. Last reboot was 28 days and 17 hours ago. Some people have reported issues with the 86U but I guess I lucked out and mine was purchased used on Ebay. It's been very reliable and stable just like the 68U it replaced. Currently using Merlin 384.9.
 
PeterV, when was the last time you did a full a proper reset to factory defaults?

Your symptoms are very specific to your setup it seems and points to the fact that a full M&M config may fix this for you. Please see the links below in my signature for details or give us more information about how you set up your router/network.
 
PeterV, when was the last time you did a full a proper reset to factory defaults?

Your symptoms are very specific to your setup it seems and points to the fact that a full M&M config may fix this for you. Please see the links below in my signature for details or give us more information about how you set up your router/network.
My new one AC86U was setup from scratch as a replacement for my old one RT-N66U.
It has running 384.8.2 version of Asuswrt-Merlin.
It has installed on : Entware, amtm, Diversion, Skynet, Stubby and FreshJR QOS.
May be the root cause of an issue is USB3 port. I will try to check it, by changing a location of the USB stick.
 
My new one AC86U was setup from scratch as a replacement for my old one RT-N66U.
It has running 384.8.2 version of Asuswrt-Merlin.
It has installed on : Entware, amtm, Diversion, Skynet, Stubby and FreshJR QOS.
May be the root cause of an issue is USB3 port. I will try to check it, by changing a location of the USB stick.

That did not answer my question though. :)

I am taking an educated guess that you did not perform a proper reset to factory defaults followed by an M&M config after you flashed the RMerlin firmware.

This is almost always required when flashing from stock to custom, as it is in this case too.

Remove the USB stick. Format the jffs partition on next boot, reboot the router 3 times waiting for 5 or 10 minutes minimum between boots. Reset to factory defaults after installing the firmware you want to use or test. Then, perform a minimal and manual configuration to secure the router and connect to your ISP.

After sufficient testing at this base level, add changes one or two at a time and keep good notes. This is how you will catch what causes this issue for you. If the above steps don't resolve it first. :)
 
That did not answer my question though. :)

I am taking an educated guess that you did not perform a proper reset to factory defaults followed by an M&M config after you flashed the RMerlin firmware.

This is almost always required when flashing from stock to custom, as it is in this case too.

Remove the USB stick. Format the jffs partition on next boot, reboot the router 3 times waiting for 5 or 10 minutes minimum between boots. Reset to factory defaults after installing the firmware you want to use or test. Then, perform a minimal and manual configuration to secure the router and connect to your ISP.

After sufficient testing at this base level, add changes one or two at a time and keep good notes. This is how you will catch what causes this issue for you. If the above steps don't resolve it first. :)
Dear L&LD, to close the topic with "proper" preparation: Yes, I made a full reset. With wiping the jffs, and all other usual things. An it was done 2 weeks before I made the first post in this thread ...
I know all these procedures, if you paid small attention - I'm on this forum from the same time, as you.

And, returning to the my problem:
Switching the location of the USB stick from USB3 to USB2 port doesn't help. Today morning, after 4 days - the issue with usb_storage is returned.
There is a graph of usb_storage cpu usage: usbstorage.PNG
And iowait, as result is growing up to enormous values:iowait.PNG
Router is fully inaccessible, so - I pressed the button ...

Next ideas - to disable logging in dnsmasq (Diversion), and to replace USB stick with ssd drive (I have one unused) ...
P.S. Yes, with full resets after changing the drive ....
P.P.S. May be someone have an idea howto made a software "eject-insert" action , similar to the "eject /dev/sdb; sleep 1; eject -t /dev/sdb" in Ubuntu/Debian. I can made ejusb , but I don't know the software way to say the system - USB is again inserted ...
P.P.P.S. Third,worst, one idea - to replace the router, may be it's a HW issue ...
 
If you have DLNA enabled on the usb drive, minidlna can spin if it encounters a corrupt or unknown file during it's scan. Checking the dlna log file on the usb drive may provide a clue.
 
If you have DLNA enabled on the usb drive, minidlna can spin if it encounters a corrupt or unknown file during it's scan. Checking the dlna log file on the usb drive may provide a clue.

Thanks for the idea. Excuse me for poor descibing of the current setup.
No DLNA, no filesharing, no any "non router" related tasks.

P.S. I made the first post update with more details.
 
Last edited:
Regarding this issue I more/or less found the root cause - it's my mistake in configuration, exactly - in DNSFilter.
It has wrong address for the routing all DNS request, really non existent address.
 
But I still have some strange issues ...

As I described - I have the Stubby in place. Due to previously I had some issues, when it lost connections to the upstream, I made a monitoring script via drill to check the responses directly from the stubby, to avoid influence of dnsmasq.
That is why I use drill (or it can be dig) to made a dns query on exact port (5453). It was scheduled via monit daemon.
Nothing special, only query of the A type record for the name one.one.one.one. And checking the result via grep, due to drill don't return error exit code on empty answer (i.e. no A records found by some reason).
And yesterday I faced with strange problem - I so in the monit log the message
Code:
Error: error sending query: Error creating socket
.
To be sure - it's message from the "client" program, i.t. it's doesn't use any specific port, and usually open a local socket on the port above 1024 ...
In the parallel any othel local command related to tcp/ip can't start with the similar error or behavior.
So, it's look like - not free socket ? The Google search didn't help, due to the most of such messages related to the server processes, it depend on the already used exact port (like 53 for dns , or 80 - for http).
The reboot is solved the problem, but ...

So, the questions are:
  • What can be a root cause of such error ?
  • Is it some how related to the open files/descriptors limit in the linux? (Now it is monitored, at least).
  • If it some how related to the amount of the max possible connection (low probability, due to the quite high limit - 300000)
  • How I can monitor the all connections, not only local via nestat and other related /proc "files" ?
    Currently I know where I can read the limit (/proc/sys/net/netfilter/nf_conntrack_max), where the total current (/proc/sys/net/netfilter/nf_conntrack_count), but I don't know how to get the Active count, to gather the equal to the Tools/Sysinfo page stats Connections 3111 / 300000 - 612 active.
P.S. "Cleaning procedure" for the router already scheduled on Saturday evening, when my wife are going to the theater.
 
B
  • How I can monitor the all connections, not only local via nestat and other related /proc "files" ?
    Currently I know where I can read the limit (/proc/sys/net/netfilter/nf_conntrack_max), where the total current (/proc/sys/net/netfilter/nf_conntrack_count), but I don't know how to get the Active count, to gather the equal to the Tools/Sysinfo page stats Connections 3111 / 300000 - 612 active.
It's always the best to answer on the own question:
It can be monitored via /proc/net/nf_conntrack , as it currently made in httpd module sysinfo :
Code:
cat /proc/net/nf_conntrack | grep -i -E '(established|udp).*assured' -c
 
After long time testing after full reset and M&M config with fixed firmware version(384.10_beta3) I'm 99,9% sure - the issue is on a kernel level.
Maximum time of the normal work currently is about 22-26 days.
Some around that uptime the free (and especially) cache size of memory is decreased to a too small for the normal and stable work value.
After that any read operation from usb use a lot of CPU (>50% iowait).
There are a graps with:
uptime: chart_uptime.png
iowait: chart_iowait.png
memory: chart_memory.png

The evening April 15th is a date, when it was fully unresponsible, with big delays on dhcp requests.
Disabling the all services (except core) didn't solve the issue.
Only a manual reboot helped.

Stopping the "additional" services wasn't free a memory.
And you can see a stable tendency of the cache, buffers and free memory decreasing.
From yesterday I added the /proc/meminfo data monitoring - especially slabs.
And the slab has a strong tendency to grow: chart_meminfo.png
And there is a slabtop -o:
Code:
sysop@RT-AC86U-4640:/tmp/mnt/entware/home/root# slabtop -o
 Active / Total Objects (% used)    : 1173276 / 1195378 (98.2%)
 Active / Total Slabs (% used)      : 27539 / 27542 (100.0%)
 Active / Total Caches (% used)     : 71 / 113 (62.8%)
 Active / Total Size (% used)       : 229922.78K / 234037.24K (98.2%)
 Minimum / Average / Maximum Object : 0.02K / 0.20K / 4096.00K

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
1035531 1031808  99%    0.06K  16437       63     65748K kmalloc-64
103788 100320  96%    0.12K   3348       31     13392K kmalloc-128
  8250   8099  98%    0.12K    250       33      1000K kernfs_node_cache
  6256   3794  60%    0.17K    272       23      1088K vm_area_struct
  4767   2809  58%    0.19K    227       21       908K kmalloc-192
  4256   2262  53%    0.07K     76       56       304K anon_vma
  4116   2332  56%    0.19K    196       21       784K dentry
  3582   2875  80%    0.43K    398        9      1592K nf_conntrack_1
  3072   2028  66%    0.25K    192       16       768K kmalloc-256
  2720   2247  82%    0.50K    340        8      1360K kmalloc-512
  1819   1817  99%    8.00K   1819        1     14552K kmalloc-8192
  1617    670  41%    0.56K    231        7       924K radix_tree_node
  1603   1603 100%   64.00K   1603        1    102592K kmalloc-65536

And I have no tools to dig inside the kmalloc's.

Resume: it's a not bad router, but it has strong requirement to have a periodical reboot.
I hope the last fixed by RMerlin will give this possibility to the stable and predictable reboot (without freezing on shutdown state)
 
As usual - the root cause is on surface, in plain view.
- KNOWN ISSUE: dcd process crashing on RT-AC86U (bug in Trend
Micro's code, outside of my control).
It's a reason of constantly increasing Unreclaimable Slab area in system memory.
After switching off the AiProtection - no any memory leaks, the memory is available enough, and the situation is stable.
chart_meminfo_0625.png
Will wait until Asus will fix the issue.
And now I can remove weekly reboot from a cron.
 
And now I can remove weekly reboot from a cron.

If the memory gets freed by disabling AiProtection, I guess your cron job could simply stop/start the AiProtection services to free up the memory, until either Asus or Trend Micro address the issue.
 
I have a LOG TAIL of DCD crashing . TAKE A LOOK:(Removed mac address...pixelserv ip: 192.168.1.2 after it gets to br0:pixelserv-tls ... it crashes )

Code:
Jun 25 21:36:52 dcd[12235]: [pctrl_func(917)] do_pctrl ret = 0
Jun 25 21:36:59 dcd[12235]: [get_cpu_info(94)] processor    : 0 BogoMIPS    : 100.00 Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 CPU implementer    : 0x42 CPU architecture: 8 CPU variant    : 0x0 CPU part    : 0x100 CPU revision    : 0  processor    : 1 BogoMIPS    : 100.00 Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 CPU implementer    : 0x42 CPU architecture: 8 CPU variant    : 0x0 CPU part    : 0x100 CPU revision    : 0
Jun 25 21:36:59 dcd[12235]: [get_mem_info(114)] MemTotal:         440420 kB MemFree:           77056 kB MemAvailable:      75132 kB Shmem:              1120 kB

Jun 25 21:36:59 dcd[12235]: [fill_service(783)] serv#0: TCP-5473;
Jun 25 21:36:59 dcd[12235]: [fill_service(783)] serv#1: TCP-18017;
Jun 25 21:36:59 dcd[12235]: [fill_service(783)] serv#2: TCP-3394;
Jun 25 21:36:59 dcd[12235]: [fill_service(783)] serv#3: TCP-515;printer
Jun 25 21:36:59 dcd[12235]: [fill_service(783)] serv#4: TCP-51111;
Jun 25 21:36:59 dcd[12235]: [fill_service(783)] serv#5: TCP-47753;
Jun 25 21:36:59 dcd[12235]: [fill_service(783)] serv#6: TCP-139;netbios-ssn
Jun 25 21:36:59 dcd[12235]: [fill_service(783)] serv#7: TCP-9100;laserjet
Jun 25 21:36:59 dcd[12235]: [fill_service(783)] serv#8: TCP-7788;
Jun 25 21:36:59 dcd[12235]: [fill_service(783)] serv#9: TCP-80;www
Jun 25 21:36:59 dcd[12235]: [fill_service(783)] serv#10: TCP-53;domain
Jun 25 21:36:59 dcd[12235]: [fill_service(783)] serv#11: TCP-3702;
Jun 25 21:36:59 dcd[12235]: [fill_service(783)] serv#12: TCP-8888;
Jun 25 21:36:59 dcd[12235]: [fill_service(783)] serv#13: TCP-8443;
Jun 25 21:36:59 dcd[12235]: [fill_service(783)] serv#14: TCP-445;
Jun 25 21:36:59 dcd[12235]: [fill_service(783)] serv#15: TCP-3838;
Jun 25 21:36:59 dcd[12235]: [fill_service(792)] serv#16: UDP-9999;
Jun 25 21:36:59 dcd[12235]: [fill_service(792)] serv#17: UDP-42000;
Jun 25 21:36:59 dcd[12235]: [fill_service(792)] serv#18: UDP-42032;
Jun 25 21:36:59 dcd[12235]: [fill_service(792)] serv#19: UDP-53;domain
Jun 25 21:36:59 dcd[12235]: [fill_service(792)] serv#20: UDP-67;bootps
Jun 25 21:36:59 dcd[12235]: [fill_service(792)] serv#21: UDP-5474;
Jun 25 21:36:59 dcd[12235]: [ioctl_get_sig_ver_str(456)] sig_ver = 2.128 (1560112038)
Jun 25 21:36:59 dcd[12235]: [ioctl_get_sig_ver_str(477)] sig_ver = 2.128 (5)
Jun 25 21:36:59 dcd[12235]: [fill_dpi_sig_ver(825)] buf_used_len=5, ver_siz=6
Jun 25 21:36:59 dcd[12235]: [fill_dpi_ver(961)] dpi_ver = 2.0.1r4031774
Jun 25 21:36:59 dcd[12235]: [fill_dpi_ver(973)] dpi_core_ver = 0_0_23_RC2
Jun 25 21:36:59 dcd[12235]: [update_tmufe_counters(1001)] remote query count=6
Jun 25 21:36:59 dcd[12235]: [update_tmufe_counters(1009)] local query count=1
Jun 25 21:36:59 dcd[12235]: [update_tmufe_counters(1023)] keep retrieving.
Jun 25 21:36:59 dcd[12235]: [fill_qos_raw_cfg(1260)] qos raw conf size is zero...
Jun 25 21:36:59 dcd[12235]: [fill_router_nifs(1350)] nr_lin=101 bcmsw     Link encap:Ethernet  HWaddr              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1           RX packets:83710387 errors:0 dropped:0 overruns:0 frame:0           TX packets:77407925 errors:0 dropped:0 overruns:0 carrier:0           collisions:0 txqueuelen:1000            RX bytes:98929001279 (92.1 GiB)  TX bytes:88757328303 (82.6 GiB)           Base address:0xffff   br0       Link encap:Ethernet  HWaddr 0
Jun 25 21:36:59 dcd[12235]: [fill_router_nifs(1390)] if_name = bcmsw (len = 5)
Jun 25 21:36:59 dcd[12235]: [fill_router_nifs(1412)] MAC=, SHA1=9630108eb9eed1482bbcafc88d8ca254cf1946ec (len=40)
Jun 25 21:36:59 dcd[12235]: [fill_router_nifs(1390)] if_name = br0 (len = 3)
Jun 25 21:36:59 dcd[12235]: [fill_router_nifs(1412)] MAC=, SHA1=9630108eb9eed1482bbcafc88d8ca254cf1946ec (len=40)
Jun 25 21:36:59 dcd[12235]: [fill_router_nifs(1492)] IP=192.168.1.1
Jun 25 21:36:59 dcd[12235]: [fill_router_nifs(1390)] if_name = br0:pixelserv-t (len = 15)
Jun 25 21:36:59 dcd[12235]: [fill_router_nifs(1412)] MAC=, SHA1=9630108eb9eed1482bbcafc88d8ca254cf1946ec (len=40)
Jun 25 21:36:59 dcd[12235]: [fill_router_nifs(1492)] IP=192.168.1.2
Jun 25 21:36:59 kernel: dcd[12235]: unhandled level 3 translation fault (11) at 0x00000000, esr
 
If the memory gets freed by disabling AiProtection, I guess your cron job could simply stop/start the AiProtection services to free up the memory, until either Asus or Trend Micro address the issue.
No. it will not help.
Every dcd crash will eat some memory. It leave unreclaimable memory scrap.
How to I investigated it - previously I disabled service per service, but without any result.
Only when I made the same, but with reboot after each change - I found the root case.
 
No. it will not help.
Every dcd crash will eat some memory. It leave unreclaimable memory scrap.
How to I investigated it - previously I disabled service per service, but without any result.
Only when I made the same, but with reboot after each change - I found the root case.

Then I guess we'll have to wait for Trend Micro to fix it (that binary comes from them, I don't think Asus has access to its source code).

Not sure why it mostly affects the RT-AC86U, even the RT-AX88U (which has a very similar architecture) doesn't show any issue.
 
Then I guess we'll have to wait for Trend Micro to fix it (that binary comes from them, I don't think Asus has access to its source code).

Not sure why it mostly affects the RT-AC86U, even the RT-AX88U (which has a very similar architecture) doesn't show any issue.
Are they (Asus & Trend Micro) aware of this issue? dcd crashes when pixelserv-tls installed
 
I have a LOG TAIL of DCD crashing . TAKE A LOOK:(Removed mac address...pixelserv ip: 192.168.1.2 after it gets to br0:pixelserv-tls ... it crashes )

Code:
Jun 25 21:36:52 dcd[12235]: [pctrl_func(917)] do_pctrl ret = 0
Jun 25 21:36:59 dcd[12235]: [get_cpu_info(94)] processor    : 0 BogoMIPS    : 100.00 Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 CPU implementer    : 0x42 CPU architecture: 8 CPU variant    : 0x0 CPU part    : 0x100 CPU revision    : 0  processor    : 1 BogoMIPS    : 100.00 Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 CPU implementer    : 0x42 CPU architecture: 8 CPU variant    : 0x0 CPU part    : 0x100 CPU revision    : 0
Jun 25 21:36:59 dcd[12235]: [get_mem_info(114)] MemTotal:         440420 kB MemFree:           77056 kB MemAvailable:      75132 kB Shmem:              1120 kB

Jun 25 21:36:59 dcd[12235]: [fill_service(783)] serv#0: TCP-5473;
Jun 25 21:36:59 dcd[12235]: [fill_service(783)] serv#1: TCP-18017;
Jun 25 21:36:59 dcd[12235]: [fill_service(783)] serv#2: TCP-3394;
Jun 25 21:36:59 dcd[12235]: [fill_service(783)] serv#3: TCP-515;printer
Jun 25 21:36:59 dcd[12235]: [fill_service(783)] serv#4: TCP-51111;
Jun 25 21:36:59 dcd[12235]: [fill_service(783)] serv#5: TCP-47753;
Jun 25 21:36:59 dcd[12235]: [fill_service(783)] serv#6: TCP-139;netbios-ssn
Jun 25 21:36:59 dcd[12235]: [fill_service(783)] serv#7: TCP-9100;laserjet
Jun 25 21:36:59 dcd[12235]: [fill_service(783)] serv#8: TCP-7788;
Jun 25 21:36:59 dcd[12235]: [fill_service(783)] serv#9: TCP-80;www
Jun 25 21:36:59 dcd[12235]: [fill_service(783)] serv#10: TCP-53;domain
Jun 25 21:36:59 dcd[12235]: [fill_service(783)] serv#11: TCP-3702;
Jun 25 21:36:59 dcd[12235]: [fill_service(783)] serv#12: TCP-8888;
Jun 25 21:36:59 dcd[12235]: [fill_service(783)] serv#13: TCP-8443;
Jun 25 21:36:59 dcd[12235]: [fill_service(783)] serv#14: TCP-445;
Jun 25 21:36:59 dcd[12235]: [fill_service(783)] serv#15: TCP-3838;
Jun 25 21:36:59 dcd[12235]: [fill_service(792)] serv#16: UDP-9999;
Jun 25 21:36:59 dcd[12235]: [fill_service(792)] serv#17: UDP-42000;
Jun 25 21:36:59 dcd[12235]: [fill_service(792)] serv#18: UDP-42032;
Jun 25 21:36:59 dcd[12235]: [fill_service(792)] serv#19: UDP-53;domain
Jun 25 21:36:59 dcd[12235]: [fill_service(792)] serv#20: UDP-67;bootps
Jun 25 21:36:59 dcd[12235]: [fill_service(792)] serv#21: UDP-5474;
Jun 25 21:36:59 dcd[12235]: [ioctl_get_sig_ver_str(456)] sig_ver = 2.128 (1560112038)
Jun 25 21:36:59 dcd[12235]: [ioctl_get_sig_ver_str(477)] sig_ver = 2.128 (5)
Jun 25 21:36:59 dcd[12235]: [fill_dpi_sig_ver(825)] buf_used_len=5, ver_siz=6
Jun 25 21:36:59 dcd[12235]: [fill_dpi_ver(961)] dpi_ver = 2.0.1r4031774
Jun 25 21:36:59 dcd[12235]: [fill_dpi_ver(973)] dpi_core_ver = 0_0_23_RC2
Jun 25 21:36:59 dcd[12235]: [update_tmufe_counters(1001)] remote query count=6
Jun 25 21:36:59 dcd[12235]: [update_tmufe_counters(1009)] local query count=1
Jun 25 21:36:59 dcd[12235]: [update_tmufe_counters(1023)] keep retrieving.
Jun 25 21:36:59 dcd[12235]: [fill_qos_raw_cfg(1260)] qos raw conf size is zero...
Jun 25 21:36:59 dcd[12235]: [fill_router_nifs(1350)] nr_lin=101 bcmsw     Link encap:Ethernet  HWaddr              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1           RX packets:83710387 errors:0 dropped:0 overruns:0 frame:0           TX packets:77407925 errors:0 dropped:0 overruns:0 carrier:0           collisions:0 txqueuelen:1000            RX bytes:98929001279 (92.1 GiB)  TX bytes:88757328303 (82.6 GiB)           Base address:0xffff   br0       Link encap:Ethernet  HWaddr 0
Jun 25 21:36:59 dcd[12235]: [fill_router_nifs(1390)] if_name = bcmsw (len = 5)
Jun 25 21:36:59 dcd[12235]: [fill_router_nifs(1412)] MAC=, SHA1=9630108eb9eed1482bbcafc88d8ca254cf1946ec (len=40)
Jun 25 21:36:59 dcd[12235]: [fill_router_nifs(1390)] if_name = br0 (len = 3)
Jun 25 21:36:59 dcd[12235]: [fill_router_nifs(1412)] MAC=, SHA1=9630108eb9eed1482bbcafc88d8ca254cf1946ec (len=40)
Jun 25 21:36:59 dcd[12235]: [fill_router_nifs(1492)] IP=192.168.1.1
Jun 25 21:36:59 dcd[12235]: [fill_router_nifs(1390)] if_name = br0:pixelserv-t (len = 15)
Jun 25 21:36:59 dcd[12235]: [fill_router_nifs(1412)] MAC=, SHA1=9630108eb9eed1482bbcafc88d8ca254cf1946ec (len=40)
Jun 25 21:36:59 dcd[12235]: [fill_router_nifs(1492)] IP=192.168.1.2
Jun 25 21:36:59 kernel: dcd[12235]: unhandled level 3 translation fault (11) at 0x00000000, esr
I wonder if it chokes on the length of the interface name, since the output you show truncates it at “t”. What if pixelserv was configured with a shorter name for its interface?
 
I wonder if it chokes on the length of the interface name, since the output you show truncates it at “t”. What if pixelserv was configured with a shorter name for its interface?
Maybe ... any idea how to change this br0:pixelserv-tls interface name? its mentioned in this file which created when installing diversion standard : /opt/etc/init.d/S80pixelserv-tls

I will try this:
1. ifconfig br0:pixelserv-t 192.168.1.2 down
2. ifconfig br0:t 192.168.1.2 down
I will check if I see dcd crash and report back

Maybe @thelonelycoder can help ...
 
Last edited:

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top