Ntpd / gps need some love part II



  • As the last thread got locked starting over again here.

    Currently utilizing the following:

    1 - Installed new from scratch PFSense Version 2.1.3 (current it locked up booting from a regular CD/DVD USB ROM drive.
    2 - Will patch said version with: (Selfish right now and all I care about is using my GPS/PPS setup; nothing much else).

    Updated this post with the 213 zipped files.  I also removed the patch as it didn't work for me with 213 (212 worked).

    Just a mention here relating to my personal upgrade to 2.2 Alpha.  The files (php) and everything is in the menus just fine.  But it didn't work for me (maybe its just me though).

    ntp_gps_full_pack_213.zip.jpg



  • Version 1.2.3 ????


  • Netgate Administrator

    Slightly confused Pete. Is this a report of working using Robi's most recent patch or are you looking for help with a 'lock up' problem?  :-\ More details please if looking for help.

    Steve



  • Is this a report of working using Robi's most recent patch

    Thank-you sephenw10

    Yes; more to continue the GPS (ntpd / GPS need some love part II) thread.  Well now it should probably be part III.

    Here modded my PFSense box in Vivo sort of building new on another piece of media (well in the same box) which concurrently leaving my older updated PFSense running.

    BTW what would turn this modification to an official PFSense "plugin"?  What can I do to help this endeavor along?

    I mean would it be something that folks would like to do; or do PFSense users not really care about said update?



  • @pete:

    BTW what would turn this modification to an official PFSense "plugin"?  What can I do to help this endeavor along?

    I mean would it be something that folks would like to do; or do PFSense users not really care about said update?

    I guess you mean a package rather than a plugin.  You know this expanded ntpd and serial gps support is already pulled into 2.2Alpha pfSense core, right?  So that means any work packaging it would have limited lifetime of basically one release, v2.1.3.  IMHO not worth the effort, especially when there is a nice patchset for 2.1.3, and 2.2 is supposed to have a relatively short development cycle.


  • Netgate Administrator

    ^Yep. Already in 2.2 and it's unlikely there will be another 2.1.x release. Although I thought that before 2.1.2 and 2.1.3! I guess further security issues aside.  :)

    Steve



  • 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?


  • Netgate Administrator

    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



  • Thank-you Steve!



  • 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



  • 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.



  • 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]



  • 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.



  • 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....



  • 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.








  • 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?



  • @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.



  • @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.



  • 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




  • Here you go.

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

    ntp_gps_full_pack_213.zip.jpg



  • 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.



  • 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...



  • 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.




  • 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.



  • 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?






  • @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.



  • 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.

    Thank you Robi.  Yup have another GPS in a different part of the house such that I have it connected to a Wintel Server which I can point PFSense to.



  • Just a heads-up here for serial GPS users.

    I'm running 2.2 alpha with an Adafruit GPS, and noticed a number spikes in the logs, with corresponding spikes in the ntp rrd graphs:

    May 20 22:19:50 pfsense ntpd[16682]: 0.0.0.0 c615 05 clock_sync
    May 20 22:19:51 pfsense ntpd[16682]: 0.0.0.0 0413 03 spike_detect -0.175410 s
    May 20 22:19:57 pfsense ntpd[16682]: 0.0.0.0 041b 0b leap_event
    May 20 22:20:07 pfsense ntpd[16682]: 0.0.0.0 0415 05 clock_sync
    May 20 22:24:55 pfsense ntpd[16682]: 0.0.0.0 041d 0d kern PPS enabled
    May 23 05:32:39 pfsense ntpd[16682]: 0.0.0.0 0413 03 spike_detect -0.249206 s
    May 23 05:32:55 pfsense ntpd[16682]: 0.0.0.0 0415 05 clock_sync
    May 23 21:49:59 pfsense ntpd[16682]: 0.0.0.0 0413 03 spike_detect -0.142089 s
    May 23 21:50:15 pfsense ntpd[16682]: 0.0.0.0 0415 05 clock_sync
    May 24 05:20:07 pfsense ntpd[16682]: 0.0.0.0 0413 03 spike_detect -0.138790 s
    May 24 05:20:23 pfsense ntpd[16682]: 0.0.0.0 0415 05 clock_sync
    May 25 20:47:35 pfsense ntpd[16682]: 0.0.0.0 0413 03 spike_detect -0.397899 s
    May 25 20:48:07 pfsense ntpd[16682]: 0.0.0.0 0415 05 clock_sync
    
    

    Then I noticed a significant number of replies from the GPS couldn't be parsed properly by ntpd (badformat).  Here, 166 of 34901 responses have had errors:

    [2.2-ALPHA][root@pfsense.localdomain]/var/log(11): ntpq
    ntpq> cv
    associd=0 status=00f2 15 events, clk_bad_format,
    device="NMEA GPS Clock",
    timecode="$GPGGA,132646.000,3666.4384,N,08999.4250,W,2,8,0.98,224.9,M,-32.5,M,0000,0000*61",
    poll=34901, noreply=0, badformat=166, baddata=0, fudgetime2=400.000,
    stratum=0, refid=pps, flags=5
    ntpq> q

    Looking further, I saw that my gps.init strings did not properly turn off the sentences as I had intended.  Turns out I had the wrong checksum in the command I entered :)  Once I got the GPS sending only the $GPGGA sentence, I haven't had any spikes (so far).  If I was ambitious, I'd go back in my clockstats file, and see what the strings looked like around the times the spikes were detected.  Hopefully it's fixed though.

    So, moral of the story:

    • Verify your checksums if you enter init commands by hand, and
    • Turn off extra NMEA sentences!


  • I suggest to use ZDA or ZDG option instead of GGA when considering sentences in case you have problems like that, as $GPZDA is less than half in size than $GPGGA, it contains only Date & Time. In order to lessen even more the stress for ntpd to process the string every second.



  • Thank-you Robi!

    Did a quickie check this morning and noticed that it wasn't running.  Enabled ZDA or ZDG option and all is well this morning.

    I wasn't paying attention.  Google location stuff was eye candy but I liked the number of satellites it was getting.

    ntpq> cv
    localhost: timed out, nothing received
    ***Request timed out
    ntpq>

    <changed and="" saved="" settings="" here="">ntpq> cv
    assID=0 status=0000 clk_okay, last_clk_okay,
    device="NMEA GPS Clock", timecode="$GPZDA,120846.000,28,05,2014,,*57",
    poll=2, noreply=0, badformat=0, baddata=0, fudgetime2=400.000,
    stratum=0, refid=GPS, flags=5
    ntpq></changed>

    So I calculated the checksum and edited the command text saving the correct check sum for each of the command lines.




  • I just found a couple of small issues, like typos and html display stuff, fine-tuned a bit SureGPS defaults and noticed that RRD graphs were not plotting on 2.1.3, fixed that.
    If applied patch using system patches package, revert the old patch, and apply this new one, or simply overwrite the files on the system, and press "Save" on the Serial GPS page.
    Pushed the fixes to GitHub also, for 2.2.

    (Edit: attachments removed, read further for updates)



  • Thanks Rob.  For the update posted do I need to recalculate the checksum stuff?

    I did notice while using FF after the save on the serial GPS page; the page looked a bit weird.

    Here is the adjusted checksums for the SureGPS.

    $PMTK225,025
    $PMTK314,1,1,0,1,0,5,0,0,0,0,0,0,0,0,0,0,0,1,0
    23
    $PMTK301,220
    $PMTK397,0
    2D
    $PMTK1023F
    $PMTK313,1
    20
    $PMTK513,126
    $PMTK319,0
    2B
    $PMTK527,0.000E
    $PMTK251,9600
    19



  • Netgate Administrator

    Love the annotation.  ;D

    Steve



  • @pete:

    Thanks Rob.  For the update posted do I need to recalculate the checksum stuff?

    I did notice while using FF after the save on the serial GPS page; the page looked a bit weird.

    Here is the adjusted checksums for the SureGPS.

    $PMTK225,025
    $PMTK314,1,1,0,1,0,5,0,0,0,0,0,0,0,0,0,0,0,1,0
    23
    $PMTK301,220
    $PMTK397,0
    2D
    $PMTK1023F
    $PMTK313,1
    20
    $PMTK513,126
    $PMTK319,0
    2B
    $PMTK527,0.000E
    $PMTK251,9600
    19

    What adjustments do these commands do? Why did you have to change them? There's a mistake for sure for example on the second line, checksum for that is not 23 but 2D. Didn't check all of them, but PMTK301,2 has the correct checksum of 2E, not 20.

    Actually I use default settings (the ones which come when you select the model in the GPS pulldown), they all have already correct checksums precalculated. I'd say you should delete the whole thing, select "Generic" from the pulldown, then select "SureGPS" again, to re-load the defaults and press Save.

    Don't know about the php error you see on that page, have you done any other modifications to your pfSense system? I use this patch on several machines in production, none of them shows this.



  • @charliem:

    Once I got the GPS sending only the $GPGGA sentence, I haven't had any spikes (so far).  If I was ambitious, I'd go back in my clockstats file, and see what the strings looked like around the times the spikes were detected.  Hopefully it's fixed though.

    I spoke (wrote?) too soon!  My spikes are back, so I've got to do more digging; will update if I find anything.



  • @robi:

    I just found a couple of small issues, like typos and html display stuff, fine-tuned a bit SureGPS defaults and noticed that RRD graphs were not plotting on 2.1.3, fixed that.

    Thanks for keeping this up!  I'm testing 2.2, and I've noticed that the ntp RRD data does not survive an update, unlike the other RRD groups like system, traffic, packets, etc.  Note that I mean update from one 2.2 snapshot to the next, not the update from 2.1.3 to 2.2 (which I didn't try).

    Sorry I haven't looked into it any deeper; I hate posting a problem without a solution … but your post reminded me.



  • I also noticed that a restart of service sometimes, but a reconfiguration of NTP settings also deletes the entire RRD data, have no clue why.



  • @robi:

    I also noticed that a restart of service sometimes, but a reconfiguration of NTP settings also deletes the entire RRD data, have no clue why.

    Found it, I think … in /etc/inc/rrd.inc:

     /* NTP, set up the ntpd rrd file */
                    if (isset($config['ntpd']['statsgraph'])) {
                            /* set up the ntpd rrd file */
                            if (!file_exists("$rrddbpath$ifname$ntpd")) {
                                    $rrdcreate = "$rrdtool create $rrddbpath$ntpd --step $rrdntpdinterval ";
                                    $rrdcreate .= "DS:offset:GAUGE:$ntpdvalid:0:1000 ";
    ...
    
    

    There shouldn't be the '$ifname' in the check for the existing file, since ntpd stats are not per interface.  From the previous captive portal stanza, $ifname is set to 'captiveportal' at this point anyway.  So '/var/db/rrd/captiveportalntpd.rrd' is of course not found, and a new ntpd.rrd file is created every time through this code.  Seems to be the case for both 2.2 and your 2.1.3 patch.



  • Also, I believe that UNKNOWN values need to be written in more data set fields during boot:

     /* set up the ntpd rrd file */
                            if (!file_exists("$rrddbpath$ntpd")) {
                                    $rrdcreate = "$rrdtool create $rrddbpath$ntpd --step $rrdntpdinterval ";
                                    $rrdcreate .= "DS:offset:GAUGE:$ntpdvalid:0:1000 ";
                                    $rrdcreate .= "DS:sjit:GAUGE:$ntpdvalid:0:1000 ";
                                    $rrdcreate .= "DS:cjit:GAUGE:$ntpdvalid:0:1000 ";
                                    $rrdcreate .= "DS:wander:GAUGE:$ntpdvalid:0:1000 ";
                                    $rrdcreate .= "DS:freq:GAUGE:$ntpdvalid:0:1000 ";
                                    $rrdcreate .= "DS:disp:GAUGE:$ntpdvalid:0:1000 ";
                                    $rrdcreate .= "RRA:MIN:0.5:1:1200 ";
                                    $rrdcreate .= "RRA:MIN:0.5:5:720 ";
                                    $rrdcreate .= "RRA:MIN:0.5:60:1860 ";
                                    $rrdcreate .= "RRA:MIN:0.5:1440:2284 ";
                                    $rrdcreate .= "RRA:AVERAGE:0.5:1:1200 ";
                                    $rrdcreate .= "RRA:AVERAGE:0.5:5:720 ";
                                    $rrdcreate .= "RRA:AVERAGE:0.5:60:1860 ";
                                    $rrdcreate .= "RRA:AVERAGE:0.5:1440:2284 ";
                                    $rrdcreate .= "RRA:MAX:0.5:1:1200 ";
                                    $rrdcreate .= "RRA:MAX:0.5:5:720 ";
                                    $rrdcreate .= "RRA:MAX:0.5:60:1860 ";
                                    $rrdcreate .= "RRA:MAX:0.5:1440:2284 ";
    
                                    create_new_rrd($rrdcreate);
                                    unset($rrdcreate);
                            }
    
                            /* enter UNKNOWN values in the RRD so it knows we rebooted. */
                            if($g['booting']) {
                                    mwexec("$rrdtool update $rrddbpath$ntpd N:U");
                            }
    
    

    The update line should be:

    mwexec("$rrdtool update $rrddbpath$ntpd N:U:U:U:U:U:U");
    


  • Can you please attach your modified /etc/inc/rrd.inc?