That's very strange, John. I've attached a couple of screenshots of the Firefox developer console, and a .har file which you can import into your own browser console so that you can click around on the various requests and see details for yourself.

?

You can see that the request to /api/request_token succeeds and I get a token in the response. This token is then supplied as part of the request to /api/nodes, but this fails with a CORS error: Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at . (Reason: CORS preflight response did not succeed). Status code: 403.

?

It doesn't make much sense to have an open API if it's only usable from pages served by BPQ itself, so I would suggest allowing any origin, rather than relying on pages to be served by BPQ. As I mentioned earlier, this will only affect browsers as other tools like NodeJS and Python don't actually bother checking or obeying CORS rules anyway.

I do not see the new BPQ32 or BPQMail, only BPQ32.dll dated 10/06 in the beta folder. The most recent

files beyond that are dated 08/27. Am I looking in the wrong place??

Best regards,

Gary, K7EK

On Sunday, October 6, 2024 at 12:25:54 PM EDT, Eric H. Christensen via groups.io <wg3k@...> wrote:

On Sunday, October 6th, 2024 at 03:30, John G8BPQ <john.wiseman@...> wrote:

> I've uploaded new versions of BPQ32, BPQMail and linbpq to my beta site.
>
> This should fix the problem with SendPToMultiple forwarding messages
> that have reached their target BBS. It adds the BBS HA to the Routing
> Trace to help diagnose problems with bull distribution.

This update seems to have fixed my problem with HA routing.? I reran routing on all my messages and it picked up @USA AND @NA messages and properly routed them.

BBS Version 6.0.24.45

241006 16:18:33 ?? ? ? ? ? Msg 8930 Routing Trace To PKTNET Via USA
241006 16:18:33 ?? ? ? ? ? Routing Trace. Check if reached correct area My HA is #SMD.MD.USA.NOAM
241006 16:18:33 ?? ? ? ? ? Routing Trace Type B (Flood) TO PKTNET VIA USA Route On WW NOAM USA (null) (null)
241006 16:18:33 ?? ? ? ? ? Routing Trace HR WW NOAM USA (null) (null) Matches BBS KA1VSC
241006 16:18:33 ?? ? ? ? ? Routing Trace HR WW NOAM USA (null) (null) Matches BBS KA3VSP
241006 16:18:33 ?? ? ? ? ? Routing Trace HR WW NOAM USA (null) (null) Matches BBS KB3KOW
241006 16:18:33 ?? ? ? ? ? Routing Trace HR WW NOAM USA (null) (null) Matches BBS N3HYM
241006 16:18:33 ?? ? ? ? ? Routing Trace - No Match

Thank you!

73,
Eric WG3K
FM18rp
Packet: WG3K@WG3K.#SMD.MD.USA.NOAM
E-Mail: wg3k@...

I just tried in Chrome and the request to /api/request_token fails with the following error: Access to XMLHttpRequest at '' from origin 'null' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Not sure which browser you were using, but that sounds like what you were seeing.

Sure. This pages tries to fetch the node list, but fails - see the developer console in your browser (right click on the page, choose "Inspect", then go to the Network tab).

?

The form expects the IP:port of a BPQ node's HTTP port. All the code for this is in js/api-client.js - to simplify the demo, it requests a new token before each request to the API (we wouldn't normally do this, of course).

On 10/6/24 07:13, Charles Hargrove wrote:

This means that you have only one forwarding partner on an RF link,
typically 220 or 440, at 1k2, 9k6 or higher. This drops the possibility
of having collisions or hidden transmitter syndrome. Dedicated links,
whether RF or AXIP links on the internet, will have NetRom quality
settings of 203 (80% reliability).

Hi, Charles:
Thank you for the response.
This may be getting 'off-topic', but
that definition sounds much like a Point-to-point link wherein
2 stations have exclusive access to a channel
(without regard to band/baud:
HF, VHF, UHF, or SHF / 300 to 144,400,000 baud. ;-).
As I prefer RF routing, I further complicate routing by assigning
'all' RF links a NETROM value of 192 and 'all' AXIP a value 191, and
generally without regard to link speed.
I keep my MINQUAL set to see only my neighbors and neighbor's neighbors, but
I prefer not to 'node hop' through my neighbor BBSs' nodes.
I prefer to move messages to the neighbor better able to route/deliver.
I just love it when folks mention hidden transmitter and exposed node syndrome.
On that topic ignorance and apathy too often lead to failure.
Again, thanks.
73, Chuck

I've uploaded new versions of BPQ32, BPQMail and linbpq to my beta site.

This should fix the problem with SendPToMultiple forwarding messages
that have reached their target BBS. It adds the BBS HA to the Routing
Trace to help diagnose problems with bull distribution.

I've added a facility to interlock KISS ports with session mode ports
like VARA and ARDOP. This means that an Interlock setting on a KISS port
which was previously ignored could now be used, so I suggest you remove
any Interlock lines from KISS port definitions.

73,
John

I have always been confused about the word 'dedicated' as in /"dedicated RF links"/.

I've hit a snag. While requests to the API will work when using curl, NodeJS, Python, etc, they won't work from within a browser. This is because browsers make an OPTIONS request before the main request (known as the "CORS Preflight") and the server does not recognise OPTIONS requests (it responds with "403 Bad Method"). The request to /api/request_token does work because it is a "Simple request", but the request to /api/nodes fails because it has an Authorization header (which means it doesn't count as a "Simple request"). A good explanation about this can be found .

?

To fix this, the server should respond to OPTIONS requests with the header Access-Control-Allow-Origin: *

?

Even a different port on the same server counts as a different origin, so the error persists even if I serve the page from my node machine, as the web server can't use the same port as BPQ's web UI.

Sure. One thing I am a bit concerned about is the access_token process. For public information (such as the node list), this doesn't seem necessary at all, and as anyone can simply request a token without any authentication, doesn't actually provide any security, while adding an extra layer of complexity. It would be required when it comes to configuration data that's normally behind a login though (both getting and setting).

?

The other point is the expires_in key. I believe this should instead be expires_at, otherwise it's a bit confusing - does it mean 300 minutes from when the request was made, from when the response was sent, or when the response was received? This should also probably use UNIX epoch rather than minutes, e.g. { "access_token": "ABC123", "expires_at": 1728050700000 }. This would make the logic on the client much simpler as you would just check if the expires_at value is greater than the current time, to know if the token is still valid.