Ntpd / gps need some love part II

[pete]

You know this expanded ntpd and serial gps support is already pulled into 2.2Alpha pfSense core, right?

No I did not know.

Thank-you charliem and Steve

Building new box / hardware while concurrently leaving old up and running which really doesn't have anything to do with OP though.

Where is 2.2Alpha core release at?

[stephenw10]

http://snapshots.pfsense.org/

I had a box running an older snapshot with no issues at all. I had to take it online to move it.
Check the 2.2 feedback subforum for any reports of issues. Be aware that any particular snapshot could be broken by some new update, though they are mostly good at this point.

Steve

[pete]

Thank-you Steve!

[robi]

If your box fails to boot properly/boot takes too long after applying the patch, consider checking if BSD's serial port driver was properly loaded:
https://forum.pfsense.org/index.php?topic=66601.msg388380#msg388380

[pete]

Thanks Robi!

If your box fails to boot properly/boot takes too long after applying the patch, consider checking if BSD's serial port driver was properly loaded:
https://forum.pfsense.org/index.php?topic=66601.msg388380#msg388380

Yup; had no issues with the 2.1.2 update and patch.  It seems I can't get it "up" with the 2.1.3 update; although it did work once from a cold boot; then it quit working on subsequent reboots.  Thought it was me and will have a look at the link above.

Yeah; with new 2.2 alpha seeing other issues; unrelated to OP but weird stuff like configuring a DHCP scope and having the application mess with my subnet, mask type stuff (well basic math problems not fat fingering anything).

I noticed that the new added integrated NTPD stuff didn't work for me on the 2.2 Alpha. It does see the serial port com; but it appears to mess with the configuration such that it doesn't work with my Sure GPS with PPS configuration.

[pete]

Yup; still no go with 2.1.3 and playing some today with 2.2.

Creates the GPS0 device.  "cat gps0" isn't showing anything.  Tried both generic and suregps setups.  (with 2.1.2 I could get both to work).

Same issue is seen on both boxes.

Looking to see this:

ntpq -c clockvar
assID=0 status=0011 clk_okay, last_clk_17,
device="NMEA GPS Clock",
timecode="$GPGLL,4134.4393,N,08800.6282,W,193236.078,A*24", poll=21,
noreply=1, badformat=0, baddata=0, fudgetime1=155.000, stratum=0,
refid=GPS, flags=5

and getting this instead:

[2.1.3-RELEASE][root/dev(3): ntpq -c clockvar
assID=0 status=0000 clk_okay, last_clk_okay,
device="Undisciplined local clock",
timecode=, poll=2,
noreply=0,badformat=0, baddata=0, stratum=12,
refid=76.79.67.76, flags=0[/quote]

[charliem]

What's the output of:

dmesg | grep uart (to be sure kernel is finding the uart)

cd /dev; ls -l cua* gps* pps* (make sure devices and links are created properly)

stty -f /dev/cuau0 (assuming cuau0 is found above, tells you current baud rate of the port)

cat /dev/cuau0 (should stream NMEA sentences)

All this should work regardless of how ntpd is configured (or mis-configured), so verify this stuff before moving on to ntpd.  Maybe you've already done this.

If this fails, do you have another machine with a serial port you can test your GPS units with?  Even a USB serial adapter would be OK for debugging NMEA sentences, since you are not yet concerned about PPS.  If you have a windows machine, this is one of the best NMEA monitoring / setup programs I've used: http://homepage2.nifty.com/k8/gps/file/NmeaMon.htm  You can select your chipset and send configuration strings from a populated library.

[pete]

Thank-you Charlie.

Yup; was testing it originally looking at the sentences with PHP stuff on PFSense 2.1.1 & 2.1.2.  Worked just fine in generic or SureGPS modes.  I did unpower and repower the SureGPS to make sure something didn't go amiss.  The SureGPS has been modded to provide PPS (well actually a few months back).  I had been using it for years though without the PPS modification.

http://www.satsignal.eu/ntp/Sure-GPS.htm

dmesg | grep uart (to be sure kernel is finding the uart)

root(1): dmesg | grep uart
uart2: <16550 or compatible> port 0x3e8-0x3ef irq 10 on acpi0
uart2: [FILTER]
uart3: <16550 or compatible> port 0x2e8-0x2ef irq 11 on acpi0
uart3: [FILTER]
uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
uart0: [FILTER]
uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0
uart1: [FILTER]

Just noticed that no PPS is here:

ls -l cua* gps* pps*
crw-rw–--  1 uucp  dialer    0,  80 May 13 15:41 cuau0
crw-rw----  1 uucp  dialer    0,  81 May 13 15:38 cuau0.init
crw-rw----  1 uucp  dialer    0,  82 May 13 15:38 cuau0.lock
crw-rw----  1 uucp  dialer    0,  86 May 13 15:38 cuau1
crw-rw----  1 uucp  dialer    0,  87 May 13 15:38 cuau1.init
crw-rw----  1 uucp  dialer    0,  88 May 13 15:38 cuau1.lock
crw-rw----  1 uucp  dialer    0,  51 May 13 15:38 cuau2
crw-rw----  1 uucp  dialer    0,  52 May 13 15:38 cuau2.init
crw-rw----  1 uucp  dialer    0,  53 May 13 15:38 cuau2.lock
crw-rw----  1 uucp  dialer    0,  57 May 13 15:38 cuau3
crw-rw----  1 uucp  dialer    0,  58 May 13 15:38 cuau3.init
crw-rw----  1 uucp  dialer    0,  59 May 13 15:38 cuau3.lock
lrwxr-xr-x  1 root  wheel        10 May 13 15:41 gps0 -> /dev/cuau0

stty -f /dev/cuau0
speed 4800 baud;
lflags: -isig -iexten -echo
iflags: -ixon -ixany -imaxbel ignbrk -brkint ignpar
oflags: -opost -onlcr tab0
cflags: cs8 -parenb -hupcl clocal
discard dsusp  eof    eol    eol2    erase  erase2  intr    kill
^@      ^@      ^@      ^@      ^@      ^@      ^@      ^@      ^@
lnext  min    quit    reprint start  status  stop    susp    werase
^@      0      ^@      ^@      ^@      ^@      ^@      ^@      ^@

After the above just noticed my PHP pages are gone…cuz I did a Firmware update yesterday back to 2.1.3 (virgin) out of frustration.

Instead of patching (which was working sort of); do you have a copy of the current PHP files for 2.1.3 that I can just copy over again?

cat /dev/cuau0 or cat/dev/gps0

is how I was originally testing and it worked fine.

I did modify the sure gps to provide PPS and that too was working fine…..well its been a few months back now...

The original set up though started some 10 years ago on a Wintel server running Tardis acting as my NTP server.  I can move the serial connection back to watch the chatter today....

[pete]

Started from scratch here with the PFSense 2.1.3 box;(virginal) as I reinstalled the firmware upgrade.

I had patched 2.1.2 with no issues.  I have not run the patch cuz when I did a couple of days ago; it did not work.

I am curious why I see the two messages regarding the issues with the patch.

Will test the PFsense 2.2 Alpha version again later on today with integrated stuff today.

[charliem]

I haven't used the built-in patching tool, so I'm no help there, sorry.

Have you got the GPS / Serial ports straightened out?  I'd worry about that first and worry about ntpd/gui second.  I see you have (4) serial ports that show up in the bios.  Are they all four wired to headers on the MB?  And all 4 brought out to a connector?  Silly question, but have you tried your GPS on each connector?

I also see (in another thread) you used the entry in loader.conf.local to get two of your serial ports to show up, attaching via isa rather than acpi.  Any reason you only enabled two of them?  Maybe having both isa and acpi involved changed the order, and what was previously COM1 is now COM3?

[robi]

@pete:

stty -f /dev/cuau0
speed 4800 baud;

Note that SureGPS board uses by default 9600 baud, and there's an init procedure also which sets it to 9600. So don't forget to also tell NTPd to connect at 9600.
This is because some reported that in certain cases, after longer power loss, the board comes back at 9600, even though you've set it to different value earlier. There is a way to hard-code it better in the card, as stated in their doc, but I don't see the reason to do that. As I've noticed, FreeBSD also defaults at 9600 so all should match by default.

[robi]

@pete:

I did modify the sure gps to provide PPS and that too was working fine…..well its been a few months back now...

The original set up though started some 10 years ago on a Wintel server running Tardis acting as my NTP server.  I can move the serial connection back to watch the chatter today....

I also suggest to check if your board is still working fine, sending NMEA senteces. You can also chech the PPS functionality with this Serial Port LEDs little Windows app. You should see the DCD pin in action.

[pete]

Thank you robi and charliem.

Curious if I did follow the patch update procedure correctly?  Why do I see the errors?

Do you have a copy of the zipped files for  2.1.3 such that I can just copy them over instead?

Its strange though that I all I did was patch up 2.1.2 and it worked right away.

All of the serial ports connect to the mother board but always used first serial port and it worked.  I will change the other serial ports to ISA.  With last redo of FW I just changed one of them.

Yup; when I first updated to 2.1.3 noticed the issue and unpowered and powered up SureGPS.  I then just looked at it with a terminal and it worked fine.

Today just hooked up my laptop and its kicking out NMEA sentences just fine at 9600 baud.  Tested the PPS and saw it flashing.  After a bit it quits flashing.  Restarting the application I see it flashing again.

I don't recall now if this is what it always did or something new.  It looks to be fine to me.

The GPS is in the attic three floor up (well and another staircase to the attic).  I decided today to remote power it in case I do have to power it on or off.

This is interesting….just plugged the RS-232 cable back to the PFSense box and looked at the serial output.

I see stuff now on GPS0 (wrong speed) but I didn't see it before.  Trying  to set the baud rate to 9600 using stty...so I can see it working before I patch it again.

Patched anyways.  Not seeing the new PHP pages though.

Turned on the 2.2 Alpha.  It appeared to work for a few minutes where I could see NMEA sentences just fine.  I then save the settings and the baud rate changed back such that I saw hash.  Doesn't create a PPS0 device from what I can see.

Trashed it though saving the NTP serial settings.

Warning: fopen(/tmp/config.lock): failed to open stream: Device not configured in /etc/inc/util.inc on line 127 Warning: flock() expects parameter 1 to be resource, null given in /etc/inc/util.inc on line 164 Warning: fclose() expects parameter 1 to be resource, null given in /etc/inc/util.inc on line 165

[robi]

Here you go.

Try overwriting the files. Are you on a full HDD install, or NanoBSD?

ntp_gps_full_pack_213.zip.jpg

[pete]

Thank-you Robi!

Updated files.  Sync to 11 satellites took less than 5 seconds.  gps0 and pps0 are there under devs.

I can see output now just fine with gps0.

[2.1.3-RELEASE][rootat]/dev(5): ntpq -c clockvar
assID=0 status=00f2 clk_okay, last_clk_242,
device="NMEA GPS Clock",
timecode="$GPGGA,142307.000,4134.4394,N,08800.6301,W,2,9,1.03,223.7,M,-34.0,M,0000,0000*67",
poll=17, noreply=0, badformat=111, baddata=0, fudgetime2=400.000,
stratum=0, refid=GPS, flags=5

You have made my day today Friday, 16th of May 2014 a great day!

Geeze; its like Christmas near Chicago today; snow and all.

[robi]

Glad to help. But I've got no clue why you couln't apply the patch… I did on 3 different boxes so far, and had no problems...

[pete]

Thank you Robi.

Yup for whatever reason new application cannot get to internet NTP servers.  I can ping them just fine though.

Playing with this stuff for years did originally block the NTP ports on my firewall and just used my GPS NTP time server for home network time.

Ideally I am fine with this scenario of not having to utilize NTP on the internet.

Is there a way to disable the use of internet NTP servers with this application?

The patch did work fine on 2.1.2.  I updated to 2.1.3 and then had issues with the patches (didn't work)

It was probably me mucking up the 2.1.3 build.

On a lark will rebuild box #2 with current 2.1.3 from scratch and will try patch and ….

Going to try this with another box (well #3) which is just a faster CPU and more memory.

May 17 06:19:46 ntpd[52732]: Listen and drop on 0 v6wildcard [::]:123
May 17 06:19:46 ntpd[52732]: proto: precision = 1.676 usec (-19)
May 17 06:19:46 ntpd[52710]: Command line: /usr/local/sbin/ntpd -g -c /var/etc/ntpd.conf -p /var/run/ntpd.pid
May 17 06:19:46 ntpd[52710]: ntpd 4.2.7p411@1.2483-o Fri Mar 28 00:14:21 UTC 2014 (1): Starting
May 17 06:19:45 ntpd[4636]: ntpd exiting on signal 15 (Terminated: 15)

I found a related thread here about putting in static routes to the IP's of the NTP servers in Internetlandia which didn't work for me though.

[pete]

Well found another issue or concern.  I don't know if this is the right place to post.

It appears that I cannot sync my NTP from the PFSense box for whatever reason.

I did a quickie test from a Wintel enterprise server and an Ubuntu 14.04 server and both are not getting NTP from PFSense and do get it fine from the internet NTP servers.  I found this to be happening by looking at my IP HD CCTV cameras which were syncing to the PFSense box and the time was way off on these devices.

Here is the "test" on the Wintel box using Tardis.  NTP / 123 is not blocked as it's getting it directly from the internet which is odd to me.

This is indicatory though that NTP from the internet does work; but doesn't work with PFSense / GPS NTP update stuff.

This sort of defeats the purpose of using NTP with a GPS/PPS on the PFSense box for me.

On a Wintel enterprise server I see:

C:\WINDOWS\system32>tardisnt debug
2014/05/19 08:24:55.39,Debug: RFC868 TCP Server started
2014/05/19 08:24:55.39,Debug: RFC868 UDP Server started
2014/05/19 08:24:55.39,Debug: RFC867 TCP Server started
2014/05/19 08:24:55.39,Debug: RFC867 UDP Server started
2014/05/19 08:24:55.45,Debug: SNTP Server started
2014/05/19 08:24:55.45,Debug: SNTP Client started
2014/05/19 08:24:55.45,Info : SNTP Client connecting to IP_OF_PFSense_Gateway
2014/05/19 08:25:10.47,Warn : SNTP Client No reply
2014/05/19 08:25:12.47,Debug: SNTP Client Stopping
2014/05/19 08:25:12.47,Debug: SNTP Client started
2014/05/19 08:25:12.47,Info : SNTP Client connecting to 2.pool.ntp.org

On an Ubuntu 14.04 box I see:

19 May 08:43:41 ntpdate[17929]: no servers can be used, exiting
root@ICS-ZM2:~# ntpdate IP_OF_PFSENSE_BOX
19 May 08:43:59 ntpdate[17937]: no server suitable for synchronization found
root@ICS-ZM2:~#
root@ICS-ZM2:~# ntpdate 1.pool.ntp.org
19 May 08:45:27 ntpdate[17979]: step time server 162.210.196.6 offset -5.106127 sec
root@ICS-ZM2:~#

NTP Log shows:

May 19 23:04:12 ntpd[86951]: ntpd 4.2.7p411@1.2483-o Fri Mar 28 00:14:21 UTC 2014 (1): Starting
May 19 16:28:55 ntpd[86135]: unable to bind to wildcard address :: - another process may be running - EXITING
May 19 16:28:55 ntpd[86135]: proto: precision = 1.676 usec (-19)
May 19 16:28:55 ntpd[85984]: Command line: /usr/local/sbin/ntpd -g -c /var/etc/ntpd.conf -p /var/run/ntpd.pid
May 19 16:28:55 ntpd[85984]: ntpd 4.2.7p411@1.2483-o Fri Mar 28 00:14:21 UTC 2014 (1): Starting
May 19 16:28:40 ntpd[81621]: unable to bind to wildcard address :: - another process may be running - EXITING
May 19 16:28:40 ntpd[81621]: proto: precision = 1.676 usec (-19)

Looking at above relating to NTPD in general found something relating to having NTPDATE on startup.

Something called a race condition between NTPD and NTPDate.

I didn't see it anywhere though.

[pete]

Apologies guys.

The issue was related to the Access restrictions.  I had left it at the defaults.  I changed it and everything is now working.

Is there a way to add a second NTP connection (well GPSd) to this configuration?

[robi]

@pete:

Is there a way to disable the use of internet NTP servers with this application?

I think you can either delete all external NTP servers from your config, or add only one pointing to localhost. Or just tick "noselect" for them, and NTP service will not use them for timing.

If you want to use only your GPS and PPS as a time source, don't forget to set "All" at the "NMEA sentences" option. This will allow to extract the relative time from the NMEA sentences in text format. PPS will be used as usual to keep the time exact within the second.
I tested this by explicitly moving my test pfSese box's date and time to some random value in the past. Pulled the WAN cable, and let the box boot. NTPd just took the correct date and time from the GPS's NMEA data coming in though the serial port, and set the system date and time accordingly. Plus PPS accuracy included. No WAN access at all.