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.

Page 222 of 229

Post #5526

makedir

16 Apr 2018, 05:23

davidc502 wrote:

@AjkayAlan
Are you running tcpdump on some of these interfaces? I see 'promiscuous mode' which would indicate interface traffic monitoring/data gathering.

Mine looks like this too though and I dont run any sniffer:

[   16.239748] mvneta f1034000.ethernet eth0: configuring for fixed/sgmii link mode
[   16.247288] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   16.253518] mvneta f1034000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
[   16.257105] br-lan: port 1(eth0.1) entered blocking state
[   16.257109] br-lan: port 1(eth0.1) entered disabled state
[   16.257219] device eth0.1 entered promiscuous mode
[   16.257221] device eth0 entered promiscuous mode
[   16.257678] br-lan: port 1(eth0.1) entered blocking state
[   16.257682] br-lan: port 1(eth0.1) entered forwarding state
[   16.266843] mvneta f1070000.ethernet eth1: configuring for fixed/rgmii-id link mode
[   16.267296] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[   16.267325] mvneta f1070000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
[   16.365393] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   16.371948] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[   18.120720] ieee80211 phy0: change: 0xffffffff
[   18.200748] br-lan: port 2(wlan0) entered blocking state
[   18.206135] br-lan: port 2(wlan0) entered disabled state
[   18.211692] device wlan0 entered promiscuous mode
[   18.216514] br-lan: port 2(wlan0) entered blocking state
[   18.221868] br-lan: port 2(wlan0) entered forwarding state
[   18.351711] ieee80211 phy1: change: 0xffffffff
[   18.415834] br-lan: port 2(wlan0) entered disabled state
[   18.421708] br-lan: port 3(wlan1) entered blocking state
[   18.427066] br-lan: port 3(wlan1) entered disabled state
[   18.432520] device wlan1 entered promiscuous mode
[   23.232287] ieee80211 phy0: change: 0x100
[   23.245379] ieee80211 phy0: change: 0x40
[   23.442678] ieee80211 phy0: change: 0x40
[   23.516430] ieee80211 phy1: change: 0x100
[   23.529488] ieee80211 phy1: change: 0x40
[   23.632683] ieee80211 phy0: change: 0x40
[   23.652714] br-lan: port 3(wlan1) entered blocking state
[   23.658061] br-lan: port 3(wlan1) entered forwarding state
[   23.702693] ieee80211 phy0: change: 0x100
[   23.820113] ieee80211 phy0: change: 0x100
[   23.832764] ieee80211 phy0: change: 0x42
[   23.970727] br-lan: port 2(wlan0) entered blocking state
[   23.976077] br-lan: port 2(wlan0) entered forwarding state

It seems all devices (eth0, eth1, wlan0, wlan1) enter promiscuous mode at boot and never leave it anymore, is this normal?

(Last edited by makedir on 16 Apr 2018, 05:51)

Post #5527

persson

16 Apr 2018, 06:40

Hi,

With the latest FW, I can select channel 48, but it says 44 after I have pushed save and apply.. same for you guys?

Regards

Post #5528

adri

16 Apr 2018, 08:48

persson wrote:

Hi,
With the latest FW, I can select channel 48, but it says 44 after I have pushed save and apply.. same for you guys?
Regards

This is normal behaviour.
If the router detects other SID's broadcasting on the same channel, it can decide to use another channel within the same range of allowed channels.
If you select 48 with 802.11ac, this means the router uses channel 48 to broadcast the SID and will use channels 36-48 for transmissions.

Post #5529

makedir

16 Apr 2018, 08:50

Guy on the post I mentioned about the WRT1200v2 reboots said this:

After a long discuss and negociation (approx 6 months) with linksys (belkin), they admit that they have a problem with the DDR3 on the board. they take all our broken router for making some test, and replace them.
they will replace all the DDR3 by changind the brand on the next board. (maybe with a V3 version)

This is unbelievable. Just great.

Post #5530

persson

16 Apr 2018, 13:56

adri wrote:

persson wrote:
Hi,
With the latest FW, I can select channel 48, but it says 44 after I have pushed save and apply.. same for you guys?
Regards
This is normal behaviour.
If the router detects other SID's broadcasting on the same channel, it can decide to use another channel within the same range of allowed channels.
If you select 48 with 802.11ac, this means the router uses channel 48 to broadcast the SID and will use channels 36-48 for transmissions.

Thanks Adri!

Post #5531

AjkayAlan

16 Apr 2018, 14:33

makedir wrote:

davidc502 wrote:
@AjkayAlan
Are you running tcpdump on some of these interfaces? I see 'promiscuous mode' which would indicate interface traffic monitoring/data gathering.
Mine looks like this too though and I dont run any sniffer:

I am not running tcpdump or a sniffer or anything. It is just a basic setup with upnp and sqm qos enabled.

Post #5532

beginner67890

16 Apr 2018, 16:03

makedir wrote:

@beginner67890 power fluctuations could be possible of course, but very unlikely. none of my other devices I use have any problems in my flat. I use for example a 2nd router in front of the wrt, which acts as a fallback unit and has in-build modem for DSL, and it never crashes. might be, that the wrt is very prone to power issues. The AC of the new WRT1200 I got from Amazon was replaced of yourse, I did use the new one. So... to me a power drop is very unlikely, or the AC series which comes with the WRT1200 has an issue.
is there no way to log somehow the last seconds before a crash, or disable auto reboot? why is there no way to write a crash dump to usb stick or somewhere else. I have no insight in seeing the crash log, which is gone after a reboot of course.

That is good you found out about the DDR3 problems with WRT1200ACv2. Maybe you could send your router to the Linksys factory for repair instead of to Amazon for replacement and get the DDR3 replaced. Or maybe get a refund and switch routers.

I decided to set up remote logging because I like to read the logs for fun. The logging can also be sent to a USB stick if that is preferred. The settings for file logging or remote logging can be seen in the /etc/init.d/log file:

uci_validate_section system system "${1}" \
        'log_file:string' \
        'log_size:uinteger' \
        'log_hostname:string' \
        'log_ip:ipaddr' \
        'log_remote:bool:1' \
        'log_port:port:514' \
        'log_proto:or("tcp", "udp"):udp' \
        'log_trailer_null:bool:0' \
        'log_prefix:string'
}

So I edited the /etc/config/system file in the system field to enable remote logging:

option log_remote '1'
option log_ip '192.168.1.114'

I need to set up my logger to receive the logs. I decide to use my Raspberry Pi Zero W because my notebook is frequently shut off and the Raspberry can run 24/7.

I have the Void distribution installed on the Raspberry with the socklog logger so this is needed:

root# socklog-conf inet nobody nobody
root# ln -s /etc/sv/socklog-inet /var/service

So the Raspberry is now running the service on port 514 to receive the logs and the router is ready to send the logs on port 514 so:

/etc/init.d/log restart

I can ssh into the Raspberry to read the logs even if the router crashes. In the /var/log/socklog-inet/current file I get what I am looking for:

@400000005ad4b20a16c08fe4 listening on 0.0.0.0:514, gid=99, uid=99, starting.
@400000005ad4b3ae25f50c74 192.168.1.1: daemon.info: Apr 16 07:31:00 LEDE logread[31303]: Logread connected to 192.168.1.114:514
@400000005ad4b4aa126fdb34 192.168.1.1: daemon.warn: Apr 16 07:35:12 LEDE odhcpd[2317]: DHCPV6 SOLICIT IA_NA from 0001000112022c0e002564488731 on br-lan: ok fded:3f9e:84c7::2ff/128
@400000005ad4b4aa13666864 192.168.1.1: daemon.info: Apr 16 07:35:12 LEDE dnsmasq[5141]: read /etc/hosts - 4 addresses
@400000005ad4b4aa1371033c 192.168.1.1: daemon.info: Apr 16 07:35:12 LEDE dnsmasq[5141]: read /tmp/hosts/odhcpd - 2 addresses
@400000005ad4b4aa137cfda4 192.168.1.1: daemon.info: Apr 16 07:35:12 LEDE dnsmasq[5141]: read /tmp/hosts/dhcp.cfg01411c - 2 addresses
@400000005ad4b4aa137e12fc 192.168.1.1: daemon.info: Apr 16 07:35:12 LEDE dnsmasq-dhcp[5141]: read /etc/ethers - 0 addresses

That should look familiar. Now I just need to get the logs to show what I want.

Post #5533

davidc502

17 Apr 2018, 00:27

AjkayAlan wrote:

makedir wrote:
davidc502 wrote:
@AjkayAlan
Are you running tcpdump on some of these interfaces? I see 'promiscuous mode' which would indicate interface traffic monitoring/data gathering.
Mine looks like this too though and I dont run any sniffer:
I am not running tcpdump or a sniffer or anything. It is just a basic setup with upnp and sqm qos enabled.

I've been watching my logs now.... Seems wlan1 restarted, and looks to be ipv6 related. Seems totally unrelated to your issue. Have you tried disabling sqm and see if the problem persists?

[   23.657318] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
[   23.659279] ieee80211 phy0: change: 0x40
[   23.667714] br-lan: port 3(wlan1) entered blocking state
[   23.673064] br-lan: port 3(wlan1) entered forwarding state

(Last edited by davidc502 on 17 Apr 2018, 00:30)

Post #5534

makedir

17 Apr 2018, 00:54

@beginner67890 These logging obviously dont work, I tried it before. They run on a too high level. The problem mostly is, when a critical kernel panic occurs, the device cant handle anything with higher drivers anymore, like usb, network, even maybe hdd. There would need to be some logging running on lowest level as possible, like Windows does for a BSOD when it collects data and writes a memory dump to disk. The last important log entries would always be missing in this case. I dont know of any other router I could replace the WRT1200 with sadly.

(Last edited by makedir on 17 Apr 2018, 00:55)

Post #5535

diabl0w

17 Apr 2018, 01:58

AddRemover wrote:

I've also noticed no push for my work mailbox few builds ago. It uses outlook365 servers so I was really sure it's issue on my side. Laptop got pushes OK. I've cheked logcat on android device and tcpdump on router to see what is wrong, since internet was OK on the android device. I've found that this is an issue... with IPv6
Whenever android got IPv6, connection to outlook365 goes via v6 and messed up. If android use IPv4 - all is OK with pushes. So I've played a bit with my IPv6 config so now everything works fine even after few builds upgrade.
root@LINKSYS:~# uci show network.wan6
network.wan6=interface
network.wan6.ifname='eth1.2'
network.wan6.proto='dhcpv6'
root@LINKSYS:~# uci show dhcp.lan
dhcp.lan=dhcp
dhcp.lan.interface='lan'
dhcp.lan.start='100'
dhcp.lan.leasetime='48h'
dhcp.lan.limit='50'
dhcp.lan.force='1'
dhcp.lan.dhcpv6='hybrid'
dhcp.lan.ra_management='2'
dhcp.lan.ra='hybrid'
root@LINKSYS:~# uci show dhcp.odhcpd
dhcp.odhcpd=odhcpd
dhcp.odhcpd.maindhcp='0'
dhcp.odhcpd.leasefile='/tmp/hosts/odhcpd'
dhcp.odhcpd.loglevel='5'
EDIT1:
Now it appears to re-read configs each 15 minutes. Will try to findout why.

I also have that problem with outlook365... so you're saying that disabling ipv6 did fix this?

Post #5536

AjkayAlan

17 Apr 2018, 02:31

davidc502 wrote:

Have you tried disabling sqm and see if the problem persists?

I will do that and see how it goes.

Post #5537

beginner67890

17 Apr 2018, 02:35

makedir-

My remote log file now has 192K after 10 hours of logging. The logs will get rotated into storage periodically so there will be a lot of information to check. I would expect the memory problems would cause the kernel to complain about bad memory blocks or cause kernel panics before causing a reboot. There are very few things that will cause the kernel to totally lock the entire system. There should be core dumps without a reboot in most cases if core dumps are enabled. I am unsure about that.

I am sure you have investigated the DDR3 reports so would know if anybody has seen any clues available to confirm the problem in your router. Maybe the chips become unresponsive except what would cause the reboot? There might be a delay when a watchdog takes action so that timing should show in the logs.

If you are convinced your router has bad DDR3 chips then nevermind my curiosity. I am still unhappy with the tiny little power adapter obviously with switching design to produce the high amperage output and whether that can maintain a valid output during periodic transients. They can occur when motors start and the voltage drops to near zero for a fraction of a second. There could be a combination of nearby washing machines, heat pumps, air compressors all starting at the same time causing the adapter to produce a low output. Then the router would basically get turned off and on again or rebooted.

Some older power supplies or higher amperage power supplies with bigger capacitors can continue to produce power during the transients so trying some that could be handy with the same voltage and plug instead of the Linksys adapter might eliminate that possibility if you want to keep the WRT1200ACv2.

(Last edited by beginner67890 on 17 Apr 2018, 02:36)

Post #5538

makedir

17 Apr 2018, 05:17

@beginner67890 The crash/reboots seem to be too critical, it will stop the CPU before a log output can be generated. And I have posted some rare memory corruption logs before on here you saw, like the one with sleep & tinyproxy.

Im thinking about buying a cheap UPS for about $50, can you advise one, which has easy and cheap battery change support? Maybe a EATON 3S 550 DIN, though it's a bit expensive at 72Euro.

Might also be, that there is some design flaw in the WRT1200v2 or its AC, and little power drops result in RAM become corrupted, and it's not per se a defective RAM at all.

Could also be, that the RAM can get too hot and the WRT1200v2 has a design flaw of RAM cooling (no heat sink on the RAM, just CPU).

Or maybe the change they made to the V2 becase of WIFI regulation results in Wifi/RAM part become too hot, because of power transmittion too high.

Or the clock or voltage regulation is wrong for the RAMs.

All these sound plausible, and the WRT1200V2 is just a ticking time bomb, and I am sure, the whole production line has it. Most people wont notice it though.

I asked the guy in the LEDE post btw, and he said his company was over 6 months in contact with Linksys, and they did nothing for them. They wrote back this to them at some point, which speaks to itself:

Thanks for the update. In the meantime, we have been able to find a couple more affected samples from among the returns in our warehouse and have had 4 more returned from another customer in France who has reported similar issues to yourself in the last few weeks.
Also, the factory has been analyzing the first unit which was returned and has determined that after they replaced the DDR3 memory the problem no longer occurred, so it seems likely that the memory was the cause of the issue. I would suggest you hold on to the affected units for the time being while I check whether we need more samples for analysis; between the one you originally sent back, the 2 others I found in our warehouse and the 4 which came from the other customer we have 6 units. I’ll let you know within a couple of days whether we still need your 3 units for analysis or whether we believe we can reliably establish the root cause with the 6 we have.

He said, the "repaired" units they got back still showed up random reboots, way more rapidly if they were not cooled by air conditioning.

(Last edited by makedir on 17 Apr 2018, 05:26)

Post #5539

sandreas83

17 Apr 2018, 08:45

@makedir
Let me get this straight. Every device of the WRT 1900v2 series has a hardware defect? (I own such a device)

If that is the case, can I contact Linksys to do an exchange?

If it only affects some devices, how can I check if my device is affected?

Post #5540

17 Apr 2018, 08:59

treefiddy wrote:

@davidc502:
Can you take a look at this issue? dslite (RFC6333) is broken on WRT3200 viewtopic.php?id=73755
Your snapshot builds are affected as well, maybe you can give us a hint where the issue could be. Thank you so much.

I created this bug report for the issue https://bugs.openwrt.org/index.php?do=d … ;pagenum=2

@davidc502: can you please have a look or can you maybe give some hints about it? Thanks a lot!

Post #5541

makedir

17 Apr 2018, 10:07

@sandreas83 If you dont have issues like reboots, than you dont need to contact Linksys I guess? I am sure though, that some if not all production line of it has an issue, may it be bad/cheap RAM, not proper cooled RAM or maybe no good power supply. As I see it though, if you just are an ordinary user and just use it literally for nothing, you wont see this happen or at least very rarely. The more processes you run on it, especially which are RAM using and multi treading, it might occur more often. I'm still trying to find out, if stressing the RAM by writing to /tmp might trigger something, but I wasnt lucky so far.

Post #5542

ghoffman

17 Apr 2018, 11:39

starcms wrote:

ghoffman wrote:
this is another dnscrypt-proxy issue (?) with davidc502 build 180330 on a wrt3200acm.
every minute or so, my syslog has a variable number (3-10) of lines lke this:
Mon Apr  9 05:21:13 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.134 to 192.168.1.250
Mon Apr  9 05:21:44 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.250 to 192.168.1.234
Mon Apr  9 05:21:46 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.234 to 192.168.1.233
Mon Apr  9 05:21:53 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.233 to 192.168.1.250
is there a way to turn off dnscrypt-proxy?
what do the above evntries mean?
thanks to davidc and to all on this forum. fantastic build.
Those have nothing to do with dnscrypt-proxy.
Those are caused by igmpproxy. It is only needed for those who have IP TV and need multicast support. Simply remove the igmpproxy package.

@starcms -
cold you please provide alittle more information? see the snippet below

Tue Apr 17 03:28:30 2018 user.warn igmpproxy[5258]: MRT_DEL_MFC; Errno(2): No such file or directory
Tue Apr 17 03:28:42 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.134 to 192.168.1.234
Tue Apr 17 03:28:45 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.234 to 192.168.1.250
Tue Apr 17 03:28:52 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.250 to 192.168.1.236
Tue Apr 17 03:29:01 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.236 to 192.168.1.179
Tue Apr 17 03:29:05 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.179 to 192.168.1.250
Tue Apr 17 03:30:34 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.250 to 192.168.1.134
Tue Apr 17 03:30:38 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.134 to 192.168.1.250
Tue Apr 17 03:31:01 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.250 to 192.168.1.179
Tue Apr 17 03:31:05 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.179 to 192.168.1.250
Tue Apr 17 03:32:34 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.250 to 192.168.1.134
Tue Apr 17 03:32:40 2018 user.warn igmpproxy[5258]: MRT_DEL_MFC; Errno(2): No such file or directory
Tue Apr 17 03:33:01 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.250 to 192.168.1.179
Tue Apr 17 03:33:05 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.179 to 192.168.1.250
Tue Apr 17 03:34:34 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.250 to 192.168.1.134
Tue Apr 17 03:34:45 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.134 to 192.168.1.250
Tue Apr 17 03:35:01 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.250 to 192.168.1.179
Tue Apr 17 03:35:05 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.179 to 192.168.1.250
Tue Apr 17 03:36:34 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.250 to 192.168.1.134
Tue Apr 17 03:36:45 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.134 to 192.168.1.250
Tue Apr 17 03:36:50 2018 user.warn igmpproxy[5258]: MRT_DEL_MFC; Errno(2): No such file or directory
Tue Apr 17 03:37:05 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.179 to 192.168.1.25

the routes seem to be getting switched around continuously- i.e. .250 goes to .179, then .179 goes to .250
doesnt this create havok on the network?
does this mean there is an address conflict, or does this mean some device is trying to be a multicast host?
the .250 device is a WD MyCloud backup device which also functions as a mac osx backup, but the devices that are getting rerouted ar enot mac/osx devices.

any help is appreciated.
thank you

Post #5543

beginner67890

17 Apr 2018, 17:28

makedir wrote:

@beginner67890 These logging obviously dont work, I tried it before. They run on a too high level. The problem mostly is, when a critical kernel panic occurs, the device cant handle anything with higher drivers anymore, like usb, network, even maybe hdd. There would need to be some logging running on lowest level as possible, like Windows does for a BSOD when it collects data and writes a memory dump to disk. The last important log entries would always be missing in this case. I dont know of any other router I could replace the WRT1200 with sadly.

I agree with your report here. I just unplugged my router power supply trying to be very fast to replug yet took about 5 seconds after fumbling. The remote log gives no indication before the reboot and none after the remote logging resumes.

I wanted to test if the router would not reboot after a very brief power outage except could not correctly reseat the adapter quick enough. I need to run more tests to see if the router would reboot with less than a second of power interruption.

Here is a very interesting article about the WRT1900ACS in comparison to the WRT1200ACv1. The circuit board is shown for both routers and show just one tiny capacitor next to the power supply socket. I think a big electrolytic capacitor could be soldered to the power switch leads or just replace the switch and so give a better transient response without making any other changes.

https://www.smallnetbuilder.com/wireles … mitstart=0

The 12 volt power adapter has a very common plug so should be easy to substitute. Just borrowing an adapter could verify the problem before making a purchase. The adapters can sometimes be found in second-hand stores. A 3 or 4 amp 12 volt supply like a brick would be very good.

The bigger UPS units can get expensive except just a very small UPS would be sufficient for the power adapters. The smallest size should be fine because 99% of all transients are very short duration and barely make the lights flicker. The UPS units contain a small 12 volt battery and they will die eventually. I just replaced one battery for a 350 watt UPS for $15. Try to borrow a UPS first before making a purchase in case the memory chips are the actual problem or at least choose a place with a good return policy.

(Last edited by beginner67890 on 17 Apr 2018, 17:44)

Post #5544

davidc502

17 Apr 2018, 17:38

ghoffman wrote:

starcms wrote:

ghoffman wrote:
this is another dnscrypt-proxy issue (?) with davidc502 build 180330 on a wrt3200acm.
every minute or so, my syslog has a variable number (3-10) of lines lke this:
Mon Apr  9 05:21:13 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.134 to 192.168.1.250
Mon Apr  9 05:21:44 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.250 to 192.168.1.234
Mon Apr  9 05:21:46 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.234 to 192.168.1.233
Mon Apr  9 05:21:53 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.233 to 192.168.1.250
is there a way to turn off dnscrypt-proxy?
what do the above evntries mean?
thanks to davidc and to all on this forum. fantastic build.
Those have nothing to do with dnscrypt-proxy.
Those are caused by igmpproxy. It is only needed for those who have IP TV and need multicast support. Simply remove the igmpproxy package.

@starcms -
cold you please provide alittle more information? see the snippet below

Tue Apr 17 03:28:30 2018 user.warn igmpproxy[5258]: MRT_DEL_MFC; Errno(2): No such file or directory
Tue Apr 17 03:28:42 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.134 to 192.168.1.234
Tue Apr 17 03:28:45 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.234 to 192.168.1.250
Tue Apr 17 03:28:52 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.250 to 192.168.1.236
Tue Apr 17 03:29:01 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.236 to 192.168.1.179
Tue Apr 17 03:29:05 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.179 to 192.168.1.250
Tue Apr 17 03:30:34 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.250 to 192.168.1.134
Tue Apr 17 03:30:38 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.134 to 192.168.1.250
Tue Apr 17 03:31:01 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.250 to 192.168.1.179
Tue Apr 17 03:31:05 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.179 to 192.168.1.250
Tue Apr 17 03:32:34 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.250 to 192.168.1.134
Tue Apr 17 03:32:40 2018 user.warn igmpproxy[5258]: MRT_DEL_MFC; Errno(2): No such file or directory
Tue Apr 17 03:33:01 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.250 to 192.168.1.179
Tue Apr 17 03:33:05 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.179 to 192.168.1.250
Tue Apr 17 03:34:34 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.250 to 192.168.1.134
Tue Apr 17 03:34:45 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.134 to 192.168.1.250
Tue Apr 17 03:35:01 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.250 to 192.168.1.179
Tue Apr 17 03:35:05 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.179 to 192.168.1.250
Tue Apr 17 03:36:34 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.250 to 192.168.1.134
Tue Apr 17 03:36:45 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.134 to 192.168.1.250
Tue Apr 17 03:36:50 2018 user.warn igmpproxy[5258]: MRT_DEL_MFC; Errno(2): No such file or directory
Tue Apr 17 03:37:05 2018 user.warn igmpproxy[5258]: The origin for route 239.255.255.250 changed from 192.168.1.179 to 192.168.1.25

any help is appreciated.
thank you

It is multicast so the packets are going to be replicated out each of the ports on the LAN... I seem to remember others set up VLANS to keep the multicast from going all over.

Having said that, I also seem to remember IGMP snooping being installed so that it will listen to the packets as to control which ports receive the traffic.

Check to see if you have IGMP snooping enabled or not.

Sorry, posts 5545 to 5550 are missing from our archive.

Page 222 of 229