sorthull Skrevet 10. februar 2021 Del Skrevet 10. februar 2021 9 minutes ago, mobile999 said: Har du testet å pinge twe'n fra en enhet med native 192.168.20.* adresse? Testet det nå ved å koble til laptop på samme vlan og pinge (fra 192.168.20.3), fungerer ikke, dessverre. Virker som om T-WE'en enten har en egen brannmur eller fjernet støtte for dette (svare på icmp-kall). Lenke til kommentar
mobile999 Skrevet 10. februar 2021 Del Skrevet 10. februar 2021 Har du mulighet til å portscanne twe''n både fra enhet på switch0.20 og switch0.1 for å sammenligne.? Lenke til kommentar
sorthull Skrevet 10. februar 2021 Del Skrevet 10. februar 2021 (endret) 59 minutes ago, mobile999 said: Har du mulighet til å portscanne twe''n både fra enhet på switch0.20 og switch0.1 for å sammenligne.? Selvsagt. Koblet til 192.168.20.x: sudo nmap -sU -sT -p- 192.168.20.2 Starting Nmap 7.80 ( https://nmap.org ) at 2021-02-10 15:14 CET Stats: 0:00:53 elapsed; 0 hosts completed (1 up), 1 undergoing UDP Scan UDP Scan Timing: About 32.94% done; ETC: 15:16 (0:01:50 remaining) Nmap scan report for 192.168.20.2 Host is up (0.00066s latency). Not shown: 65531 filtered ports, 65530 open|filtered ports PORT STATE SERVICE 8080/tcp open http-proxy 8081/tcp closed blackice-icecap 8082/tcp closed blackice-alerts 9080/tcp closed glrpc 5013/udp closed fmpro-v6 5014/udp closed onpsocket 5015/udp closed unknown 5021/udp closed zenginkyo-2 5022/udp closed mice Koblet til 192.168.1.x: sudo nmap -sU -sT -p- 192.168.20.2 Starting Nmap 7.80 ( https://nmap.org ) at 2021-02-10 15:22 CET Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn Nmap done: 1 IP address (0 hosts up) scanned in 3.13 second Legger til -Pn og får: (oppdaterer når den er ferdig, holdt på en stund .. går en tur ut og handler i mellomtiden, haha). E: kom visst statusoppdatering hvis man trykket på piltast, ferdig om 3t og 30min sier den 😮 Endret 10. februar 2021 av sorthull Lenke til kommentar
mobile999 Skrevet 10. februar 2021 Del Skrevet 10. februar 2021 For meg så betyr det du allerede har postet at noe ikke fungerer som tiltenkt. Økte telleren på nat masquerade? Lenke til kommentar
sorthull Skrevet 10. februar 2021 Del Skrevet 10. februar 2021 (endret) 11 minutes ago, mobile999 said: For meg så betyr det du allerede har postet at noe ikke fungerer som tiltenkt. Økte telleren på nat masquerade? Jepp, er nesten oppe i halvparten av antall tilfellere som regelen for wan eth0 masquerade som har gått siden routeren ble satt opp, så virker som at nat masquerade fungerer som den skal i alle fall. Mon tro hva som ikke fungerer som tiltenkt. Det er så og si identiske regler på T-WE vlan'et og IoT vlan'et jeg har, og med enheter på IoT-vlanet fungerer det helt fint å pinge og alt mulig rart. Eneste forskjellen i brannmuren på de to er vel at jeg per nå har åpnet opp for enda mer på T-WE vlan'et. Meget frustrerende opplegg, dette her. Endret 10. februar 2021 av sorthull Lenke til kommentar
mobile999 Skrevet 10. februar 2021 Del Skrevet 10. februar 2021 sorthull skrev (8 minutter siden): Mon tro hva som ikke fungerer som tiltenkt. Det er så og si identiske regler på T-WE vlan'et og IoT vlan'et jeg har, og med enheter på IoT-vlanet fungerer det helt fint å pinge og alt mulig rart. Telenor har sørget for at T-we'n ikke skal kommunisere med enheter som ikke er på "hjemmenettverket" (samme subnett/vlan). Man må derfor lure boksen til å tro at enhetene er på samme subnett/vlan. Jeg er nesten tom for ideer i øyeblikket. Det eneste jeg kan tenke meg er å teste et annet oppsett der du kan bruke eth1.20 i nat masquerade regelen som jeg foreslo for å se om det gjør noe forskjell. Du får vurdere om du ønsker å teste et slik type oppsett. Lenke til kommentar
sorthull Skrevet 10. februar 2021 Del Skrevet 10. februar 2021 1 hour ago, mobile999 said: Telenor har sørget for at T-we'n ikke skal kommunisere med enheter som ikke er på "hjemmenettverket" (samme subnett/vlan). Man må derfor lure boksen til å tro at enhetene er på samme subnett/vlan. Jeg er nesten tom for ideer i øyeblikket. Det eneste jeg kan tenke meg er å teste et annet oppsett der du kan bruke eth1.20 i nat masquerade regelen som jeg foreslo for å se om det gjør noe forskjell. Du får vurdere om du ønsker å teste et slik type oppsett. Du har nok rett her. Tenker jeg lander på at jeg lar det være, resten av oppsettet fungerer som jeg ønsker, og jeg har jo alltids muligheten til å caste til Chromecast'en som står i TV'en, så det hele var jo mer et prosjekt for å se om det gikk an å få dette til. Og det går jo sikkert på et eller annet finurlig vis, men akkurat nå merker jeg at det har gått nok tid på dette. Uansett takk for alle innspill, har satt pris på tilbakemeldinger da nettverk ikke er det jeg kan aller mest om i utgangspunktet. Lenke til kommentar
TH123 Skrevet 4. april 2021 Del Skrevet 4. april 2021 Hei, har nå kommet til det punktet at jeg har "sett meg blind". Jeg klarer ikke finne ut hvor jeg har konfigurert feil. Opplever at TV-sendingen kutter etter noen minutter, andre ganger kan det vare flere 10-minutter før den kutter. Alt tyder på IGMP scriptet, men jeg klarer ikke finne feilen. Noen av dere som klarer å pinpointe feilen hos meg? Her er beskrivelse av mitt setup/config. Ønsker da at alle enheter er på LAN1 slik at jeg får alt på samme nett. Hvis ikke må jeg ha dobbelt sett med kabler for NAS aksess mm. Har fulgt oppskrift fra ubnt sitt forum, blir som følger: Laget gruppe i brannmuren. IP adresser for IPTV - "IPTV Source" Regler brannmur IPv4 WAN IN Lage regel for å akseptere traffikk fra Telenor sine servere inn i nettverk. WAN LOCAL Lage regel for å akseptere IGMP traffikk internt Json script legges på Cloudkey Mappen: /srv/unifi/data/sites/default ( ser at noen opplyser sitenavn, jeg har bare "default" når jeg sjekker. Scriptet ser da slik ut: { "protocols": { "igmp-proxy": { "interface": { "eth0": { "alt-subnet": [ "0.0.0.0/0" ], "role": "upstream", "threshold": "1" }, "eth1": { "alt-subnet": [ "192.168.1.0/24" ], "role": "downstream", "threshold": "1" } } } } } På USG-3P så er ETH0 =WAN ETH1= LAN1 Noen som kan peke på hvor jeg har feilen min? Jeg klarer ikke å finne den 😞 Lenke til kommentar
NULL Skrevet 4. april 2021 Del Skrevet 4. april 2021 Har du satt opp IGMP på svitsjene også? Lenke til kommentar
TH123 Skrevet 4. april 2021 Del Skrevet 4. april 2021 (endret) Hei og takk for svar. Nei, trodde at switcher arvet innstillinger når man aktiverte IGMP på LAN settings? Spørsmålet ditt hjalp uansett, for switchene fra Unifi har jo "Switch Port Profile=All" som default. Settings som skal akseptere IGMP er jo satt for LAN, og da må jo portene hvor TV skal stå på spesifiseres som kun LAN, ikke "all" slik de er som default. Endret "Switch Port Profile" til LAN for porten til den ene dekoderen---> sammenhengende sending i 20 minutter til nå. Satser på at det ikke blir noen brudd på sendingen her. Endret 5. april 2021 av TH123 Lenke til kommentar
sorthull Skrevet 10. april 2021 Del Skrevet 10. april 2021 (endret) @TH123 Ikke sikkert det er noe du bryr deg om, men poster allikevel ettersom det kan være greit å være klar over. Siden Flex-mini ikke støtter IGMP snooping (se tidligere post fra ubn-ansatt i samme tråd som lenken) vil alle portene bli floodet med IPTV-trafikk. Hvis man ønsker å unngå dette må IPTV på eget VLAN - og da vil kun de portene på Flex-minien som er tagget med IPTV-VLANet bli floodet. https://community.ui.com/questions/Is-IGMP-Snooping-going-to-be-supported-on-FLEX-MINI/0c05a803-9f14-4981-b255-fa7c1fba1445#answer/849642c5-6695-42d2-a012-5c2299014c33 Endret 10. april 2021 av sorthull 1 Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå