Informationen zu den wöchentlichen 4.0-Archiven vom

Transcription

Subject: Informationen zu den wöchentlichen 4.0-Archiven vom 19.02.2016
(44579)
Posted by fl_0 on Sat, 20 Feb 2016 10:04:54 GMT
View Forum Message <> Reply to Message
-----BEGIN PGP SIGNED MESSAGE----Hash: SHA512
Hallo,
vor wenigen Tagen haben wir das Release 3.10.5 veröffentlicht, daher
gibt es in dieser Woche nur ein paar kleine Änderungen.
Im Vergleich zu den Archiven vom 13.02.2016 (r44496) gibt es die
folgenden Änderungen:
- -------------Fertiggestellt
- -------------FFL-1625: Paket APCUPSD akzeptiert nicht alle gültigen Zeichen in UPSNAME
* Der reguläre Ausdruck wurde angepasst und erlaubt jetzt neben Großund Kleinschreibung auch Binde- und Unterstriche.
FFL-1626: Paket APCUPSD erwartet bei TYPE='pcnet' zwingend eine
Portangabe beim Parameter APCUPSD_UPSDEVICE
* Die Angabe eines Ports kann jetzt entfallen sofern der Standardport
verwendet wird.
FFL-1639: FBR: Installation von Symlinks verbessern
* Sofern beim FBR Bau Symlinks angelegt wurden und der FBR Bau dann
abgebrochen wurde, wurden alle weiteren Builds aufgrund eines
fehlerhaften Umgangs mit diesen Symlinks abgebrochen. Dieser Fehler
wurde beseitigt.
FFL-1640: Anzeigebereich des multimon.cgi im Webgui von APCUPSD ist
nicht hoch genug
* Jetzt schon :-)
- --------In Arbeit
- --------FFL-357: Refactoring von mkfli4l
* Entsprechend einer Entscheidung durch das fli4l-Team wurde die
alternative Syntax noch einmal überarbeitet und die führenden Punkte
bei verschachtelten Zuweisungen entfernt.
- -----------------Die "FFL-<Nummer>"-Angaben sind Tickets. Sie können unter
http://bugs.fli4l.de/ eingesehen werden.
Page 1 of 42 ---- Generated from
net(t)forum
Viel Spaß beim Testen. Rückmeldungen gerne in die entsprechenden Tickets.
Viele Grüße
Florian
- -fli4l-Team
-----BEGIN PGP SIGNATURE----Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBCgAGBQJWyDpDAAoJEEjqHmQHmMqaGqoQAMsgGfov1D39bmjHdM9lrKEN
Wb0KbK2ReKZjaRBUJB0p+xWmdux6cwTsJsGwQCJNCRxE1OASN0w2d04RZeuqKYsc
sXJCm0HIPDlD3AadCfRaqa+isfqGFhiMXc8JUo2MN4iAVd9kxvpySzzCSvZ7BqXG
xvNHkGG7D4wGz6oeEbAfhuiBqthRpeT63Q9qAtpWoU1dR9K3Te0Tvu5hFUc5sKhv
Vj1/X77dLhOMHkxmflLyEElR6whh4xzTAzJjdLsz5SzGpPlkfWeh9H9y470aAFnY
RW4touvOYvqjNCvIaeGqjYy4VumPpBs+c/DEk89IHdUuhAacbj+4duPW3jyPABRz
a2n95m9cVXO5jBVFBaOojSmTZj8UIy8bwa7Pg+s+NeYUl+6wGkLr8EKrYJb/TWsD
C46tNSVYTZqNAu1qyywrOtmHeqnXawxb5o4IqKgD6GjV1/aXgllXoNqayYd9pRDu
YghwACsT/4SwEFucjZYhYj2C2aFbA+SQOeOzAjinpK6DDsrBzCebsn9vNjIK9PAA
CQpw2tTqykLNRm5HKjKtGrbtT3cAoKORRcP9bCYzGul6YH9Aob/TF4OWBfQ2zGKi
8sNiAvxO/nSuAfKFp0oHpZVdGVyM3H0Bqz5+Gx/lJuPQFKdhg0vJ9JAxbPLvrHW/
YJ1dCAG6w7ZoEZ63Bpk/
=6ZVb
-----END PGP SIGNATURE-----
Subject: Re: Informationen zu den wöchentlichen 4.0-Archiven vom 19.02.2016
(44579)
Posted by B. Sprenger on Mon, 22 Feb 2016 17:10:24 GMT
Hallo zusammen,
Am 20.02.2016 um 11:04 schrieb Florian Wolters:
> -----BEGIN PGP SIGNED MESSAGE----> Hash: SHA512
>
> Hallo,
>
> vor wenigen Tagen haben wir das Release 3.10.5 veröffentlicht, daher
> gibt es in dieser Woche nur ein paar kleine Änderungen.
> Im Vergleich zu den Archiven vom 13.02.2016 (r44496) gibt es die
> folgenden Änderungen:
>
Ich habe versucht dieses Release anzupassen, scheitere aber an der neuen
net(t)forum
Syntax.
Beim Build-Prozess hagelt es reichlich Fehler.
Wäre schön, wenn mir da mal jemand auf die Sprünge helfen könnte.
Meine Netzwerkkonfiguration sah vorher so aus:
OPT_IPV4='yes'
# enable IPv4 networking
IP_NET_N='5'
# number of IPv4 networks, usually 1
IP_NET_1='172.17.0.1/16'
# IP address of your n'th ethernet card
# netmask in CIDR (no. of set bits)
IP_NET_1_DEV='eth0'
# required: device name like ethX
IP_NET_2='172.30.0.1/16'
IP_NET_2_DEV='eth2'
IP_NET_3='{IPTV}'
IP_NET_3_DEV='eth1.8'
IP_NET_3_MAC='00:40:63:da:cf:32' # neue MAC/nicht MAC von eth1
IP_NET_4='{VDSL}'
# eth1.7 zum modem
IP_NET_5='192.168.1.2/30'
IP_NET_5_DEV='eth1'
# für den Zugriff auf das DSL-Modem
# /30 maskiert *.1.0, *.1.1, *.1.2, *.1.3
Das habe ich versucht zu adaptieren:
OPT_IPV4='yes'
IP_NET[1]='172.17.0.1/16'
{
DEV='eth0'
}
IP_NET[2]='172.30.0.1/16'
{
DEV='eth2'
}
IP_NET[3]={IPTV}
{
DEV='eth1.8'
IP_NET_MAC='00:40:63:da:cf:32' # neue MAC/nicht MAC von eth1
}
IP_NET[4]={VDSL}
net(t)forum
{
DEV='eth1.7'
IP_NET_MAC='00:40:63:da:cf:33' # neue MAC/nicht MAC von eth1
}
IP_NET[5]='192.168.1.2/30'
# /30 maskiert *.1.0, *.1.1, *.1.2, *.1.3
{
DEV='eth1'
}
In der Doku steht ja noch nichts darüber drin.
Wahrscheinlich stimmt meine Circuits.txt auch noch nicht, aber eines
nach dem anderen.
LG
Boris
(44579)
Posted by LanSpezi on Mon, 22 Feb 2016 17:44:04 GMT
Hallo Boris,
Am Mon, 22 Feb 2016 18:10:24 +0100 schrieb B. Sprenger:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
IP_NET_N='5'
# number of IPv4 networks, usually 1
IP_NET_1='172.17.0.1/16'
IP_NET_1_DEV='eth0'
IP_NET_2='172.30.0.1/16'
IP_NET_2_DEV='eth2'
IP_NET_3='{IPTV}'
IP_NET_4='{VDSL}'
# eth1.7 zum modem
IP_NET_5='192.168.1.2/30'
IP_NET_5_DEV='eth1'
# /30 maskiert *.1.0, *.1.1, *.1.2, *.1.3
> Das habe ich versucht zu adaptieren:
>
net(t)forum
>
>
>
>
>
>
>
>
>
>
>
>
>
>
OPT_IPV4='yes'
IP_NET[1]='172.17.0.1/16'
{
DEV='eth0'
}
IP_NET[2]='172.30.0.1/16'
{
DEV='eth2'
}
IP_NET[3]={IPTV}
hier fehlen die '' um {IPTV}
> {
> DEV='eth1.8'
> IP_NET_MAC='00:40:63:da:cf:32' # neue MAC/nicht MAC von eth1
und hier ist das IP_NET zu viel
> }
>
> IP_NET[4]={VDSL}
und hier noch mal die fehlenden ''
> {
> DEV='eth1.7'
> IP_NET_MAC='00:40:63:da:cf:33' # neue MAC/nicht MAC von eth1
und noch mal das IP_NET_ zuviel
>
>
>
>
>
>
>
}
IP_NET[5]='192.168.1.2/30'
# /30 maskiert *.1.0, *.1.1, *.1.2, *.1.3
{
DEV='eth1'
}
> In der Doku steht ja noch nichts darüber drin.
das kommt noch
> Wahrscheinlich stimmt meine Circuits.txt auch noch nicht, aber eines
> nach dem anderen.
die können wir fals nötig gemeinsam korrigieren um die neue Syntax nutzen
zu können - die alte funktioniert ja weiterhin
net(t)forum
Gruß Peter
(44579)
Posted by Christoph Schulz on Mon, 22 Feb 2016 18:03:16 GMT
Hallo!
B. Sprenger schrieb:
> Ich habe versucht dieses Release anzupassen, scheitere aber an der neuen
> Syntax.
> Beim Build-Prozess hagelt es reichlich Fehler.
Wie können wir dir helfen, wenn du nicht einmal sagst, *welche* Fehler
auftauchen?
Immerhin hat Peter bereits einige definitiv fehlerhafte Stellen gefunden,
eventuell läuft mkfli4l ja jetzt bei dir durch. Aber das nächste Mal bitte
die konkreten Meldungen auch liefern. Das hilft. Wirklich. ;-)
Viele Grüße,
-Christoph Schulz
[fli4l-Team]
(44579)
Posted by B. Sprenger on Tue, 23 Feb 2016 18:42:02 GMT
Hallo zusammen,
vielen Dank schon mal für die Hilfe
(auch wenn ich die Fehlermeldungen wegrationalisiert habe, gelobe aber
Besserung).
Die fehlenden '' habe ich ergänzt, da schäme ich mich fast etwas, weil
ich das nicht selbst gesehen habe.
Das mit dem
"und noch mal das IP_NET_ zu viel"
habe ich nicht verstanden.
Welches IP_NET ist denn zu viel?
Ist es das IP_NET_MAC? Das wird doch benötigt?
Und das IP_NET[x]='{VDSL}' kann es doch auch nicht sein?
Bin gerade ziemlich verwirrt.
Im Log ist auch diesbezüglich kein Fehler für mich erkennbar, aber der
net(t)forum
Buildprozess scheint auch noch nicht durch zu laufen.
Und weiter geht es:
Error while processing variable assignments.
var::slot_check: Value 'dhcp' of variable 'CIRC_2_TYPE' is not
properly typed: wrong circuit type, choose one of: route, net,
ppp
Error while checking variable values.
Die dazugehörigen Konfigurationszeilen sehen wie folgt aus:
CIRC_2_NAME='IPTV'
# circuit name, don't use spaces
CIRC_2_TYPE='dhcp'
# this is a DHCP circuit
CIRC_2_ENABLED='yes'
# the circuit is enabled
CIRC_2_CLASS_N='1'
# set meaningful classes
CIRC_2_CLASS_1='Fernsehen'
CIRC_2_NETS_IPV4_N='1'
CIRC_2_NETS_IPV4_1='193.158.34.0/23'
CIRC_2_USEPEERDNS='no'
CIRC_2_UP='yes'
CIRC_2_WAIT='15'
CIRC_2_DHCP_DAEMON='dhcpcd'
CIRC_2_DHCP_DEV='IP_NET_3_DEV' # listen on this interface
Und ein weiterer Auszug aus dem Log:
Error while parsing variable assignments at [configuration file
'I:\freigabe\fli4l\FLI4l_Tarball_4.0_19022016-r44579\config.e40/dns_dhcp .txt'
(package dns_dhcp) 80:0]: syntax error, unexpected ABSOLUTE_INDEX,
expecting ID or LBRACKET or RBRACE
Was bedeutet denn ID?
was bedeutet RBRACE?
und was bedeutet LBRACKET?
Und
Error while scanning variable assignments at [configuration file
(package dns_dhcp) 80:1]: Unknown character '_' (ASCII 0x5f).
Die Config-Zeile, die das vermutlich verursacht sieht so aus:
HOST[]
{
NAME='RX-V-773'
IP4='172.17.0.5'
MAC='00:A0:DE:90:EC:9C'
}
net(t)forum
Muss ich in den eckigen Klammern eine fortlaufende Zahl angeben?
LG
Boris
(44579)
Posted by LanSpezi on Tue, 23 Feb 2016 19:12:06 GMT
Hallo Boris,
Am Tue, 23 Feb 2016 19:42:02 +0100 schrieb B. Sprenger:
>
>
>
>
>
>
Das mit dem
"und noch mal das IP_NET_ zu viel"
habe ich nicht verstanden.
Welches IP_NET ist denn zu viel?
Ist es das IP_NET_MAC? Das wird doch benötigt?
Und das IP_NET[x]='{VDSL}' kann es doch auch nicht sein?
und danach kommt bei dir
{ <- Begin eines Blockes der sich auf die Zeile davor bezieht
MAC='xxxxxxxxx' <- Variablenname vor dem Block wird mit MAC ergänzt ->
es wird also bei der Verarbeitung eib IP_NET_<ID>_MAC='xxxxx' daraus
} <- Ende des Blockes
> Error while processing variable assignments.
> var::slot_check: Value 'dhcp' of variable 'CIRC_2_TYPE' is not
>
properly typed: wrong circuit type, choose one of: route, net,
>
ppp
da deutet darauf hin, das du im Paket dns_dhcp die den DHCP_CLIENT nicht
aktiviert hast
OPT_DHCP_CLIENT='yes'
und dadurch dann der Werte für den CIRCUIT_TYPE nicht dhcp annehmen darf.
>
>
>
>
>
>
>
>
>
Die dazugehörigen Konfigurationszeilen sehen wie folgt aus:
CIRC_2_NAME='IPTV'
CIRC_2_TYPE='dhcp'
CIRC_2_CLASS_N='1'
CIRC_2_NETS_IPV4_1='193.158.34.0/23'
net(t)forum
>
>
>
>
CIRC_2_UP='yes'
CIRC_2_WAIT='15'
könnte man auch so schreiben
CIRC[2]
{
NAME='IPTV'
TYPE='dhcp'
ENABLED='yes'
....
....
DHCP_DEV='IP_NET_3_DEV'
}
>
>
>
>
>
>
>
>
>
>
Und ein weiterer Auszug aus dem Log:
Was bedeutet denn ID?
eindeutiger Zahl - der Zähler der Variable
> was bedeutet RBRACE?
Right Bracket = rechte Klammer
> und was bedeutet LBRACKET?
Left Bracket = linke Klammer
>
>
>
>
>
>
>
>
>
>
>
>
Error while scanning variable assignments at [configuration file
(package dns_dhcp) 80:1]: Unknown character '_' (ASCII 0x5f).
HOST[]
{
NAME='RX-V-773'
IP4='172.17.0.5'
net(t)forum
> MAC='00:A0:DE:90:EC:9C'
> }
die Block ist es definitiv nicht
> Muss ich in den eckigen Klammern eine fortlaufende Zahl angeben?
nein - du kannst/könnntest aber
leere [] = es wird automatisch nummeriert
Bsp.
HOST[1] <- hieraus wird dann HOST_1_.....
{
....
}
HOST[] <- heraus wird dann HOST_3_.... da der aksolute Index 2 weiter unten
zugeodnet wurde
{
....
}
HOST[2] <- hieraus wird HOST_2_....
{
.....
}
Ich hoffe meine Erklärungen helfen Dir die neue alternative
Konfigurationsyntax zu verstehen.
Gruß Peter
(44579)
Posted by Christoph Schulz on Tue, 23 Feb 2016 19:47:23 GMT
Hallo!
> Error while parsing variable assignments at [configuration file
>
> 'I:\freigabe\fli4l\FLI4l_Tarball_4.0_19022016r44579\config.e40/dns_dhcp.txt'
>
>
>
net(t)forum
Du fängst direkt mit einer Zahl an anstatt mit einem Namen (ID), einer
öffnenden Array-Klammer "[" (LBRACKET) oder mit einer schließenden
Gruppenklammer "}" (RBRACE).
> Error while scanning variable assignments at [configuration file
> 'I:\freigabe\fli4l\FLI4l_Tarball_4.0_19022016r44579\config.e40/dns_dhcp.txt'
> (package dns_dhcp) 80:1]: Unknown character '_' (ASCII 0x5f).
Hier kommt ein "_" hinter einer Zahl, etwa "1_".
Diese Meldung kommt wirklich _nach_ der obigen? Das ist seltsam, da der
Scanner vor dem Parser ausgeführt wird.
>
>
>
>
>
>
>
>
HOST[]
{
NAME='RX-V-773'
IP4='172.17.0.5'
MAC='00:A0:DE:90:EC:9C'
}
Nein, hier ist alles in Ordnung. Schau wirklich exakt in Zeile 80 der Datei
config/dns_dhcp.txt. In dem zitierten Teil kommt nicht ein einziger
Unterstrich vor!
> Muss ich in den eckigen Klammern eine fortlaufende Zahl angeben?
Nein. Der Fehler steckt irgendwo anders.
Viele Grüße,
-Christoph Schulz
[fli4l-Team]
(44579)
Posted by B. Sprenger on Wed, 24 Feb 2016 15:43:58 GMT
Hallo Christoph, hallo Peter,
vielen Dank für die ausführlichen Erläuterungen.
Damit komme ich erst mal ein ganzes Stück weiter.
Ich glaube auch so langsam die Logik hinter der neuen Syntax zu verstehen.
Ich melde mich die nächsten Tage, wenn ich wieder Zeit zum probieren habe.
LG
net(t)forum
Boris
(44579)
Posted by B. Sprenger on Fri, 26 Feb 2016 18:57:11 GMT
Hallo zusammen,
mit dem neu gelernten habe ich heute weiter gemacht und bin ein ganzes
Stück weiter.
Aber der Buildprozess läuft noch nicht durch.
In meiner alten cicuits.txt standen vorher folgende Zeilen:
CIRC_2_NAME='IPTV'
CIRC_2_TYPE='dhcp'
CIRC_2_CLASS_N='1'
CIRC_2_NETS_IPV4_1='193.158.34.0/23'
CIRC_2_UP='yes'
# activate at boot time
CIRC_2_WAIT='15'
CIRC_2_DHCP_HOSTNAME=''
CIRC_2_DHCP_STARTDELAY='0'
CIRC_2_ROUTE_GATEWAY_IPV4='93.227.63.254' # next IPv4 hop to use
Den letzten Parameter (Gateway) vermisse ich in der neuen Konfiguration.
Diese habe ich wie folgt umgesetzt:
CIRC[] {
NAME='IPTV'
TYPE='dhcp'
ENABLED='yes'
CLASS[]='Fernsehen'
# set meaningful class
NETS_IPV4[]='193.158.34.0/23'
USEPEERDNS='no'
UP='yes'
WAIT='15'
DHCP_DAEMON='dhcpcd'
# DHCP_HOSTNAME=''
DHCP_STARTDELAY='0'
}
Wäre dann hier
GATEWAY_IPV4='93.227.63.254' # next IPv4 hop to use
zu ergänzen?
net(t)forum
Diese sollte dann unbedingt in die Musterkonfiguration aufgenommen werden.
Weiterhin muss die Zeile
# DHCP_HOSTNAME=''
auskommentiert werden.
Warum ist das so?
Könnte man hier nicht so parsen, dass, wenn die Variable leer ist, der
Parameter ignoriert wird?
So finde ich das ziemlich verwirrend.
Folgende Fehlermeldungen tauchen derzeit beim Buildprozess auf:
(Und: ja, ich habe die Datei kernel_4_3_nonfree.tar.gz heruntergeladen
und entpackt. Die unten aufgeführten Dateien sind aber nicht enthalten.)
Liegt der Fehler bei mir oder ist hier tatsächlich ein Fehler passiert?
Fehler in den fli4l-Konfigurationsdateien!
==================================================================
opt/kernel_4_3_nonfree.txt:180: cannot access
'files/lib/firmware/rtl_nic/rtl8105e-1.fw' of type 'local file
system object'
system object'
system object'
system object'
system object'
'files/lib/firmware/rtl_nic/rtl8168d-1.fw' of type 'local file
system object'
'files/lib/firmware/rtl_nic/rtl8168d-2.fw' of type 'local file
system object'
system object'
system object'
system object'
'files/lib/firmware/rtl_nic/rtl8168f-1.fw' of type 'local file
net(t)forum
system object'
'files/lib/firmware/rtl_nic/rtl8168f-2.fw' of type 'local file
system object'
'files/lib/firmware/rtl_nic/rtl8168g-2.fw' of type 'local file
system object'
'files/lib/firmware/rtl_nic/rtl8168g-3.fw' of type 'local file
system object'
'files/lib/firmware/rtl_nic/rtl8168h-1.fw' of type 'local file
system object'
'files/lib/firmware/rtl_nic/rtl8168h-2.fw' of type 'local file
system object'
'files/lib/firmware/rtl_nic/rtl8402-1.fw' of type 'local file
system object'
system object'
system object'
Error: No network driver found for NET_DRV_1='8139too', check
config/base.txt
==================================================================
Der Build-Prozess wurde aufgrund eines Fehlers abgebrochen!
Schon mal vielen Dank fürs Lesen bis hierher.
LG
oris
(44579)
Posted by LeSpocky on Fri, 26 Feb 2016 19:47:02 GMT
Moin,
B. Sprenger schrieb Freitag, 26. Februar 2016, 19:57 (CET):
> Folgende Fehlermeldungen tauchen derzeit beim Buildprozess auf:
> (Und: ja, ich habe die Datei kernel_4_3_nonfree.tar.gz heruntergeladen
> und entpackt. Die unten aufgeführten Dateien sind aber nicht enthalten.)
>
> Liegt der Fehler bei mir oder ist hier tatsächlich ein Fehler passiert?
net(t)forum
Möglich, dass das ein Fehler im Paket ist. Hast Du mal einen anderen
Kernel probiert? Bspw. 4.1?
Gruß
Alex
-***** http://blog.antiblau.de/ *****************************
GnuPG-FP: C28E E6B9 0263 95CF 8FAF 08FA 34AD CD00 7221 5CC6
(44579)
Posted by Christoph Schulz on Fri, 26 Feb 2016 21:22:17 GMT
Hallo!
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
CIRC_2_ROUTE_GATEWAY_IPV4='93.227.63.254' # next IPv4 hop to use
Den letzten Parameter (Gateway) vermisse ich in der neuen Konfiguration.
Diese habe ich wie folgt umgesetzt:
CIRC[] {
NAME='IPTV'
TYPE='dhcp'
ENABLED='yes'
CLASS[]='Fernsehen'
NETS_IPV4[]='193.158.34.0/23'
USEPEERDNS='no'
UP='yes'
WAIT='15'
# DHCP_HOSTNAME=''
DHCP_STARTDELAY='0'
}
Wäre dann hier
GATEWAY_IPV4='93.227.63.254' # next IPv4 hop to use
zu ergänzen?
Nein. Der Präfix ist "CIRC[]", d.h. CIRC + Index. Du musst also gedanklich
-- wie bei allen anderen Einstellungen auch -- "CIRC_2_" wegdenken, und es
bleibt "ROUTE_GATEWAY_IPV4" übrig. Also:
CIRC[] {
...
net(t)forum
ROUTE_GATEWAY_IPV4='93.227.63.254'
}
Abgesehen davon ist diese Einstellung aber auch nutzlos, denn du definierst
einen Circuit vom Typ "dhcp", und da wird CIRC_x_ROUTE_... (was zu Circuits
des Typs "route" gehört) ohnehin ignoriert.
> Diese sollte dann unbedingt in die Musterkonfiguration aufgenommen werden.
Jein. Zum einen sind Circuits vom Typ "route" bereits dokumentiert. Zum
anderen werden "route"-Circuits irgendwann demnächst ohnehin durch "net"Circuits ersetzt werden. Warum sich also die Mühe machen, noch mehr
Beispiele zu ersinnen, die dann sowieso alle umgearbeitet werden müssen?
> Weiterhin muss die Zeile
> # DHCP_HOSTNAME=''
> auskommentiert werden.
Warum?
> Warum ist das so?
Weiß ich nicht, siehe oben.
> Könnte man hier nicht so parsen, dass, wenn die Variable leer ist, der
> Parameter ignoriert wird?
> So finde ich das ziemlich verwirrend.
Ich auch. Noch verwirrender finde ich, dass du behauptest, man müsse die
Zeile auskommentieren, aber keinen Beleg dafür lieferst, dass es tatsächlich
so ist. Mit anderen Worten: Wie genau lautet die Fehlermeldung, die mkfli4l
in diesem Falle ausgibt?
>
>
>
>
>
>
>
>
>
>
>
>
Folgende Fehlermeldungen tauchen derzeit beim Buildprozess auf:
(Und: ja, ich habe die Datei kernel_4_3_nonfree.tar.gz heruntergeladen
und entpackt. Die unten aufgeführten Dateien sind aber nicht enthalten.)
Liegt der Fehler bei mir oder ist hier tatsächlich ein Fehler passiert?
==================================================================
system object'
[...]
Das sind alles Meldungen über fehlende Firmware (files/lib/firmware/...). Du
hast also allem Anschein nach vergessen, das passende firmware-Paket mit zu
entpacken.
> Error: No network driver found for NET_DRV_1='8139too', check
>
config/base.txt
net(t)forum
Diese Meldung wundert mich, denn der Treiber ist im Paket enthalten. Hast du
das Kernel-Paket *komplett* entpackt, und passt die KERNEL_VERSION in deiner
Konfiguration mit der Version des Kernel-Pakets überein? Du findest die
Kernel-Version als Verzeichnis unterhalb von opt/files/lib/modules/ wieder.
Viele Grüße,
-Christoph Schulz
[fli4l-Team]
(44579)
Posted by B. Sprenger on Sun, 28 Feb 2016 08:05:20 GMT
Hallo zusammen,
Am 26.02.2016 um 22:22 schrieb Christoph Schulz:
> Hallo!
>
> B. Sprenger schrieb:
>
>> CIRC_2_ROUTE_GATEWAY_IPV4='93.227.63.254' # next IPv4 hop to use
>>
>
> Nein. Der Präfix ist "CIRC[]", d.h. CIRC + Index. Du musst also
gedanklich
> -- wie bei allen anderen Einstellungen auch -- "CIRC_2_" wegdenken,
und es
> bleibt "ROUTE_GATEWAY_IPV4" übrig. Also:
>
> CIRC[] {
> ...
> ROUTE_GATEWAY_IPV4='93.227.63.254'
>}
>
> Abgesehen davon ist diese Einstellung aber auch nutzlos, denn du
definierst
> einen Circuit vom Typ "dhcp", und da wird CIRC_x_ROUTE_... (was zu
Circuits
> des Typs "route" gehört) ohnehin ignoriert.
Hm, ich meine mich zu erinnern, dass "wir" den Parameter vor etwa 2
Jahren aufgenommen haben, da der Telekom-Server per DHCP nicht das
richtige Gateway bzw. da Gateway nicht standardkonform übermittelt.
Aber ich habe es gerade mit meiner aktuellen Konfiguration (r4384)
ausprobiert. Das Ergebnis: Der Parameter kann tatsächlich entfallen.
Ich frage mich nur gerade warum er dann bei mir in der Konfiguration
net(t)forum
stand. Aber IPTV funktioniert gerade auch ohne dieses Gateway.
>
>
>> Weiterhin muss die Zeile
>> # DHCP_HOSTNAME=''
>> auskommentiert werden.
>
> Warum?
>
>> Warum ist das so?
>
> Weiß ich nicht, siehe oben.
>
>> Könnte man hier nicht so parsen, dass, wenn die Variable leer ist, der
>> Parameter ignoriert wird?
>> So finde ich das ziemlich verwirrend.
>
> Ich auch. Noch verwirrender finde ich, dass du behauptest, man müsse die
> Zeile auskommentieren, aber keinen Beleg dafür lieferst, dass es
tatsächlich
> so ist. Mit anderen Worten: Wie genau lautet die Fehlermeldung, die
mkfli4l
> in diesem Falle ausgibt?
Bitte schön:
==================================================================
var::slot_check: Value '' of variable 'CIRC_2_DHCP_HOSTNAME' is not
properly typed: wrong hostname, only letters, numbers and minus
sign are allowed; no leading or trailing minus sign; 63
characters maximum
Error while checking variable values.
Error while processing configuration, aborting!
==================================================================
>
>> Folgende Fehlermeldungen tauchen derzeit beim Buildprozess auf:
>> ==================================================================
>> opt/kernel_4_3_nonfree.txt:180: cannot access
>>
>>
system object'
>> [...]
>
> Das sind alles Meldungen über fehlende Firmware
(files/lib/firmware/...). Du
> hast also allem Anschein nach vergessen, das passende firmware-Paket
mit zu
> entpacken.
>
Ich habe gerade die heruntergeladenen Dateien
net(t)forum
kernel_4_3_nonfree.tar.gz und kernel_4_3.tar.gz nochmal entpackt. Die in
der Fehlermeldung aufgelisteten Dateien bzw. Verzeichnisse sind nicht
vorhanden....
Und dann festgestellt, dass mir beim Download irgendwie die
firmware.tar.gz durch die Lappen gegangen war.
Also zurück zur Cicuits.txt
Ich habe im Moment keinen Schimmer wie ich eine normale DSL-Einwahl
konfigurieren soll.
Meine alte Konfiguration
CIRC_CLASS_N='2' # number of circuit classes
CIRC_CLASS_1_NAME='internet' # 1st circuit class
CIRC_CLASS_2_NAME='Fernsehen' # 2st circuit class
CIRC_1_NAME='VDSL' # circuit name, don't use spaces
CIRC_1_TYPE='ppp' # this is a PPP circuit...
CIRC_1_PPP_TYPE='ethernet' # ...routed over Ethernet (PPPoE)
CIRC_1_ENABLED='yes' # the circuit is enabled
CIRC_1_CLASS_N='1' # set meaningful classes
CIRC_1_CLASS_1='internet'
CIRC_1_PPP_ETHERNET_DEV='eth1.7' # eth dev connected to ADSL modem,
CIRC_1_PPP_ETHERNET_TYPE='kernel'
CIRC_1_PPP_USERID='[email protected]' # username
CIRC_1_PPP_PASSWORD='password' # password
CIRC_1_PPP_FILTER='no' # filter traffic to be able to hangup
CIRC_1_PPP_FILTER_EXPR='' # the filter to use; leave empty to use
CIRC_1_PPP_VJ='yes'
CIRC_1_NETS_IPV4_1='0.0.0.0/0' # use default IPv4 route over this
CIRC_1_DEBUG='no' # enable pppd debugging, 'yes' or 'no'
CIRC_1_USEPEERDNS='yes' # use dns server of your provider:
CIRC_1_HUP_TIMEOUT='0' # idle time after which to hangup
#CIRC_1_CHARGEINT='60' # value of charge interval (in seconds)
CIRC_1_UP='yes' # activate at boot time
#CIRC_1_TIMES='Mo-Su:00-24:0.0:Y'
(den zweiten Circiut habe ich weggelassen, da gab es ein Beispiel, der
dürfte stimmem)
habe ich versucht wie folgt umzusetzen:
CIRC_CLASS_N='2' # number of circuit classes
CIRC_CLASS_1_NAME='internet' # 1st circuit class
CIRC_CLASS_2_NAME='Fernsehen' # 2st circuit class
CIRC[] {
NAME='VDSL' # circuit name, don't use spaces
TYPE='ppp' # this is a PPP circuit...
PPP_TYPE='ethernet' # ...routed over Ethernet (PPPoE)
net(t)forum
ENABLED='yes' # the circuit is enabled
CLASS_N='1' # set meaningful classes
CLASS_1='internet'
PPP_ETHERNET_DEV='eth1.7' # eth dev connected to ADSL modem,
PPP_ETHERNET_TYPE='kernel'
PPP_USERID='[email protected]' # username
PPP_PASSWORD='password' # password
PPP_FILTER='no' # filter traffic to be able to hangup
PPP_FILTER_EXPR='' # the filter to use; leave empty to use
PPP_VJ='yes' # try Van Jacobson TCPv4 header compression
NETS_IPV4_N='1'
NETS_IPV4_1='0.0.0.0/0' # use default IPv4 route over this circuit
DEBUG='no' # enable pppd debugging, 'yes' or 'no'
USEPEERDNS='yes' # use dns server of your provider: yes or no
HUP_TIMEOUT='0' # idle time after which to hangup
#CIRC_1_CHARGEINT='60' # value of charge interval (in seconds)
UP='yes' # activate at boot time (START_IMOND='no')
#CIRC_1_TIMES='Mo-Su:00-24:0.0:Y'
}
Dabei bekomme ich folgende Fehlermeldungenm:
==================================================================
var::slot_write: Missing indices (1 instead of 2) while setting
variable 'CIRC_1_CLASS_%'.
Setting variable 'CIRC_1_CLASS_%' to 'internet' at [configuration file
'N:\fli4l\FLI4l_Tarball_4.0_19022016-r44579\config.e40/circuits.txt'
(package circuits) 73:0] failed.
Variable 'CIRC_%_CIRC_1_PPP_FILTER_EXPR' set at [configuration file
(package circuits) 85:0] does not exist.
variable 'CIRC_1_NETS_IPV4_%'.
Setting variable 'CIRC_1_NETS_IPV4_%' to '0.0.0.0/0' at [configuration
file
Error while processing variable assignments.
Error while processing configuration, aborting!
==================================================================
Der Build-Prozess wurde aufgrund eines Fehlers abgebrochen!
Die helfen mir leider nicht so richtig weiter.
LG
Boris
net(t)forum
(44579)
Posted by Hans Bachner on Sun, 28 Feb 2016 09:27:00 GMT
Hallo Boris,
ich hab zwar die neue Syntax selbst noch nicht verwendet, würde es aber
aufgrund der Beschreibung, die es hier in der Gruppe bereits gab, so
probieren:
B. Sprenger schrieb am 28.02.2016 um 09:05:
[gequotete Schnipsel neu angeordnet]
> var::slot_write: Missing indices (1 instead of 2) while setting
> variable 'CIRC_1_CLASS_%'.
> Setting variable 'CIRC_1_CLASS_%' to 'internet' at [configuration file
> 'N:\fli4l\FLI4l_Tarball_4.0_19022016-r44579\config.e40/circuits.txt'
> (package circuits) 73:0] failed.
[...]
> CIRC_CLASS_N='2' # number of circuit classes
> CIRC_CLASS_1_NAME='internet' # 1st circuit class
> CIRC_CLASS_2_NAME='Fernsehen' # 2st circuit class
CIRC_CLASS[1] { NAME='internet' }
CIRC_CLASS[2] { NAME='Fernsehen' }
(die explizieten Indizes können nach meinem Verständnis auch weggelassen
werden, also nur [] statt [n])
> var::slot_write: Missing indices (1 instead of 2) while setting
> variable 'CIRC_1_NETS_IPV4_%'.
> Setting variable 'CIRC_1_NETS_IPV4_%' to '0.0.0.0/0' at [configuration
> file
> (package circuits) 89:0] failed.
[...]
> NETS_IPV4_1='0.0.0.0/0' # use default IPv4 route over this circuit
NETS_IPV4[1] { '0.0.0.0/0' }
Zu
> Variable 'CIRC_%_CIRC_1_PPP_FILTER_EXPR' [...] does not exist.
habe ich jetzt keine Idee - das sieht so aus, als hättest du in der
Konfigurationsdatei CIRC_1_PPP_FILTER_EXPR definiert anstatt nur
PPP_FILTER_EXPR, dein Beispiel zeigt das aber nicht.
Viel Erfolg,
Hans.
net(t)forum
(44579)
Posted by LeSpocky on Sun, 28 Feb 2016 09:27:17 GMT
Hallo,
B. Sprenger schrieb Sonntag, 28. Februar 2016, 09:05 (CET):
>> Ich auch. Noch verwirrender finde ich, dass du behauptest, man müsse die
>> Zeile auskommentieren, aber keinen Beleg dafür lieferst, dass es
> tatsächlich
>> so ist. Mit anderen Worten: Wie genau lautet die Fehlermeldung, die
> mkfli4l
>> in diesem Falle ausgibt?
>
> Bitte schön:
> ==================================================================
> var::slot_check: Value '' of variable 'CIRC_2_DHCP_HOSTNAME' is not
> properly typed: wrong hostname, only letters, numbers and minus
> sign are allowed; no leading or trailing minus sign; 63
> characters maximum
> Error while checking variable values.
> Error while processing configuration, aborting!
> ==================================================================
Da steht doch glasklar, was los ist: die Variable darf nicht leer sein
und muss stattdessen mit einem korrekten Hostnamen gefüllt werden, der
ausschließlich Buchstaben, Ziffern und ein Minuszeichen (nicht am Anfang
oder Ende) enthalten und nicht länger als 63 Zeichen sein darf. Also
entweder trägst Du da etwas korrektes ein, oder Du kommentierst die
Variable aus, die "Zwischenlösung" mit der leeren Variable so wie Du es
im Moment hast, wird abgelehnt.
Vermutlich weil es keinen Sinn macht als DHCP-Client dem DHCP-Server
einen hostnamen vorzuschlagen, der leer ist. Und dafür ist ja vermutlich
die Variable. Der fli4l agiert hier als DHCP-Client und kann im
DHCP-Request einen hostname mitgeben. Dieser dient dem DHCP-Server
üblicherweise dazu, diesen host ins DNS mit einzutragen. Bei einer
Verbindung zum Provider sollte sowas in aller Regel nicht nötig sein.
Grüße
Alex
(44579)
net(t)forum
Hallo,
Am 28.02.2016 um 10:27 schrieb Alexander Dahl:
>> ==================================================================
>> var::slot_check: Value '' of variable 'CIRC_2_DHCP_HOSTNAME' is not
>> properly typed: wrong hostname, only letters, numbers and minus
>> sign are allowed; no leading or trailing minus sign; 63
>> characters maximum
>> Error while checking variable values.
>> Error while processing configuration, aborting!
>> ==================================================================
>
> Da steht doch glasklar, was los ist: die Variable darf nicht leer sein
> und muss stattdessen mit einem korrekten Hostnamen gefüllt werden, der
> ausschließlich Buchstaben, Ziffern und ein Minuszeichen (nicht am Anfang
> oder Ende) enthalten und nicht länger als 63 Zeichen sein darf. Also
> entweder trägst Du da etwas korrektes ein, oder Du kommentierst die
> Variable aus, die "Zwischenlösung" mit der leeren Variable so wie Du es
> im Moment hast, wird abgelehnt.
>
> Vermutlich weil es keinen Sinn macht als DHCP-Client dem DHCP-Server
> einen hostnamen vorzuschlagen, der leer ist. Und dafür ist ja vermutlich
> die Variable. Der fli4l agiert hier als DHCP-Client und kann im
> DHCP-Request einen hostname mitgeben. Dieser dient dem DHCP-Server
> üblicherweise dazu, diesen host ins DNS mit einzutragen. Bei einer
> Verbindung zum Provider sollte sowas in aller Regel nicht nötig sein.
Ja, ich habe die Variable ja auskommentiert.
Ich finde die Fehlermeldung aber nicht logisch (kein Hostname <> wrong
hostname).
Und ich finde es nicht logisch eine Variable auskommentieren zu müssen.
IMHO wäre es logischer die Variable leer zu lassen wenn man sie nicht
benötigt und dann beim parsen eben einfach zu ignorieren.
Lg
Boris
(44579)
Hallo,
Am 28.02.2016 um 10:27 schrieb Hans Bachner:
> Hallo Boris,
>
> ich hab zwar die neue Syntax selbst noch nicht verwendet, würde es aber
> aufgrund der Beschreibung, die es hier in der Gruppe bereits gab, so
net(t)forum
> probieren:
>
>
>
>
>
>
>
CIRC_CLASS[1] { NAME='internet' }
CIRC_CLASS[2] { NAME='Fernsehen' }
(die explizieten Indizes können nach meinem Verständnis auch weggelassen
werden, also nur [] statt [n])
Genau das habe ich getan:
also:
CIRC_CLASS[] { NAME='internet' }
CIRC_CLASS[] { NAME='Fernsehen' }
>
>> var::slot_write: Missing indices (1 instead of 2) while setting
>> variable 'CIRC_1_NETS_IPV4_%'.
>> Setting variable 'CIRC_1_NETS_IPV4_%' to '0.0.0.0/0' at [configuration
>> file
>> 'N:\fli4l\FLI4l_Tarball_4.0_19022016-r44579\config.e40/circuits.txt'
>> (package circuits) 89:0] failed.
> [...]
>> NETS_IPV4_1='0.0.0.0/0' # use default IPv4 route over this circuit
>
> NETS_IPV4[1] { '0.0.0.0/0' }
>
> Zu
>> Variable 'CIRC_%_CIRC_1_PPP_FILTER_EXPR' [...] does not exist.
> habe ich jetzt keine Idee - das sieht so aus, als hättest du in der
> Konfigurationsdatei CIRC_1_PPP_FILTER_EXPR definiert anstatt nur
> PPP_FILTER_EXPR, dein Beispiel zeigt das aber nicht.
Naja,
ich hatte
NETS_IPV4_N='1'
NETS_IPV4[]='0.0.0.0/0' # use default IPv4 route over this circuit
und das "NETS_IPV4_N='1'" ist natürlich überflüssig und verursacht den
Fehler.
Von dieser Sorte Fehler hatte ich noch ein paar in meiner Konfiguration.
Immerhin läuft der Buildprozess jetzt durch.
Aber noch funktioniert (fast) nichts.
Im httpd habe ich unter Probleme folgenden Eintrag:
[rc340.circuits] ERR: circuit 2 (IPTV): interface does not exist
Die dazugehörige Konfiguration sieht so aus:
CIRC[] {
NAME='IPTV'
TYPE='dhcp'
net(t)forum
ENABLED='yes'
CLASS[]='Fernsehen'
NETS_IPV4[]='193.158.34.0/23'
USEPEERDNS='no'
# use dns server of your provider:
UP='yes'
# activate at boot time (OPT_IMOND='no')
WAIT='15'
# wait max. 15 seconds for an IP
# choose the DHCP program to use;
# DHCP_HOSTNAME=''
# Transfer a specific host-id
DHCP_STARTDELAY='0'
# Time [sec] to wait before the client
}
und die dazugehörigen Zeilen in der Base.txt:
IP_NET[1]='172.17.0.1/16'
{
DEV='eth0'
}
IP_NET[2]='172.30.0.1/16'
{
DEV='eth2'
}
IP_NET[3]='{IPTV}'
{
DEV='eth1.8'
MAC='00:40:63:da:cf:32' # neue MAC/nicht MAC von eth1
}
IP_NET[4]='{VDSL}'
{
DEV='eth1.7'
}
IP_NET[5]='192.168.1.2/30'
# /30 maskiert *.1.0, *.1.1, *.1.2, *.1.3
{
DEV='eth1'
}
Was ist denn hier noch falsch?
Ach ja und die Internet-Einwahl funktioniert auch noch nicht.
Welche Informationen sind hierzu hilfreich um das Problem einzugrenzen?
LG
Boris
(44579)
Sorry, der letzte Post ist mir an die falsche Stelle gerutscht.
Ich post ihn gleich nochmal an die richtige Stelle im Thread.
LG
Boris
(44579)
Hallo,
>> ==================================================================
>> var::slot_check: Value '' of variable 'CIRC_2_DHCP_HOSTNAME' is not
>> properly typed: wrong hostname, only letters, numbers and minus
>> sign are allowed; no leading or trailing minus sign; 63
>> characters maximum
>> Error while checking variable values.
>> Error while processing configuration, aborting!
>> ==================================================================
>
> Da steht doch glasklar, was los ist: die Variable darf nicht leer sein
> und muss stattdessen mit einem korrekten Hostnamen gefüllt werden, der
> ausschließlich Buchstaben, Ziffern und ein Minuszeichen (nicht am Anfang
> oder Ende) enthalten und nicht länger als 63 Zeichen sein darf. Also
> entweder trägst Du da etwas korrektes ein, oder Du kommentierst die
> Variable aus, die "Zwischenlösung" mit der leeren Variable so wie Du es
> im Moment hast, wird abgelehnt.
>
> Vermutlich weil es keinen Sinn macht als DHCP-Client dem DHCP-Server
> einen hostnamen vorzuschlagen, der leer ist. Und dafür ist ja vermutlich
> die Variable. Der fli4l agiert hier als DHCP-Client und kann im
> DHCP-Request einen hostname mitgeben. Dieser dient dem DHCP-Server
> üblicherweise dazu, diesen host ins DNS mit einzutragen. Bei einer
> Verbindung zum Provider sollte sowas in aller Regel nicht nötig sein.
hostname).
Lg
Boris
(44579)
Posted by LanSpezi on Sun, 28 Feb 2016 16:41:57 GMT
Hi Boris,
Am Sun, 28 Feb 2016 12:03:55 +0100 schrieb B. Sprenger:
>
>
>
>
>
>
ich hatte
NETS_IPV4_N='1'
NETS_IPV4[]='0.0.0.0/0' # use default IPv4 route over this circuit
und das "NETS_IPV4_N='1'" ist natürlich überflüssig und verursacht den
Fehler.
genau - wenn man die [] einsetzt darf kein entsprechendes N definiert sein
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
Die dazugehörige Konfiguration sieht so aus:
CIRC[] {
NAME='IPTV'
TYPE='dhcp'
ENABLED='yes'
CLASS[]='Fernsehen'
NETS_IPV4[]='193.158.34.0/23'
USEPEERDNS='no'
# use dns server of your provider:
UP='yes'
# activate at boot time (OPT_IMOND='no')
WAIT='15'
# wait max. 15 seconds for an IP
# choose the DHCP program to use;
# DHCP_HOSTNAME=''
# Transfer a specific host-id
DHCP_STARTDELAY='0'
# Time [sec] to wait before the client
}
und die dazugehörigen Zeilen in der Base.txt:
IP_NET[1]='172.17.0.1/16'
{
DEV='eth0'
}
IP_NET[2]='172.30.0.1/16'
{
DEV='eth2'
}
IP_NET[3]='{IPTV}'
{
net(t)forum
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
DEV='eth1.8'
}
IP_NET[4]='{VDSL}'
{
DEV='eth1.7'
}
IP_NET[5]='192.168.1.2/30'
# /30 maskiert *.1.0, *.1.1, *.1.2, *.1.3
{
DEV='eth1'
}
Was ist denn hier noch falsch?
zeig mal deine config/advenced_networking.txt in Bezug zu VLAN nach 8.2.1q
> Ach ja und die Internet-Einwahl funktioniert auch noch nicht.
> Welche Informationen sind hierzu hilfreich um das Problem einzugrenzen?
Mein Glaskugel sagt: wenn kein eth1.8 dann ist wahrscheinlich auch kein
eth1.7 da ;)
Gruß Peter
(44579)
Posted by Christoph Schulz on Sun, 28 Feb 2016 16:50:34 GMT
Hallo!
>
>
>
>
>
>
hostname).
Ich verstehe deinen Standpunkt. Aber "keine Information vorhanden" ist etwas
anderes als "die Information ist vorhanden, dass nichts da ist". Mit anderen
Worten: Kein Hostname ist etwas anderes als ein leerer Hostname, der da ist.
Den Hostnamen explizit auf etwas Leeres zu setzen ist somit nicht erlaubt
net(t)forum
(wie Alex sagt, das würde dem Wunsch entsprechen, einen leeren Hostnamen zum
DHCP-Server zu schicken). Gar keinen Hostnamen zu schicken ist jedoch
möglich, was dadurch ausgedrückt wird, dass die Variable überhaupt nicht
gesetzt wird.
Diese Unterscheidung gibt es noch an sehr vielen anderen Stellen. Fast alle
optionalen Variablen sind so gestrickt, dass man sie entweder weglassen oder
auf einen vernünftigen Wert setzen kann, aber sie auf eine leere
Zeichenkette zu setzen ist nicht erlaubt.
Viele Grüße,
-Christoph Schulz
[fli4l-Team]
(44579)
Hallo!
Hans Bachner schrieb:
>> CIRC_CLASS_N='2' # number of circuit classes
>> CIRC_CLASS_1_NAME='internet' # 1st circuit class
>> CIRC_CLASS_2_NAME='Fernsehen' # 2st circuit class
>
> CIRC_CLASS[1] { NAME='internet' }
> CIRC_CLASS[2] { NAME='Fernsehen' }
>
> (die explizieten Indizes können nach meinem Verständnis auch weggelassen
> werden, also nur [] statt [n])
Richtig. Man muss hier immer "in Präfixen" denken, d.h. in ausgeklammerten
Wortanfängen. Ich kann die obige Konfiguration also so schreiben:
CIRC.CLASS[].NAME='internet'
CIRC.CLASS[].NAME='Fernsehen'
Oder so:
CIRC.CLASS[] {
NAME='internet'
}
CIRC.CLASS[] {
NAME='Fernsehen'
}
net(t)forum
Oder so:
CIRC.CLASS {
[].NAME='internet'
[].NAME='Fernsehen'
}
Oder so:
CIRC.CLASS {
[] {
NAME='internet'
}
[] {
NAME='Fernsehen'
}
}
>> NETS_IPV4_1='0.0.0.0/0' # use default IPv4 route over this circuit
>
> NETS_IPV4[1] { '0.0.0.0/0' }
Das geht nicht, weil hier die Zuweisung unter den Tisch gefallen ist.
Richtig ist:
NETS_IPV4[1]='0.0.0.0/0'
Oder ohne Index:
NETS_IPV4[]='0.0.0.0/0'
Alle möglichen Anfänge können natürlich wieder ausgeklammert werden, z.B.:
NETS.IPV4 {
[]='0.0.0.0/0'
}
NETS {
IPV4 {
[]='0.0.0.0/0'
}
}
Viele Grüße,
-Christoph Schulz
[fli4l-Team]
net(t)forum
(44579)
Hallo!
>
>
>
>
Ich habe gerade die heruntergeladenen Dateien
kernel_4_3_nonfree.tar.gz und kernel_4_3.tar.gz nochmal entpackt. Die in
der Fehlermeldung aufgelisteten Dateien bzw. Verzeichnisse sind nicht
vorhanden....
Huch? 8139too.ko existiert nicht in den Archiven?
>
>
>
>
>
>
habe ich versucht wie folgt umzusetzen:
[...]
CIRC[] {
[...]
CLASS_N='1' # set meaningful classes
CLASS_1='internet'
CLASS_N nicht setzen, und dann:
CLASS[]='internet'
> PPP_FILTER='no' # filter traffic to be able to hangup
> PPP_FILTER_EXPR='' # the filter to use; leave empty to use
Da PPP_FILTER='no', ist es unnötig, PPP_FILTER_EXPR setzen zu wollen.
> NETS_IPV4_N='1'
> NETS_IPV4_1='0.0.0.0/0' # use default IPv4 route over this circuit
NETS_IPV4_N nicht setzen, und dann:
NETS_IPV4[]='0.0.0.0/0'
>
>
>
>
>
>
>
>
>
Dabei bekomme ich folgende Fehlermeldungenm:
==================================================================
Das liegt an einer Vermischung von [<Index>] und _<Index>. Ich muss mal in
Ruhe schauen, was genau dabei das Problem ist. Bis dahin empfiehlt es sich
einfach nicht, in ...[] und ..._1 o.ä. zu vermischen.
net(t)forum
> Variable 'CIRC_%_CIRC_1_PPP_FILTER_EXPR' set at [configuration file
> (package circuits) 85:0] does not exist.
Die Variable ist inzwischen auskommentiert, somit sollte diese Meldung nicht
mehr auftauchen.
>
>
>
>
>
>
variable 'CIRC_1_NETS_IPV4_%'.
Setting variable 'CIRC_1_NETS_IPV4_%' to '0.0.0.0/0' at [configuration
file
Dasselbe Problem (Vermischung von [<Index>] und _<Index>).
Viele Grüße,
-Christoph Schulz
[fli4l-Team]
(44579)
Posted by Hans Bachner on Sun, 28 Feb 2016 17:24:19 GMT
Hallo Christoph,
Christoph Schulz schrieb am 28.02.2016 um 17:54:
> Hans Bachner schrieb:
>
> [schnipp]
>> NETS_IPV4[1] { '0.0.0.0/0' }
>
> Das geht nicht, weil hier die Zuweisung unter den Tisch gefallen ist.
> Richtig ist:
>
> NETS_IPV4[1]='0.0.0.0/0'
>
> Oder ohne Index:
>
> NETS_IPV4[]='0.0.0.0/0'
>
> Alle möglichen Anfänge können natürlich wieder ausgeklammert werden, z.B.:
>
> NETS.IPV4 {
> []='0.0.0.0/0'
> }
>
net(t)forum
> NETS {
> IPV4 {
>
[]='0.0.0.0/0'
Danke für die Korrektur und die zahlreichen Beispiele!
Wie schon in meinem einleitenden Disclaimer des letzten Postings
erwähnt, hab ich mit der neuen Syntax noch keine praktische Erfahrung
und daher gemeint:
> ich [...] würde es [...] so probieren
War ja für den Anfang gar nicht so weit daneben :-)
Schöne Grüße,
Hans.
(44579)
Hallo zusammen,
der Thread ist mittlerweile etwas unübersichtlich geworden, auch durch
meinen Post an der falschen Stelle im Thread.
Daher jetzt hier die Fortführung (und Abschluss) aller oben angefangen
Zweige.
Für die Eiligen, die das nicht zu Ende lesen wollen:
Alle Probleme sind gelöst.
>> Ich habe gerade die heruntergeladenen Dateien
>> kernel_4_3_nonfree.tar.gz und kernel_4_3.tar.gz nochmal entpackt. Die in
>> der Fehlermeldung aufgelisteten Dateien bzw. Verzeichnisse sind nicht
>> vorhanden....
>
> Huch? 8139too.ko existiert nicht in den Archiven?
Naja, nicht in den kernel*.tar.gz, sondern in der firmware.tar.gz.
Wie ich weiter oben schrieb, ist mir diese Datei beim Download durch die
Lappen gegangen.
Das Problem ist also gelöst.
>
>>
>>
>>
>>
==================================================================
net(t)forum
>> 'N:\fli4l\FLI4l_Tarball_4.0_19022016-r44579\config.e40/circuits.txt'
>> (package circuits) 73:0] failed.
>
> Das liegt an einer Vermischung von [<Index>] und _<Index>. Ich muss mal in
> Ruhe schauen, was genau dabei das Problem ist. Bis dahin empfiehlt es sich
> einfach nicht, in ...[] und ..._1 o.ä. zu vermischen.
In der Tat war das das Problem.
Ich bin noch dabei die neue Syntax zu verstehen.
Das Verständnis kommt erst langsam.
Wobei ich den/die Vorteile gegenüber der alten Syntax noch nicht sehe.
Wird aber hoffentlich noch kommen....
>
> Dasselbe Problem (Vermischung von [<Index>] und _<Index>).
Jawohl.
Wie ich im Thread weiter oben schrieb, habe ich nach und nach meine
weiteren Fehler gefunden.
Ich schrieb weiter oben:
[Die Konfigurationsdaten spare ich mir hier erst mal, die stehen in dem
einen Post von 12:03 Uhr]
Peter Schiefer schrieb:
> zeig mal deine config/advenced_networking.txt in Bezug zu VLAN nach
8.2.1q
>
>> Ach ja und die Internet-Einwahl funktioniert auch noch nicht.
>> Welche Informationen sind hierzu hilfreich um das Problem einzugrenzen?
>
> Mein Glaskugel sagt: wenn kein eth1.8 dann ist wahrscheinlich auch kein
> eth1.7 da ;)
>
Deine Glaskugel ist super!!
Danke für den Hinweis.
Da war ein Tippfehler drin, so dass es keine VLAN-Devices gab.
Damit funktioniert es jetzt.
Der Router läuft so wie er soll, IPTV und OPENVPN funktionieren.
Vielen Dank für eure Unterstützung und die Geduld.
Teilweise waren es echt triviale Fehler....
net(t)forum
@Christoph Schulz:
Danke nochmal für die ausführlich Darlegung des Unterschiedes einer
auskommentierten Variablen und einer leeren Variablen.
Ich kann zwar immer noch nicht 100-ig zustimmen, aber vermutlich ist es
es bei anderen Variablen sinnvoll das zu unterscheiden. Und dass muss
natürlich konsistent umgesetzt werden.
Ich dachte es wäre ein Verbesserungsvorschlag.
Was ich mich die ganzen letzten Tage gefragt habe, warum ich nur der
einzige bin, der mit der neuen Syntax Probleme hat....
LG
Boris
(44579)
Posted by Matthias Prager on Sun, 28 Feb 2016 21:27:00 GMT
Am 28.02.2016 um 19:22 schrieb B. Sprenger:
>
> Was ich mich die ganzen letzten Tage gefragt habe, warum ich nur der
> einzige bin, der mit der neuen Syntax Probleme hat....
>
Bist Du nicht, ich habe auch einen Moment gebraucht, um mich rein zu
denken. Aber ich habe selbst schon Parser geschrieben - das hilft beim
reindenken in die Logik ;-) . Wenn man es erst mal raus hat, ist die
neue Syntax allerdings sehr praktisch.
Gruß
Matthias
(44579)
Posted by B. Sprenger on Tue, 01 Mar 2016 06:51:17 GMT
Guten Morgen,
Am 28.02.2016 um 22:27 schrieb Matthias Prager:
> Am 28.02.2016 um 19:22 schrieb B. Sprenger:
>>
>> Was ich mich die ganzen letzten Tage gefragt habe, warum ich nur der
>> einzige bin, der mit der neuen Syntax Probleme hat....
>>
> Bist Du nicht, ich habe auch einen Moment gebraucht, um mich rein zu
> denken. Aber ich habe selbst schon Parser geschrieben - das hilft beim
> reindenken in die Logik ;-) . Wenn man es erst mal raus hat, ist die
net(t)forum
> neue Syntax allerdings sehr praktisch.
>
Ich weiss noch nicht ob ich die neu Syntax praktischer finde. Im Moment
ist sie erst mal (für mich) schwerer zu lesen. Das andere war man halt
gewohnt (für mich seit rund 17 Jahren)
Gestern habe ich einen zweiten Router umgestellt. Das hat auch zuerst
nicht funktioniert. Nach ein wenig Nachdenken konnte ich den Fehler aber
dann selbst finden (ein VLAN Device war falsch konfiguriert).
Die Anpassung war mit der alten Methode einfacher.
Ich habe mehrere Router mit Telekom VDSL, die meisten mit Entertain. Ein
Router jedoch ohne Entertain. Hier musste ich in der Konfiguration immer
nur die Zähler ändern, also so etwas wie
CIRC_N='2'
# number of circuits
einfach auf '1' setzen.
Jetzt muss ich den kompletten Block auskommentieren oder löschen.
Oder geht das auch einfacher?
LG
Boris
(44579)
Posted by Christoph Schulz on Tue, 01 Mar 2016 06:55:37 GMT
Hallo!
>
>
>
>
>
>
>
>
>
Die Anpassung war mit der alten Methode einfacher.
Ich habe mehrere Router mit Telekom VDSL, die meisten mit Entertain. Ein
Router jedoch ohne Entertain. Hier musste ich in der Konfiguration immer
nur die Zähler ändern, also so etwas wie
CIRC_N='2'
# number of circuits
einfach auf '1' setzen.
Jetzt muss ich den kompletten Block auskommentieren oder löschen.
Oder geht das auch einfacher?
Einen kompletten Block auskommentieren *ist* heutzutage einfach -- wenn man
einen vernünftigen Editor verwendet: Markieren, passende Tastenkombination
drücken -- fertig.
Ansonsten darfst du ja weiterhin CIRC_1_...='...' schreiben und CIRC_N
verwenden. Es gibt jedoch eine Menge Anwendungsfälle, in denen die neue
Syntax Vorteile bietet, etwa wenn man im Nachhinein Elemente in ein
bestehendes Array einfügen muss, in dem die Reihenfolge eine Rolle spielt.
net(t)forum
Das kommt etwa bei der Firewall-Konfiguration vor.
Viele Grüße,
-Christoph Schulz
[fli4l-Team]
(44579)
Hallo Christoph,
>> Jetzt muss ich den kompletten Block auskommentieren oder löschen.
>>
>> Oder geht das auch einfacher?
>
> Einen kompletten Block auskommentieren *ist* heutzutage einfach -- wenn man
> einen vernünftigen Editor verwendet: Markieren, passende Tastenkombination
> drücken -- fertig.
>
Okay,was wäre denn ein vernünftiger Editor?
Ich benutze (auf einen Tipp aus dieser Newsgroup) derzeit Winmerge.
Ich habe gerade nochmal in die Doku geschaut, aber keinen Hinweis auf so
eine Funktion gefunden.
Allerdings weiss ich auch nicht, nach was ich suchen soll.
mit "Suchen und Ersetzen" geht es ja eher nicht.
LG
Boris
(44579)
Hallo!
> Okay,was wäre denn ein vernünftiger Editor?
> Ich benutze (auf einen Tipp aus dieser Newsgroup) derzeit Winmerge.
Winmerge ist ein Programm zum Zusammenführen (engl. Merge) von
unterschiedlichen (Konfigurations-)Änderungen auf einer gemeinsamen Basis.
net(t)forum
Dein Anwendungsfall ("einen Circuit deaktivieren") hat doch nichts mit einem
Update auf eine neue fli4l-Version zu tun. Daher sehe ich den Vorteil von
Winmerge hier nicht. Warum sollte man Winmerge zum Übertragen einer
Konfiguration von einem Router auf einen anderen nutzen?
Abgesehen davon kann ich dir keinen Editor empfehlen, wenn ich nicht weiß,
welches Betriebssystem du nutzt. Ich habe hier nur Linux im Einsatz, dort
würde ich generell Geany empfehlen -- ich kann damit ganz gut arbeiten, und
es ist ein leichtgewichtiger Editor. Unter Windows schwören viele auf
Notepad++ (https://notepad-plus-plus.org/). Dort kann man Zeilen (sobald man
den Typ der Sprache auf "Shell" gestellt hat) via Strg+K auskommentieren und
via Strg+Umschalt+K wieder entkommentieren (schreckliches Wort, ich weiß).
Schließlich kannst du eine Circuit-Definition auch einfach deaktivieren,
indem du CIRC_x_ENABLE='no' setzt.
Viele Grüße,
-Christoph Schulz
[fli4l-Team]
(44579)
Posted by LeSpocky on Tue, 01 Mar 2016 07:57:23 GMT
Moin,
B. Sprenger schrieb Dienstag, 1. März 2016, 08:35 (CET):
> Okay,was wäre denn ein vernünftiger Editor?
Ich benutze ja für die fli4l Configs ausschließlich Vim.
Aber das sollten wir besser in s.f.g diskutieren. ;-)
Grüße
Alex
(44579)
Moin,
net(t)forum
> Ich weiss noch nicht ob ich die neu Syntax praktischer finde. Im Moment
> ist sie erst mal (für mich) schwerer zu lesen. Das andere war man halt
> gewohnt (für mich seit rund 17 Jahren)
Du kannst die alte Syntax weiter benutzen. Es gibt keinen Zwang zur
Umstellung.
> Die Anpassung war mit der alten Methode einfacher.
Wieso benutzt Du dann nicht die alte Methode weiter?
Grüße
Alex
(44579)
Hallo Christoph,
>
> Winmerge ist ein Programm zum Zusammenführen (engl. Merge) von
> unterschiedlichen (Konfigurations-)Änderungen auf einer gemeinsamen Basis.
>
> Dein Anwendungsfall ("einen Circuit deaktivieren") hat doch nichts mit einem
> Update auf eine neue fli4l-Version zu tun. Daher sehe ich den Vorteil von
> Winmerge hier nicht. Warum sollte man Winmerge zum Übertragen einer
> Konfiguration von einem Router auf einen anderen nutzen?
Ich nutze zur Übertragung einer alten Konfiguration auf die neue
Konfiguration.
Sprich ich vergleiche die Konfigurationsdaten bei einem Releasewechsel
und passe die neuen Dateien gemäß dem alten Vorbild an.
Winmerge zeigt mir ja direkt die Unterschiede in den zeilen an.
So sehe ich sofort umbenannte Variablen oder neu hinzugekommene.
>
> Unter Windows schwören viele auf
> Notepad++ (https://notepad-plus-plus.org/). Dort kann man Zeilen (sobald man
> den Typ der Sprache auf "Shell" gestellt hat) via Strg+K auskommentieren und
> via Strg+Umschalt+K wieder entkommentieren (schreckliches Wort, ich weiß).
Danke für den Tipp und die Tastenkombination, das werde ich ausprobieren.
>
net(t)forum
> Schließlich kannst du eine Circuit-Definition auch einfach deaktivieren,
> indem du CIRC_x_ENABLE='no' setzt.
Das gefällt mir noch besser, diese Variable werde ich in meine
Konfiguration für alle Router übernehmen.
LG
Boris
(44579)
Hallo Alexander,
>
> Wieso benutzt Du dann nicht die alte Methode weiter?
zum einen, da ich das bis heute nicht wusste.
Und zum Zweiten habe ich die Erfahrung gemacht, dass man bei
irgendwelchen Umstellungen nicht an der Vorversion festhalten sollte.
Irgendwann kommt man nicht mehr drum herum und dann ist es nur noch
schwerer.
Und wer garantiert denn, dass die alte Methode dauerhaft die nächsten
Jahre funktionieren wird?
Ich werde mich schon noch daran gewöhnen.
Und in der dns_dhcp.txt ist die neue Methode tatsächlich ein
Riesenvorteil, da ich hier ein Haufen Hosts eingetragen habe, dich jetzt
nicht mehr durchnummerieren muss.
LG
Boris
(44579)
Hallo!
>
>
>
>
Ich nutze zur Übertragung einer alten Konfiguration auf die neue
Konfiguration.
Sprich ich vergleiche die Konfigurationsdaten bei einem Releasewechsel
und passe die neuen Dateien gemäß dem alten Vorbild an.
net(t)forum
> Winmerge zeigt mir ja direkt die Unterschiede in den zeilen an.
> So sehe ich sofort umbenannte Variablen oder neu hinzugekommene.
Prima, so würde ich es an deiner Stelle auch machen!
Das passt aber nicht zu deinem Anwendungsfall "Circuit deaktivieren". Denn
welches fli4l-Update macht(e) es nötig, einen ganzen Circuit zu
deaktivieren? Das will noch nicht so richtig in meinen Kopf...
Viele Grüße,
-Christoph Schulz
[fli4l-Team]
(44579)
Hei hei,
> Und wer garantiert denn, dass die alte Methode dauerhaft die nächsten
> Jahre funktionieren wird?
>
> Ich werde mich schon noch daran gewöhnen.
> Und in der dns_dhcp.txt ist die neue Methode tatsächlich ein
> Riesenvorteil, da ich hier ein Haufen Hosts eingetragen habe, dich jetzt
> nicht mehr durchnummerieren muss.
In diesem Fall ist es technisch so, dass die alte Variante weiter
funktionieren muss, weil das genau die Syntax ist, die die Skripte auf
dem target erwarten. D.h. mkfli4l generiert aus der neuen Syntax quasi
die alte Syntax der /etc/rc.cfg, die dann von den Shell-Skripten auf dem
fli4l eingelesen werden kann. Das kann man nicht ändern ohne die gesamte
Logik und Magic, die in fli4l steckt zu ändern, in allen Paketen.
Insofern würde ich da im Moment sehr sicher sein, dass das noch lange
erhalten bleibt.
Grüße
Alex
net(t)forum
(44579)
Posted by B. Sprenger on Thu, 03 Mar 2016 18:17:29 GMT
Hallo Christoph,
> Hallo!
>
>
>> Ich nutze zur Übertragung einer alten Konfiguration auf die neue
>> Konfiguration.
>> Sprich ich vergleiche die Konfigurationsdaten bei einem Releasewechsel
>> und passe die neuen Dateien gemäß dem alten Vorbild an.
>> Winmerge zeigt mir ja direkt die Unterschiede in den zeilen an.
>> So sehe ich sofort umbenannte Variablen oder neu hinzugekommene.
>
> Prima, so würde ich es an deiner Stelle auch machen!
>
> Das passt aber nicht zu deinem Anwendungsfall "Circuit deaktivieren". Denn
> welches fli4l-Update macht(e) es nötig, einen ganzen Circuit zu
> deaktivieren? Das will noch nicht so richtig in meinen Kopf...
Ja, das ist vielleicht nicht auf Anhieb zu verstehen.
Bei einem Update bearbeite zunächst meinen Router zu Hause.
Wenn das funktioniert, kopiere ich den Ordner (z.B. config.1) nach config.2.
90% der Dateien darin muss ich jetzt nicht mehr anfassen, da z.B.
tools.txt, easycron.txt, hd.txt und httpd.txt usw. auf allen Routern
gleich sind.
Die Base.txt muss ich natürlich anpassen und da auf einem Router eben
einfach den nicht benötigten IPTV-Circuit deaktivieren.
LG
net(t)forum

Informationen zu den wöchentlichen 4.0-Archiven vom

Transcription

Similar documents

Kompakte Pinguine: fli4l und eisfair

MATLAB - Eine Einführung

Subject: 3.5.0-rev-19267 Syslog Fehlermeldungen

TEAMWORKNET Installation

Computer trifft Zelle - Forschungszentrum Jülich

imond unter `normalem` Linux - heidbrede-bs.de