Advanced Tomato upnp/dlna issue?

Discussion in 'Tomato Firmware' started by wikdclown, Mar 11, 2018.

  1. wikdclown

    wikdclown Network Newbie Member

    Wondering if someone with tomato experience might help me with a issue in having with advanced tomato. The router is a older wnr3500l v2 with advanced tomato on it, and on a fresh boot all castable devices are shown on my network, everything casts fine and perfect,however, sometime later (3-4 hours) all devices just disappear and the only way for them to show back up is to reboot router. I'm sure it's something simple but this is the first time I have used tomato so I'm at a loss. Any help would be appreciated.
     
  2. Sean B.

    Sean B. LI Guru Member

    What do you mean by disappear? You cannot see them on the network via PC? You cannot see them in the routers GUI under Status->Devices? They physically vanish from your household? ;) . Can you ping the IP address of one of the devices after it's disappeared and receive a response?
     
  3. wikdclown

    wikdclown Network Newbie Member

    They disappear as in I cannot select them to cast anything to, they are otherwise fine, they show up in devices connected to network and they will connect to the net, and yes I can ping them. Here's the scenario, I am on phone/tablet on freshly booted network, I open bubbleupnp (or any other casting software) in renderer it shows firetv, firestick, smart TV, few hours later I open bubbleupnp and there is nothing shown that I can cast to, even on pc it shows nothing I can cast to. I reboot router and voila they are back again for a certain amount of time as devices I can cast to. I have tried multiple phones and tablets and casting software and they all do the same thing.
     
  4. Sean B.

    Sean B. LI Guru Member

    Goto Administration->Debugging and click "Download Logs" near the bottom of the page. This needs to be done after the issue has occurred but before a reboot of the router, as the logs will be lost on reboot. Check the logs for any errors or warnings that may be related. Post anything that looks out of place here if you're unsure what it relates to. Also, try disconnecting and re-connecting one of the casting devices rather than rebooting the router and see what results that has.
     
  5. eibgrad

    eibgrad Network Guru Member

    I'd also be curious if this is only a problem w/ wireless clients, rather than wired and wireless.

    In my experience, I find casting to be somewhat unreliable over wireless, and why I prefer to use ethernet or powerline w/ such devices.
     
  6. Sean B.

    Sean B. LI Guru Member

    I would agree. In general, this issue does not initially come across as likely to be Tomato related/caused. However, I've been surprised before.
     
  7. koitsu

    koitsu Network Guru Member

    When the problem is happening, you can try restarting miniupnpd, which is what's responsible for UPnP only (not DLNA):

    Code:
    killall miniupnpd && sleep 3 && miniupnpd -f /etc/upnp/config
    
    If this doesn't fix the problem, then the issue is not with UPnP.

    I don't remember what process is responsible for DLNA.
     
  8. wikdclown

    wikdclown Network Newbie Member

    Here is some errors that stood out to me

    Mar 11 12:54:20 unknown daemon.err miniupnpd[1354]: ioctl(s, SIOCGIFADDR, ...): Cannot assign requested address
    Mar 11 12:54:20 unknown daemon.err miniupnpd[1354]: Failed to get IP for interface vlan2
    Mar 11 12:54:20 unknown daemon.warn miniupnpd[1354]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
    Mar 11 12:54:21 unknown user.debug dhcpc-event[1365]: 255: pptp peerdns disabled
    Mar 11 12:54:21 unknown user.debug init[1]: 255: pptp peerdns disabled
    Mar 11 12:55:39 unknown daemon.crit dnsmasq[1962]: error at line 5350 of /etc/dnsmasq.adblock

    Not much other than those errors. I'll try some of these other suggestions and post back. I have other routers, hook them up and can cast fine.

    Restart upnp and the log says it restated fine, so I guess it's not upnp

    Second edit:
    Rebooting fire TV and unplugging smart TV and firestick brings them all back as castable devices without rebooting router.
     
    Last edited: Mar 12, 2018
  9. Sean B.

    Sean B. LI Guru Member

    Are you experiencing WAN connection drops at the same time this issue occurs?
     
  10. wikdclown

    wikdclown Network Newbie Member

    N
    No, everything is running fine.
     
  11. Sean B.

    Sean B. LI Guru Member

    Not according to this line. Something has changed on the WAN via the DHCP client. Watch your WAN IP for changes. Your issue may be UPnP trying to rebind to the WAN before an address has been assigned, basically right in the middle of a dhcp release/renew. If that's the case, a simple script added to Administration->Scripts for WAN-UP to restart UPnP should fix the issue. May be worth just putting it in there and seeing if anything improves:

    **EDIT** Just saw this edit:

    There is something else happening that is causing this. With the log showing lines from dhcpc and dnsmasq, some connectivity issue or change is occurring. And sense reboot/reconnect of the devices brings them back.. it implies they are being lost in the shuffle rather than the router having a direct issue with them. Would you post your syslog file for a full review please?

    Does a restart of miniupnpd, as @koitsu suggested, return them to castable as well? Or only a reboot of the router / reconnect of devices restore it? If it does, put this in the WAN-UP script box:

    Code:
    #!/bin/sh
    
    # Kill miniupnpd if it's alive.
    if [ "$(pidof miniupnpd)" ]
      then
        killall miniupnpd >/dev/null 2>&1
        sleep 1
    fi
    
    # Confirm miniupnpd is down, then start it.
    if [ ! "$(pidof miniupnpd)" ]
      then
        miniupnpd -f /etc/upnp/config
    # Complain in syslog if miniupnpd is still alive.
      else
        logger "ERROR: Could not kill miniupnpd for WAN-UP restart."
    fi
    While this is likely a workaround rather than a fix, sense it doesn't address whatever the root cause is for them dropping off, it should at least automate their return for the time being if restarting upnp does bring them back.
     
    Last edited: Mar 12, 2018
  12. wikdclown

    wikdclown Network Newbie Member


    Yes i can post a full log later, for now i just rebooted and going to let it run till they stop so it can get full log file.
    I tried putting in that script in WAN UP but for some reason it wont save, it will save up to this part


    # Kill miniupnpd if it's alive.
    if [ "$(pidof miniupnpd)" ]
    then
    killall miniupnpd >/dev/null 2>

    If i leave off &1 it will save the whole script.
     
  13. Sean B.

    Sean B. LI Guru Member

    That's rather odd. Just tried pasting it into WAN-UP on my end in case my browser messed something up pasting it into the post, but it copied over just fine. You can leave the 2>&1 off.. it just silences stout & err. So the line would be: killall miniupnpd

    You might try saving the full script, then checking if it's actually messed up in the NVRAM rather than taking the GUI's word for it, as it could be a browser issue. To do so, copy over the full script as is and save in the GUI. Then in Tools->System commands run:

    Code:
    nvram get script_wanup
    And see if it retained the full and correct script text.
     
  14. wikdclown

    wikdclown Network Newbie Member

    OK, tried what you said and the tools thing only shows up to that same point again. I removed the parts you said and the whole script stays even when using the tools. So far today after putting in that script all devices have been showing on network perfectly, I have my fingers crossed that it has fixed it. I will post back soon if something goes wonky. I'd like to thank you for helping me btw, very much appreciated.
     
    Sean B. likes this.
  15. Sean B.

    Sean B. LI Guru Member

    You're quite welcome, happy to help.
     
  16. koitsu

    koitsu Network Guru Member

    If it turns out to be miniupnpd, then someone gets to go through minimum of 180 commits to find out what may be a potential fix for whatever this problem is. TomatoUSB uses miniupnpd 2.0, which was released back in April of 2016. This is the release: https://github.com/miniupnp/miniupnp/releases/tag/miniupnpd_2_0

    There's a "XXX commits to master since this tag" link that will list those commits since. I think TomatoUSB has some custom patches (I think for bugs though, i.e. since fixed in miniupnpd master) though.

    Really though, it sounds like it's a side-effect of the WAN going down in some manner (or something? I really need to see a full /var/log/messages. Could be DHCP client-released, e.g. DHCP lease time brings down the WAN to get a new IP), during which time miniupnpd "breaks" cuz the WAN IP just got pulled out from under it. I'm blabbing without any details, it's just me brain dumping. The WAN going down would be the root cause, and IMO, fix that and all the rest of this becomes kinda moot.

    Edit: it looks like committers "generally" update the ChangeLog when they make something major -- https://github.com/miniupnp/miniupnp/blob/master/miniupnpd/Changelog.txt -- but I know that the project has a history of not maintaining this file very well. Possibly this is all IPv6-related? I see a lot of commits relating to fixing IPv6 stuff since April 2016.
     
  17. Sean B.

    Sean B. LI Guru Member

    It brings to mind what we were seeing with the "constant dnsmasq restarts" situation rooted in DHCPv6. However the spurious WAN up/down and dnsmasq restarts were curbed by my patch. Advanced Tomato is Shibby based and he applied said patch, but maybe it's a new twist on an old problem. As you stated, we'd need more of the log to start getting an idea.
     
    koitsu likes this.
  18. wikdclown

    wikdclown Network Newbie Member

    Ok, what i have done is factory reset the router and i will leave off the script and other stuff like adblock etc, and when it does it again ill post the full log.
     
  19. wikdclown

    wikdclown Network Newbie Member

    Here is the log file https://pastebin.com/CYeJ8nsv This is a log from a reboot up until I noticed the devices disappearing, only thing I removed was Mac id's and name server (opendns) . Another odd thing I noticed was when this happens the fire TV remote app you can download from gplay store doesn't detect the fire TV or stick.
    Don't know why it jumps from Dec to March like that, but that is the entire log.
     
  20. Sean B.

    Sean B. LI Guru Member

    Roughly how much time was there between the reboot of the router and when the issue occurred?
     
  21. wikdclown

    wikdclown Network Newbie Member

    I'd say within a 2 or 3 hour range.
     
  22. Sean B.

    Sean B. LI Guru Member

    Any chance 192.168.1.30 and 192.168.1.4 are cast devices?
     
  23. wikdclown

    wikdclown Network Newbie Member

    192.168.1.14
    15
    16
    17

    Are castable.
     
  24. Sean B.

    Sean B. LI Guru Member

    Only thing that stands out is none of the IP's you listed show up after the router's date/time has been corrected, unlike several other IP's of which are logged renewing their leases with dnsmasq. Note that the date/time correction is a product of rebooting. The firmware is unable to maintain a real time clock through power loss, so it's clock reverts to Dec31 of someyear ( i forget exactly ) until the WAN interface and any connection over it ( tunnel, PPPoE etc ) required for internet connectivity is up and running. It then reaches out to time servers and updates to current. Seems odd those devices didn't renew as other clients did.

    Are any of these devices configured to have a static IP or DHCP reservation in the router? And are you running any custom VLAN configurations?

    And are the connections to these cast devices wireless/wired/mixed?
     
  25. wikdclown

    wikdclown Network Newbie Member

    No, only thing I have assigned a static ip is the pc,i do name them all though so I can keep track of what "belongs" on my network. All 4 devices are wireless and this is default setup so I changed nothing from the default vlan configuration. The only things I changed was turning on adblock, reverse port order enabled Qos and turned on media server.

    Edit:
    [​IMG] Vlan Settings
     
    Last edited: Mar 17, 2018
  26. Sean B.

    Sean B. LI Guru Member

    Under Advanced->Wireless:

    WMM = enabled
    APSD Mode = disabled
    Wireless multicast forwarding = enabled


    Change those settings to match, if any differ, and see if anything changes.
     
  27. wikdclown

    wikdclown Network Newbie Member

    OK i tried those settings and it still does it, i found out though all i have to do is toggle wifi off then on and they will come back, i dont have to reboot entire router. At 11:50 am I did a fresh reboot and at 2:20 pm they had vanished from the network.
    Here is the log.
     
  28. Sean B.

    Sean B. LI Guru Member

    I don't know if this is considered "normal" for multiwan versons of Tomato, but dnsmasq gets killed/restarted a LOT during boot, spread over about a 10 minute period from boot. It's normal to see it kill/restart 2 - 3 even 4 times during the initial boot sequence, because it gets started before the WAN is up and is restarted for each change of the interface. But as many times as in your log spread out over that time frame doesn't seem right. And I notice something this time as well:

    Code:
    Mar 17 12:02:55 unknown daemon.notice miniupnpd[3587]: version 2.0 started
    Mar 17 12:02:56 unknown daemon.notice miniupnpd[3587]: HTTP listening on port 45427
    Mar 17 12:02:56 unknown daemon.info httpd[3590]: Tomato interface started successfully
    Mar 17 12:03:34 unknown user.info adblock: activated - 56648 entries
    Mar 17 12:03:34 unknown daemon.info dnsmasq[3149]: exiting on receipt of SIGTERM
    Mar 17 12:03:35 unknown user.debug init[1]: 255: pptp peerdns disabled
    Mar 17 12:03:36 unknown daemon.info dnsmasq[3642]: started, version 2.76 cachesize 4096
    Mar 17 12:03:36 unknown daemon.info dnsmasq[3642]: compile time options: IPv6 GNU-getopt no-RTC no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset Tomato-helper auth DNSSEC loop-detect no-inotify
    Mar 17 12:03:36 unknown daemon.info dnsmasq[3642]: asynchronous logging enabled, queue limit is 5 messages
    Mar 17 12:03:36 unknown daemon.info dnsmasq-dhcp[3642]: DHCP, IP range 192.168.1.2 -- 192.168.1.51, lease time 1d
    Mar 17 12:03:36 unknown daemon.info dnsmasq[3642]: reading /etc/resolv.dnsmasq
    Mar 17 12:03:36 unknown daemon.info dnsmasq[3642]: using nameserver opendns
    Mar 17 12:03:36 unknown daemon.info dnsmasq[3642]: using nameserver opendns
    Mar 17 12:03:36 unknown daemon.info dnsmasq[3642]: read /etc/hosts - 2 addresses
    Mar 17 12:03:36 unknown daemon.info dnsmasq[3642]: read /etc/dnsmasq/hosts/hosts - 25 addresses
    Mar 17 12:03:36 unknown daemon.info dnsmasq-dhcp[3642]: read /etc/dnsmasq/dhcp/dhcp-hosts
    Mar 17 12:05:11 unknown daemon.info dnsmasq-dhcp[3642]: DHCPDISCOVER(br0) smartphone
    Mar 17 12:05:11 unknown daemon.info dnsmasq-dhcp[3642]: DHCPOFFER(br0) 192.168.1.6 smartphone
    Mar 17 12:05:11 unknown daemon.info dnsmasq-dhcp[3642]: DHCPREQUEST(br0) 192.168.1.6 smartphone 
    Mar 17 12:05:11 unknown daemon.info dnsmasq-dhcp[3642]: DHCPACK(br0) 192.168.1.6 smartphone
    Mar 17 12:06:55 unknown daemon.info dnsmasq-dhcp[3642]: DHCPREQUEST(br0) 192.168.1.11 IPad
    Mar 17 12:06:55 unknown daemon.info dnsmasq-dhcp[3642]: DHCPACK(br0) 192.168.1.11  IPad
    Mar 17 12:06:57 unknown daemon.info dnsmasq-dhcp[3642]: DHCPREQUEST(br0) 192.168.1.12 IPHONE
    Mar 17 12:06:57 unknown daemon.info dnsmasq-dhcp[3642]: DHCPACK(br0) 192.168.1.12 IPHONE
    For all the restarting of dnsmasq, miniupnpd is restarted as well after each event.. except after the last one. In the section of log above you can see miniupnpd having been restarted, followed by the final dnsmasq kill/restart ( you can see following this event there are just DHCP logs ) however miniupnpd is not restarted the last time. This would fit your symptom, as the devices would remain aware of each other as they're still in the multicast group established by miniupnpd before dnsmasq restarted, but sense miniupnpd did not restart after the last event it would not re-establish group control on the interface. The group would eventually timeout.

    I have no idea if this is use-case specific, perhaps @kille72 could comment as to how common this is for a multiwan boot?

    @wikdclown .. For now, and the foreseeable near future, I would recommend for you to reinstate the script from my earlier post in order to retain your cast device functionality. Thank you for your efforts in providing logs and debugging info.
     
  29. wikdclown

    wikdclown Network Newbie Member

    Could it be where I have static names for the devices in dhcp? I went through and deleted them all and so far that's the only thing I've changed and the devices have not disappeared. I hate being unable to know what devices are connected but I guess if that's the problem I'd have to live with it. I'll post back in a few hours if it's still working.
     
  30. Sean B.

    Sean B. LI Guru Member

    No. The first log you posted did not show hostnames configured so I assume it was happening without them anyway? Also, when I asked earlier if you have set anything static, you stated no. How exactly have you configured the host names in the router?
     
  31. wikdclown

    wikdclown Network Newbie Member

    I guess I misunderstood, I had them with static names but did not have them bound to specific ips.
     
  32. Sean B.

    Sean B. LI Guru Member

    And how did you set these static names? Basic->Static DHCP/ARP/IPT?
     
  33. wikdclown

    wikdclown Network Newbie Member

    Yes.
     
  34. Sean B.

    Sean B. LI Guru Member

    That creates a DHCP reservation for the client/IP pair. The IP address and the host name are entered into dnsmasq's hosts file and become "static" as far as the server is concerned. The checkbox in the "Bound to" column is for ARP binding. Still unlikely to be the cause, however it does have an avenue to do so.
     
  35. wikdclown

    wikdclown Network Newbie Member

    Well so far they are all still showing fine (6hrs +) , if by morning they are still there it will be a first. I had assumed it only bound ip if you checked bind to. Is that the only way to setup hostname associated with mac on tomato? If so I guess I'll just change each device hostname on each device to be identifiable.
     
  36. Sean B.

    Sean B. LI Guru Member

    Remove the entries from Basic->Static DHCP/ARP/IPT and use this:

    Code:
    dhcp-host=XX:XX:XX:XX:XX:XX,hostname
    In the custom config box for dnsmasq under Advanced->DHCP/DNS. Where XX's are the MAC address of the client and hostname is the name you want them to have. Repeat the line for each host you want to configure. This leaves out the IP association, which the GUI doesn't let you do.

    If this does fix the issue, then it's more related to how the cast devices you have are handling the minor difference in information sent in the DHCP exchange when a reservation exists. Behavior normal clients ( computers, phones etc ) don't exhibit.
     
    wikdclown likes this.
  37. wikdclown

    wikdclown Network Newbie Member

    Thank you for the info about the dnsmasq. I believe this has remedied the issue, so far after deleting all the stuff from basic the devices have all shown perfectly and none disappear. I appreciate all the help you gave given.
     
    Sean B. likes this.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice