asus RT-N66u configureren voor Sparql

[Xilv3r]

Hallo Nogmaals,

 

Routed configuratie heb ik semi-werkend, de router wordt alleen heel instabiel, en als TV aanstaat kan je niet internetten (of heeeel traag en dan helemaal niet meer), heeft me al redelijk wat factory resets gekost.

Gezien de 88U 8 poorten heeft vind ik het niet erg dat er 2 poorten puur voor IPTV gebruikt worden dus heb ik de standaard gui configuratie nu aanstaan. Alleen mis ik de static route (en mogelijk de igmp configuratie)

 

Is het ook mogelijk om die static route aan de bridged configuratie toe te passen?

Hierbij de setup

 

In Asus Router GUI -> Lan -> IPTV

Internet VLAN 43 Prio 1

Lan 4 VLAN 4 Prio 5

Lan 3 VLAN 4 Prio 5

 

DHCP routes disabled

Beide IMGP enabled

Udp 0

 

(Met bovenstaande krijg je een bridged configurtie met internet en IPTV)

Waarbij IPTV niet in de network range zit van LAN. Deze setup heeft alleen problemen met wisselen van kanalen op de Sparql box.

 

Ik dacht dat ik de wan-start kon aanpassen om alleen de static route te plaatsen maar die geeft: No such proces melding

Iemand enig idee?

 

Met vriendelijke groet,

 

Xil

[Xilv3r]

Laatste stukje config om een separate vlan10 op het interne netwerk te maken op poort 1 van de asus

 

in wan-start in /jffs/configs:

#vlan10 only for sparql box
#strip port 1 from vlan1
/usr/sbin/robocfg vlan 1 ports "2 3 4 8t"
#create vlan10 and put port 1 in
/usr/sbin/robocfg vlan 10 ports "1 8t"
/sbin/vconfig add eth0 10
#bring up vlan10 interface
ifconfig vlan10 multicast up
#create br1 bridge and add vlan10
/usr/sbin/brctl addbr br1
/usr/sbin/brctl addif br1 vlan10
#set ip address on br1 interface
ifconfig br1 192.168.3.1 netmask 255.255.255.0
ifconfig br1 multicast up
#iptables to allow traffic to br1 and not to br0
/usr/sbin/iptables -I FORWARD -i br1 -j ACCEPT
/usr/sbin/iptables -I INPUT -i br1 -j ACCEPT
/usr/sbin/ebtables -t broute -I BROUTING -p ipv4 -i br1 -j DROP
/usr/sbin/ebtables -t broute -I BROUTING -p ipv6 -i br1 -j DROP
/usr/sbin/ebtables -t broute -I BROUTING -p arp -i br1 -j DROP
/usr/sbin/iptables -I FORWARD -i br1 -j ACCEPT
/usr/sbin/iptables -I INPUT -i br1 -j ACCEPT
/usr/sbin/iptables -I FORWARD -i br1 -d 192.168.36.1/24 -j DROP
/usr/sbin/iptables -I INPUT -i br1 -d 192.168.36.1/24 -j DROP

Interne lan draait hier op 192.168.36.0/24, port 1 van mijn asus is nu 192.168.3.0/24

 

Ik had eerst mijn asus rechtstreeks op mijn managed switch aangesloten, maar die switch doet jammer genoeg geen igmpsnooping dus als er een multicast pakketje voorbij komt gaat dat mijn hele netwerk door. Nu heb ik mijn sparql box in een separaat netwerk in een apart vlan zodat broadcasts alleen op dat vlan blijven.

 

Hi Wiz

 

Vraagje is deze script aanvullend op de vorige wan-start of geheel stand alone?

Heb mijn stabiliteits problemen opgelost doormiddel van een firmware downgrade, maar wil toch SparQL in een aparte vlan hebben. zou jij enigzins kunnen assisteren?

 

Setup idee:

NTU -> AC88U - -> VLANx1 -> Internet

                         \ -> VLANx2 -> IPTV (SparqL) (incl static route en igmpproxy/snoping)

 

Bij voorbaat dank,

 

Xil

[wiz]

Xil,

 

ik heb al bijna een jaar geen sparql meer. Als ik me goed herinner was dit allemaal in wan-start gedaan.

[Xilv3r]

Xil,

 

ik heb al bijna een jaar geen sparql meer. Als ik me goed herinner was dit allemaal in wan-start gedaan.

 

Hi Wiz,

 

Thanks voor de response.

 

Ik heb het uiteindelijk met veel gefriemel zelf opgelost.

Daarbij ben ik op 2 oplossingen gekomen (waarbij 1 niet geheel soepel werkt)

 

Oplossing 1: Alleen Asus router

Met wat tweaken van jou scripts was het gelukt om de Zyxel geheel te vervangen en 2 VLANs te gebruiken waarbij IPTV voor 1 VLAN werdt gebruikt en Internet voor de andere, en beide vlan's zijn geisoleerd van elkaar. 

Maar nadeel van deze configuratie is dat igmpproxy niet goed werkt bij de Asus router, denk op firmware niveau. (Na 5 a 10 min TV kijken bevriest het beeld, als je dan naar een andere kanaal gaat werkt het weer en weer na 5 a 10 min bevriest het beeld en dat is niet prettig TV kijken)

 

Oplossing 2: Asus router als "Main" router en Zyxel  alleen voor IPTV

Dit is uiteindelijk me werkbare oplossing gezien Igmpproxy wel goed werkt op de Zyxel (zelfs met meerdere STB's)

Voor deze oplossing gebruik ik nog steeds 2 aparte VLAN's (met andere IP range en isolation) echter is de Zyxel de router die igmpproxy voorziet en alle STB's zijn verbonden op de Zyxel.

 

Had liever de oplossing gezien zonder Zyxel maar zolang de igmpproxy bij Asus niet goed werkt gaat het hem niet worden.

Nogmaals bedankt voor je scripts, die hebben me enorm op weg geholpen.

Met vriendelijke groet,

 

 

Xil

[wiz]

raar, dat igmp proxy ding werkte feilloos bij mijn opstelling.

 

Ik kijk even in mijn backup, ik had wel de igmpproxy.conf aangepast.

 

dit was mijn igmpproxy.conf

quickleave



phyint vlan4 upstream  ratelimit 0  threshold 1

        altnet 0.0.0.0/0

phyint br1 downstream  ratelimit 0  threshold 1

phyint br0 downstream  ratelimit 0  threshold 1



phyint lo disabled

phyint eth0 disabled

phyint eth1 disabled

phyint eth2 disabled

phyint vlan1 disabled

phyint vlan34 disabled

phyint wl0.1 disabled

phyint wl0.2 disabled

phyint tap21 disabled

de disableds heb ik op alle fysieke interfaces gezet, en alleen op br0 en br1 mag er geproxied worden.

 

Eigenlijk heb ik daar nooit problemen mee gehad met kanalen wisselen. Die quickleave is ook van belang.

 

Wellicht helpt dit?

 

Nee, ik weet het alweer.

 

heb je deze regel er wel in staan:

 

 

echo 0 > /proc/sys/net/ipv4/conf/vlan4/rp_filter

 

hiermee zet je reverse path filtering uit op vlan4. Dat filter sloopt als ik me het goed herinner je proxying van multicast pakketjes.

 

Ik denk dat dat het was.

[wiz]

Ik heb nog even gezocht op rp_filter, dit zorgt ervoor dat de weg terug wordt gecontroleerd. Als de host waar het pakketje vandaan komt niet bereikbaar is vanaf de host die wordt benaderd, dan dropt dit filter het inkomende pakket. Dat doet hij niet meteen, maar na een tijdje. Vanaf je settop box kan je de host waar de streams vandaan komen natuurlijk niet benaderen, vandaar dat je de igmpproxy gebruikt. Zet de waarde op 0 (disable) en dan kan ook jij gewoon lekker tv kijken met alleen je asus router aangesloten.

[Xilv3r]

Hi Wiz

 

Ik had dezelfde igmpproxy alleen had ik de altnet's van tweak toegepast. zie hieronder

quickleave

phyint vlan4 upstream  ratelimit 0  threshold 1
		altnet 172.16.0.0/16
		altnet 10.0.0.0/8

phyint br1 downstream  ratelimit 0  threshold 1

phyint lo disabled
phyint br0 disabled
phyint eth0 disabled
phyint eth1 disabled
phyint eth2 disabled
phyint vlan1 disabled
phyint vlan34 disabled
phyint wl0.1 disabled
phyint wl0.2 disabled
phyint tap21 disabled 

Bij mij is br1 voor IPTV en br0 gewone internet vandaar dat die disabled staat.

 

De rp filter had ik in nat_start:

#!/bin/sh

#set return check vlan4 off
echo 0 > /proc/sys/net/ipv4/conf/vlan4/rp_filter

#static route to media portal
/opt/sbin/route add -net 185.6.48.0/26 gw 10.10.56.1

En TV werkte wel alleen voor 5 a 10 min en dan bevroor het beeld, als je de kanaal switchte werkte het weer voor 5 a 10 min en bevroor het weer.

Had ook geprobeerd igmpproxy -dvvv om logging te zien echter op het moment van vastlopen gebeurd er niks in de LOG. Dus vandaar dat ik denk dat het op firmware gebied een probleem is en niet met de scripts. Heb ook bij snbforums een en ander gelezen en zag daar wat meldingen van "broken igmpproxy bij verscheidene Asus routers". Dus ik blijf het onderzoeken en testen.

Op zich niks mis met de huidige setup echter die extra stroombron is beetje zonde.

 

Nogmaals bedankt voor de hulp!

Met vriendelijke groet,

 

 

Xil

[wiz]

ik weet niet welke versie firmware je hebt draaien, ik draai al tijden een merlin fork (deze), en daar draaide het prima mee. Het is wel een hele oude kernel, maar dat komt omdat de drivers voor wifi dat eisen en deze driver set heeft het beste bereik. In latere firmwares is er onder dwang van de fcc nogal wat gelimiteerd in de wifi. Je zou nog eens kunnen proberen of het met de fork wel werkt?

[Xilv3r]

ik weet niet welke versie firmware je hebt draaien, ik draai al tijden een merlin fork (deze), en daar draaide het prima mee. Het is wel een hele oude kernel, maar dat komt omdat de drivers voor wifi dat eisen en deze driver set heeft het beste bereik. In latere firmwares is er onder dwang van de fcc nogal wat gelimiteerd in de wifi. Je zou nog eens kunnen proberen of het met de fork wel werkt?

 

Hi Wiz,

 

Ja ik denk dat het ook daar mee te maken heeft gehad ja, ik kan die vork niet gebruiken gezien ik de AC88U router heb (wordt niet ondersteund). Zit nu op Merlin 380.66_6

Maar wel iets m.b.t de rp_filter:

 

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/Documentation/networking/ip-sysctl.txt#n1090

rp_filter - INTEGER
	0 - No source validation.
	1 - Strict mode as defined in RFC3704 Strict Reverse Path
	    Each incoming packet is tested against the FIB and if the interface
	    is not the best reverse path the packet check will fail.
	    By default failed packets are discarded.
	2 - Loose mode as defined in RFC3704 Loose Reverse Path
	    Each incoming packet's source address is also tested against the FIB
	    and if the source address is not reachable via any interface
	    the packet check will fail.

	Current recommended practice in RFC3704 is to enable strict mode
	to prevent IP spoofing from DDos attacks. If using asymmetric routing
	or other complicated routing, then loose mode is recommended.

	The max value from conf/{all,interface}/rp_filter is used
	when doing source validation on the {interface}.

	Default value is 0. Note that some distributions enable it
	in startup scripts. 

 Ik zie nu wel in dat het wellicht hier mee te maken heeft dat na enige tijd de source niet meer klopt en dus de stream wordt afgebroken. Zal dit wel verder onderzoeken.

Thanks voor de tip!

 

Met vriendelijke groet,

 

Xil

[wiz]

Je zou nog eens kunnen kijken of het helpt als je die regel in wan_start zet, wellicht heeft het iets met volgorde te maken. Ik had hem niet voor niets in wan_start gezet.

[Xilv3r]

Je zou nog eens kunnen kijken of het helpt als je die regel in wan_start zet, wellicht heeft het iets met volgorde te maken. Ik had hem niet voor niets in wan_start gezet.

Hi Wiz,

 

Ja volgorde is zeker van belang.

Ik had hem voorheen in wan_start zitten en had hetzelfde probleem als in nat_start (had hem verplaatst omdat ik dacht dat als het in nat_start zit ik zeker weet dat de interface (vlan4) aangemaakt is en up and running).

 

In beide gevallen blijf ik hetzelfde probleem aanhouden waarbij je z'n 5 a 10 min TV kan kijken en vervolgens het beeld & geluid vast zit.

 

In de tweede post van deze forum staat m'n volledige config:

https://www.snbforums.com/threads/creating-a-seperate-vlan-for-iptv-on-ac88u.40134/

 

(In de eerste post zit de configuratie zonder aparte VLAN, dat is precies jou eerste configuratie)

 

Met vriendelijke groet,

 

 

Xil

[wiz]

Wat je nog zou kunnen proberen is via entware icmpproxy installeren (opkg install icmpproxy). Dan uit /opt/bin igmpproxy starten en eens kijken of die het wel doet?

 

je kan met tcpdump -i vlan4 > /pad naar usbstick/tcpdump.log de packets volgen en in een file schrijven. Dan kan je zien wat er gebeurt als je tv er mee ophoudt.

[wiz]

Als het echt om de 15 minuten is zou het ook nog kunnen zijn dat je lease van vlan4 niet vernieuwd wordt. Volgens het dhcp protocol zal halverwege de lease de client een renew request doen. Als deze geen antwoord krijgt (of antwoord krijgt van een andere server),  blijft hij om een renewal vragen tot dat de lease verlopen endan zal  het ip adres gedropt worden. Als je dan opnieuw verkeer gaat genereren zal de dchp client geen renew request doen maar om een nieuw adres vragen. Wellicht gaat het mis met de dhcp lease op vlan4? Dat zou je ook prima moeten kunnen terug zien met tcpdump.

[Xilv3r]

Wat je nog zou kunnen proberen is via entware icmpproxy installeren (opkg install icmpproxy). Dan uit /opt/bin igmpproxy starten en eens kijken of die het wel doet?

 

je kan met tcpdump -i vlan4 > /pad naar usbstick/tcpdump.log de packets volgen en in een file schrijven. Dan kan je zien wat er gebeurt als je tv er mee ophoudt.

Hi Wiz,

 

Oh dit wist ik niet, ik ga dit proberen en zal terug koppeling geven.

Punt is wel ik gebruik wel optware voor nettools en wat ik tot nu toe heb kunnen zien kan je ze niet beiden gebruiken.

 

In entware kan ik niet zo snel vinden wat ik zou kunnen gebruiken ter vervangen van net-tools, het lijkt er wel op dat Merlin build iproute2 ondersteund wellicht dat dat een optie is (ben er niet zo in thuis)

Maar ik ga ervan uit dat deze regel: 

#static route to media portal
/opt/sbin/route add -net 185.6.48.0/26 gw 10.10.56.1

Vervangen kan worden door:

#static route to media portal
ip route add 185.6.48.0/26 via 10.10.56.1 vlan4

Als dit kan, zou net-tools niet nodig zijn en dan kan entware gewoon gebruikt worden.

Met vriendelijke groet,

 

Xil

[wiz]

ip route zou dan inderdaad moeten werken. Het is of de igmpproxy, of wellicht de dhcp op vlan4 die het probleem veroorzaakt denk ik. Irritant is het wel, en jammer ook omdat je nu twee apparaten gebruikt terwijl dat natuurlijk ook door de asus alleen zou moeten kunnen werken.