I have found what may be a bug, or a design efficiency in the way services urls are input and stored.

The issue:

The input form  (www.cgi-bin/ports) assumes that there will always be a port number attached for the url. This may be true when the protocol is http/https. But it is not the case for all protocols.

Suggestion. The form handler should accept an empty port field, and when the port field is empty, it should also delete the ";". This would not break http/https urls that use port 80 as the default.

Further, the code that reads /etc/config/services and creates /var/run/services_olsr also appears to not like missing port numbers. If the port number is not present, it does not copy the service entry.  And, lastly, the code in /www/cgi-bin/mesh will not add a url from /var/run/services_olsr if it does not contain a port.

The specific use case here is the entry of urls for TeamTalk4, which are of the form:

tt://tt4us.bearware.dk?tcpport=10333&udpport=10333&username=guest&password=guest

Ok on the difficulty.  I wasn't sure how much of that code was bbhn and how much was olsr. There might be a hack to get around it based on manual entries... but probably doomed. In any case, I'll learn more about the guts of this beast.

On the tt://  url. Te port numbers are not the port numbers the program listens on. They are the port arguments of the server it should connect to. In fact, the request is sent to TeamTalk by whatever url/application mapping mechanism the OS supports. In my case, MacOS, TeamTalk actually launches, but can't automatically make the connection to the server because the url doesn't parse (because of the :port).

No huge problem... But, as people start extending more services over the mesh, we will probably run into problems like this again.

BTW, I just realized my spell "checker" changed inefficiency to efficiency in the Subject. Not quite what I intended.

Richard