1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

NTP redirect failing

Discussion in 'TiVo Premiere DVRs' started by forum1, Feb 2, 2018.

  1. forum1

    forum1 TiVo user since 2000

    88
    8
    May 24, 2011
    Apparently the TiVo Premiere doesn’t like having its NTP requests redirected to a local NTP server. With a firewall setup to redirect destination UDP port 123 the TiVo’s service call fails, complaining it can’t set the clock. This is very peculiar to me for multiple reasons:
    1. Other Linux and Windows based systems on the network can successfully obtain time in this manner. I can only assume that the TiVo expects some sort of hard-coded NTP response that it isn’t getting from other NTP servers.
    2. There are many old posts on various forums about how redirection is a solution to other TiVo NTP issues, although with no confirmations I can see, so I question if that advice was ever valid and if so when/why did things change?
    3. The TiVo’s error message indicates that not only is UDP 123 blocked but that TCP 37 is blocked as well. This leads me to believe that the legacy Time protocol is still supported, but clearly the TiVo isn’t successfully falling back to it. The local firewall is not configured to redirect UDP 37 traffic, so everything there should pass unfettered.
    4. I find it odd that the TiVo can't obtain the time from within a service call session instead of making a discrete NTP, Time, etc. request a blocking step for the service call.

    Is there a way get the current TiVo software to play nice with an NTP server other than the TiVo service one? Any other insights are welcome.
     
  2. JoeKustra

    JoeKustra in the other Alabama TCF Club

    10,409
    998
    Dec 7, 2012
    Ashland, PA...
    Plenty of discussion of that error:

    tivo fails on TCP port 37

    However, it's not related to the failing service connection. First, run the Network Troubleshooting/Internet Connection. Fail or Pass? Then repeat a service connection.

    Yesterday my service connection failed at setting clock on two TiVo boxes. Each were ok on the second try. However, my failure was C125 which indicates a failure of Ports 123 and 37. For a really good discussion of time and TiVo -> Clock off in Roamio by 2 minutes
     
  3. forum1

    forum1 TiVo user since 2000

    88
    8
    May 24, 2011
    My error is also C125, but in my case I'm fairly confident it's the UDP 123 redirect because I can turn the redirect off, run a service connection, and all is well. Turn the redirect on, run another service connection, and it fails. Bone dead simple. 100% reproducible thus far. And yes, I saw those other 4 and 16 page threads. Unless there is some buried tidbit in there which you can point me to all my previous observations/questions still stand.
     
  4. JoeKustra

    JoeKustra in the other Alabama TCF Club

    10,409
    998
    Dec 7, 2012
    Ashland, PA...
    Nope. Seems you have it under control.
     
  5. forum1

    forum1 TiVo user since 2000

    88
    8
    May 24, 2011
    Bump - Does anyone have recent experience with redirecting TiVo NTP requests to a local NTP server, either with Premiere or otherwise? The "many old posts on various forums" I mentioned (Item 2) date back to the Series 1 and 2 heydays so of course a lot of time has passed.
     
  6. JoeKustra

    JoeKustra in the other Alabama TCF Club

    10,409
    998
    Dec 7, 2012
    Ashland, PA...
  7. kdmorse

    kdmorse Well-Known Member

    5,628
    286
    Jan 29, 2001
    Germantown, MD
    Just to clarify, you did something akin to the following? (Obviously interface names and addresses will differ)

    Code:
    # Redirect all NTP requests that come from the Tivo, on the internal interface, back into a Pi
    iptables -t nat -I PREROUTING -i int -s 10.1.1.216 -p UDP --dport 123 -j DNAT --to-destination 10.1.1.13:123
    
    # Ensure any firewall rules permit the traffic
    # Also have a RELATED/ESTABLISHED rule (not shown here), or addding a rule to permit the replies will be required.
    iptables -I FORWARD -i int -s 10.1.1.216 -o int -d 10.1.1.13 -p UDP --dport 123 -j ACCEPT
    
    # Ensure the redirected packets as source natted so the reply is forced back through the router to be un-natted
    iptables -t nat -I POSTROUTING -o int -p UDP --dport 123 -s 10.1.1.216 -d 10.1.1.13 -j MASQUERADE
    
    And of course running iptables -L -vn, and iptables -t nat -L -vn, after an attempt to ensure the rules are all getting hit, and the counters are incrementing after each attempt would be a smart thing to do.

    There are lots of ways to do it (by source ip, by interface, by target ip, etc..), but I've never had any trouble.

    After doing the above, I could trace all my units ntp queries getting bounced Tivo -> Router -> Pi | Pi -> Router -> Tivo. I was able to screw with the clock on my Pi, fudge it as a stratum 3 server, run a call, and three tivos would jump to the new time. (Getting ntpd on the Pi to lie was the hardest part. It really, really didn't want to).

    My Tivo's are now thoroughly confused clock wise ;)

    So, against Roamio's and Bolts, I've had no problems with directing the traffic to a local NTP server, or localhost, or redirected it externally to other public NTP servers.

    But I can't speak to Premiers specifically, not without dragging one out of the closet.

    Although I'll add that if putting a redirect in causes port 123 to report closed/failed, you don't have it redirecting correctly. It should be 100% transparent to the Tivo. Any shenanigans detectable by the Tivo are insufficiently transparent and shenaniganny.

    Also, you might want to check to see if your unit is pointing at sjr1/2/3 in the first place. They seem to be tweaking things, it may not...

    If you choose to continue, and are still having problems, you'll probably want to run a tcpdump -vnnl udp -i internalinterfacename port 123, run a daily call, and examine or post the results. Equivalent output of ntpdate -q, or w32tm pointed at your 'local' time source, and at the servers you're trying to redirect from would be a good idea as well.

    Some queries follow for reference:

    Note that I'm clearly talking to three different servers

    w32tm /monitor /computers:204.176.49.10,204.176.49.11,204.176.49.12,1.2.3.4,5.6.7.8
    204.176.49.10[204.176.49.10:123]:
    NTP: +0.0231484s offset from local clock
    RefID: time3.apple.com [17.254.0.31]
    Stratum: 2
    204.176.49.11[204.176.49.11:123]:
    NTP: +0.0747477s offset from local clock
    RefID: time3.apple.com [17.254.0.31]
    Stratum: 2
    204.176.49.12[204.176.49.12:123]:
    NTP: +0.0921546s offset from local clock
    RefID: time3.apple.com [17.254.0.31]
    Stratum: 2
    1.2.3.4[1.2.3.4:123]:
    NTP: error ERROR_TIMEOUT - no response from server in 1000ms
    5.6.7.8[5.6.7.8:123]:
    NTP: error ERROR_TIMEOUT - no response from server in 1000ms
    Now I'm clearly talking to the same server, 5 times.

    w32tm /monitor /computers:204.176.49.10,204.176.49.11,204.176.49.12,1.2.3.4,5.6.7.8
    204.176.49.10[204.176.49.10:123]:
    NTP: -0.0132025s offset from local clock
    RefID: ntp2.wiktel.com [69.89.207.199]
    Stratum: 3
    204.176.49.11[204.176.49.11:123]:
    NTP: -0.0137096s offset from local clock
    RefID: ntp2.wiktel.com [69.89.207.199]
    Stratum: 3
    204.176.49.12[204.176.49.12:123]:
    NTP: -0.0132652s offset from local clock
    RefID: ntp2.wiktel.com [69.89.207.199]
    Stratum: 3
    1.2.3.4[1.2.3.4:123]:
    NTP: -0.0133640s offset from local clock
    RefID: ntp2.wiktel.com [69.89.207.199]
    Stratum: 3
    5.6.7.8[5.6.7.8:123]:
    ICMP: error IP_REQ_TIMED_OUT - no response in 1000ms
    NTP: -0.0108239s offset from local clock
    RefID: ntp2.wiktel.com [69.89.207.199]
    Stratum: 3
    w32tm /monitor /computers:204.176.49.10,204.176.49.11,204.176.49.12,1.2.3.4,5.6.7.8
    204.176.49.10[204.176.49.10:123]:
    NTP: +7857.4707248s offset from local clock
    RefID: 'INIT' [0x54494E49]
    Stratum: 0
    204.176.49.11[204.176.49.11:123]:
    NTP: +7857.4674896s offset from local clock
    RefID: 'INIT' [0x54494E49]
    Stratum: 0
    204.176.49.12[204.176.49.12:123]:
    NTP: +7857.4660452s offset from local clock
    RefID: 'INIT' [0x54494E49]
    Stratum: 0
    1.2.3.4[1.2.3.4:123]:
    NTP: +7857.4705275s offset from local clock
    RefID: 'INIT' [0x54494E49]
    Stratum: 0
    5.6.7.8[5.6.7.8:123]:
    NTP: +7857.4677951s offset from local clock
    RefID: 'INIT' [0x54494E49]
    Stratum: 0

    ntpdate -q 10.1.1.13
    server 10.1.1.13, stratum 16, offset 7857.474066, delay 0.02609
    9 Feb 01:13:30 ntpdate[9103]: no server suitable for synchronization found
    w32tm /monitor /computers:204.176.49.10,204.176.49.11,204.176.49.12,1.2.3.4,5.6.7.8
    204.176.49.10[204.176.49.10:123]:
    NTP: +7857.4780645s offset from local clock
    RefID: (unknown) [0x00017F7F]
    Stratum: 3
    204.176.49.11[204.176.49.11:123]:
    NTP: +7857.4811496s offset from local clock
    RefID: (unknown) [0x00017F7F]
    Stratum: 3
    204.176.49.12[204.176.49.12:123]:
    NTP: +7857.4838748s offset from local clock
    RefID: (unknown) [0x00017F7F]
    Stratum: 3
    1.2.3.4[1.2.3.4:123]:
    NTP: +7857.4821176s offset from local clock
    RefID: (unknown) [0x00017F7F]
    Stratum: 3
    5.6.7.8[5.6.7.8:123]:
    NTP: +7857.4794523s offset from local clock
    RefID: (unknown) [0x00017F7F]
    Stratum: 3

    ntpdate -q 10.1.1.13
    server 10.1.1.13, stratum 3, offset 7857.474842, delay 0.02612
    9 Feb 01:15:26 ntpdate[9283]: step time server 10.1.1.13 offset 7857.474842 sec

    No idea if any of that helps at all.

    Edit: Oh good lord is my tivo confused. To many lies. My last daily call is now next week...
     
    Last edited: Feb 9, 2018
  8. forum1

    forum1 TiVo user since 2000

    88
    8
    May 24, 2011
    kdmorse, thanks for the response! Yes, my firewall (pfSense 2.4.2-p1) using pf is setup similarly to yours using iptables. Assorted Windows and Linux nodes on the same LAN segment are successfully getting their time via the NTP redirect.

    As far as the NTP responses from my local NTP server (the same pfSense system), on a Windows client w32tm returns the results with an incremented stratum and pass through RefID (the pfSense NTP is synced with multiple stratum 1 hosts), like your redirected "tells the truth" example. I assume your TiVo units are happy with the redirected truthful responses and that I don't need to get serious about generating NTP "lies". If this is not the case please let me know.

    I finally got around to doing a UDP-123 filtered packet capture, something I'd been meaning to do for a while, and found some pretty screwy stuff. After the Premiere makes its first NTP request to a NIST server at 129.6.15.27 the pfSense response looks good. On the second query to the same NIST server the pfSense response comes back as unsynchronized (unspecified or invalid stratum, unidentified reference source "RATE", etc.). Then it gets worse. The third and fourth queries to the same NIST sever from the Premiere go unanswered, at least using the PCAP filter I had in place. I'll need to cast a wider PCAP net to get a better picture of what else the Premiere/pfSense are saying to each other, but with what I have now I can see that the Premiere moves on to three other NIST servers (129.6.15.28, 132.163.96.4, 132.163.97.1), making four queries to each, none of which get a response from pfSense. But if I go to w32tm I can query the same NIST servers over and over again with no problem (all answered by pfSense). One other thing I will note is that the TiVo is sending NTP version 3 requests while w32tm is sending NTP version 1 requests.

    So there are a number of variables that are in play here. Just what I need, more stuff to debug. In the end it may be an issue with the NTP server in pfSense, but of course it's only manifesting as an issue with the TiVo, which I find is a recurring theme.

    Again, thanks for the response!
     
  9. Andrea_SAN

    Andrea_SAN New Member

    1
    0
    Friday
    This seems to have to do with the frequency the Client (TIVO) is sending requests to the NTP Server.
    Have you compared with other Clients?
     

Share This Page