Announcing availability of a QLNET driver for the Q68 (ND-Q68)

[pjw]

What could be of interest in this context is the mem_ device driver which is part of the DIY toolkit (in the v_n section) - That allows you (amongst some really "magic" (or is it dubious?) other stuff) to PEEK and POKE into a remote machine's memory over QLAN (George Gwilt's NET_PEEK does something similar, but allows only read access).
<>

MEM could be a real security risk once QLs become more connected. Is there any way of blocking, or at least limiting, it?

[tofro]

What could be of interest in this context is the mem_ device driver which is part of the DIY toolkit (in the v_n section) - That allows you (amongst some really "magic" (or is it dubious?) other stuff) to PEEK and POKE into a remote machine's memory over QLAN (George Gwilt's NET_PEEK does something similar, but allows only read access).
<>

MEM could be a real security risk once QLs become more connected. Is there any way of blocking, or at least limiting, it?

Block, yes (simply don't start FSERVE or the mem driver), limit, well, no. QL designers believed in the good in people. You could maybe use Toolkit III, that allows to restrict access to files and devices by users (and, BTW, comes with yet another MEM device driver). I don't know how secure that is, however. (Toolkit II introduces a file access flag "HOST ONLY" - which forbids exposure of a file to the file server)

But anyways: Everything regarding to the QL regarding networking is a potential security risk and should only be operated behind a firewall - So don't use any of the many available online banking applications and don't run your business-critical enterprise applications on it

[pjw]

<>
But anyways: Everything regarding to the QL regarding networking is a potential security risk and should only be operated behind a firewall - So don't use any of the many available online banking applications and don't run your business-critical enterprise applications on it

Oh sh*t! NOW you tell me!

Ok, the issue here is that I have long wanted to write a game that can be played with, in this case, up to four players, each sitting at their own QL-like computer, possibly at remote locations.

Every iteration of QL networking capabilities has breathed fresh life into that idea (and I presume Im not the only one!) but each time Ive been frustrated by the unreliability of QL comms, with lots of fiddling to set things up, followed by endless drop-outs, garbling, and long hangs. Still, hope springs eternal, so Im at it again (thinking, that is).

Id like to air some possible ideas here, once I have formulated my questions intelligibly.

But clearly, I wouldnt want to open my computer remotely if anyone who, perhaps even as just a friendly joke, could mess about in my system. As you say, turning off FSERVE is one way, but that might get in the way of functionality of what Im trying to do or mess with other aspects on one's setup.. I wasnt aware of the HOST_ONLY facility. Have to check it out.

[dilwyn]

"On the internet, nobody knows you're a dog"

Only takes a couple of, err, bytes to find out. Or when the dog uses a bark-code

[xelalex]

Ok, the issue here is that I have long wanted to write a game that can be played with, in this case, up to four players, each sitting at their own QL-like computer, possibly at remote locations.

Every iteration of QL networking capabilities has breathed fresh life into that idea (and I presume I'm not the only one!)...

Quite right, I also had been thinking in that direction for some time, and I've recently added something like "Sinclair Network over IP" to OqtaDrive. This enables an OqtaDrive to act as a kind of Internet gateway for your Spectrum/QL, and lets you communicate over the Internet with other Spectrums and QLs.

The idea here is that all the commands using the Sinclair Network can be used transparently over this connection, just as if the other stations were connected directly to your machines. No modifications to your Spectrum or QL are necessary, and no additional software is required. So you could simply do 'SAVE *"n";24' on your Spectrum for example, and have a friend do 'LOAD *"n";18' to transfer your current BASIC program to them. It should also be possible to implement something like a multiplayer networked game using this. For the Spectrum, I've written a small group chat application, and that works quite nicely.

The Sinclair Network feature currently supports Spectrums, haven't tried it out yet with a QL. I expect that some minor tweaking may be necessary. Once the current state is officially released, I'll look into QL support. More details here.

[Martin_Head]

Hi all,
I am not sure that is the right thread to post it but... Ill do...

My Q68 is part of a bigger Lan and it act as a bridge for 2 QL, I mean:
" QL NET 1 ----> Q68 (Net 2) ----> QL Net 3"

I share the resources of the 2 QL to the other Component of the Lan (PC running SMSQE/emulators) and the Q68 act as a bridge, so far everything works perfectly.

Now going to the point: on the Q68, in the boot, I run a little program that, using tcp, connect the Q68 to the site "time.nist.gov:13" and keep the Q68 system date/time updated, all is fine and everything works, in the program to open a channel I am using the SB line "100 OPEN_IN #4,"tcp_time.nist.gov:13"........

More than Q68, that is stable in keeping time, I would like to update the time on the 2 QL, connected to the Q68 using QLnet, and in doing this I changed the program on the QLs using "100 OPEN_IN #4,"n2_tcp_time.nist.gov:13". Net 2 is the Q68 in QLnet.

Results: doesn't work and the Q68 reboot after I run the program on the QL.

The QLs run SMSQ/E and both have SuperGC, Hermes etc etc

I am missing something? Do someone have a clever idea how to get this?

I hope to be sufficient clear in explaining the issue.

Thx

I've got around to having a look at this problem.

I've just had a quick try, and on the setup I've put together, On trying the OPEN_IN#4,"n2_tcp_time.nist.gov:13", and INPUTing #4. The Q68 does not reset itself.
But there is a lot of activity on the QL Network, the Q68's orange light is flickering constantly.

I can BREAK into the QL and close the channel, and the network activity stops.

I now need to try to trace things through to try to find where it fails.

Edit: Update. Just had another play, the n2_tcp_time.nist.gov:13 on the QL, connects the Q68 to the internet and fetches the time packet. But when the QL tries to read it over the QL network, it just returns chr$(0). That's the network activity light flashing. I will have to look at Martyn Hill's FSERVE to see if I can stick a break in it with JMON to see if it's picking up the wrong data, or getting stuck with something in the time packet.

Another edit: Just tried the same thing with QPC2 taking the role of the QL over my IP Network driver, Same results. So it effects my FSERVE as well.

[Martin_Head]

I've been looking some more into this. I'm pretty sure that the time packet make it all the way to to the remote QL (client).

I think the problem is that the time packet has a CHR$(10) right at the start. If I create a text file on the server QL (Q68) that starts with CHR$(10). I have problems reading it on the client QL (QPC2). But without the CHR$(10) it's OK.

[Martin_Head]

Now going to the point: on the Q68, in the boot, I run a little program that, using tcp, connect the Q68 to the site "time.nist.gov:13" and keep the Q68 system date/time updated, all is fine and everything works, in the program to open a channel I am using the SB line "100 OPEN_IN #4,"tcp_time.nist.gov:13"........

More than Q68, that is stable in keeping time, I would like to update the time on the 2 QL, connected to the Q68 using QLnet, and in doing this I changed the program on the QLs using "100 OPEN_IN #4,"n2_tcp_time.nist.gov:13". Net 2 is the Q68 in QLnet.

Results: doesn't work and the Q68 reboot after I run the program on the QL.

Sorry for the delay in sorting this out. It's been running me round in circles.

I've not seen a Q68 rebooting problem. But I managed to get the remote QL to read the internet time signal from the Q68. It was a problem in the Q68's Ethernet driver not handling End Of File correctly in IO_FBYTE and IO_FSTRG.

After fixing this, I then found that when trying to get the internet time signal from the Q68 with QPC2, over the IP Network. The returned time text was corrupted when using INPUT, but OK with INKEY$. I eventually tracked this down to a bug in the IP network driver.

I have attached the two updated drivers, Please try them to see if I have sorted out the problems, and not introduced any new ones. If they are OK, I will do an official release with the source code.