QL TK2 Network bug...
-
- Aurora
- Posts: 933
- Joined: Sat Oct 25, 2014 9:53 am
QL TK2 Network bug...
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...
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...
- NormanDunbar
- Forum Moderator
- Posts: 2281
- Joined: Tue Dec 14, 2010 9:04 am
- Location: Leeds, West Yorkshire, UK
- Contact:
Re: QL TK2 Network bug...
Nice bug! (For certain values of "nice".)
Cheers,
Norm.
Cheers,
Norm.
Why do they put lightning conductors on churches?
Author of Arduino Software Internals
Author of Arduino Interrupts
No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
Author of Arduino Software Internals
Author of Arduino Interrupts
No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
- mk79
- QL Wafer Drive
- Posts: 1349
- Joined: Sun Feb 02, 2014 10:54 am
- Location: Esslingen/Germany
- Contact:
Re: QL TK2 Network bug...
Wow, sounds like an "interesting" debugging session. So a simple check for zero in the receiver would fix this?
-
- Aurora
- Posts: 933
- Joined: Sat Oct 25, 2014 9:53 am
Re: QL TK2 Network bug...
Hi Marcel!
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...
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.mk79 wrote:Wow, sounds like an "interesting" debugging session. So a simple check for zero in the receiver would fix this?
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...
-
- Aurora
- Posts: 933
- Joined: Sat Oct 25, 2014 9:53 am
Re: QL TK2 Network bug...
Hi Norm!
I really ought to get out more ...
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?'NormanDunbar wrote:Nice bug! (For certain values of "nice").
I really ought to get out more ...
Re: QL TK2 Network bug...
but it does show a good and thorough testing mentality - so that's a plus.
Re: QL TK2 Network bug...
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?'NormanDunbar wrote:Nice bug! (For certain values of "nice").
I really ought to get out more ...
--
All things QL - https://dilwyn.qlforum.co.uk/index.html
All things QL - https://dilwyn.qlforum.co.uk/index.html
- NormanDunbar
- Forum Moderator
- Posts: 2281
- Joined: Tue Dec 14, 2010 9:04 am
- Location: Leeds, West Yorkshire, UK
- Contact:
Re: QL TK2 Network bug...
Nah! Outside is vastly over rated! As for asking inane questions, you are living up to my motto: "Don't think, find out!".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 ...
Keep it up.
Cheers,
Norm.
Why do they put lightning conductors on churches?
Author of Arduino Software Internals
Author of Arduino Interrupts
No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
Author of Arduino Software Internals
Author of Arduino Interrupts
No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
- mk79
- QL Wafer Drive
- Posts: 1349
- Joined: Sun Feb 02, 2014 10:54 am
- Location: Esslingen/Germany
- Contact:
Re: QL TK2 Network bug...
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!)martyn_hill wrote:Then there's the question of where to host the updated build....
Well, a) the SMSQ/E caretaker is Wolfgang and b) my sources are already part of SMSQ/E.The source could be hosted by our SMSQE caretaker, Jochen, but as a standalone TK2 image I'm not sure...
-
- Aurora
- Posts: 854
- Joined: Tue Dec 17, 2013 1:17 pm
Re: QL TK2 Network bug...
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.
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.