Port lock error when activating P2P (ppp connection) on mosaic-x5

Hi all,

I try to use the p2p feature on mosaic-x5 (SPARKPNT GNSS FLEX MOD MOSAIC-X5).

As soon as the P2P server is started on the mosaic-x5, a “port lock error” is reported by the module. This can be reproduced on any com port.

Can anyone confirm that this feature actually works ?

thanks for your help !

Hi @sebs ,

What settings are you using when you enable Point2Point? Have you checked the syntax?

Please see section 1.2.3.3 Point-to-Point Link in the Firmware Reference Guide. Please also see setPointToPoint (sp2p) in the Command Line Reference (section 3.2.13)

I hope this helps,
Paul

Hi Paul,

the command sent to setup p2p is the following :

setPointToPoint, P2PP1, Server, COM1, 192.168.60.2, 192.168.60.1, none, “none”

Here is the module reply :

> $R: setPointToPoint, P2PP1, Server, COM1, 192.168.60.2, 192.168.60.1, none, “none”

> PointToPoint, P2PP1, Server, COM1, “192.168.60.2”, “192.168.60.1”, None, “62NABPX1CQ1PG599X4U9GK576D70PN79WA0ID0QF”, 60, 600

A few seconds later, the module starts to cycle : initializing… waiting for connection… Error (port lock)… initializing… and so on.

As soon as the server is starded, any other NMEA or SBF output on COM1 is stopped, so some part of the job is done but it seems that on the mosaic, the pppd server never starts due to some lock error.

I have also tried to disable any output and input (sdio, COM1, none, none)… no chance to avoid the “port lock error”.

Hi @sebs ,

Maybe try:

setPointToPoint,P2PP1,Server,COM1,192.168.60.2,192.168.60.1,None

or

setPointToPoint,P2PP1,Server,COM1,192.168.60.2,192.168.60.1,None,,60,600

(Note the double comma after None)

I think your second “none” might end up being set as a password? The “62…QF” looks very much like a hashed password.

Maybe you’re seeing Port Lock because the X5 believes you have set a password and it is expecting you to supply it when connecting?

Best,
Paul

I have tested both commands :

< setPointToPoint,P2PP1,Server,COM1,192.168.60.2,192.168.60.1,None
 > $R: setPointToPoint,P2PP1,Server,COM1,192.168.60.2,192.168.60.1,None
 >   PointToPoint, P2PP1, Server, COM1, "192.168.60.2", "192.168.60.1", None, "6K26T7C3RN37VFQQCL8QVPFODUOX72OQ46XEUXNZ", 60, 600

< setPointToPoint,P2PP1,Server,COM1,192.168.60.2,192.168.60.1,None,,60,600
 > $R: setPointToPoint,P2PP1,Server,COM1,192.168.60.2,192.168.60.1,None,,60,600
 >   PointToPoint, P2PP1, Server, COM1, "192.168.60.2", "192.168.60.1", None, "6K26T7C3RN37VFQQCL8QVPFODUOX72OQ46XEUXNZ", 60, 600

In both cases the result is the same : post lock error (and consequently no activity on the TX of the mosaic).

OK, but that "6K26T7C3RN37VFQQCL8QVPFODUOX72OQ46XEUXNZ" does look like a hashed password. Maybe you accidentally set one previously and haven’t yet deleted it?

Please try erasing the current and boot configuration:

exeCopyConfigFile,RxDefault,Current
exeCopyConfigFile,RxDefault,Boot

Also, it is weird that your P2PPStatus screenshot says “COM3” when everything else you’ve posted indicates you are trying to configure P2PP on COM1. That needs investigating…

Yes, I have tested the setup on all com ports, the screenshot was one of the tests.

In all cases (COM1…COM4 whether or not the port has a physical output) I can see the same “port lock error”.

This is the trace for the setup reset :

< exeCopyConfigFile,RxDefault,Current
> $R: exeCopyConfigFile,RxDefault,Current
> CopyConfigFile, RxDefault, Current
< exeCopyConfigFile,RxDefault,Boot
> $R? exeCopyConfigFile: Not authorized! Please use the "login" command to create a user and get authorization.
< Requesting login,********
> $R? LogIn: At least one user with a non-empty password should be available before attempting to login!
> Please use the login command with 4 parameters to create a first user and login:
> login,<username>,<password>,<factoryUserName>,<factoryPassword>

etc.

and then :

< exeCopyConfigFile,RxDefault,Boot
> $R: exeCopyConfigFile,RxDefault,Boot
> CopyConfigFile, RxDefault, Boot

After that, I restarted the p2p server :

< setPointToPoint, P2PP1, Server, COM1, 192.168.60.2, 192.168.60.1, none, "none"
> $R: setPointToPoint, P2PP1, Server, COM1, 192.168.60.2, 192.168.60.1, none, "none"
> PointToPoint, P2PP1, Server, COM1, "192.168.60.2", "192.168.60.1", None, "PD6PR8GIVAI830LLG2WL3U097O9T869LNPTZOTAX", 60, 600

There is again a hashed password. Anyway, I can define a password :

< sp2p,P2PP1,Server,COM1,"192.168.60.2", "192.168.60.1", PAP, "passwd", 60, 600
> $R: sp2p,P2PP1,Server,COM1,"192.168.60.2", "192.168.60.1", PAP, "passwd", 60, 600
> PointToPoint, P2PP1, Server, COM1, "192.168.60.2", "192.168.60.1", PAP, "81XTZL7NC1K1A7EEQZSEAR73GV391X3EFT9UV90O", 60, 600

And once again : port lock error.

The password has nothing to do with the problem since with or without password, the PPP negotiation does not start (no TX activity on the com port).

Note : I should write again that the com ports are perfectly working with NMEA, SBF, or command I/O. The problem only appears with P2P server.

The error is reported by the module itself when the p2p server is started. “Port lock” as error type probably indicates that there is a problem in the embedded system. On linux, most of the time, a lock error on pppd startup indicates that the device is already used by another process.

The port lock error is reported on *any* port, with/without password, with without a party connected on the other side.

Since I can’t imagine that the feature is documented while it does not work, I guess that there is some other parameter on the mosaic module that starts a process listening on the tty port that the P2P server wants to use. I think that the other process is *listening* and not writing since with a scope we cannot see any activity on the TX line (from the mosaic) when the p2p server is running. This situation should have a solution with some kind of tricky setup.

The other possibility is that a dead lock is preventing the p2p server to start in the module, but in this case, it would mean that the documentation describes someting that simply cannot work.

So my questions : has anyone tested the p2p feature ? with success ? if yes : what was the setup ?

kind regards, thanks for you time

Hi @sebs ,

Thank you for the detailed reply. We are getting to the point where we need to ask Septentrio for advice…

So, three things:

Which firmware is the X5 running? I’m guessing 4.15.1 since it is demanding a login. If you want to, you could try downgrading to 4.14.10.1 - which I think was the last version where logins were not mandatory - and see if the behaviour is the same.

If you are running 4.15.1, it supports the command “FactoryReset”, which is the nuke from orbit option to completely reset everything… That may help, but I too suspect something else is causing this. You need to issue FactoryReset within 30 seconds of powering up. If you’re too slow, you’ll see a polite “Command needs to be provided within 30 seconds after starup” error message.

Septentrio will ask for a diagnostic report. Please generate one when the Port Lock is visible. If you are happy to, please attach it here. Or you can PM it to me and I will pass it to Septentrio when I open the support case.

Best wishes,
Paul

Thank you,

I have just PM the diagnostic report.

the mosaic is running 4.15.0, I will test 4.15.1 and 4.14.10.1 as well.

Thank you @sebs ,

I have your report.

Do you have time to try 4.14.10.1 today? If you do, please let me know how it goes.

(Septentrio are on California time. I am on UK time. I will send the report to them later this afternoon as needed.)

Best,
Paul

4.15.1 : same error

4.14.10.1 : update running…

GREAT !

So many thanks ! p2p is running with firmware 4.14.10.1 !

Hi @sebs ,

Excellent! I am glad it is working for you.

I think the Port Lock must be a ‘feature’ of firmware >= 4.15.0, possibly caused by a login being mandatory?

If you want us to, we can ask Septentrio for advice on how to get P2PP working with 4.15.0. Please let me know.

Best wishes,
Paul

Yes please, I have spent so much time on this problem, with scope, with many questions about our hardware. I would be very happy if other users can use the ppp feature. It’s really useful.

(I have contacted Septentrio in early february about this problem, after some emails, they told me to contact sparkfun. good choice :wink: ).

again, thanks a lot

Done. It usually takes them a few days to reply. I will post their reply here when I receive it.

À bientôt,
Paul

nice !

By the way, the documentation does not say anything about two “details” :

  • the baudrate of the com port when ppp is used : one can understand that the baudrate (and flow control) are those defined in the Serial Port settings. However, it seems that using P2P forces the com port to 115200 without flow control. The manual could be clarified or the firmware changed to actually use the settings defined from the COM port in “Serial Port settings”.
  • how is defined the default gateway when the ethernet interface is off and P2P is running ? It seems that no default gateway is defined when ethernet is off. P2P could be a useful fallback since the client may offer a route to the internet…