NTP not working on Sangoma SBC

I have configured the Sangona SBC to use europe.pool.ntp.org for its time, but it still tells me it is stuck in 2012.

Do I need to do anything funky to get NTP to work?

Manually set the time once to something close?

Some devices will not adjust NTP over a certain difference.

No, just tried that, and I set it to the correct date, but 5 hours behind, but it just stays 5 hours behind.

I’ve also taken a wireshark, and there is no NTP traffic on the wire.

Do I have to do someting to kick NTP into life, or is it just broken? (In which case that sucks, as all the logs have the wrong date/timestamp)

Try an IP address instead of FQDN

Ah, good shout. But sadly no. Still no NTP updates even using an IP address.

What output do you get from ntpq -p ?

It sounds like you may have a problem with a firewall somewhere blocking NTP traffic. I see several discussions on Reddit and other places about this – have you been able to use NTP on any other systems on your network?

I would take that to the folks who sold it to you, any ‘Session Border Controller’ that doesn’t know what the time is or how to get it is, to use a technical term, f*&^ed

from what I have been reading some ISPs are blocking the default ntp port – not sure where, certainly none of mine do.

I don’t think its a networking issue. I have 4 Raspberry Pi’s here on the same subnet which are set up to do NTP and they are all working ok.

Actually, I’ve just realised, it can’t be a Firewall issue as I’m not even seeing any NTP packets coming out of the device itself when I look at a Wireshark trace.

So, the solution to this issue was that I had 2 IP addresses configured on eth0. (The Sangoma training videos omitted to tell you to remove the default IP address of 192.168.168.2). Subsequently the NTP packets packets (which were actually being generated ok, I just had an issue with wireshark) were coming from the default IP address, which of course was not in the subnet I was using, so replies couldn’t get back.

This also prevented any other comms out to the internet for updates etc. and as a result, the SBC shut itself down after a day or so.

Simply removing the default IP address from eth0 solved all my issues.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.