Hey ik heb een mini pc geflasht met openwrt. Dit werkt top want ik zit in de ict en heb meer opties daardoor. Ik gebruik op mijn 1000/1000 ook quality of service. Met name cake qos.
Nu vraag ik me af wat de waarde is van de packet overhead. Dit moet je namelijk voor cake instellen zodat het algoritme goed werkt met je verbinding. Cake wordt gezet op de wan. Wat in mijn geval de pppoe-wan zou zijn.
Je hebt namelijk een ethernet aansluiting, gewoonweg de pure wan. Wat 38 bytes als het goed is moet zijn aan packet overhead. Dit kan je vinden op de cake manpage.
Maar er zit een vlan op voor internet en tv. Dat zou 4 bytes moeten zijn plus het pppoe waarin ook ppp verwerkt zou zijn. De pppoe zou 6 bytes moeten zijn en de ppp 2 bytes.
Dat zou een totaal moeten zijn van 38 + 4 + 6 + 2 = 50 bytes aan packet overhead.
Klopt mijn denkwijze en kan iemand dit bevestigen. Ik kan deze informatie nergens vinden bij kpn en wellicht kan iemand bij kpn dit aangeven mocht mijn denkwijze niet kloppen wat het wel is.
Bij voorbaat dank,
Martin
Bladzijde 1 / 2
@wjb weet hier veel van @Martjekday , misschien dat hij je kan en wil helpen.
Ik heb hem even ingeseind.
De MTU van de WAN poort heb ik op 1512 bytes staan.
De MTU van vlan 6 staat op 1508 (4 bytes overhead voor een vlan).
De MTU van de pppoe interface staat op 1500 (8 bytes overhead voor pppoe).
Hey dank jullie wel voor de reactie. Dit heb ik persoonlijk ook zo staan in mijn network config. Alleen dat betreft netwerk configuratie.
In dit geval is het niet de configuratie van het netwerk alleen gaat het meer om de verkeerstromen. Je kunt namelijk verkeer classificeren, door dit te doen hebben sommige packets voorrang op andere.
Quality of service met de smaak cake is vrij gemakkelijk in te stellen en is eigenlijk een verkeersregelaar. Ik heb twee screenshots gemaakt van de cake manpage dan begrijp je t beter waar ik op doel.
Het komt erop neer hoe groot is packet overhead in totaal in de situatie van kpn.
Hier kun je zien dat er waardes zijn voor verschillende lijnen. Wanneer ik cake instel op up en download moet ik ook aangeven hoe groot de packetoverhead is.
Nu begrijp ik zelf dat het beter is om een grotere waarde te doen dan een te kleine. Vroeg me af of de packet overhead van in totaal 50 waar ik aan kwam een correcte benadering was van de theorie erachter.
Ethernet is namelijk 38 met 84 mpu. Plus 4 voor de vlan is 42 plus nog pppoe 6 + 2 is in totaal 50 dan met 84 mpu lijkt me.
@Martjekday Ik gebruik voor openwrt de geadviseerde waarde voor KPN FTTH, alles loopt prima met up/down speed 1gbs
You can connect the WAN port of your router directly to the fiber termination box delivered by KPN using RJ-45. Internet will be delivered on VLAN 6 using PPPoE. The username/password combination is internet/internet. To get 1500 MTU (PPPoE is 1492 default due to 8 bytes overhead) you need to set the WAN port's MTU to 1508 bytes and then set the PPPoE interface to 1500 bytes. KPN is compliant with RFC4638.
Je kan ook testen met ping
Pinging kpn.com i75.2.72.204] with 1472 bytes of data: Reply from 75.2.72.204: bytes=1472 time=6ms TTL=250 Reply from 75.2.72.204: bytes=1472 time=4ms TTL=250 Reply from 75.2.72.204: bytes=1472 time=5ms TTL=250 Reply from 75.2.72.204: bytes=1472 time=6ms TTL=250
Ping statistics for 75.2.72.204: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 4ms, Maximum = 6ms, Average = 5ms
Pinging kpn.com P75.2.72.204] with 1473 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out.
Ping statistics for 75.2.72.204: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
@TDN Hey ik heb dit ook gezien. Alleen wat ik niet snap is hoe ze daarbij komen. Ook als ik kijk naar hoe ze de voorbeeld code laten zien krijg ik vraagtekens.
@wjb Jij gebruikt zeker een edgerouter?
Wat ik persoonlijk niet begrijp is hoe de wan poort op ‘1508’ kan.
Tussen de wan zit namelijk nog vlan en pppoe. Bij edgerouter zeggen ze 1512. Maar het is dezelfde techniek. Technisch gezien is vlan altijd 4 bytes. En pppoe is 6 + 2 = 8 bytes.
Wat de voorbeeld code van openwrt hieronder laat zien is dat ze eigenlijk hier zeggen de pppoe zit direct op vlan device en we rekenen de vlan niet mee. Wat in principe niet zou kunnen kloppen.
Ook in de code hieronder van het voorbeeld zie je op wan interface ipv6 ‘1’. Hoezo de ipv6 wordt gedaan door de wan6. Dus de wan hoeft helemaal geen ipv6 ‘1’. Want die krijgt hij aangewezen.
Wat ik hiermee bedoel is dat ze bij openwrt wel een leuke lijst hebben samengesteld. Echter twijfel ik of die wel klopt. De beredenering klopt namelijk niet, Ze zeggen dat vlan geen impact heeft er dus geen bytes produceren.
config device option name 'eth1' option mtu '1508'config device option type '8021q' option ifname 'eth1' option vid '6' option name 'eth1.6'config interface 'wan' option proto 'pppoe' option device 'eth1.6' option username 'internet' option password 'internet' option mtu '1500' option peerdns '0' list dns '8.8.8.8' list dns '8.8.4.4' option ipv6 '1' option metric '1'config interface 'wan6' option proto 'dhcpv6' option device 'pppoe-wan' option reqaddress 'try' option reqprefix 'auto' option peerdns '0' list dns '2001:4860:4860::8888' list dns '2001:4860:4860::8844' option metric '0'
@TDN Alleen dit is netwerk configuratie. Ik had het in mijn vraag meer over de packetoverhead die je moet instellen voor quality of service. Dus mijn beredenering van je hebt een ethernet link (wan) is 38 bytes met 84 mpu. Daar komt nog vlan en pppoe bij zou dus 12 zijn. Dus 50 bytes en 84 mpu in totaal. Alleen met de beredenering van openwrt zou het betekenen dat ik in plaats van 50, 46 zou moeten zetten want ze berekenen de vlan niet mee. Dat vind ik vreemd om eerlijk te zijn want ik denk dat het niet klopt.
Wat ik persoonlijk niet begrijp is hoe de wan poort op ‘1508’ kan.
Die moet ook niet op 1508 staan maar op 1512.
Onderstaand de MTU instellingen van mijn WAN interfaces.
De MTU van de pppoe verbinding bij KPN is 1500 bytes. Deze draait op vlan 6 en dus moet de MTU van vlan 6 acht bytes groter zijn (de overhead van pppoe). De MTU van de WAN poort moet op zijn beurt weer vier bytes groter zijn immers de overhead van een vlan is vier bytes,
@wjb Ja ik deel compleet je beredenering. Het gekke is dus dat ze bij openwrt zeggen nee hoor in mijn geval eth1 kan 1508. En dan de eth1.4 en eth1.6 ook op 1508, ze laten ook een code stukje zien waarvan ze dus bevestigen dat ze weten dat het cable fiber op vlan met pppoe is.
Maar zoals ik al eerder zei zie ik verschillende elementen in hun configuratie dat vreemd lijkt.
Ok dan zet ik mijn packet overhead op qos op 50. En zet ik de ethernet link op 1512.
Mag ik vragen waarom je de iptv vlan op 1500 heb staan? Waarom die niet op 1508?
@Martjekday Je kan zien aan mijn ping dat alle pakketten boven 1472 gedropd worden. Dus de overheads voor ethernet is 1500-1472=28 (14b ethernet header + 4b CRC + 4b VLAN + 6b PPPoE), voor de WAN is overheads 8 (2b PPP + 6b PPPoE), omdat KPN geen MTU boven 1500 toelaat, moet je hier MTU=1508 zetten. Zo kloppen precies de berekeningen van OpenWRT adviezen.
De MTU van de pppoe verbinding is niet 1492 bytes maar 1500 bytes en dus moet de MTU van vlan 6 op 1508 staan en de MTU voor de WAN poort op 1512.
Pingen met een packetsize van 1480 bytes gaat ook prima ...
… alleen niet naar kpn.com.
@TDN, Probeer eens te pingen met een packetsize van 1480 naar 1.1.1.1. Lukt dat wel?
@TDN, Probeer eens te pingen met een packetsize van 1480 naar 1.1.1.1. Lukt dat wel?
Naar cloudflare gaat zelfs met 15000
Pinging 1.1.1.1 with 15000 bytes of data: Reply from 1.1.1.1: bytes=15000 time=12ms TTL=59 Reply from 1.1.1.1: bytes=15000 time=6ms TTL=59 Reply from 1.1.1.1: bytes=15000 time=13ms TTL=59 Reply from 1.1.1.1: bytes=15000 time=8ms TTL=59
Ping statistics for 1.1.1.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 6ms, Maximum = 13ms, Average = 9ms
Naar google gaat ook niet
Pinging 8.8.8.8 with 1480 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out.
Ping statistics for 8.8.8.8: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)
Dus naar alle sites behalve cloudflare gaat niet boven 1472. Wat is bijzonder aan cloudflare?
@TDN, Bij een ping wordt een header van 28 bytes gebruikt. 20 bytes IP header en 8 bytes ICMP header.
Bij een payload van 1472 bytes is dus sprake van een packetsize van 1500 bytes.
Dit is de grootste packetsize die zonder fragmentatie mogelijk is op een interface met een MTU size van 1500 bytes.
De MTU size van de pppoe interface is dus 1500 bytes. Aangezien pppoe een overhead heeft van 8 bytes moet de MTU size van vlan 6 dus 1508 bytes zijn. De MTU size van de WAN poort moet minimaal de grootste MTU size van de één van de op de WAN poort actieve vlans zijn.
Mag ik vragen waarom je de iptv vlan op 1500 heb staan? Waarom die niet op 1508?
Omdat de MTU size voor ethernet standaard 1500 bytes is en er op vlan 4 geen sprake is van een pppoe verbinding met een overhead van 8 bytes. Die 1508 is enkel voor vlan 6 om de 8 bytes overhead voor de pppoe verbinding aan te kunnen terwijl de MTU size voor de pppoe verbinding wel gewoon 1500 bytes blijft.
@wjb Hey dank je wel je bijdrage. Helder dan weet ik genoeg.
De MTU size van de pppoe interface is dus 1500 bytes. Aangezien pppoe een overhead heeft van 8 bytes moet de MTU size van vlan 6 dus 1508 bytes zijn. En aangezien een vlan een overhead heeft van 4 bytes moet de MTU size van de WAN poort 1512 bytes zijn.
Enkel de 8 bytes voor PPPoE zijn van belang, de 4 bytes van de VLAN-tag zijn onderdeel van de ethernet-header en niet van de payload. Het is niet heel waarschijnlijk dat er iets verkeerd gaat met de MTU 4 bytes hoger instellen, maar nodig is het niet.
Ik kan zijn bevinding bevestigen. Het maakt niet uit wat voor waarde op WAN staat, als het maar groter dan 1508 is. Met TCP Optimizer kan ik zien dat in ieder geval MTU voor intern LAN 1500 het maximaal is.
@TDN Dan zou zijn theorie ook kloppen dat de mtu van de eth1.4 op 1500 moet. anders zou deze op 1504 moeten omdat de vlan 4 bytes zou zijn. Dank je wel voor het uitzoeken en het delen van de kennis.
Hey, mag ik vragen waar je op uitgekomen bent qua overhead voor SqM. Ik zit nu in hetzelfde schuitje en gebruik nu de standaard zoals voorgeschreven in de guide en vraag me af of deze correct is. Bedankt!
@vicking Ok voor de eth1 heb ik hem op 1508 de vlan 6 ook. In theorie zou t 1512 moeten zijn, maar t lijkt erop dat hij toch die 4 bytes niet meeneemt. Dus dan is 1508 beter om fragmentatie te voorkomen. De iptv staat op 1500 dat heb ik gezet ook op de vlan4. Stel je gebruikt quality of service. Dan zou ik cake adviseren. Ik heb een 1000/1000 verbinding. Ik gebruik op mijn openwrt 23.05.4 verschillende scripts om mijn x86/64 router te tunen. Als je echt alle performance eruit wilt halen kun je ook zelf een kernel bouwen. Dan kun je alle opties open zetten en alle performance eruit halen.
Voor de cake heb ik de overhead op 50 mpu 84 gezet. Cake gaat uit van de ethernet link wat 38 zou zijn + de pppoe wat 8 is + de vlan wat 4 is wat in totaal 50 maakt. De mpu 84 is om pakketjes die kleiner zijn ook mee te pakken.
Ik gebruik hiervoor qosify.
Mijn bufferbloat waardes zijn unloaded 0.4 jitter op download 0 ms met 0.4 jitter en upload 0ms met 0.4 jitter. Dit zijn echt super cleane waardes. Beter dan dat gaat t echt niet worden.
Heb overigens wel de cpu op een fixed rate gezet en in performance mode. Verbruikt hij wel wat meer energie, maar t internet werkt wel als een trein.
Overigens ik heb even via mijn mobiel in mijn router gelogd en mijn network config gekopieerd.
qdisc clsact ffff: dev ifb-pppoe-wan parent ffff:fff1
Stel je wilt wat meer weten hierover dan geef je maar een gil
Bedankt voor je reactie!
Je config lijkt sterk op dat van de mijne, ik ben laatste tijd ook bezig om wat te knutselen met een eigen router, eerst dmv een rpi4 oc’ed naar 2ghz met openwrt maar nu dmv een nanopi r4s die ik ook al zo getweaked heb dat de CPU zonder packet steering de load netjes verdeeld over de cores!
Ook ik heb een 1gb verbinding, dus die vraagt nog al wat van de CPU tijdens SqM haha. Wel merk ik, dat als ik de waveform bufferbloat test doe, ik nog al gemixte resultaten krijg en eigenlijk nooit een steady A+ als resultaat.
Heb jij overigens onder interfaces ook een pppoe-wan tunnel device gekregen? Bij mij is daar de mtu standaard van op 1492 gezet. Overrule ik deze naar 1500 werkt mijn verbinding niet meer goed.
Mag ik vragen wat voor systeem jij gebruikt als router? :D
Je kunt de MTU voor de WAN poort (eth1) inderdaad op 1508 laten staan, de vier bytes overhead voor de vlan vallen inderdaad buiten de MTU. Je mag hem ook rustig op 1512 laten staan, daardoor zal geen fragmentatie optreden omdat de MTU van de onderliggende vlans niet groter is dan de MTU van de WAN.
Wat mij opvalt in jouw configuratie is dat je in je wan interface obtain ipv6 adres op disabled “0” hebt staan maar dat je wel specifiek een interface geconfigureerd heb voor wan6 met request address op none.
Wellicht maak je en wil je geen gebruik maken van ipv6? Maar anders zou ik in je wan interface deze op 1 zetten (manual) en in je wan6 configuratie request address op “try”. Op deze manier heb je daadwerkelijk ook een Ipv6 adres, anders is deze interface overbodig, of ik zie iets over het hoofd. Zo lang doe ik nog niet mee met OpenWrt en het configureren van eigen routers haha.
@vicking
Ik heb even zoeken draai mijn hwinfo even:
: None 03.0: 10103 CPU Created at cpu.462] Unique ID: 4zLr.j8NaKXDZtZ6 Hardware Class: cpu Arch: X86-64 Vendor: "GenuineIntel" Model: 6.122.8 "Intel(R) Celeron(R) J4125 CPU @ 2.00GHz" Features: fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,pdpe1gb,rdtscp,lm,constant_tsc,art,arch_perfmon,pebs,bts,rep_good,nopl,xtopology,nonstop_tsc,cpuid,aperfmperf,tsc_known_freq,pni,pclmulqdq,dtes64,monitor,ds_cpl,est,tm2,ssse3,sdbg,cx16,xtpr,pdcm,sse4_1,sse4_2,x2apic,movbe,popcnt,tsc_deadline_timer,aes,xsave,rdrand,lahf_lm,3dnowprefetch,cpuid_fault,cat_l2,cdp_l2,ssbd,ibrs,ibpb,stibp,ibrs_enhanced,fsgsbase,tsc_adjust,sgx,smep,erms,mpx,rdt_a,rdseed,smap,clflushopt,intel_pt,sha_ni,xsaveopt,xsavec,xgetbv1,xsaves,dtherm,ida,arat,pln,pts,umip,rdpid,sgx_lc,md_clear,arch_capabilities Clock: 1996 MHz BogoMips: 3993.60 Cache: 4096 kb Units/Processor: 64 Config Status: cfg=new, avail=yes, need=no, active=yes
Ik heb echt een windows x64 machine geflasht op een ssd met openwrt. Ook de bios aangepast zodat hij weet dat hij op een ssd draait.
Heb de default 104 mb vervangen met de volledige 128gb. Dus ik kan draaien wat ik wil.
Je moet in je firewall wat aanpassen om dat goed te krijgen. Ik deel de firewall config even:
De mss clamp moet eraf anders dan vind hij t niet leuk. Had hetzelfde probleem, echter al doende leer je. Mijn cpu heeft een turbo van 2.7 gighertz. Echter laat ik hem max onder turbo lopen. Ik heb een script om de minfreq en maxfreq op 2.00 te laten draaien. Dit kun je ook zien uit mijn hwinfo. Daar zegt hij ook dat hij rond de 2.00 draait.
Waarschijnlijk heb jij de optie mtu_fix 1 in je firewall script staan, die moet eruit
config zone option name 'lan' option input 'ACCEPT' option output 'ACCEPT' option forward 'ACCEPT' list network 'lan'
config zone option name 'wan' option input 'REJECT' option output 'ACCEPT' option forward 'REJECT' option masq '1' list network 'wan' list network 'wan6'
config forwarding option src 'lan' option dest 'wan'
config rule option name 'Allow-DHCP-Renew' option src 'wan' option proto 'udp' option dest_port '68' option target 'ACCEPT' option family 'ipv4'
config rule option name 'Allow-Ping' option src 'wan' option proto 'icmp' option icmp_type 'echo-request' option family 'ipv4' option target 'ACCEPT'
config rule option name 'Allow-IGMP' option src 'wan' option proto 'igmp' option family 'ipv4' option target 'ACCEPT'
config rule option name 'Allow-DHCPv6' option src 'wan' option proto 'udp' option dest_port '546' option family 'ipv6' option target 'ACCEPT'
config rule option name 'Allow-MLD' option src 'wan' option proto 'icmp' option src_ip 'fe80::/10' list icmp_type '130/0' list icmp_type '131/0' list icmp_type '132/0' list icmp_type '143/0' option family 'ipv6' option target 'ACCEPT'
config rule option name 'Allow-ICMPv6-Input' option src 'wan' option proto 'icmp' list icmp_type 'echo-request' list icmp_type 'echo-reply' list icmp_type 'destination-unreachable' list icmp_type 'packet-too-big' list icmp_type 'time-exceeded' list icmp_type 'bad-header' list icmp_type 'unknown-header-type' list icmp_type 'router-solicitation' list icmp_type 'neighbour-solicitation' list icmp_type 'router-advertisement' list icmp_type 'neighbour-advertisement' option limit '1000/sec' option family 'ipv6' option target 'ACCEPT'
config rule option name 'Allow-ICMPv6-Forward' option src 'wan' option dest '*' option proto 'icmp' list icmp_type 'echo-request' list icmp_type 'echo-reply' list icmp_type 'destination-unreachable' list icmp_type 'packet-too-big' list icmp_type 'time-exceeded' list icmp_type 'bad-header' list icmp_type 'unknown-header-type' option limit '1000/sec' option family 'ipv6' option target 'ACCEPT'
config rule option name 'Allow-IPSec-ESP' option src 'wan' option dest 'lan' option proto 'esp' option target 'ACCEPT'
config rule option name 'Allow-ISAKMP' option src 'wan' option dest 'lan' option dest_port '500' option proto 'udp' option target 'ACCEPT'
config zone option name 'IPTV_WAN' option input 'ACCEPT' option forward 'REJECT' option output 'ACCEPT' option masq '1' list network 'IPTV_WAN' option family 'ipv4'
config forwarding option dest 'IPTV_WAN' option src 'lan'
config rule option name 'Allow-IGMP-Proxy' option proto 'udp' option family 'ipv4' option target 'ACCEPT' option dest_ip '224.0.0.0/4' option dest 'lan' option src 'IPTV_WAN'
@vicking
Waarschijnlijk heb jij de optie mtu_fix 1 in je firewall script staan, die moet eruit
Thanks, die stond er inderdaad in. Wat doet dit als ik vragen mag? En nu deze weg is, wat kan ik anders/moet ik anders configureren nu?
Nu deze er uit is zie ik overigens nog steeds dat pppoe-wan tunnel device met een mtu van 1492… haha
@vicking het is mss clamping dat is wat de mtu fix doet het zorgt ervoor dat de mtu voor pppoe-wan op 1492 wordt gezet. Niet iedere provider die een oude backend heeft stelt hun klanten in staat om de mtu naar 1500 op te hogen. Voor standaard pppoe is het 1492. Echter kun je deze bij kpn zetten op 1500. Dan moet wel de clamping eraf. Maar het is een verouderd systeem. Je wilt namelijk helemaal geen pppoe, maar het is goedkoper om oude systemen te koppelen met nieuwe. Dus t is een beetje jammer wat kpn doet. Je hoort gewoon direct op de eth1 te zitten en eigenlijk wil je altijd een hardware bridge die het internet en de tv scheid zoals ziggo doet. Dan hoeft de router namelijk minder hard te werken. En heb je ook minder interference in je router.
Voor de mtu op 1500:
Je moet dan ook op je wan link bij mij is dit eth1, bij jou wellicht eth0. Zetten op de 1508, maar ook waar je je pppoe gegevens wegzet, de mtu op 1500 zetten. Mijn vermoeden is dat je nu de clamping eraf hebt, maar nog niet de mtu fixed hebt op 1500 op de pppoe-wan. Drop anders je config, dan kan ik zien wat er verkeerd staat.
Mijn ipv6 werkt denk ik wel volgens mijn config. Kijk ik heb een foto van mijn interface gemaakt.
Thanks, ik heb nu die mtu_fix er af gehaald en merk dat mijn internet heel instabiel is. Ik zal even mijn config droppen zodat je kan zien dat ik de MTU wel degelijk correct ingesteld heb.
config device option type '8021q' option ifname 'eth1' option vid '4' option name 'eth1.4' list egress_qos_mapping '0:5' list egress_qos_mapping '1:5' list egress_qos_mapping '2:5' list egress_qos_mapping '3:5' list egress_qos_mapping '4:5'
config device option type 'bridge' option name 'br-iptv' list ports 'eth1.4' option ipv6 '0'
config zone option name 'lan' option input 'ACCEPT' option output 'ACCEPT' option forward 'ACCEPT' list network 'lan'
config zone option name 'wan' option input 'REJECT' option output 'ACCEPT' option forward 'REJECT' option masq '1' list network 'wan' list network 'wan6'
config forwarding option src 'lan' option dest 'wan'
config rule option name 'Allow-DHCP-Renew' option src 'wan' option proto 'udp' option dest_port '68' option target 'ACCEPT' option family 'ipv4'
config rule option name 'Allow-Ping' option src 'wan' option proto 'icmp' option icmp_type 'echo-request' option family 'ipv4' option target 'ACCEPT'
config rule option name 'Allow-IGMP' option src 'wan' option proto 'igmp' option family 'ipv4' option target 'ACCEPT'
config rule option name 'Allow-DHCPv6' option src 'wan' option proto 'udp' option dest_port '546' option family 'ipv6' option target 'ACCEPT'
config rule option name 'Allow-MLD' option src 'wan' option proto 'icmp' option src_ip 'fe80::/10' list icmp_type '130/0' list icmp_type '131/0' list icmp_type '132/0' list icmp_type '143/0' option family 'ipv6' option target 'ACCEPT'
config rule option name 'Allow-ICMPv6-Input' option src 'wan' option proto 'icmp' list icmp_type 'echo-request' list icmp_type 'echo-reply' list icmp_type 'destination-unreachable' list icmp_type 'packet-too-big' list icmp_type 'time-exceeded' list icmp_type 'bad-header' list icmp_type 'unknown-header-type' list icmp_type 'router-solicitation' list icmp_type 'neighbour-solicitation' list icmp_type 'router-advertisement' list icmp_type 'neighbour-advertisement' option limit '1000/sec' option family 'ipv6' option target 'ACCEPT'
config rule option name 'Allow-ICMPv6-Forward' option src 'wan' option dest '*' option proto 'icmp' list icmp_type 'echo-request' list icmp_type 'echo-reply' list icmp_type 'destination-unreachable' list icmp_type 'packet-too-big' list icmp_type 'time-exceeded' list icmp_type 'bad-header' list icmp_type 'unknown-header-type' option limit '1000/sec' option family 'ipv6' option target 'ACCEPT'
config rule option name 'Allow-IPSec-ESP' option src 'wan' option dest 'lan' option proto 'esp' option target 'ACCEPT'
config rule option name 'Allow-ISAKMP' option src 'wan' option dest 'lan' option dest_port '500' option proto 'udp' option target 'ACCEPT'
config zone option name 'iptv' option input 'ACCEPT' option output 'ACCEPT' option forward 'REJECT' option masq '1' list network 'iptv' option family 'ipv4'
config zone option name 'iptv_lan' option input 'ACCEPT' option output 'ACCEPT' option forward 'REJECT' list network 'iptv_lan'
config forwarding option src 'iptv_lan' option dest 'iptv'
config forwarding option src 'iptv_lan' option dest 'wan'
config rule option name 'Allow-IPTV-To-Lan' option src 'iptv_lan' option dest 'iptv' option target 'ACCEPT' option family 'ipv4' list proto 'all'
config rule option name 'Allow-IGMP-Proxy' option family 'ipv4' list proto 'udp' option src 'iptv' option dest 'iptv_lan' list dest_ip '224.0.0.0/4' option target 'ACCEPT'
config rule option name 'Block-Public-DNS' option src 'lan' option dest 'wan' option dest_port '53 853 5353' option target 'REJECT'
config redirect option dest 'lan' option target 'DNAT' option name 'camera' list proto 'tcp' option src 'wan' option src_dport '554' option dest_ip '192.168.1.60' option dest_port '554'
Ik maak gebruik van Unbound, vandaar de extra regels en heb een eigen Vlan ingesteld voor mijn IPTV apparaten.
@vicking klopt maar je hebt een oude config denk ik. Op welke openwrt zit jij? Want het bridgen van iptv hoort niet meer. Als je goed kijkt naar mijn config. Dan zie je dat t heel anders is. Ook zou ik de qos mappings eruit halen. Ik heb dit ook geprobeerd maar je kunt beter luci-app-sqm pakken of wat ik heb qosify hiermee kun je namelijk op dns niveau dscp values toekennen. Ik zou ook irqbalance en packet steering gebruiken. Ik heb een aantal configs. Ik weet niet of je discord hebt of iets dan kan ik ze met je delen. Werkt op ieder apparaat.
Ik zou letterlijk mijn firewall config overnemen en ook mijn netwerk config. Alleen dan de waardes veranderen want ik dan de eth1 heb in jou geval eth0. Het kan namelijk niet zijn dat t bij mij wel werkt en bij jou niet.
Ik zie ook dat je de forwards meerdere kanten heb staan van iptv. Je hebt ook twee bridges dit zou ik niet doen. Je hebt ook geen igmp snooping, op zich kan dat omdat je twee bridges hebt, ik heb echter altijd begrepen dat dit niet gewenst is. Dat je een bridge moet hebben.
Save anders jouw configs en zet die mtu_fix erbij en kopier letterlijk de mijne eens en plak die erin. Even een reboot. Vervolgens open je via putty of winscp en dan putty, tik je in route en dan zie je een getal onderin de tabel dat getal plaats je in het netwerk config bij iptv en dan doe je service network reload.
Ook heb je de iptv niet gezet op 1500 en de vlan 4 ook niet op 1500. Of als je de vlan 4 op 1500 zet hoeft dat niet meer op de iptv interface want die neemt de mtu van vlan over. Dat egress verhaal zou ik niet doen. Je hebt beter spul dat fatsoenlijker werkt.
Reageer
De Kennisbank
Heb je vragen over diensten, producten of wil je weten hoe je modeminstellingen verandert? Vind het antwoord op de meest gestelde vragen in onze Kennisbank
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
Bestand scannen voor virussen
Sorry, we zijn de inhoud van dit bestand nog aan het controleren om er zeker van te zijn dat het veilig is om te downloaden. Probeer het nog een keer over een paar minuten.
