Topic: RA lifetime (IPV6 informational message in system log?)

The content of this topic has been archived on 19 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Page 1 of 1

Post #1

mariano.silva

9 Apr 2017, 11:49

Hi gurus!

Would like some expert advice on how to get rid of this annoying message in the System Log ...

Sun Apr  9 07:19:46 2017 daemon.info odhcpd[1342]: Using a RA lifetime of 0 seconds on br-lan
Sun Apr  9 07:19:51 2017 daemon.info odhcpd[1342]: Using a RA lifetime of 0 seconds on br-lan
Sun Apr  9 07:19:52 2017 daemon.info odhcpd[1342]: Using a RA lifetime of 0 seconds on br-lan
Sun Apr  9 07:19:57 2017 daemon.info odhcpd[1342]: Using a RA lifetime of 0 seconds on br-lan
Sun Apr  9 07:20:01 2017 daemon.info odhcpd[1342]: Using a RA lifetime of 0 seconds on br-lan
Sun Apr  9 07:20:03 2017 daemon.info odhcpd[1342]: Using a RA lifetime of 0 seconds on br-lan
Sun Apr  9 07:20:07 2017 daemon.info odhcpd[1342]: Using a RA lifetime of 0 seconds on br-lan

From research I did, I think this is an informational message from the DHCP IPV6 server ... I don't use IPV6, but tried to disabled ( not sure if i succeeded or not ) wouldn't get rid of the message either. This message is swamping my System Log , writing this every 2 to 15 seconds

I've tried setting the RA and associated parameters, with no luck in dnsmasq.conf

#quiet-ra
#ra=disabled
#ra_default=2
#quiet-dhcp
#quiet-dhcp6

Thanks in advance for any hints on how to get rid of it...

Post #2

hnyman

9 Apr 2017, 12:21

mariano.silva wrote:

advice on how to get rid of this annoying message in the System Log

Sun Apr  9 07:20:03 2017 daemon.info odhcpd[1342]: Using a RA lifetime of 0 seconds on br-lan
Sun Apr  9 07:20:07 2017 daemon.info odhcpd[1342]: Using a RA lifetime of 0 seconds on br-lan

Due to changed default logging level settings in odhcpd.
There is now an uci config parameter for controlling the odhcpd logging level (in LEDE where that up-to-date odhcpd is in use):
https://forum.lede-project.org/t/odhcpd … level/1884

(Last edited by hnyman on 9 Apr 2017, 12:22)

Post #3

mariano.silva

9 Apr 2017, 22:34

Great, I was running the latest LEDE , so your tip fixed the issue... but now I'm noticing this other issue... ( not sure if those 2 are related ... )

Sun Apr  9 18:30:58 2017 daemon.info miniupnpd[1548]: HTTP REQUEST from [::ffff:192.168.1.102]:42040 : POST / (HTTP/1.1)
Sun Apr  9 18:30:58 2017 daemon.debug miniupnpd[1548]: Host: 192.168.1.1:5000
Sun Apr  9 18:30:58 2017 daemon.info miniupnpd[1548]: SOAPAction: #GetSpecificPortMappingEntry
Sun Apr  9 18:30:58 2017 daemon.info miniupnpd[1548]: Returning UPnPError 714: NoSuchEntryInArray
Sun Apr  9 18:30:58 2017 daemon.info miniupnpd[1548]: HTTP REQUEST from [::ffff:192.168.1.102]:42041 : POST / (HTTP/1.1)
Sun Apr  9 18:30:58 2017 daemon.debug miniupnpd[1548]: Host: 192.168.1.1:5000
Sun Apr  9 18:30:58 2017 daemon.info miniupnpd[1548]: SOAPAction: #AddPortMapping
Sun Apr  9 18:30:58 2017 daemon.info miniupnpd[1548]: AddPortMapping: ext port 9188 to 192.168.1.102:80 protocol TCP for: WD2go leaseduration=604800 rhost=
Sun Apr  9 18:30:58 2017 daemon.debug miniupnpd[1548]: UPnP permission rule 1 matched : port mapping rejected
Sun Apr  9 18:30:58 2017 daemon.info miniupnpd[1548]: redirection permission check failed for 9188->192.168.1.102:80 TCP
Sun Apr  9 18:30:58 2017 daemon.info miniupnpd[1548]: Returning UPnPError 718: ConflictInMappingEntry
Sun Apr  9 18:30:58 2017 daemon.info miniupnpd[1548]: HTTP REQUEST from [::ffff:192.168.1.102]:42042 : POST / (HTTP/1.1)
Sun Apr  9 18:30:58 2017 daemon.debug miniupnpd[1548]: Host: 192.168.1.1:5000
Sun Apr  9 18:30:58 2017 daemon.info miniupnpd[1548]: SOAPAction: #DeletePortMapping
Sun Apr  9 18:30:58 2017 daemon.info miniupnpd[1548]: Returning UPnPError 402: Invalid Args
Sun Apr  9 18:30:58 2017 daemon.info miniupnpd[1548]: HTTP REQUEST from [::ffff:192.168.1.102]:42043 : POST / (HTTP/1.1)
Sun Apr  9 18:30:58 2017 daemon.debug miniupnpd[1548]: Host: 192.168.1.1:5000
Sun Apr  9 18:30:58 2017 daemon.info miniupnpd[1548]: SOAPAction: #DeletePortMapping
Sun Apr  9 18:30:58 2017 daemon.info miniupnpd[1548]: Returning UPnPError 402: Invalid Args
Sun Apr  9 18:30:58 2017 daemon.info miniupnpd[1548]: HTTP REQUEST from [::ffff:192.168.1.102]:42044 : POST / (HTTP/1.1)
Sun Apr  9 18:30:58 2017 daemon.debug miniupnpd[1548]: Host: 192.168.1.1:5000
Sun Apr  9 18:30:58 2017 daemon.info miniupnpd[1548]: SOAPAction: #GetSpecificPortMappingEntry
Sun Apr  9 18:30:58 2017 daemon.info miniupnpd[1548]: Returning UPnPError 714: NoSuchEntryInArray
Sun Apr  9 18:30:58 2017 daemon.info miniupnpd[1548]: HTTP REQUEST from [::ffff:192.168.1.102]:42045 : POST / (HTTP/1.1)
Sun Apr  9 18:30:58 2017 daemon.debug miniupnpd[1548]: Host: 192.168.1.1:5000
Sun Apr  9 18:30:58 2017 daemon.info miniupnpd[1548]: SOAPAction: #AddPortMapping

192.168.1.1 is the Router, and 192.168.1.102 is my WD NAS drive... trying to get a UPnp port. It's doing this thousands of times per minute ...

Post #4

cvmiller

10 Apr 2017, 18:53

The two issues are _not_ linked.

Interesting that your WD NAS wants to open a port on your firewall (which is what UPNP does). I would be suspicious of that. If you don't want to see these, you could be an entry in your firewall to block requests from 192.168.1.102 (should your NAS connect to the internet?)

Post #5

mariano.silva

10 Apr 2017, 19:40

cvmiller wrote:

The two issues are _not_ linked.
Interesting that your WD NAS wants to open a port on your firewall (which is what UPNP does). I would be suspicious of that. If you don't want to see these, you could be an entry in your firewall to block requests from 192.168.1.102 (should your NAS connect to the internet?)

Well, I think it is supposed to as it is a WD cheap SAN drive that has an "web enabled" functionality to access it from the internet, so I'm guessing it is giving my public ip address and UPNP port to a WD server, and when I use the APP from my cellphone/notebook to see my pictures (let's say), it will channel the connection through there. I don't really use it, ever, so I will shut it down as you've recommended

Post #6

mariano.silva

10 Apr 2017, 19:59

Just to share with the community, I did what @cvmiller instructed me to do by adding this code to /etc/config/firewall:

config rule
        option family 'ipv4'
        option src_ip '192.168.1.102'
        option dest_ip '192.168.1.1'
        option dest_port '5000'
        option target 'DROP'
        option name 'Block UPNP traffic from WD Caviar NAS into Router UPNP port 5000'
        option src '*'

(Last edited by mariano.silva on 10 Apr 2017, 21:45)

Post #7

cvmiller

11 Apr 2017, 17:52

Thanks for publishing your firewall rule.

I hadn't realized that your WD NAS was trying to be Internet available (which I agree explains the UPNP request). Given the lack of security thought that goes into appliances (think: IoT) these days, I would do a lot of poking and prodding (with nmap) before opening my firewall to such a device.

Post #8

mariano.silva

11 Apr 2017, 18:40

cvmiller wrote:

Thanks for publishing your firewall rule.
I hadn't realized that your WD NAS was trying to be Internet available (which I agree explains the UPNP request). Given the lack of security thought that goes into appliances (think: IoT) these days, I would do a lot of poking and prodding (with nmap) before opening my firewall to such a device.

Will do ... even tough you NEED to trust Western Digital and what they are doing ( no sense to be paranoid there ), I would like to explore what's actually happening by capturing some traffic.

BTW: Having this new firewall rule in place (therefore the packets are not being processed by miniUPNP anymore ) , the CPU consumption dropped from an average of 2% on each core to an average of 0.1% on each core of my WRT1900 ACS v2 ) - Thanks for the solution @cvmiller, again!

Post #9

cvmiller

12 Apr 2017, 17:18

Glad it worked for you.

Post #10

mariano.silva

26 Apr 2017, 17:08

hnyman wrote:

mariano.silva wrote:
advice on how to get rid of this annoying message in the System Log
Sun Apr  9 07:20:03 2017 daemon.info odhcpd[1342]: Using a RA lifetime of 0 seconds on br-lan
Sun Apr  9 07:20:07 2017 daemon.info odhcpd[1342]: Using a RA lifetime of 0 seconds on br-lan
Due to changed default logging level settings in odhcpd.
There is now an uci config parameter for controlling the odhcpd logging level (in LEDE where that up-to-date odhcpd is in use):
https://forum.lede-project.org/t/odhcpd … level/1884

I've changed the loglevel parameter to 4, and I'm still getting the following every 10 seconds in the syslog:

daemon.info odhcpd[1360]: Using a RA lifetime of 0 seconds on br-lan

I've tried with loglevel 8 ... and 1 , same thing ... Ideas?

The discussion might have continued from here.

Page 1 of 1