22.04.2010 18:18:45
Elioni Digi-Tv ainult Linuxi-kastiga
Oman korrusmaja baasil DigiTV ühendust (1 Mbit). Kuna ei tahtnud 2-a lepinguga end siduda, viisin testperioodi jooksul Elioni ruuteri ja digiboksi tagasi, sest huvitas ainult internet. Nüüd oleks huvitatud vahetevahel digitv salvestamisest. Pmts siis võrk mul järgmine:
1) tuppa tuleb cat5 kaabel, mis jookseb Linuxi masinasse (Ubuntu 8.04.4 Server, graafikata) eth1 võrgukaarti
2) Linuxis tehtud NAT eth0 kaarti, millest läheb juhe switci.
3) läbi switchi võtab neti windowsi masin
Pmts nett ja digitv salvestamine (käsurealt linuxi masinas) mõlemad töötavad. Aga mitte samal ajal. Kuna Elioni DTV istub vlan neljandas, tegin Digitv jaoks interfeisi eth1.4 mis näeb välja selline:
eth1.4 Link encap:Ethernet HWaddr 00:40:95:*:*:*
inet addr:10.248.*.* Bcast:10.248.255.255 Mask:255.255.192.0
inet6 addr: *::*:*:*:*/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
ja välisühendus tuleb siis lihtsalt eth1-st:
eth1 Link encap:Ethernet HWaddr 00:40:95:*:*:*
inet addr:88.196.*.* Bcast:88.196.109.255 Mask:255.255.254.0
inet6 addr: *::*:*:*:*/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Olgu mainitud, et nii eth1 kui eth1.4 on sama MAC-aadressiga, sest kui need juhtuvad erinema, ei tõmmata eth1.4 dhcp-ga üles. Aga korraga töötab siiski ainult üks ühendus. Kas istun netis või salvestan Digitv. Aktiivne on see võrk, kummale viimati DHCP küsiti. Kui tahan jälle välisühendust tagasi, pean eth1.4 maha tapma.
Oskab keegi aidata, mis tuleks ümber teha? Proovisin välisühenduse suruda ka vlan 1 peale (eth1.1), aga sealt ei antud ühtegi aadressi. Saan ma aru, et tavaline internet on üldse ilma vlan tagita? Kas probleem võib tulla sellest, et kast ei tea, millised paketid kuhu interfeissi suunata? Mingi ruutimise probleem sisuliselt?
vahepeal sai ka leiutatud sama asja ja siis proovisin mac vlani, rohkem infot >> http://www.candelatech.com/~greear/vlan.html
et eraldi vlan interface oma mac aadressiga, siis kui ruuteris mac reeglid paigas peaks oskama suunata õigesse vlanni ja dhcpcd õige metric siis peaks töötama.
vlc-s kasutada siis --mcast võtit,
aga praktikas krt ei töötanud, tõenäoliselt mingi eripära SpeedTouchi firmwares talveperioodil. lõppes see sellega, et kõik asjad lendasid ühte vlani ja mingi ime läbi töötab nüüd tv ja nett igast asendist korraga, miks või kuidas ära küsi, ei tea, aga töötab ja mina rohkem ei näpi. seadmeks ST546v6 FW7.4.3.2
korrusmaja puhul asjad natuke teisiti ka muidugi
ei maleta hetkel peas, keegi jagas 100m nett laiali. kala oli selles, et peabki valis interface-il blokida sissevxrk(192.168.0.0/32 näiteks) mis on su linux ruuteri taga (LAN), sest vahepeal kuidagi saavad vxrra mac-id (lanist) wan interfaci, yhendus muidugi kukub selletaga.
Täiendan natuke teemat. Kohendasin võrku, nüüd siis võiks pilt näha välja järgmine:
Elioni CAT5 kaabel läheb esimesse switchi, millest 2 kaablit Ubuntu kasti, interface eth1 (internet) ja eth2 (IPTV). Kolmas võrgukaart eth0 on sisevõrgu NATi jaoks Windowsi masinatele. Nüüd ifconfig näeb mul välja järgmine:
Internet ja IPTV on viidud eraldi võrgukaartidele, nüüd on võimalik kasutada erinevaid MAC aadresse. eth2 peale tehtud vlan ID 4, mis suudab siis võtta vastu IPTV taggitud ethernet pakette. Mõlemad võrgud (internet ja IPTV) tõmmatakse üles DHCP-ga, peale aadresside küsimist lisatakse ruutingutabelisse sealt saadud gateway. Probleem on selles, et nüüd on võrke 2 ning lisatakse tabelisse 2 default gatewayd:
Sellest tekivadki probleemid. Kahte default gatewayd ei tohiks olla, aga äkki oskab keegi anda soovitusi, kuidas ruutingutabel ümber korraldada nii, et
1) default gatewayks jätaks interneti
2) IPTV IP aadressidele saadetud paketid (tavaliselt algavad 10.X.X.X) läbiks teist, IPTV jaoks mõeldud gatewayd 10.248.192.1
hea küss.. kolmas kord juba loen teemat ja ei tule midagi meelde. vaid, on soov millelgi pärast linuxi serveri taga majutada L2 switch mis suudab tagid ja teha 2 vlan-id sinu võrgus, kus vlan1 nt. internet vlan2 nat-tud iptv. Muidu hea eksperement, teoreetiliselt kui väline interface mis vaatab elioni poole ja kloonitud MACiga, siis on hää küsimus, kas saaks korraga rohkem kui 1xkanal käima panna. =) ei mul vajadust selles pole, kuna enda digitv 50+ kanalid ilusti funkavad, aga neljaks korteriks 100mbps, isegi mitte garanteeritud kiirusega...
Ma hakkan just sama asja leiutama. Kas tõesti ei saa WAN poolepeal 1 võrkariga hakkama. Väga raiskamine tundub võttas asjad sisse eraldi võrkaritelt.
Saab küll....
Vähemalt kui ruuter vahelt välja visata üldse. (muidu pead sellele, oma masina poolse ETH pordi "trunk"`i konfima)
[Märksõnadeks: tagged & untagged vLan]
Debianil on selleks puhuks "pakk" vlan abiks, vaikimisi seda ei installita...seda vajad mõlemal juhul...
(sama pakk siis ka *buntudel)
Ehk täpsustad, mis distro kasutusel? _________________ ...life is random...so am I...
So, there is a fan. Time to grab your sh*t, gentlemen!
Ikka jah ruuteri tahan välja visata. See siin ikka paneb käpa maha ja teeb igast muid trikke.
Mul erinevat rauda, aga ilmselt vist mingi intel atom peab võtma, et 100Mbit jõuas ruutida/nattida.
Keegi teab kui palju 5x86 133Mhz jõuab Nat'da?
Rohkem RHga tuttav, et tahaks centosi peale visata. Kui mingi väiksema ruuteriboxi peale läheb siis openwrt.
Pmts saab tõesti ka ainult ühe välise interface-ga hakkama, aga mul miskipärast annab DHCP digitv vlanile aadressi ainult siis, kui vlani ja füüsilise interfeissi MAC aadressid ühtivad (ei tea, milles on kala). Ehk siis, eth1 näiteks tuleb internet (untagged) ja eth1 peale konfid vlan id 4. Mul on miski ruutimistabeli taga veel asi, pole täpselt välja jaganud, aga usun et ei tohiks keeruline olla.
daemon, mina täiendasin just enda freebsd baasil ruuterit (p2@300, 128M) selliseks:
Masinal on 3 võrkarit.
rl0 saab digitv jaoks ruuteri neljandast pordist dhcpga seaded.
rl1 on sisevõrk.
tun0 on pppoe virtuaalkaart, mille liiklus käib üle vr0. speedtouch on konfitud pppoe jaoks.
Vlanidega pole seni jamanud, kuigi elegantsuse mõttes oleks soov üks kaart vähemaga hakkama saada.
rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1492
options=8<VLAN_MTU>
ether 00:10:a7:07:c9:fc
inet 10.248.162.110 netmask 0xffffc000 broadcast 10.248.191.255
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
rl1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1492
options=8<VLAN_MTU>
ether 00:30:4f:28:00:25
inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
vr0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1492
options=8<VLAN_MTU>
ether 00:50:ba:cb:63:9a
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1492
inet 88.196.213.100 --> 80.235.56.1 netmask 0xffffffff
Opened by PID 407
Ruutingud töötavad automaatselt, mulle tundub et iptv dhcp ei anna liigseid route. Iseenesest peaks enamasti dhcp klientidel olema option, et mitte küsida/rakendada dhcp pakutavaid route.
Üritasin ka jupp aega multicast routingut tööle saada et sisevõrgust digitv näeks. Ei hakkinud läbi. Mingi hetk tekkis tunne et kasutusel on dense multicast, mis pole eriti toetatud. Siis leidsin sellise asja nagu udpxy ja telepilt masinas:) Niipalju veel, et iga tulemüür ei pruugi by default läbi lubada tcp option flagiga pakette.
Jama on praegu selline et kahte erinevat kanalit vaadates hakkab pilt hakkima. Sügan kukalt, et kus mul pudelikael on... _________________ Mida Ott ei õpi, seda Egon ei tea.
daemon, mina täiendasin just enda freebsd baasil ruuterit (p2@300, 128M) selliseks:
Masinal on 3 võrkarit.
rl0 saab digitv jaoks ruuteri neljandast pordist dhcpga seaded.
rl1 on sisevõrk.
tun0 on pppoe virtuaalkaart, mille liiklus käib üle vr0. speedtouch on konfitud pppoe jaoks.
Vlanidega pole seni jamanud, kuigi elegantsuse mõttes oleks soov üks kaart vähemaga hakkama saada.
rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1492
options=8<VLAN_MTU>
ether 00:10:a7:07:c9:fc
inet 10.248.162.110 netmask 0xffffc000 broadcast 10.248.191.255
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
rl1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1492
options=8<VLAN_MTU>
ether 00:30:4f:28:00:25
inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
vr0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1492
options=8<VLAN_MTU>
ether 00:50:ba:cb:63:9a
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1492
inet 88.196.213.100 --> 80.235.56.1 netmask 0xffffffff
Opened by PID 407
Ruutingud töötavad automaatselt, mulle tundub et iptv dhcp ei anna liigseid route. Iseenesest peaks enamasti dhcp klientidel olema option, et mitte küsida/rakendada dhcp pakutavaid route.
Üritasin ka jupp aega multicast routingut tööle saada et sisevõrgust digitv näeks. Ei hakkinud läbi. Mingi hetk tekkis tunne et kasutusel on dense multicast, mis pole eriti toetatud. Siis leidsin sellise asja nagu udpxy ja telepilt masinas:) Niipalju veel, et iga tulemüür ei pruugi by default läbi lubada tcp option flagiga pakette.
Jama on praegu selline et kahte erinevat kanalit vaadates hakkab pilt hakkima. Sügan kukalt, et kus mul pudelikael on...
mõnus tuleb ka eksperementeerida sellega Kas pilt tuleb ainult ühe masinasse samalajal või ?
Ruutingud töötavad automaatselt, mulle tundub et iptv dhcp ei anna liigseid route. Iseenesest peaks enamasti dhcp klientidel olema option, et mitte küsida/rakendada dhcp pakutavaid route.
Suhteliselt võõras see FreeBSD ruutingutabel, aga küsiksin järgmist: kas mõne rea oled ka ise tabelisse lisanud või on kõik tekkinud sinna automaatselt läbi DHCP? Näiteks minu Ubuntu Linux lisab iptv ühenduse puhul ainult kaks rida:
Destination Gateway Genmask Flags Metric Ref Use Iface
10.248.192.0 * 255.255.192.0 U 0 0 0 vlan4
default 10.248.192.1 0.0.0.0 UG 100 0 0 vlan4
ja sealt need probleemid tekivad, kuna nii välis- kui dtv ühendus konfivad ennast default gatewayks, mida aga ei saa olla rohkem kui üks. Nüüd sinu tabeli puhul huvitaks mind väga, et mis võrk on 84.50.149.0 ja kus kohast sai sinna selline rida:
84.50.149.0 on mingi digitvga tulev route, ma ei tea miks ta seal on aga asi töötab. pakette pole sinnapoole liikumas näinud.
Lisaks veel, dhcp annab 10.248.128.0/18, aga tabelisse tekib veel ka 10.0.0.0/8. Müstika.
EDIT: praegu tabas, see rida: option classless-routes 24,84,50,149,10,248,128,1,8,10,10,248,128,1;
kui need numbrid lahti kirjutada siis näeb pakutavaid route küll:
24/84.59.149.0 -> 10.248.128.1,
8/10.0.0.0 -> 10.248.128.1
Arvutist teleka vaatamiseks ei paista neid route vaja olevat. Äkki on mingi digiboxi värk? Huvitav on, et terve /24 subnet on mööda ruuditud ja kogu 10.0.0.0/8 tahetakse ka endale hoida? _________________ Mida Ott ei õpi, seda Egon ei tea.
84.50.149.0 on mingi digitvga tulev route, ma ei tea miks ta seal on aga asi töötab. pakette pole sinnapoole liikumas näinud.
Lisaks veel, dhcp annab 10.248.128.0/18, aga tabelisse tekib veel ka 10.0.0.0/8. Müstika.
EDIT: praegu tabas, see rida: option classless-routes 24,84,50,149,10,248,128,1,8,10,10,248,128,1;
kui need numbrid lahti kirjutada siis näeb pakutavaid route küll:
24/84.59.149.0 -> 10.248.128.1,
8/10.0.0.0 -> 10.248.128.1
Arvutist teleka vaatamiseks ei paista neid route vaja olevat. Äkki on mingi digiboxi värk? Huvitav on, et terve /24 subnet on mööda ruuditud ja kogu 10.0.0.0/8 tahetakse ka endale hoida?
Mina pidin küll SuSE linuxis vaatamiseks käsitsi mõned route-d juurde tegema:
224.0.0.0/4
10.0.0.0/8
84.50.255.0/24
224.0.0.0 on multicast, 10.0.0.0 on vajalik selleks, et 10.0.0.2 pealt saadetavaid striime vastu võtta (see vajadus tekkis alates umbes SuSE 10.2-st).
84.50.255.80 pealt tehakse IGMP grupi päringuid. Kui neile ei vasta, siis lõpeb umbes minuti pärast striim ära.
Kogu tabel on selline:
Destination Gateway Genmask Flags Metric Ref Use Iface
84.50.149.0 10.252.0.1 255.255.255.0 UG 0 0 0 eth1
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
84.50.255.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
10.252.0.0 0.0.0.0 255.255.192.0 U 0 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
224.0.0.0 0.0.0.0 240.0.0.0 U 0 0 0 eth1
0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 eth0
84.50.149.0 on mingi digitvga tulev route, ma ei tea miks ta seal on aga asi töötab. pakette pole sinnapoole liikumas näinud.
Lisaks veel, dhcp annab 10.248.128.0/18, aga tabelisse tekib veel ka 10.0.0.0/8. Müstika.
EDIT: praegu tabas, see rida: option classless-routes 24,84,50,149,10,248,128,1,8,10,10,248,128,1;
kui need numbrid lahti kirjutada siis näeb pakutavaid route küll:
24/84.59.149.0 -> 10.248.128.1,
8/10.0.0.0 -> 10.248.128.1
Arvutist teleka vaatamiseks ei paista neid route vaja olevat. Äkki on mingi digiboxi värk? Huvitav on, et terve /24 subnet on mööda ruuditud ja kogu 10.0.0.0/8 tahetakse ka endale hoida?
tänud vastuse pärast =) siis isegi võib midagi sellega ettevõtta
raud on siis p2MMX 300MHz 96MB rammiga. 2x pci 3com 100M võrkkarid + 1 onboard 100M. Masin on vist Compaq Deskpro 4000 kui ma ei eksi. Peale panin Centos 5.4. lisaks paigaldasin vconfig ja bridge-utils paketid. vconfig on vlan'ide tegemiseks (ifup ifdown kasutavad). bridge utils on kah kasutuses nende poolt. Ühendusena on elioni 100M korrusmaja nett. eth0 on siis välis kaabli otsas. eth1 on lan ja eth2 otsas on digibox. Tarkvara konf suht lihtne. eth0 on dhcp peal, eth1 on static ip'ga, dhcp server pandud eth1 peale jagama sisse ip'sid. eth2 on ilma ip'ta, st BOOTPROTO=none. eth0 peale on thetud vlan id'ga 4 ja samuti BOOTPROTO=none. mingit ip'd. eth2 ja eth0.4 on pandud bridge ja bridge kah BOOTPROTO=none, justkui läbipaistvad. digibox saab kenasti ip ja toimib, HD kanalid kah probleemideta. eth1 tulevatele asjadele teed SNAT'i eth0 peale ja nett on olemas. kui IPTABLES'is forward chain panna default DROP'i peale siis tuleb lubada liiklus bridge'st bridgesse (jah, samast devicest samasse device'i(iptables -i bridge -o bridge -j ACCEPT)) muidu digi liiklus dropitakse, jälgi tcpdumpiga. mingit multicasti route kuskil pole kuna linux digi võrgu IP'd ei saa ega selles pmst ei osale, lihtsalt forwardib edasi vlan4 eth2'te. linuxi sees saab juba seda bridge liiklust suunata siis kuhu vaja, kasvõi samma lan võrku. windowsi masinale teine ip juurde ja route sisse et see digitv võrk asub läbi teise GW ja peaks lippama, kui on soovi kõik yhele masinale peale upitada. birdged ja vlan'id on tehtud ifcfg failidega, ylilihtne, netis palju juhendeid, ise tulevad networkiga üles ja lähevad maha kui vaja, eraldi skripte ja junne pole vaja treida, vlan'i ja bridge konf paika, service network restart ja kõik pysti. mis load'i puudutab siis ega masinast palju järgi ei jäänud. load oli mingi 0.8-0.9. selles 70% on software interruptid ja siis natuke sys'i userit ja hi'd. aga võrk oli alati 100% 100M ja vajakka ei jäänud masinast.
Kui on soovi konfi saada või mingit muid kysimusi siis andke teada.
Annan teema alustajana ka oma vahepealsetest (edu)sammudest teada! Kõigepealt peab mainima, et väga suur abi oli kasutajate loox ja kaabakas välja toodud route tabelitest, nii et suured tänud! Paistab, et minu Ubuntu 8.04.4 serveris (non-GUI) sisalduv dhclient v3.0.6 ei oska DHCP serverilt küsida classless route ning ei leidnud kusagilt ka kinnitust, et ta seda teha peaks oskama. Seega tuli lisada käsitsi routed, millele on viidanud ka mõlemad kasutajad. Minu uus route tabel näeb välja selline:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
84.50.149.0 10.248.192.1 255.255.255.0 UG 0 0 0 vlan4
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
84.50.255.0 0.0.0.0 255.255.255.0 U 0 0 0 vlan4
88.196.108.0 0.0.0.0 255.255.254.0 U 0 0 0 eth1
10.248.192.0 0.0.0.0 255.255.192.0 U 0 0 0 vlan4
10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 vlan4
224.0.0.0 0.0.0.0 240.0.0.0 U 0 0 0 vlan4
0.0.0.0 88.196.108.1 0.0.0.0 UG 100 0 0 eth1
Interfaced olid mul siis sellises järjestuses: eth0 (sise), eth1 (internet) ja vlan4 (digi-tv). Praeguses konfis täidab süsteem minu soovid: saan digitv kanaleid salvestada otse linuxi arvutisse, ilma et interneti välisühendus vahepeal maha kukuks. Ehk siis töötab nii nagu vaja! Digipildi reaalajas vaatamine pole olnudki eesmärgiks, kuigi ehk katsetan nimetatud udpxy selle eesmärgi rahuldamiseks kunagi ära. Nüüd on jäänud ainult see probleem, et peale masina rebooti või kui dhclient küsib iptv poole pealt aadressi, tuleb kõigepealt kustutada route tabelist dhcliendi poolt sinna lisatud default route:
0.0.0.0 10.248.192.1 0.0.0.0 UG 0 0 0 vlan4
ning seejärel lisada teised vajalikud marsruudid:
route add -net 84.50.149.0 gw 10.248.192.1 netmask 255.255.255.0 dev vlan4
route add -net 224.0.0.0 netmask 240.0.0.0 dev vlan4
route add -net 84.50.255.0 netmask 255.255.255.0 dev vlan4
route add -net 10.0.0.0 netmask 255.0.0.0 dev vlan4
Ilmselt tuleb selle jaoks skript kirjutada. Teiseks kavatsen hakata kasutama ajastatud salvestamist vlc-ga, selle teostamiseks võtan ilmselt kasutusele nii skriptid kui crontabi.
Kirjutaks ka siis oma kogemusest.
Endal on ka sisuliselt linuxi põhise ruuteriga tegemist, täpsemalt küll siis openwrt.
Internet tuleb sisse mööda interface'i eth1, sellele on lisatud vconfig'iga vlan id 4 - eth1.4. Mõlemad if-d saavad ip dhcp'ga. Kuna aga esmalt küsitakse dhcp'ga ip eth1-le ja seejärel eth1.4-le, siis oli ka see probleem, et eth1.4 seaded kirjutasid default ruutingu üle, samamoodi ka nimeserverid muutusid 10.0.0.x midagi.
Tegin dhcp action skripti veidi ümber, et selle eth1.4 interface'i puhul saadavaid ruutinguid ja nimeservereid ignoreeritakse. Siis sai tööle mõlemad korraga.
Algul kasutasin multicasti ruutimiseks programmi nimega igmpproxy, mis siis kuulas sisevõrgus, kui keegi näiteks soovis joinida aadressiga 239.3.1.1,
siis igmpproxy saatis eth1.4 kaudu vastava teate edasi ja lisas multicasti ruutingu ning striim jõudis sisevõrku. See lahendus eeldab, et multicasti ruutingu tugi on kernelis olemas.
Hetkel kasutan ka eelmainitud udpxy nimelist lahendust, selle oluline eelis on see, et töötab ka üle wifi normaalselt, multicast üle wifi oli suht ikaldus. udpxy teeb udp streamist http streami, mis toimib oluliselt paremini üle wifi.
Udpxy puhul polnud sisuliselt midagi konfida ka vaja, oli vaja ette anda multicasti source interface (mul siis eth1.4) ja sisevõrgu interface ja port, millel kuulatakse. Vlc's kasutatavad aadressid ka veidi muutusid.
Lisaruutingutega polnud kummagi lahenduse puhul vaja jännata, küll aga pidi igmpproxy puhul see 10.0.0.0/8 võrk olema confis ja aadress 84.50.255.47.
EDIT:
Lisaks oli vaja tulemüüri reeglit 224.0.0.0/4 võrgu kohta igmpproxy puhul.
viimati muutis petskets 07.05.2010 21:46:49, muudetud 2 korda
iptv käimasaamiseks ei ole vaja mingeid müstilise konfe teha. Piisab, kui ruutingutabelis siduda multicast võrk vastava võrguliidesega ja liidesel endal võib suvaline ip aadress olla. Igasugused muud parameetrid on ebavajalikud. _________________ Show someone an MS OS if they've never seen a computer, and see how surprised they are that you turn it off by going to the start button.
route add -net 84.50.149.0 gw 10.248.192.1 netmask 255.255.255.0 dev vlan4
route add -net 224.0.0.0 netmask 240.0.0.0 dev vlan4
route add -net 84.50.255.0 netmask 255.255.255.0 dev vlan4
route add -net 10.0.0.0 netmask 255.0.0.0 dev vlan4
Ilmselt tuleb selle jaoks skript kirjutada. Teiseks kavatsen hakata kasutama ajastatud salvestamist vlc-ga, selle teostamiseks võtan ilmselt kasutusele nii skriptid kui crontabi.
Ajastatud salvestamiseks on at päris mugav. Kirjutad käsureale näiteks
Lõpetamiseks sobivaks ajaks samamoodi anda ette fail sisuga "killall vlc".
Marsruutide tekitamiseks tasub konfiguratsioonifaile ja distros kasutatavaid võrguskripte uurida. SuSE kasutab dhcpcd-d, ja tal on võimalik tekitada fail /etc/sysconfig/network/ifroute-eth1 järgmise sisuga:
Default route tegemise saab dhcp konfis ära keelata. Man soovitab siis igale interfacele oma protsessi koos oma konfiga käima tõmmata.
comcute kirjutas:
iptv käimasaamiseks ei ole vaja mingeid müstilise konfe teha. Piisab, kui ruutingutabelis siduda multicast võrk vastava võrguliidesega ja liidesel endal võib suvaline ip aadress olla. Igasugused muud parameetrid on ebavajalikud.
#Enable linux to accept PING
$IPTABLES -A INPUT -p icmp -j ACCEPT
#do snat so inside clients can access outside
$IPTABLES -t nat -A POSTROUTING -o $EXTIF -j SNAT --to $EXTIP
#what traffic is allowed to be routed out --- limitations go here, like http only.
$IPTABLES -A FORWARD -o $EXTIF -p tcp --dport 445 -j DROP
$IPTABLES -A FORWARD -o $EXTIF -p udp --dport 137 -j DROP
$IPTABLES -A FORWARD -o $EXTIF -p udp --dport 138 -j DROP
$IPTABLES -A FORWARD -o $EXTIF -p tcp --dport 139 -j DROP
$IPTABLES -A FORWARD -s $LANNW -d any/0 -j ACCEPT
#DIGI TV
$IPTABLES -A FORWARD -i brDTV -o brDTV -j ACCEPT
#set default rules to drop except on output chain
$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT ACCEPT
rohkem kiiruga meelde ei tulnud mis konfi vaja veel oleks
# we want the nameserver to appear at a fixed address
host janno-pc-pc {
#next-server marvin.redhat.com;
hardware ethernet 6C:F0:49:02:0B:B5;
fixed-address 192.168.1.201;
}
}
HW:
[root@faith etc]# echo "PROCESSORS:"; cat /proc/cpuinfo | grep "model name"; echo "MEMORY:"; free -m; echo "FREE SPACE:" ;df -h; echo "USB DEVICES:"; dmesg | lsusb | grep "Linksys\|Power" ; echo "PCI DEVICES:" ;lspci | grep Gigabit
PROCESSORS:
model name : Intel(R) Atom(TM) CPU D510 @ 1.66GHz
model name : Intel(R) Atom(TM) CPU D510 @ 1.66GHz
model name : Intel(R) Atom(TM) CPU D510 @ 1.66GHz
model name : Intel(R) Atom(TM) CPU D510 @ 1.66GHz
MEMORY:
total used free shared buffers cached
Mem: 994 62 932 0 0 9
-/+ buffers/cache: 52 941
Swap: 0 0 0
FREE SPACE:
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 3.6G 936M 2.5G 28% /
/dev/sda1 99M 7.2M 87M 8% /boot
tmpfs 498M 0 498M 0% /dev/shm
USB DEVICES:
Bus 001 Device 002: ID 13b1:0018 Linksys USB200M 10/100 Ethernet Adapter
Bus 001 Device 003: ID 3538:0901 Power Quotient International Co., Ltd
PCI DEVICES:
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03)
05:00.0 Ethernet controller: Intel Corporation 82541PI Gigabit Ethernet Controller (rev 05)
Kahjuks ei teinud ka inteli gigait imet - Neti kiiruseks jäi 62MB/s Nagu kirvega raiutud. Mingi minutiks hüppas testimisel veel 68Mbit/s peale. Tundub, et mingi kaabli jama. Koridori kapist proovisin ka. Ikka sama.
Uplink summaarselt umbes-täpselt 20Mbit/s.
sa ei või postitada uusi teemasid siia foorumisse sa ei või vastata selle foorumi teemadele sa ei või muuta oma postitusi selles foorumis sa ei või kustutada oma postitusi selles foorumis sa ei või vastata küsitlustele selles foorumis sa ei saa lisada manuseid selles foorumis sa võid manuseid alla laadida selles foorumis
Hinnavaatlus ei vastuta foorumis tehtud postituste eest.