Resolved: The command '/usr/local/sbin/ping-auth -s > /etc/thoth/thothid 2>/dev/null' returned exit code '127', the output was ''
-
@stephenw10 Thanks for looking into this. I opened a TAC ticket but they just sent me firmware, when I said I installed it and it did not fix it the ticket was closed. I think he got mixed up with my ticket.
-
It's not a TPM device, it doesn't have anything to do with drive encryption.
I wouldn't expect a driver to make any difference here. I could just about imagine causing problems communicating with the chip but that would be the same in 23.05.1.
I assume running
ping-auth -s
correctly returns the crypto ID there? -
@stephenw10 said in The command '/usr/local/sbin/ping-auth -s > /etc/thoth/thothid 2>/dev/null' returned exit code '127', the output was '':
ping-auth -s
in 23.05.01
So its something with that build? I also have issues with experimental ethernet rules and compex ath0 driver they no longer separate the layer 2 broadcast domains for ARP requests from LAN to Compex card, this version is prone to ARP broadcast storms across different interfaces before it broke them up I never showed traffic between the two interfaces.
https://forum.netgate.com/topic/184894/ethernet-rules-on-two-networks
-
https://redmine.pfsense.org/issues/15103
-
Did you try 23.09.1 without the new SSD installed?
-
@stephenw10 yes but I can't remember I think it also had the same issue. Could a SSD cause this?
-
It could if, for example it somehow had the same smbus address as the crypto chip. It shouldn't but it works fine for me here in 23.09.1 without an SSD.
Is that test from 23.05.1 also with the SSD?
-
So as you have already noticed, I'm guessing, what you're showing is different than the build date I'm showing and posted above
Curious was that image before or after TAC sent you the new image, or is/was the date the same on both.
Still think it is different than just a package here or there, as was discussed here.
https://forum.netgate.com/topic/184681/after-update-2-7-2-23-09-1?_=1702938917839
-
@stephenw10 said in The command '/usr/local/sbin/ping-auth -s > /etc/thoth/thothid 2>/dev/null' returned exit code '127', the output was '':
The later 2100s didn't have the chip as we moved away from that
define "later" by D.O.M. - please.
-
@stephenw10 yes the 23.05.01 is an SSD that came with my 2100-MAX 32GB
The 23.09.01 is on a KingSpec SSD it's 128GB
The new SG2100MAX comes with 128GB so I wanted mine to max up to the new MAX
-
Ah, but not the same one...
-
@stephenw10 no it's a different it's a KingSpec the smart status does not show as much as the trendnet SSD. The install SSD guide for 2100 did not state any cyptoID issues also, that's why I thought it couldn't be the 128GB SSD everything works except that cryptoID is missing and it has the system errors to go with it
-
So I think the only reason my system info is showing the Crypto ID is because the file with the id in it already exists and I upgraded on the existing system
system_get_thothid
technically if my system did not have the id already in file and got to the exec of /usr/local/sbin/ping-auth it would fail. File does not exist.
ls: /usr/local/sbin/ping-auth: No such file or directory
The system info has displayed this since day one, and will continue to do so, until the file is gone. Then it will error.
Begs the question, @JonathanLee does the file exist on your system?
@stephenw10 should it? clearly it has in the past.
Clearly the dashboard is going to call system_get_thothid and if the file does not exist it is going to call ping-auth.
-
Can I just copy it over to the new SSD? I am confused is yours missing also as that path is invalid.
I wonder what the path is to the id file. It has to match the chip each is different.
I just need my top secret missing critical cryptoID file then for it to work again?
-
@jrey is your 2100 a MAX?
-
Can you test 23.09.1 on the other SSD or on the eMMC?
-
I can't because I will loose my Snort package that works with out core dumps in 23.05.01
Snort package .11 will be lost in the process if I do a firmware install on that drive. That's my everything works everyday version of PfSense. There has got to be another way....
It's my 🥯 drive
-
Location of file that is needed!!! Bingo
Just add it to backup package
-
the file with the id in it exists - yes.
-rw-r--r-- 1 root wheel 19 Jan 23 2023 /etc/thoth/thothid
the file that creates it (ping-auth), if the ID does not exist, does not exist my question to @stephenw10 was should it ?
because the file with the ID stored in it already exist, it happily displays it on my dashboard.
Could a SSD cause this?
in a word yes.
should you copy the file from the old one?
ping-auth is likely a NO, if required it is likely a different build. don't do it.
bring the thothid file over (with the ID in it), MAYBE, depends on if and/or what it is still used for. Stephen did imply they have gone away from this in undefined "later" hardware so maybe nothing uses it anymore.I'd wait to see what is said about the existence of ping-auth.
I'm going to venture a guess that the ID is no longer used and the code just hasn't been cleaned up to generate it. Then because you went to a new drive, the ID file doesn't exist, and you get an error.
I still have the file (same drive) and therefore never tries to recreate it. But it is still likely not used anymore.
MAX, if that in their new terminology means >= 32GB SSD stock then yes this is MAX, but I call him Wallie.
Then I see you've already moved the file.. WOW. So the question will then be "is it still needed for anything?"
-
@jrey If it is not needed why is the GUI set to request it, This is used in OpenVPN so it is used. They do not have them in the non plus version.