Solange die Pakete für den Zugriff auf ein GUI des Modems auch alle brav an dieses Modem gesendet werden (also nicht irgendwoanders im LAN ihr Ziel finden), "fischt" sich das Modem diese Pakete schon selbst aus dem Datenstrom heraus, wenn es dort "seine" IP-Adresse als Ziel vorfindet und sendet dann (in der Regel) die Antworten auch wieder auf dem Interface zurück, auf dem die Anfrage einging.
Daher braucht es für die Kommunikation mit einem Modem über den WAN-Port einer FRITZ!Box üblicherweise auch keine weitere Konfiguration ... wenn (ja, wenn) nicht noch weitere Kapselungen der Daten in einem Paket hinzukommen (wie eben das PPPoE) und damit die Pakete für das Modem eben NICHT länger als einfache Ethernet-Pakete zu erkennen sind. In diesen Fällen braucht es dann ein zweites (virtuelles) Interface, bei dem KEINE PPPoE-Kapselung erfolgt und die Pakete somit "unverfälscht" zum Modem gelangen.
Für dieses zweite Interface braucht es dann aber üblicherweise auch eine explizite Konfiguration der IP-Einstellungen ... nur so kann sichergestellt werden, daß in der Routing-Table passende Einträge existieren, um die Daten auf das korrekte (virtuelle) Interface auszugeben und somit vor der zusätzlichen Kapselung mit einem PPP-Header zu bewahren. Welche Adresse dieses Interface dann in der FRITZ!Box erhält, ist weitestgehend egal ... sie muß halt nur dazu führen, daß Pakete für die IP-Adresse 192.168.100.1 über genau dieses virtuelle Interface ausgegeben werden.
Leider ist aber (meines Wissens) bei AVM die manuelle Konfiguration mehrerer virtueller Interfaces auf der WAN-Seite (das schließt den Betrieb mit internem und externem Modem ein) nicht im Angebot ... man muß sich also entweder mit einer eigenen "providerspezifischen Konfiguration" behelfen oder die (exportierte) Konfigurationsdatei von Hand ändern.
Wie so eine geänderte Konfiguration aussehen müßte, kann man sich z.B. beim Profil
htpngn_fiber ansehen (das müßte für den "NGN Fiber"-Tarif von htp sein:
https://www.htp.net/glasfaser), wo die
ar7.cfg folgende Voreinstellungen beinhaltet:
Rich (BBCode):
ar7cfg {
mode = dsldmode_router;
vccs {
dsl_encap = dslencap_mixed;
connections = "internet", "voip", "tr069";
}
dslifaces {
name = "internet";
dsl_encap = dslencap_pppoe;
vlancfg {
vlanencap = vlanencap_fixed_prio;
vlanid = 22;
vlanprio = 0;
}
stay_always_online = yes;
} {
name = "voip";
dsl_encap = dslencap_ether;
vlancfg {
vlanencap = vlanencap_fixed_prio;
vlanid = 10;
vlanprio = 0;
}
} {
enabled = yes;
name = "tr069";
dsl_encap = dslencap_ether;
dslinterfacename = "dsl";
no_masquerading = no;
use_fixed_masqaddr_if_no_masquerading = no;
no_firewall = no;
stackmode = stackmode_ipv4only;
pppoevlanauto = no;
pppoevlanauto_startwithvlan = no;
vlancfg {
vlanencap = vlanencap_fixed_prio;
vlanid = 8;
vlanprio = 0;
}
ppptarget = "tr069";
fixed_masqaddr = 0.0.0.0;
mtu = 0;
etherencapcfg {
use_dhcp = yes;
use_dhcp_if_not_encap_ether = no;
ipaddr = 0.0.0.0;
netmask = 0.0.0.0;
gateway = 0.0.0.0;
dns1 = 0.0.0.0;
dns2 = 0.0.0.0;
}
is_mcupstream = no;
stay_always_online = yes;
disable_ondemand = no;
reconnect_delay_after_conn_abort = 30s;
only_route_when_connected = no;
redial_delay_after_auth_failure = 1m;
redial_limit = 3;
redial_after_limit_reached = 10m;
redial_after_limit_reached_variance = 5m;
redial_delay_after_low_error = 10s;
redial_delay_after_ppp_timeout = 10s;
redial_delay_after_ppp_error = 0w;
routes_only_for_local = no;
tcclassroutes = "tr069dns", "tr069", "ntp", "ntpdns";
disable_staticroutes_on_dhcproutes = no;
ripv2receiver_enabled = no;
ripv2_update_timer = 30s;
ripv2authmode = ripv2_auth_none;
ripv2md5_keyid = 0;
ripv2passwd = "";
set_replicate_dhcpoptions_in_parameter_request_list = no;
unset_ignored_dhcpoptions_in_parameter_request_list = yes;
dsldpconfig {
security = dpsec_firewall;
filter_teredo = yes;
filter_netbios = yes;
lowinput {
policy = "permit";
}
lowoutput {
policy = "permit";
}
highinput {
policy = "permit";
}
highoutput {
policy = "permit";
}
}
dhcp_auth_mode = auth_none;
dhcp_requests_with_client_id = yes;
}
targets {
name = "internet";
ProviderDisconnectPreventionHour = 3;
} {
name = "voip";
bProviderDisconnectPrevention = no;
} {
name = "tr069";
bProviderDisconnectPrevention = no;
}
dslglobalconfig {
autodetect = no;
pppoeiface = "eth0";
speed_in_netto = 100000;
speed_out_netto = 10000;
}
tr069discover_active = no;
}
ntpclient {
server_list = "2.europe.pool.ntp.org", "ntp.htp-apv.de";
chrony_enabled = yes;
}
// EOF
Hier werden also für die WAN-Seite drei virtuelle Interfaces definiert, mit den Namen
internet,
voip und
tr069, wobei nur das erste von den dreien eine zusätzliche Kapselung der Pakete im Rahmen des PPP(oE)-Protokolls verwendet, während die beiden anderen direkt mit Ethernet-Paketen arbeiten. Bei anderen Anbietern kommt ggf. auch noch ein
iptv-Interface hinzu, was üblicherweise auch direkt mit dem Ethernet-Protokoll arbeitet (z.B. beim Inexio-Profil für den Fiber-Anschluß).
Dieser Inhalt des Templates für die
ar7.cfg liefert aber nur den "Rahmen" für weitere Daten in der Konfiguration ... bei den beiden Ethernet-Interfaces wird sich dann in der resultierenden Konfigurationsdatei
ar7.cfg jeweils auch noch ein Abschnitt
etherencapcfg innerhalb der Interface-Definition finden lassen (die Datei ist ja Bestandteil einer Sicherungsdatei mit den Einstellungen und kann ganz normal mit einem Text-Editor (sofern der Unix-Zeilenenden versteht) betrachtet werden), in dem dann die IP-Konfiguration (DHCP ja/nein, wenn nein, dann Adresse, Maske, Gateway, DNS) beschrieben ist, die für dieses virtuelle Interface verwendet werden soll.
Wenn die bereits vorhandenen Interfaces (ich habe keine Ahnung, welches Provider-Profil im FRITZ!OS für den Betrieb mit dem "Glasfasermodem 2 von der Telekom" einzustellen wäre und wie die darin definierten Interfaces dann aussehen) keinen (direkten Ethernet-)Zugriff auf das Modem (so es denn ein eigenes GUI hat) erlauben, kann man sich also durch Ergänzen eines passenden Interfaces in der Konfiguration immer noch behelfen - auch wenn da unterschiedliche Transportprotokolle (mal mit, mal ohne PPP) zum Einsatz kommen.
