[Fli4l_dev] var::slot_write: Cannot write to ... und andere eigenartige Fehler

[Hans Bachner]

Hallo Alex,

danke für deine Vorschläge.

Alexander Dahl schrieb am 28.08.2020 um 08:22:
> Hallo Hans,
> 
> ich habe mal meine zuletzt gelaufene UMTS config vorgekramt (fli4l 4.0).
> 
> Hans Bachner schrieb Freitag, 28. August 2020, 02:23 (CEST):
>> Alexander Dahl schrieb am 27.08.2020 um 21:23:
>>> Hans Bachner schrieb Donnerstag, 27. August 2020, 19:59 (CEST):
>>>> wollte mir heute noch rasch einen Router für den Urlaub konfigurieren
>>>> (LTE Stick für den Internetzugang) mit der vor ein paar Monaten herunter
>>>> geladenen Version 4.0.0-r58491-testing (x86).
>>>>
>>>> Beim Build bekomme ich aber einige Fehlermeldungen, die ich mir nicht
>>>> erklären kann:
>>>>
>>>>> var::slot_write: Cannot write to 'IP_DYN_ADDR' (priority 2) with
>>>>>        priority 2 by strong access.
>>>>> Setting variable 'IP_DYN_ADDR' to 'yes' at [configuration file
>>>>>       'Q:\fli4l\v4.0.0-r58491-testing-x86\config.toscana.acrosser.hd/circuits.txt'
>>>>>       (package circuits) 23:0] failed.
>>>>
>>>> was will mir der Build damit sagen?
>>>
>>> Verstehe ich auch nicht.
>>>
>>>>> var::slot_write: Cannot write to 'DIALMODE' (priority 2) with priority
>>>>>        2 by strong access.
>>>>> Setting variable 'DIALMODE' to 'auto' at [configuration file
>>>>>       'Q:\fli4l\v4.0.0-r58491-testing-x86\config.toscana.acrosser.hd/circuits.txt'
>>>>>       (package circuits) 24:0] failed.
>>>>
>>>> dito.
>>>
>>> Seltsam.
>>
>> Diese beiden Fehler habe ich nach wie vor :-(
> 
> Die beiden Variablen sehen aber korrekt aus, hab ich auch so in
> circuits.txt:
> 
>   IP_DYN_ADDR='yes'               # use dyn. IP addresses (most providers do)
>   DIALMODE='auto'                 # standard dialmode: auto, manual, or off

Das funktioniert erst einmal, wenn ich beide Variable auskommentiere. 
Sie kommen dann automatisch mit genau dieser Einstellung in die rc.cfg.

>>>>> Error while processing variable assignments.
>>>>> var::slot_check: Value '' of variable 'CIRC_1_PPP_USERID' is not
>>>>>        properly typed: should not be empty
>>>>
>>>> Mein Anbieter (drei.at) braucht keine Userid für die LTE-Einwahl.
>>>
>>> Dann kannst Du da einen Dummy-Wert eintragen. Ich meine die Doku macht
>>> sogar ein paar Vorschläge für den Fall.
>>
>> In der Doku habe ich nichts gefunden, aber: wenn ich die Variable
>> auskommentiere, ist der Fehler weg.
>>
>>>>> var::slot_check: Value 'ppp' of variable 'CIRC_1_TYPE' is not properly
>>>>>        typed: wrong circuit type, choose one of: route, net
>>>>
>>>> der TYPE ist auf ppp gesetzt - das sollte doch mit dem Paket UMTS passen?
>>>
>>> Ja, aber Du musst auch noch das Paket ppp auspacken und aktivieren.
>>
>> Ach ja - ausgepackt war das Paket, aber die ppp.txt im
>> Konfig-Verzeichnis hat gefehlt...
> 
> OPT_PPP='yes'
> 
> ;-)

ja, klar. Dieser Fehler ist ja auch schon weg.

>>> Hast Du schon eine andere UMTS-Konfiguration laufen? Sonst such ich Dir
>>> ein Beispiel von mir raus.
>>
>> Ja, hab ich, mir dem selben UMTS-Stick, anderem Provider, etwas ältere
>> Version.
>>
>> Ich hab versuchsweise das Konfig-Verzeichnis auch zu dieser VErsio
>> kopiert, da fliegt mir der Build mot Bomben und Granaten um die Ohren.
> 
> Von 3.10 zu 4.0 ist das zu erwarten. Oder war das auch schon 4.0?

das sind beides 4.0er Versionen.

>>>>> var::slot_check: Value '' of variable 'CIRC_1_PPP_PASSWORD' is not
>>>>>        properly typed: should not be empty
>>>>
>>>> Mein Anbieter (drei.at) braucht kein Passwort für die LTE-Einwahl.
>>>
>>> Siehe oben.
>>
>> Siehe oben
> 
> Ja hier verlangt mein provider auch weder userid noch password, circuit
> config sieht dann so aus, man beachte PPP_USERID und PPP_PASSWORD, die
> sind halt auf dummy-Werte gesetzt wie in der Doku beschrieben (?):
> 
>   CIRC[] {
>     NAME='UMTS-IPv4'
>     TYPE='ppp'
>     DIALMODE='auto'
>     PPP_TYPE='umts'
>     ENABLED='yes'
>     UP='no'
>     PRIORITY='2'
>     CLASS[]='internet-v4-private'
>     UMTS_APN='internet'
>     UMTS_DIALOUT='*99#'
>     PPP_USERID='anonymer'
>     PPP_PASSWORD='surfer'
>     PPP_FILTER='yes'
>     PPP_FILTER_EXPR=''
>     NETS_IPV4[]='0.0.0.0/0'
>     HUP_TIMEOUT='0'
>     USEPEERDNS='yes'
>   }

Der Build geht durch, wenn ich PPP_USERID und PPP_PASSWORD 
auskommentiere. Beide Variable landen dann mir einem leeren string in 
der rc.cfg, genau was ich will.

> Circuit class braucht man nicht unbedingt.
> 
>>>>> Error while checking variable values.
>>>>> Error while processing configuration, aborting!
>>>>
>>>> Vielen Dank für jegliche Erleuchtung!
>>>
>>> Na wir werden schon Licht ins Dunkel bringen.
>>
>> Danke, eine ganze Menge!
>>
>> Ich frag mich jetzt nur noch, was die eigenartigen Meldungen zu
>> IP_DYN_ADDR und DIALMODE sollen...
>>
>> Hab jetzt die beiden Variablen einfach auskommentiert und siehe da, der
>> Build läuft durch. Beim Booten gibt es aber jetzt ein Problem mit dem
>> LTE-Stick, der Router schmeißt kryptische Meldungen am laufenden Band
>> raus (muss ich gelegentlich kopieren und hier einkippen).
> 
> Vergleiche mal ggf. nochmal mit den mitgelieferten config-Dateien, quasi
> die vor der Anpassung.
> 
>> Da in der ersten Bootphase (vor dem syslinux boot: Prompt) immer
>> Meldungen kamen, dass DEVICETREEDIR eine unbekannte Option sei, habe ich
>> vermutet, dass hier ein altes syslinux in die Suppe spuckt.
> 
> DeviceTree ist für x86 irrelevant, das braucht's nur für Arm. Kann man
> einfach ignorieren, syslinux ignoriert das auch.

ok, glaube ich schon einmal gehört zu haben. Trotzdem kommt die Meldung 
mit dem neueren syslinux nicht mehr - oder wird mit den anderen Messages 
verschluckt.

>> Also noch
>> einmal die alte 3.9er Version gebootet, syslinux von der 4.0 hinkopiert
>> und mit # syslinux -si /dev/sda1 den neuen Bootcode hinkopiert. Hat die
>> Situation leider nicht verbessert. Jetzt werden auch die *.MSG Files
>> nicht mehr angezeigt, es kommt gleich kommentarlos
>>> SYSLINUX 6.03 2014-10-06 Copyright (C) 1994-2014 H. Peter Anvin et al
>>> boot:
>> An dieser Stelle akzeptiert er aber "n" und "r", die syslinux.cfg liest
>> er aber. Warum er die DISPLAY Befehle ignoriert, ist mir ein Rätsel...
> 
> Keine Ahnung. Ob und wann syslinux da Eingaben akzeptiert scheint nicht
> ganz klar zu sein, da hatten wir auch mal ein Ticket zu, ist aber im
> Sande verlaufen. Hat mit UMTS aber nicht viel zu tun.

nein, eh nicht. Ist im Moment auch zweitrangig.

>> Der Router läuft einwandfrei mit einer Uralt-Konfiguration aus 2013
>> (fli4l 3.9.0-rev28090) und einem älteren UMTS-Stick. Wollte halt LTE
>> nutzen mit dem gleichen neuen Stick, der auf dem anderen Router
>> einwandfrei läuft.
> 
> Soweit klar.
> 
> Na vielleicht helfen ja die Boot-Meldungen, die Du noch nachliefern
> wolltest.  Vielleich hat auch noch wer anders eine Idee zu den Meldungen
> von mkfli4l?

Die Boot-Meldungen werde ich noch nachliefern, wahrscheinlich aber erst 
nächste Woche.

Ich bin nämlich inzwischen im Urlaub und habe hier schon einiges an Zeit 
investiert, um den Router mit der alten, schon mehrfach verwendeten 
Konfiguration ans laufen zu kriegen - leider noch ohne Erfolg (siehe 
eigenes Topic).

Inzwischen jedenfalls danke + schöne Grüße,
Hans.