FujiNet: Bug causes incompatibility

Erhard · Beitrag von **Erhard** » 28.10.2022 18:06

DE / EN

Nach meinem derzeitigen Kenntnisstand:

Mit Erscheinen der Version 1.6 des FujiNet (FN) wurden seitens des Authors / der Authoren einige Änderungen durchgeführt.

Diese Änderungen haben es zur Folge, daß einige SIO-Befehle zwischen FujiNet 1.1-1.5 und FujiNet 1.6 untereinander nicht mehr kompatibel sind. Gleiches gilt folglich für die FujiNet Tools für den Atari, die diese SIO-Kommandos benutzen.

An dem Beispiel WLAN SSID stelle ich dar, warum es da ein Problem gab und wie es korrigiert wurde.

Eine SSID darf laut Spezifikation 32 Oktette (Bytes) lang sein.

Bei den FN 1.1 - 1.5 kann man über das Menü nur 31 Zeichen eingeben, gefolgt von einem ENTER. Über einen SIO-Befehl kann man durchaus 32 Zeichen setzen, aber dann erkennt die Firmware nicht das Ende der Zeichenkette, misachtet also die maximale Pufferlänge.

Die Ursache soll darin begründet sein, daß zur Programmierung der Firmware des FN sowie der Atari Tools die Programmiersprache C verwendet wurde, welche üblicherweise Null-terminierte Zeichenketten verwendet.

Im Fall der SSID wäre also nach Ansicht der Authoren ein 33.tes Byte für den Puffer erforderlich gewesen, was in der Firmware der FN 1.1-1.5 übersehen wurde.

Hier dazu der mit SIO Kommando $E8 an Adresse $4000 ausgelesene Datenblock von meinem FN 1.1-1.5:

Code: Alles auswählen

  4000  48 57 30 00 00 00 00 00 HW0.....
  4008  00 00 00 00 00 00 00 00 ........
  4010  00 00 00 00 00 00 00 00 ........
  4018  00 00 00 00 00 00 00 00 ........
  4020  45 50 2D 46 75 6A 69 4E EP-FujiN
  4028  65 74 00 00 00 00 00 00 et......
  4030  00 00 00 00 00 00 00 00 ........
  4038  00 00 00 00 00 00 00 00 ........
  4040  00 00 00 00 00 00 00 00 ........
  4048  00 00 00 00 00 00 00 00 ........
  4050  00 00 00 00 00 00 00 00 ........
  4058  00 00 00 00 00 00 00 00 ........
  4060  C0 A8 B1 18 C0 A8 B1 01 @(1.@(1.
  4068  FF FF FF 00 C0 A8 B1 01 ....@(1.
  4070  C4 5B BE 3B 0D 8C 38 10 D[>;..8.
  4078  D5 29 D7 87 30 2E 35 2E U)W.0.5.
  4080  66 38 63 63 34 32 39 32 f8cc4292
  4088  00 00 00 FF FF FF FF FF ........

Hier kann man den Aufbau sehen:

ab $4000 sind es 32 Byte für die SSID
ab $4020 sind es 64 Byte für den Hostnamen
ab $4060 sind es 4 Byte für die IP-Adresse
ab $4064 sind es 4 Byte für das Gateway
ab $4068 sind es 4 Byte für die Subnetzmaske
ab $406C sind es 4 Byte für den DNS-Server

Jetzt ist man hergegangen und hat für die SSID und andere davon betroffenen Einträge die entsprechenden SIO-Befehle um (mindestens) 1 Byte Datenlänge vergößert.

Hier das jetzige (v1.6) SIO-Kommando für GET-SSID ($FE), welches SSID und PSK ausliest:

https://github.com/FujiNetWIFI/fujinet- ... E-Get-SSID

Code: Alles auswählen

Device : $70
CMD    : $FE
Bytes  : 97 ($61)
DAUX1/2: 0

Für mein FN 1.1-1.5 wird die SSID mit 32 Zeichen übermittelt und das Kommando überträgt folglich nur 96 Bytes:

Code: Alles auswählen

Device : $70
CMD    : $FE
Bytes  : 96 ($60)
DAUX1/2: 0

Wenn man jetzt das "v1.5" Kommando gegen ein "v1.6" FujiNet absetzt erhält man einen Prüfsummenfehler.
Wenn man jetzt das "v1.6" Kommando gegen ein "v1.5" FujiNet absetzt erhält man einen Timeout.

Meines Erachtens besteht hier Handlungsbedarf. Diese Unterschiede zwischen den FujiNets dürfen keinesfalls bleiben. Wir haben ja auch keine Atari 1050 Laufwerke, wo die eine Sorte 128 Bytes pro Sektor verwendet und die andere Sorte 129 Bytes pro Sektor und jeweils handgeschnitzte DOS-Versionen dafür.

Ich sehe derzeit folgende Möglichkeiten:

- es kommt eine neue Firmware für alle alten FujiNets
- die Änderungen für die v1.6 werden revidiert und man verzichtet auf das letzte Zeichen

Gegen Punkt 1 spricht das Gerücht, daß man bei einigen oder allen alten FujiNets die Firmware nicht oder nur mit Problemen aktualisieren können soll.

Ganz davon ab wäre das Problem meines Erachtens einfacher zu lösen gewesen. Die C-Problematik mit der Null-terminierten Zeichenkette hätte man nicht auf den Atari übertragen müssen.

Ich finde, daß die Zeichenkette nur dann durch ein Sonderzeichen abgegrenzt werden muß, solange der Puffer dafür nicht voll genutzt wird.

Hier ein einfaches Beispiel in Assembler zum Auslesen, welches als Ende für die Zeichenkette sowohl die Null als auch das Pufferende verwendet, ohne daß der Puffer 1 Byte länger sein muß als die maximale Länge der Zeichenkette:

Code: Alles auswählen

    	LDA #$0
    	TAY
:L1 	LDA SSID_BFR,Y
    	STA SSID,Y
    	BEQ :XIT
    	INY
    	CPY #33
    	BCC :L1 ;ist BCC hier richtig? Müßte ich noch checken
:XIT    RTS
.LOCAL

Abgesehen davon scheint es das Problem mit der Null-Terminierung auch woanders zu geben. Bei der Suche im Netz, wie lang ein "Preshared Key (PSK)" für die Verwendung bei WLAN unter WPA sein darf, habe ich folgende Anmerkung gefunden:

"WPA-PSK: In the Passphrase mode, the input must be 8 to 63 characters. In the Hexadecimal mode, enter 64 characters."
Quelle: https://forums.androidcentral.com/googl ... ength.html

Da konnte wohl noch jemand die ENTER-Taste nicht mehr verarbeiten, wenn das PSK als Zeichenkette eingegeben wurde...

Ich bin auch selber schon auf das Problem gestoßen, wenn ich bei WLAN-Geräten namhafter Hersteller für den PSK 32 Zeichen eingegeben habe. Der Schlüssel hat dann einfach nicht funktioniert. Ich vergebe mittlerweile standardmäßig 30 Zeichen, so daß das auf jeden Fall in den Puffer passen sollte.

Wie auch immer finde ich, daß wir für die FujiNets eine Lösung brauchen, die die verschiedenen Versionen wieder untereinander kompatibel macht und ich hoffe, daß die Authoren da Abhilfe schaffen können.

Abgesehen davon: beim Hostnamen wurde das 64-Byte lange Feld bislang nicht auf 65 Zeichen erweitert. Braucht man da keine Null-Terminierung?

CU, Erhard

===

According to my knowledge as of today:

With the release of version 1.6 of FujiNet (FN), some changes have been made by the author(s).

As a result of these changes, some SIO commands between FujiNet 1.1-1.5 and FujiNet 1.6 are no longer compatible with each other. Consequently, the same applies to those FujiNet Tools for the Atari using these SIO commands.

Using the example of WLAN SSID, I will explain why there was a problem and how it was corrected.

According to the specification a SSID may be 32 octets (bytes) long.

With the FN 1.1 - 1.5 you can only enter 31 characters in the menu, followed by an ENTER. One can set the SSID to 32 chars via a SIO command, but then the firmware does not recognise the end of the string which means it doesn't take the max buffer length into consideration.

The reason is said to be that for programming the firmware of the FN as well as the Atari Tools the programming language C was used, which usually uses null-terminated strings.

So in the case of the SSID, according to the authors, a 33rd byte would have been required for the buffer, which was overlooked in the firmware of the FN 1.1-1.5.

Here the data block my FN 1.1-1.5 returns using SIO command $E8, buffer address $4000:

Code: Alles auswählen

  4000  48 57 30 00 00 00 00 00 HW0.....
  4008  00 00 00 00 00 00 00 00 ........
  4010  00 00 00 00 00 00 00 00 ........
  4018  00 00 00 00 00 00 00 00 ........
  4020  45 50 2D 46 75 6A 69 4E EP-FujiN
  4028  65 74 00 00 00 00 00 00 et......
  4030  00 00 00 00 00 00 00 00 ........
  4038  00 00 00 00 00 00 00 00 ........
  4040  00 00 00 00 00 00 00 00 ........
  4048  00 00 00 00 00 00 00 00 ........
  4050  00 00 00 00 00 00 00 00 ........
  4058  00 00 00 00 00 00 00 00 ........
  4060  C0 A8 B1 18 C0 A8 B1 01 @(1.@(1.
  4068  FF FF FF 00 C0 A8 B1 01 ....@(1.
  4070  C4 5B BE 3B 0D 8C 38 10 D[>;..8.
  4078  D5 29 D7 87 30 2E 35 2E U)W.0.5.
  4080  66 38 63 63 34 32 39 32 f8cc4292
  4088  00 00 00 FF FF FF FF FF ........

Here you can see the structure:

from $4000 there are 32 bytes for the SSID
from $4020 there are 64 bytes for the hostname
from $4060 there are 4 bytes for the IP address
from $4064 there are 4 bytes for the gateway
from $4068 it is 4 bytes for the subnet mask
from $406C there are 4 bytes for the DNS server

So data length was increased by (at least) 1 byte in the corresponding SIO commands for the SSID and other affected entries.

Here is the current (v1.6) SIO command for GET-SSID ($FE), which reads SSID and PSK:

https://github.com/FujiNetWIFI/fujinet- ... E-Get-SSID

Code: Alles auswählen

Device  : $70
CMD     : $FE
Bytes   : 97 ($61)
DAUX1/2 : 0

For my FN 1.1-1.5 the SSID is transmitted with 32 characters and therefore the command transmits only 96 bytes:

Code: Alles auswählen

Device  : $70
CMD     : $FE
Bytes   : 96 ($60)
DAUX1/2 : 0

The "v1.5" SIO command against a "v1.6" FujiNet will result in a checksum error.
The "v1.6" SIO command against a "v1.5" FujiNet will result in a timeout.

In my opinion this has to be rectified soon. These differences between the FujiNets must not remain. We don't have Atari 1050 drives where one type uses 128 bytes per sector and the other type uses 129 bytes per sector and hand carved DOS versions for each either, do we?

I currently see the following options:

- a new firmware is released for all old FujiNets
- the changes for v1.6 are revised and the last character is not usable

A new firmware for all old FujiNets might be a problem because there is the rumor that some or all old FujiNets are unable to update the firmware or at least that the procedure is problematic.

Quite apart from that, I think the problem would have been easier to solve. The C-language problem with the null-terminated string would not have had to be transferred to the Atari.

I think that the string only needs to be delimited by a special character as long as it does not fill the entire buffer.

Here is a simple example in assembler, which uses both the zero and the buffer end as the end for the string, without the buffer having to be 1 byte longer than the maximum length of the string:

Code: Alles auswählen

    	LDA #$0
    	TAY
:L1	LDA SSID_BFR,Y
    	STA SSID,Y
    	BEQ :XIT
    	INY
    	CPY #33; is BCC correct here? Have to recheck this.
    	BCC :L1
:XIT RTS
.LOCAL

Apart from that, the problem with null termination seems to exist elsewhere as well. While searching the net for how long a "preshared key (PSK)" may be for use with WLAN under WPA, I found the following note:

"WPA-PSK: In the Passphrase mode, the input must be 8 to 63 characters. In the Hexadecimal mode, enter 64 characters."
Source: https://forums.androidcentral.com/googl ... ength.html

I guess someone else couldn't handle the ENTER key when the PSK was entered as a string....

I have also encountered the problem myself when I entered 32 characters for the PSK on WLAN devices from well-known manufacturers. The key then simply did not work. I now assign 30 characters by default, so that should definitely fit in the buffer.

Anyway, I think that we need a solution for the FujiNets that makes the different versions compatible again and I hope that the authors can find a remedy.

By the way, there are still only 64 chars for the hostname. Do we not need a delimiter byte here, too?

CU, Erhard

DjayBee · Beitrag von **DjayBee** » 28.10.2022 19:06

Meines Wissens gibt es nur eine Firmware für ALLE Fujinets.

Insofern wird die Aktualisierung der Firmware auf deinen "alten" Fujinets das Problem vermutlich beheben.

Janzh · Beitrag von **Janzh** » 29.10.2022 18:25

Ja, es gibt nur eine Firmware, aber bestimmte Hardware Versionen setzen eine Minimalversion voraus.

Das Problem ist auch, dass die fujinet-config-tools passen müssen. Leider kommt keine Meldung, wegen falscher Version, sondern einfach Time-Outs und SIO Error und dann ist man am suchen.

Leider haben alle Firmware-Releases die gleiche Versionsnumber 0.5 und unterscheiden sich nur im GitHub-Hash (die 8-stellige Hex-Nummer nach 0.5.) und es gibt keine vollständige History mit den Änderungen (da müsste man alle Commits durchgehen).
Ich weiß nur, das in f8cc4292 die SSID noch 32bytes ist aber in 393a4d49 dann 33 Bytes:
https://github.com/FujiNetWIFI/fujinet- ... o/releases
Leider kann man am Hash auch nicht erkennen, was älter oder neuer ist und wann die Änderung der SSID-Länge reinkam.

Die Änderung der SSID-Länge in FCONFIG war Anfang Mai.
Also würde ich davon ausgehen, dass die Änderung ab dieser Version drin ist:
fujinet-ATARI-0.5.393a4d49.zip

Beim Hostnamen ist das gleiche Probblem, im Moment gehen nur 63 Zeichen (63 Zeichen + terminierende Null). Anscheinend läuft man seltener gegen diese Grenze, daher ist es noch nicht aufgefallen (hätte der Entwickler aber bei der Korrektur der SSID leicht sehen können). Die Firmware-Version hat das gliche Problem, fällt aber erst auf, wenn man mindestens dreistellige Version und zweistellige Unterversionsnummern hat.

Es macht eigentlich nur Ärger, daher stimme ich Erhard zu:
Das SIO Protokoll sollte nicht vom Datentyplayout einer Hochsprache abhängen.

tschak909 · Beitrag von **tschak909** » 30.10.2022 02:31

There was a user who ran into the issue of the SSID being one byte too small, so it was corrected.

This did cause a change in the Fuji protocol, an addition of one byte.

Because SIO commands must have a known quantity, and can't be fewer or more bytes than what is defined in the device control block, we can't support both forms.

So the firmware, CONFIG, and the fnc-tools were all updated to account for this problem.

Sorry it bit you guys, but the solution is fixed by using the latest firmware and the latest copy of fnc-tools.

-Thom

Janzh · Beitrag von **Janzh** » 30.10.2022 08:37

Hi Thom,
That's what I feared. That ship has already sailed.
In the future in my opinion such changes should mentioned in the release note and the version of both firmware and config should be increased. So you can write (and maybe check in programs) the firmware version 0.6 requires at least version 0.2 of config. The GitHub hashes are not very handy for human.
This issue also hits all programs the use SIO commands containing SSID.
Regards
Holger

Erhard · Beitrag von **Erhard** » 30.10.2022 09:15

Hi,

tschak909 hat geschrieben: ↑
30.10.2022 02:31
There was a user who ran into the issue of the SSID being one byte too small, so it was corrected.

I do not deny that there was a problem, but like pointed-out in my first article I guess this could have been easily corrected in the firmware without the need to change data sizes in SIO commands.

Beyond this I can see that there are other fields, like hostname that was and still is 64 characters. So I fear that there will be another change if a 65th character is implemented for a delimiter which would cause new SIO command definitions again. And maybe another change for full length PSK ?

I spent considerable time to search for and find precompiled firmware files being pushed back and fro between AA, Github and fujinet.online.

(I did not find a direct link to precompiled firmware, maybe I overlooked it).

However I was lucky to find an address only a few minutes ago

https://fujinet.online/firmware-dl/

which presents a nice and easy to understand folder structure and which comes along with a .json file containing the firmware file versions along with release dates and modification notes.

The firmware describtions in the .json file are sorted from new (top) to old (bottom). So now we can see which 0.5.xx firmware is which and which one is the latest.

I do not want to grumble about the FujiNet. In contrary I do like it very much and I appreciate all the tedious work that has been put into creating this great piece of hardware.

I just think that it would have been a nicer solution if the null-termination string length related problem would have been corrected without changing the amount of transferred bytes in some SIO commands - at least in this late state.

Kind regards,

Erhard

Janzh · Beitrag von **Janzh** » 30.10.2022 11:13

PS:

[url]tnfs://fujinet.online/ATARI/fnc-tools.atr[/url]
and
https://github.com/FujiNetWIFI/fujinet- ... -tools.atr
contain still the old version.

This initially irritate me (my first action I tried with my new FujiNet):
I mounted [url]tnfs://fujinet.online/ATARI/fnc-tools.atr[/url]
Started FCONFIG.COM
Result SIO ERROR

After a debugging session I figured out what's happened

tschak909 · Beitrag von **tschak909** » 30.10.2022 16:30

My apologies on the old version. I took a precaution and rebuilt everything, and pushed the ATR to Github.

I will ask Mozzwald to update fnc-tools.atr on fujinet.online (as I do not have admin rights to that server).

Again, I do apologize for adjusting the data structure, back in May, there was a discussion about it in the Discord, and I ultimately made the call because we needed to change the size of the SSID field (it should have been 33 bytes in the first place).

Almost nobody uses the full 64 characters of the password field, so it wasn't considered critical.

I will remind everyone, that I am here, and that I am trying to engage everyone who takes the time to use what we make, because I want people to use the things we make.

I also must state, that while I have limited engineering cycles, I make time to teach anyone who wants to understand how FujiNet works so they can make it better. FujiNet belongs to all of us.

-Thom

Janzh · Beitrag von **Janzh** » 30.10.2022 18:41

Hi Thom,
Thanx a lot for clarification and your efforts. It is perfectly fine with me. I like FujiNet very much. Such things happened only if you have a lot of users

so you can be proud of yourself and your work. Compatibility is always an issue and the off-by-one issue is a C built-in

Regards
Holger

Erhard · Beitrag von **Erhard** » 31.10.2022 09:11

Hi Thom,

tschak909 hat geschrieben: ↑
30.10.2022 16:30
I do apologize for adjusting the data structure

there is no need to apologize. There are things that can be overlooked in a project as huge as this one.

I still think that it would have been possible to make full use of those 32 bytes in SSID without the need to change SIO data length.

tschak909 hat geschrieben: ↑
30.10.2022 16:30
Almost nobody uses the full 64 characters of the password field, so it wasn't considered critical.

On the other hand, well, how many people will ever really require that thirtysecond byte in SSID ...

Okay, so if those rumours about problems with firmware updates on certain devices are either not true or belong to the past so that everyone who owns a FujiNet can update his one without fearing to kill the thing I am fine, too.

Again I would like to mention that I did not intend to mourn. It is just that those changes may trash projects that rely on how FujiNet works.

My apologies in case I stepped on anybody's foot. There was no intention to do so.

Kind regards,

Erhard

Erhard · Beitrag von **Erhard** » 31.10.2022 13:36

Hi,

Erhard hat geschrieben: ↑
30.10.2022 09:15
I did not find a direct link to precompiled firmware, maybe I overlooked it

ich habe seoben festgestellt, daß man die Firmware zum Flashen nicht herunterladen muß.

Das aktuelle Flash-Programm macht das online und bietet eine sehr übersichtliche Auswahlliste an.

Das ist ultra-bequem ...

Für mich kommt da ein aber, aber das interessiert ja keinen außer mich.

==

I just found out that you do not have to download any firmware files.

The current flash program offers a clearly arranged selection list and performs an online download.

This is ultra-convenient ...

Erhard