The Sinclair QL Forum

Hi everyone!

During my on-going development of the QLUB Adapter project, I have come across a rather nasty bug in the TK2 network driver and thought to share it here as I hadn't read about it anywhere else.

The bug won't adversely affect a QL running the native QDOS network driver, only where both the sending and receiving stations are running the enhanced TK2 driver. The issue only upsets the receiving station, arises only in a very specific scenario and, even then, you may get lucky. Read on if you rely on the QL Network with TK2.

The Sinclair Network Standard defines a byte-sized count (NBYT) within the 8-byte packet header defining the size of the packet to follow. Valid ranges are 1-255 as zero shouldn't happen in normal use. The one time a zero-sized packet can and will occur is when a simple output NET channel is opened, and then closed immediately without sending any bytes. TT comments in his notes in the TK2 network description on what happens - namely that a 256-byte packet is actually transmitted (with 'dummy' data).

Whilst untidy, this isn't a real problem as the NET input channel always has at least (255 + a bit) bytes available in the receive buffer within it's Channel Definition Block, so nothing important get's smashed when this slightly over-sized dummy data-packet is received. Furthermore, the actual SERIO QDOS routine around which the NET driver is built will still recognise zero new bytes available, so no real harm done.

Introduce the brilliant TK2 NET driver and, in order to accommodate the large FSERVE packets (4-1020 bytes), the byte-sized count within the header is extended to word-size and tested as such (subq.w #1,d2, bne.s <nextByte>) to determine when all bytes have been sent (or received.)

So, returning to our prematurely closed NET output channel, now we see an uber-large 64kB packet transmitted - and dutifully received at the other-end. Bam! Anything interesting within the Channel Definition area beyond the NET CDB or within 64kB higher in memory will get smashed.

Mind-you, you do get a whopping 6.3 KBps out of the network at this size of packet, albeit, short-lived...

Anyhow, forewarned is fore-armed, as they say.

Meanwhile, back to debugging my next QLUB Net driver release...

Nice bug! (For certain values of "nice".)

Cheers,
Norm.

Wow, sounds like an "interesting" debugging session. So a simple check for zero in the receiver would fix this?

Hi Marcel!

mk79 wrote:Wow, sounds like an "interesting" debugging session. So a simple check for zero in the receiver would fix this?

Yes, it would be trivial to code this and should still 'fit' even in the 16KB of your Network version of v2.32 (I'll do so over the weekend), but as with any such fix or enhancement, it's only readily consumable for those users who have access to an EPROM burner and are inclined to tinker with their QL hardware - or else run TK2 from Non Volatile SRAM, as I do.

Then there's the question of where to host the updated build.... The source could be hosted by our SMSQE caretaker, Jochen, but as a standalone TK2 image I'm not sure...

Hi Norm!

NormanDunbar wrote:Nice bug! (For certain values of "nice").

Indeed, like many of the observations that have come about from this study of the QL Network over the years, only discovered out of bloody-minded curiosity and asking innane questions, such as 'what happens to zero length packets?'

I really ought to get out more ...

but it does show a good and thorough testing mentality - so that's a plus.

martyn_hill wrote:Hi Norm!

NormanDunbar wrote:Nice bug! (For certain values of "nice").

Indeed, like many of the observations that have come about from this study of the QL Network over the years, only discovered out of bloody-minded curiosity and asking innane questions, such as 'what happens to zero length packets?'

I really ought to get out more ...

He he. But at least you discovered it in the end.

martyn_hill wrote:Hi Norm!

Indeed, like many of the observations that have come about from this study of the QL Network over the years, only discovered out of bloody-minded curiosity and asking innane questions, such as 'what happens to zero length packets?'

I really ought to get out more ...

Nah! Outside is vastly over rated! As for asking inane questions, you are living up to my motto: "Don't think, find out!".

Keep it up.

Cheers,
Norm.

martyn_hill wrote:Then there's the question of where to host the updated build....

Well, there is https://www.kilgus.net/2017/03/19/toolk ... he-sequel/, which was the home of 2.32, too (by the way, you're a bit behind!)

The source could be hosted by our SMSQE caretaker, Jochen, but as a standalone TK2 image I'm not sure...

Well, a) the SMSQ/E caretaker is Wolfgang and b) my sources are already part of SMSQ/E.

I don't know if Marcel has already fixed it, but there is/was a bug in TK2 that effects the network driver with the N8_ device.

In the 'wild card' routines that handle something like DIR N8_FLP1_ . the routine checks for N0_ to N7_ instead of N1_ to N8_

This got fixed some time ago in SMSQ/E after someone reported a problem in my IP Network driver, which I traced it back to a SMSQ/E problem. Which I found was also in TK2.