:fill(white):strip_exif()/i/2006002120.jpeg?f=thumbmini)
:strip_exif()/i/2006002116.png?f=thumbmini)
:strip_exif()/u/422876/animated-gifs-radar-121.gif?f=community)
/u/276779/crop5fa05ec8e06fa_cropped.png?f=community)
:strip_icc():strip_exif()/u/1623466/crop65722036eb80b_cropped.jpg?f=community)
:strip_icc():strip_exif()/u/142317/crop5cbd9d51d7e14_cropped.jpeg?f=community)
Dat klopt, ik krijg alleen maar sales antwoorden toen ik meer info vroeg om mijn SFP script te verbeteren
Met de UDM werkt het in 1x of je hebt wat gedoe, met de FS is het bij mijn UniFi apparatuur in 1x goed. Zoals je zegt het zijn uitzonderingen gelukkig.
Is dat echt een SFP issue of de enorm complexe en vooral niet schaalbare manier van provisioning bij DFN? Waarom is er een hardware profiel per SFP ze zijn immers allemaal voorzien van dezelfde firmware, waarom moet je bij een snelheidsaanpassing aan je abonnement het originele provider ONT weer ophangen
om je snelheidsaanpassing te activeren? No offence maar als je provisioning zo in elkaar steekt dat je tijdens een nachtelijk onderhoud, landelijk alle Zarams per ongeluk decomissioned
voelt het als heel kwetsbaar en gebaseerd op handwerk. Ik sta er heel ver vandaan, ik heb het gevoel dat ze technisch verkeerd gestart zijn met het ontwerp van de provisioningstraat en nu een steeds groter wordende ijsberg aan het beheren zijn. Weet niet of dit echt aan de FS te wijten is, is er een topic over?
:strip_icc():strip_exif()/u/651669/crop61f075a821e45.jpg?f=community)
Wat ik er van begrijp is het een issue waarbij bij gebruik van PPoE bij Freedom over DFN de FS.com SFP over een andere “card” wil communiceren dan dat verwacht wordt.
Firmware bij de SFP’s is niet gelijk. En klaarblijkelijk laten de normen vrijheid voor de producent van de XGS-PON SFP’s. De BBF-247 norm was bedoeld om interoperabiliteit te garanderen maar is in praktijk een wassen neus.Waarom is er een hardware profiel per SFP ze zijn immers allemaal voorzien van dezelfde firmware, waarom moet je bij een snelheidsaanpassing aan je abonnement het originele provider ONT weer ophangen
Eens, maar dit was eenmalig en snel hersteld. Shit happens, of het nou DFN is, KPN of Microsoft.No offence maar als je provisioning zo in elkaar steekt dat je tijdens een nachtelijk onderhoud, landelijk alle Zarams per ongeluk decomissioned
Laten we dit maar verder in de Delta thread bespreken.
Provider heeft niets te maken met dit probleem, het is een probleem wat zit in de SFP. Wat ik denk dat er gebeurd is, is dat de DFN gebruiker een door een andere gebruiker retour gestuurde SFP heeft ontvangen die klaar is gemaakt op het KPN netwerk. Ik meen dat default card van FS.com op 10 staat, wij gebruiken 1. Die van de gebruiker op discord heeft slot 1 wat dus niet werkt op DFN. Enfin.. laten we maar weer ontopic gaan
[ Voor 4% gewijzigd door Economics op 20-04-2025 20:29 ]
:strip_icc():strip_exif()/u/693291/crop65a15b4f941a2_cropped.jpg?f=community)
Ik heb geen 2e hands FS sfp’s verstuurd dus dat zou wel bijzonder zijn als die via mij is gekomen.:
[...]
Provider heeft niets te maken met dit probleem, het is een probleem wat zit in de SFP. Wat ik denk dat er gebeurd is, is dat de DFN gebruiker een door een andere gebruiker retour gestuurde SFP heeft ontvangen die klaar is gemaakt op het KPN netwerk. Ik meen dat default card van FS.com op 10 staat, wij gebruiken 1. Die van de gebruiker op discord heeft slot 1 wat dus niet werkt op DFN. Enfin.. laten we maar weer ontopic gaan
Tweakers V&A denk ik.:
[...]
Ik heb geen 2e hands FS sfp’s verstuurd dus dat zou wel bijzonder zijn als die via mij is gekomen.
/u/10716/crop6401150aea058_cropped.png?f=community)
:strip_icc():strip_exif()/u/19306/crop62cd57cce9612_cropped.jpg?f=community)
Ik had @wbschenk al een email gestuurd maar misschien is een topic hier beter...
Ik heb een ZARAM SFP+ in mijn Unifi Cloud Gateway fiber met KPN 4Gbps verbinding.
Van Unifi support kreeg ik nav een issue met u7 Pro performance de volgende feedback:
- On the UCG-Fiber WAN port, we observed a high number of tx_pause frames: 404,756[/li]
- On the UCG-Fiber LAN port, we also saw:
rx_pause: 11,100,425
tx_dropped: 1,813
These counters suggest potential flow control issues between the UCG-Fiber and its upstream device (e.g., modem or ISP CPE). Please try enabling flow control on the uplink (modem) side and check if that improves the throughput performance.
Flow Control staat aan.
In zie ook een "Tx fault" op de SFP+ poort:
:strip_exif()/f/image/KHba8flqU6KDJlnRi1SORFK0.png?f=user_large)
Op de UCG-F zie ik met SSH dit:
SSH naar de Zaram lukt niet, ondanks toevoegen van 192.168.200.2 aan ETH6:
De verbinding lijkt verder goed te werken al heb ik wel last van IPTV (via het script van Fabian) die af en toe vastloopt.
Is hier iets mis en zo ja hoe zou ik dit kunnen troubleshooten?
Ik heb een ZARAM SFP+ in mijn Unifi Cloud Gateway fiber met KPN 4Gbps verbinding.
Van Unifi support kreeg ik nav een issue met u7 Pro performance de volgende feedback:
- On the UCG-Fiber WAN port, we observed a high number of tx_pause frames: 404,756[/li]
- On the UCG-Fiber LAN port, we also saw:
rx_pause: 11,100,425
tx_dropped: 1,813
These counters suggest potential flow control issues between the UCG-Fiber and its upstream device (e.g., modem or ISP CPE). Please try enabling flow control on the uplink (modem) side and check if that improves the throughput performance.
Flow Control staat aan.
In zie ook een "Tx fault" op de SFP+ poort:
Op de UCG-F zie ik met SSH dit:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
| ifconfig eth6
eth6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1512
inet 192.168.200.2 netmask 255.255.255.0 broadcast 0.0.0.0
inet6 fe80::962a:6fff:fef0:fcd9 prefixlen 64 scopeid 0x20<link>
ether 94:2a:6f:f0:fc:d9 txqueuelen 10000 (Ethernet)
RX packets 95488394 bytes 117772350065 (109.6 GiB)
RX errors 0 dropped 31 overruns 0 frame 0
TX packets 59495596 bytes 48000149128 (44.7 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
ethtool -m eth6
Identifier : 0x03 (SFP)
Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID)
Connector : 0x01 (SC)
Transceiver codes : 0x20 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Transceiver type : 10G Ethernet: 10G Base-LR
Encoding : 0x06 (64B/66B)
BR, Nominal : 10300MBd
Rate identifier : 0x00 (unspecified)
Length (SMF,km) : 20km
Length (SMF) : 20000m
Length (50um) : 0m
Length (62.5um) : 0m
Length (Copper) : 0m
Length (OM3) : 0m
Laser wavelength : 1270nm
Vendor name : Zaram
Vendor OUI : 00:0b:6f
Vendor PN : ZXOS11NPI
Vendor rev : 1B
Option values : 0x22 0x02
Option : RX_LOS implemented
Option : Power level 2 requirement
Option : Power level 3 requirement
BR margin, max : 0%
BR margin, min : 0%
Vendor SN : ZRMTXXXXXXXX
Date code : 230327
Optical diagnostics support : Yes
Laser bias current : 20.128 mA
Laser output power : 4.1167 mW / 6.15 dBm
Receiver signal average optical power : 0.0389 mW / -14.10 dBm
Module temperature : 61.50 degrees C / 142.70 degrees F
Module voltage : 3.3949 V
Alarm/warning flags implemented : Yes
Laser bias current high alarm : Off
Laser bias current low alarm : Off
Laser bias current high warning : Off
Laser bias current low warning : Off
Laser output power high alarm : Off
Laser output power low alarm : Off
Laser output power high warning : Off
Laser output power low warning : Off
Module temperature high alarm : Off
Module temperature low alarm : Off
Module temperature high warning : Off
Module temperature low warning : Off
Module voltage high alarm : Off
Module voltage low alarm : Off
Module voltage high warning : Off
Module voltage low warning : Off
Laser rx power high alarm : Off
Laser rx power low alarm : Off
Laser rx power high warning : Off
Laser rx power low warning : Off
Laser bias current high alarm threshold : 90.000 mA
Laser bias current low alarm threshold : 2.000 mA
Laser bias current high warning threshold : 80.000 mA
Laser bias current low warning threshold : 4.000 mA
Laser output power high alarm threshold : 6.5535 mW / 8.16 dBm
Laser output power low alarm threshold : 2.1380 mW / 3.30 dBm
Laser output power high warning threshold : 6.5535 mW / 8.16 dBm
Laser output power low warning threshold : 2.3442 mW / 3.70 dBm
Module temperature high alarm threshold : 90.00 degrees C / 194.00 degrees F
Module temperature low alarm threshold : -45.00 degrees C / -49.00 degrees F
Module temperature high warning threshold : 85.00 degrees C / 185.00 degrees F
Module temperature low warning threshold : -40.00 degrees C / -40.00 degrees F
Module voltage high alarm threshold : 4.0000 V
Module voltage low alarm threshold : 3.0000 V
Module voltage high warning threshold : 3.5000 V
Module voltage low warning threshold : 3.1000 V
Laser rx power high alarm threshold : 0.1995 mW / -7.00 dBm
Laser rx power low alarm threshold : 0.0006 mW / -32.22 dBm
Laser rx power high warning threshold : 0.1778 mW / -7.50 dBm
Laser rx power low warning threshold : 0.0008 mW / -30.97 dBm |
SSH naar de Zaram lukt niet, ondanks toevoegen van 192.168.200.2 aan ETH6:
code:
1
2
| ssh admin@192.168.200.1 ssh: connect to host 192.168.200.1 port 22: No route to host |
De verbinding lijkt verder goed te werken al heb ik wel last van IPTV (via het script van Fabian) die af en toe vastloopt.
Is hier iets mis en zo ja hoe zou ik dit kunnen troubleshooten?
Ja we hebben het eerder (recent) besproken dit vreemde gedrag heb je niet met de fs.com variant, als je nog binnen de 14 dagen zit zou ik wisselen. TV stopt zeker na 4:30seconden? Die lage upload had ik ook met de Zaram in mijn UCG-Fiber alleen via WiFi, bedraad is het gewoon 2,5Gbps.
Wat ook nog wel eens werkt is wisselen tussen improxy of igmpproxy om je tv stabieler te krijgen.
De UNI-poort van de ONU ontvangt pause-frames vanuit het achterliggende netwerk (UDM) dat hiermee aangeeft overbelast te zijn. Omdat de ONU het verkeer niet voldoende kan bufferen, ontstaan er uitgaande drops op de UNI-poort. Dat wat UI support zag in hun support file zie je ook terug in de Zaram dus dat is true
Ik zou flowcontrol eens uitschakelen en dan eens aankijken.
Crosscheck: is het met de KPN ont, het zwarte kastje, wel allemaal in orde?
Ik zie zo geen optie om flow control uit te schakelen voor alleen de UCG-F? Zou het wel met ethool even kunnen doen om te testen...:
[...]
Ja we hebben het eerder (recent) besproken dit vreemde gedrag heb je niet met de fs.com variant, als je nog binnen de 14 dagen zit zou ik wisselen. TV stopt zeker na 4:30seconden, die lage upload had ik ook met de Zaram in mijn UCG-Fiber alleen via WiFi bedraad is het gewoon 2,5Gbps.
Wat ook nog wel eens werkt is wisselen tussen improxy of igmpproxy om je tv stabieler te krijgen.
De UNI-poort van de ONU ontvangt pause-frames vanuit het achterliggende netwerk (UDM) dat hiermee aangeeft overbelast te zijn. Omdat de ONU het verkeer niet voldoende kan bufferen, ontstaan er uitgaande drops op de UNI-poort. Dat wat UI support zag in hun support file zie je ook terug in de Zaram dus dat is true
Ik zou flowcontrol eens uitschakelen en dan eens aankijken.
Hoe schakel ik om naar igmpproxy (de tool van Fabian gebruikt improxy)?
Hier kom je bij een checkbox uit. De checkbox voor flowcontrol is bij mij leeg.
:strip_exif()/f/image/gNRBgMYflTSjGWIBc1K0rzvf.png?f=user_large)
code:
1
2
3
| apt update apt install igmpproxy nano /etc/udm-iptv.conf -> improxy vervangen door igmpproxy |
[ Voor 4% gewijzigd door stormfly op 22-04-2025 21:55 ]
/u/949709/crop63c6adff478e4_cropped.png?f=community)
/u/120414/crop5da8242fa2360_cropped.png?f=community)
/u/132497/crop64ece057d3f12_cropped.png?f=community)
Absoluut maar ik denk dat er hier weinig Vlamingen zijn die hierover gaan posten, we hebben immers ons eigen forum userbase.be voor alles wat Internet providers betreft en ik zie hier niet meteen Walen langskomen want die hebben ook hun eigen adsl-bc.be forum
Ook dat is uitvoerig besproken in dit topic of tenminste op tweakers. Zonde om het allemaal weer te tikken met dit warme weer
:strip_exif()/u/34750/Trooper.gif?f=community)
:strip_exif()/u/18479/crop5dc6a5310ec8f_cropped.gif?f=community)
:strip_exif()/u/128173/crop59a1592e54731_cropped.gif?f=community)
After the first glass you see things as you wish they were. After the second you see things as they are not. Finally you see things as they really are, and that is the most horrible thing in the world...
Oscar Wilde
After the first glass you see things as you wish they were. After the second you see things as they are not. Finally you see things as they really are, and that is the most horrible thing in the world...
Oscar Wilde
Heeft iemand al een keer een issue gehad met de Vrije ONT keuze pagina van KPN die niet vindt dat je door mag gaan en derhalve leeg blijft?
"Log in" en "Of maak makkelijk en snel een account aan" (Ik bén ingelogd).
Verder niets.
Het was al een heel drama om een vervangende originele ONT hier te krijgen omdat in de systemen van KPN het niet duidelijk was dat het hier GPON gebied is.
Dat heeft aardig wat moeite, tijd en verkeerde ONT (AON) gekost voordat dat opgelost was. Nu vermoed ik sterk dat de briljante mensen bij KPN intern het nog steeds hebben doorgevoerd dat we hier GPON hebben met als gevolg dat de bijbehorende tooling niet werkt.
Ik wil het drama van de KPN helpdesk niet nog een keer ondergaan....
"Log in" en "Of maak makkelijk en snel een account aan" (Ik bén ingelogd).
Verder niets.
Het was al een heel drama om een vervangende originele ONT hier te krijgen omdat in de systemen van KPN het niet duidelijk was dat het hier GPON gebied is.
Dat heeft aardig wat moeite, tijd en verkeerde ONT (AON) gekost voordat dat opgelost was. Nu vermoed ik sterk dat de briljante mensen bij KPN intern het nog steeds hebben doorgevoerd dat we hier GPON hebben met als gevolg dat de bijbehorende tooling niet werkt.
Ik wil het drama van de KPN helpdesk niet nog een keer ondergaan....
We live in a primitive time don't we, neither savage nor wise. Half measures are the curse of it; any rational society would either kill me or put me to some use.
Als je even een DM stuurt kan ik voor je kijken:
Heeft iemand al een keer een issue gehad met de Vrije ONT keuze pagina van KPN die niet vindt dat je door mag gaan en derhalve leeg blijft?
"Log in" en "Of maak makkelijk en snel een account aan" (Ik bén ingelogd).
Verder niets.
Het was al een heel drama om een vervangende originele ONT hier te krijgen omdat in de systemen van KPN het niet duidelijk was dat het hier GPON gebied is.
Dat heeft aardig wat moeite, tijd en verkeerde ONT (AON) gekost voordat dat opgelost was. Nu vermoed ik sterk dat de briljante mensen bij KPN intern het nog steeds hebben doorgevoerd dat we hier GPON hebben met als gevolg dat de bijbehorende tooling niet werkt.
Ik wil het drama van de KPN helpdesk niet nog een keer ondergaan....
We live in a primitive time don't we, neither savage nor wise. Half measures are the curse of it; any rational society would either kill me or put me to some use.
:strip_icc():strip_exif()/u/116210/crop5ab6397009836_cropped.jpeg?f=community)
/etc/network/interfaces .... ik denk telkens dat die depricated is
.... mtu 1452, die is toch 1500 op de PPPoE interface (aldus KPN's eigen router doc) en voor de volledigheid (van wat ik her en der heb gelezen) 1508 op VLAN6 en 1512 op de fysieke interface.
Verder zie ik niet wat opvallends in de instellingen dat verschilt met hier.
Het enige verschil in de laatste is dat "save yes" er niet bij staat of mis ik iets?
After the first glass you see things as you wish they were. After the second you see things as they are not. Finally you see things as they really are, and that is the most horrible thing in the world...
Oscar Wilde
Op https://community.kpn.com...-box-458609/index119.html vond ik een setup voor Ubuntu. Daar hadden ze issues met masquerade op de standaard mtu (80% van de sites werkten op de lan niet, terwijl deze het wel op de wan kant deden of je kreeg rare disconnects) wat opgelost bleek te zijn door een mtu van 1452 te gebruiken. Ik heb hem daarom direct op 1452 gegooid wegens gebrek aan tijd door de verhuizing.:
[...]
/etc/network/interfaces .... ik denk telkens dat die depricated is
.... mtu 1452, die is toch 1500 op de PPPoE interface (aldus KPN's eigen router doc) en voor de volledigheid (van wat ik her en der heb gelezen) 1508 op VLAN6 en 1512 op de fysieke interface.
Verder zie ik niet wat opvallends in de instellingen dat verschilt met hier.
[...]
Het enige verschil in de laatste is dat "save yes" er niet bij staat of mis ik iets?
De MTU waardes die jij vermeld kan ik zo snel niet terugvinden. Echter als ik meer tijd heb ga ik daar es mee klieren. Belangrijk voor mij was dat de verbinding werkte.
About /etc/network/interfaces: deze is volgens mij nog niet deprecated al gaat dat vast wel gebeuren in de toekomst. Echter ik ben volgens mij ook deprecated dus soort zoekt soort
Try looking into that place where you dare not look! You'll find me there, staring out at you!
Hmm, okee.
Ik weet niet meer waar ik het oorspronkelijk had gelezen, maar het komt nog wel eens voorbij hier.
:
About /etc/network/interfaces: deze is volgens mij nog niet deprecated al gaat dat vast wel gebeuren in de toekomst. Echter ik ben volgens mij ook deprecated dus soort zoekt soort
After the first glass you see things as you wish they were. After the second you see things as they are not. Finally you see things as they really are, and that is the most horrible thing in the world...
Oscar Wilde
:strip_icc():strip_exif()/u/504847/crop67c1d8df17bfe_cropped.jpg?f=community)
Tja gewoon bestellen, en binnen 14 dagen retourneren als het niet werkt is misschien het gemakkelijkste? Ik denk dat er niet veel Nederlanders zijn die deze setup hebben draaien. Je hebt nu 4 devices wat ook op één device kan werken met WAN1 en WAN2 faillover.
Zoek vooral even op reddit en de community van UI hoe goed de schaduwmode failover werkt
het is zeker niet foutloos (geweest?).
After the first glass you see things as you wish they were. After the second you see things as they are not. Finally you see things as they really are, and that is the most horrible thing in the world...
Oscar Wilde
/u/30817/avetar_colors.png?f=community)
Thanks, maar dat is het helaas niet. Dit staat er namelijk al in (had dat topic ook al gevonden). Wellicht is het handiger dat ik ff post wat ik al heb. (ook handig mocht ik het nog eens terugzoeken - got als backup
)/etc/network/interfaces
code:
1
2
3
4
5
| # The pppoe network interface on vlan 6 auto enp3s0.6 iface enp3s0.6 inet ppp pre-up /bin/ip link set enp3s0 up # line maintained by pppoeconf provider dsl-provider |
/etc/ppp/peers/dsl-provider
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| +ipv6 defaultroute6 noipdefault defaultroute replacedefaultroute hide-password noauth persist mtu 1500 plugin rp-pppoe.so nic-enp3s0.6 usepeerdns user "kpn" |
/etc/ppp/ipv6-up.d/ipv6-addresses-up
code:
1
2
| /usr/bin/systemctl restart wide-dhcpv6-client.service /bin/ip -6 route add default dev ppp0 scope link |
/etc/default/wide-dhcpv6-client
code:
1
2
| INTERFACES="ppp0" VERBOSE=2 |
/etc/wide-dhcpv6/dhcp6c.conf
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
| profile default {
information-only;
request domain-name-servers;
request domain-name;
script "/etc/wide-dhcpv6/dhcp6c-script";
};
interface ppp0 {
send ia-na 0;
send ia-pd 0;
};
id-assoc na 0 {
};
id-assoc pd 0 {
prefix-interface enp4s0 {
sla-len 8;
sla-id 3;
ifid 1;
};
}; |
/etc/wide-dhcpv6/dhcp6c-script
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
| RESOLVCONF="/sbin/resolvconf"
[ -f /etc/default/wide-dhcpv6-client ] && . /etc/default/wide-dhcpv6-client
if [ -n "$new_domain_name" -o -n "$new_domain_name_servers" ]; then
old_resolv_conf=/etc/resolv.conf
new_resolv_conf=/etc/resolv.conf.dhcp6c-new
rm -f $new_resolv_conf
if [ -n "$new_domain_name" ]; then
echo search $new_domain_name >> $new_resolv_conf
fi
if [ -n "$new_domain_name_servers" ]; then
for nameserver in $new_domain_name_servers; do
# No need to add an already existing nameserver
res=$(grep "nameserver $nameserver" $old_resolv_conf)
if [ -z "$res" ]; then
echo nameserver $nameserver >> $new_resolv_conf
fi
done
fi
# Use resolvconf if available
if [ -h "$old_resolv_conf" -a -x "$RESOLVCONF" ]; then
for IFACE in $INTERFACES; do
cat $new_resolv_conf | $RESOLVCONF -a $IFACE
done
else
# To preserve IPv4 informations...
cat $old_resolv_conf >> $new_resolv_conf
chown --reference=$old_resolv_conf $new_resolv_conf
chmod --reference=$old_resolv_conf $new_resolv_conf
mv -f $new_resolv_conf $old_resolv_conf
fi
fi
exit 0 |
Alles werkt dus goed op de services na die dus niet binden op ipv6 omdat ze te vroeg geladen worden. Ohja.. en Android verliest na een bepaalde periode zijn ipv6, maar dat is bekend en heb ik niet zoveel last van.
@ernstoud Thanks, maar dat is niet zo eenvoudig als het lijkt. De helft van de services wordt op user level geladen, een hoop zie ik niet eens terug in de rc.d meuk (anders kon ik de priority aanpassen alhoewel daar alles al vanaf het begin op 1 staat en 0 geen optie is). Ik weet zeker dat ik iets over het hoofd zie. Maar wat?
Try looking into that place where you dare not look! You'll find me there, staring out at you!
In dat geval vraag ik mij af of er niet een andere verkeerde route in de weg zit/zat, die overschreven wordt door:
[...]
Thanks, maar dat is het helaas niet. Dit staat er namelijk al in (had dat topic ook al gevonden). Wellicht is het handiger dat ik ff post wat ik al heb. (ook handig mocht ik het nog eens terugzoeken - got als backup
Bash:
en anders zou je debug aan kunnen zetten, kijken of er dan iets in journalctl verschijnt dat het (oorspronkelijke) probleem zou kunnen verklaren.
1
| /bin/ip -6 route add default dev ppp0 scope link |
After the first glass you see things as you wish they were. After the second you see things as they are not. Finally you see things as they really are, and that is the most horrible thing in the world...
Oscar Wilde
Wow wat een uitgebreid en mooi antwoord.
Ik heb het al ingeklopt, maar kan nu niet testen. Dan is het hier oorlog
Bedankt en ik laat het nog weten.
@Raven thanks. Mocht bovenstaand niet direct lukken ga ik dat zeker proberen uit te sluiten.
Try looking into that place where you dare not look! You'll find me there, staring out at you!
Zoiets heb ik hier ook:
Ik heb het al ingeklopt, maar kan nu niet testen. Dan is het hier oorlog
(om PPPoE proberen werkend te krijgen onder Debian), daarom maar dubbel NAT met de EB, dat was zo werkend te krijgen....
After the first glass you see things as you wish they were. After the second you see things as they are not. Finally you see things as they really are, and that is the most horrible thing in the world...
Oscar Wilde
Helaas blijken beide opties niet te werken. Hij wilt gewoonweg niet luisteren op de ipv6 host. Als ik even uitga van de laatste optie heb ik zelfs een echo blaat >> tekstbestand toegevoegd opdat ik zeker weet dat hij het script uitvoert (de ipv6-up-script /etc/ppp/ipv6-up lijn in dsl-provider geeft overigens een foutmelding, maar zonder dat voert hij wel het script uit dat in /etc/ppp/ipv6-up.d/ staat).
Nu er nergens de externe host stond toegevoegd in interfaces dacht ik dat dit een issue kon zijn. Ik heb voor de zekerheid deze toegevoegd aan het script. Eerst ppp0 en later enp3s0.6.
[code]
/bin/ip -6 addr add 2a02:xxxx:xxx:x:xxxx:xxxx:xxxx:xxxx/64 dev enp3s0.6
[code]
Na boot nog steeds geen ipv6 op de services tenzij ik deze manual herstart.
Enige dat ik nog kan bedenken dat mijn rules.v6 niet kloppen. Anders zou ik het echt niet meer weten.
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
| *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A INPUT -p ipv6-icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -m state --state NEW -m udp -p udp --dport 546 -d fe80::/64 -j ACCEPT -A INPUT -m state --state NEW -m udp -p udp --dport 547 -d fe80::/64 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT COMMIT |
Kleine update: Toen ik besloot even naar de andere services te kijken blijkt dat die het nu wel doen en netjes binden aan ipv6. Enkel apache2 doet echter pas na een manuele herstart. Apart, maar ik ben nu op 99%
2e update: Opgelost door in de Rc meuk speciaal voor apache2 een symlink te maken met S99 als prequal om apache2 op het einde te herstarten. Wellicht 'lelijk' maar het werkt en gelukkig moet ik dat door jullie input niet voor alle services doen. Nogmaals bedankt allen.
[ Voor 14% gewijzigd door liberque op 07-06-2025 12:42 ]
Try looking into that place where you dare not look! You'll find me there, staring out at you!
OK, maar dan gaat KPN wellicht die AON-aansluiting veranderen naar XSG-PON in welk geval je een SPF+ insteekmodule nodig hebt die niet met de FB5490 gebruikt kan worden... Dan zit je trouwens wel in het juiste topic hier.