Windows Media Server su diverse lan

[Caterpillar_WRT]

Scenario:
- rete principale con router adsl e server di contenuti multimediali (windows media server dlna) ip 192.168.1.x
- diverse sottoreti collegate tramite router con nat e dhcp (quindi indirizzi ip diversi dalla rete principale) 192.168.x.x

Il problema è questo:
- da quello che ho letto, wms distribuisce contenuti solo in lan, quindi immagino significhi che è visibile solo nella stessa classe di ip (192.168.1.x)
- come faccio a mettere in comunicazione le sottoreti dietro router con il media server?

Tentativi:
- ho provato a creare una route di collegamento tra il server ed i client dietro router, ma non funge

note:
- ovviamente devo mantenere le sottoreti su classi ip diverse in modo che non si "condividano" l'impossibile"
- il router adsl principale è un DrayTek 2710Vn che fa anche il caffè ma che, secondo me, ha qualche problema con l'ip bind (se qualcuno lo conosce, mi spiego meglio)

[Il Bruco]

Facendo un PING da un PC appartenente alla sottorete 192.168.X.X verso l'IP di un PC appartenente alla sottorete 192.168.1.X , che cosa ottieni come risposta?

[pigi2pigi]

Non so che route hai provato e dove ma che io sappia DLNA richiede UPnP e multicast e serve un router IGMP, l'unica limitazione del DLNA è che i device non possono comunicare se distano più di 4 hop e solo su lan con indirizzi privati.
La cosa più semplice è mettere una seconda/terza scheda di rete al server e collegarlo alla lan2/3

Oppure togliere il secondo router e mettere un firewall con le regole che ti pare

[Caterpillar_WRT]

I router sono TP-Link.
Uno è il WR1043ND:
IGMP abilitato
uPnP abilitato
RTSP ALG abilitato (dovrebbe essere il multicasting)

Uno è il WDR4300:
IGMP abilitato
uPnP abilitato
RTSP ALG abilitato (dovrebbe essere il multicasting)
ISP ALG abilitato (come sopra)

La route che ho provato era:
- lato lan tutti gli ip del range dhcp (192.168.2.x)
- porte tcp-ip/udp 1-65535
- lato wan ip del media server (192.168.1.x)

In questo momento non posso provare il ping dal client al server.
Dal server al client mi dà richiesta scaduta.

p.s.: sapete per caso perchè continuo ad avere alcuni client che non mollano l'ip pur essendo impostati in automatico? Ovviamente ho un solo server dhcp e non ho ip assegnati dal router, o meglio, prima li avevo, adesso li ho cancellati tutti e disabilitato l'ip bind.

[pigi2pigi]

I router sono TP-Link.
Uno è il WR1043ND:
IGMP abilitato
uPnP abilitato
RTSP ALG abilitato (dovrebbe essere il multicasting)

Uno è il WDR4300:
IGMP abilitato
uPnP abilitato
RTSP ALG abilitato (dovrebbe essere il multicasting)
ISP ALG abilitato (come sopra)

La route che ho provato era:
- lato lan tutti gli ip del range dhcp (192.168.2.x)
- porte tcp-ip/udp 1-65535
- lato wan ip del media server (192.168.1.x)

In questo momento non posso provare il ping dal client al server.
Dal server al client mi dà richiesta scaduta.

p.s.: sapete per caso perchè continuo ad avere alcuni client che non mollano l'ip pur essendo impostati in automatico? Ovviamente ho un solo server dhcp e non ho ip assegnati dal router, o meglio, prima li avevo, adesso li ho cancellati tutti e disabilitato l'ip bind.

Il ping per funzionare richiede che conosca sia la route da pc1 a pc2 ma anche da pc2 a pc1

Se scrivevi la route capivo di più, così non ho capito cosa hai messo, e il cenno alle porte mi ha ucciso definitivamente, comunque

supponendo che il router2 sia wan 192.168.1.102 e lan 192.168.2.1
supponendo che il router3 sia wan 192.168.1.103 e lan 192.168.3.1

sui pc della 192.168.2.0 (che probabilmente hanno come gateway il 192.168.2.1 non servono route per i pc della rete 1, già la hanno (quella del default gateway) e lo stesso vale per la rete3.

su tutti i pc della 192.168.1.0 che vuoi vedano e vengano visti dai pc della 192.168.2.0 e della 182.168.3.0 devi mettere la route
192.168.2.0 255.255.255.0 gw 192.168.1.102 dev eth0
e analogamente per la rete3
192.168.3.0 255.255.255.0 gw 192.168.1.103 dev eth0
(lla route va scritta con la sintassi richiesta dal SO)

Se vuoi che i pc della rete 2 vedano i pc ella rete3 e viceversa allora bisogna aggiugere 1 route su entrami i router2 e 3, ma questa mi sembra fosse una cosa che non vuoi

Nel dhcp completi c'è un parametro che dice per quanto tempo deve riservare lo stesso indirizzo, di solito nei router non è modificabile, se poi hai un pc fisso e lo cambi in dhcp, se il router lo ha in arp-cache, anche in quel caso, se rientra nel suo range, gli rida lo stesso indirizzo

[Caterpillar_WRT]

Ok, grazie.
Praticamente devo creare la route sul pc con il media server.

Per quanto riguarda il problema del dhcp, parto dall'inizio.

In origine la rete era tutta gestita dal DrayTek 2710Vn che distribuiva gli ip:
- fissi fino al 30 (i nodi per le "sottoreti" - access point e router e modem wireless impostati come ap)
- dhcp dal 31 al 200 con ip bind per circa la metà di questi ai quali assegnavo la priorità e la banda

Al di là del fatto che le risorse condivise lo erano per tutti, funzionava bene, poi ho cominciato ad avere sporadici problemi, nodi o client che sparivano. Ho aggiornato il DrayTek all'ultimo firmware e i problemi sono aumentati fino a non riuscire a raggiungere neanche il router principale. Non sono riuscito a trovare informazioni chiare sul modo in cui il DrayTek gestisce ip fissi, assegnati e in dhcp automatico, quindi non capisco se sbaglio nelle impostazioni. Attualmente ho cancellato tutti gli ip assegnati ed ho attivato solo il dhcp automatico con lease 1800 sec. (mezz'ora) e funziona, ma alcuni client continuano a mantenere il vecchio ip assegnato, anche se cancello l'arp cache.
Inoltre non riesco a disabilitare l'assegnazione ip sul DrayTek.
I casi sono 2, o il DrayTek da i numeri, oppure windows 7 mi prende in giro ed io non vedo i dati in realtime ma da una qualche cache, sto usando firefox per accedere al router.

p.s. arp -a lanciato dal media server mi da, insieme ai 192.168.1.x, alcuni ip di cui non conosco l'origine:
224.0.0.2
224.0.0.22
224.0.0.252
233.89.188.1
239.255.255.250

[pigi2pigi]

Approfitto dell'ultima domanda. Nei pc coinvolti in multicast fra subnet, ci deve essere una route
224.0.0.0 netmask 240.0.0.0 dev eth0 (o ip-proprio sempre a seconda della sintassi del sistema)

perchè il multicast utilizza indirizzi da
224.0.0.0 a 239.255.255.255 di questi però alcuni hanno significati/usi particolari


224.0.0.2
224.0.0.22
224.0.0.252

ping 224.0.0.1 Tutti i pc (della stessa subnet) multicast
risponderanno
ping 224.0.0.2 Tutti i router configurati multicast risponderanno
ping 224.0.0.3 Tutti i router PIM
ping 224.0.0.4 Tutti i router DVMRP
ping 224.0.0.5 Tutti i routers OSPF
224.0.0.22 IGMP

Il fatto che sull'arp del mediaserver ci sia 224.0.0.2 vuol dire che i router multicast li ha trovati


233.89.188.1
239.255.255.250
Poi da 224.0.1.0 a 239.255.255.255 sono dinamicamente assegnati ad applicazioni multicast. Di questi gli indirizzi da 232.0.0.0 a 232.255.255.255 sono riservati per Source Specific Multicast;

probabilmente il 239.255.255.250 è il tuo mediaserver

In genere per il lease del dhcp non si scende sotto il giorno (strano che sia in secondi si usa di solito da 1 a 30 giorni)

Per il dhcp è semplice, nell'ambito dello scope (il range che gestisce), si possono anche riservare indirizzi a particolari mac-address, quelli fuori range vanno messi nel pc direttamente

[Caterpillar_WRT]

Approfitto dell'ultima domanda. Nei pc coinvolti in multicast fra subnet, ci deve essere una route
224.0.0.0 netmask 240.0.0.0 dev eth0 (o ip-proprio sempre a seconda della sintassi del sistema)

perchè il multicast utilizza indirizzi da
224.0.0.0 a 239.255.255.255 di questi però alcuni hanno significati/usi particolari



ping 224.0.0.1 Tutti i pc (della stessa subnet) multicast
risponderanno
ping 224.0.0.2 Tutti i router configurati multicast risponderanno
ping 224.0.0.3 Tutti i router PIM
ping 224.0.0.4 Tutti i router DVMRP
ping 224.0.0.5 Tutti i routers OSPF
224.0.0.22 IGMP

Il fatto che sull'arp del mediaserver ci sia 224.0.0.2 vuol dire che i router multicast li ha trovati


E perchè il media server non mi rileva il ricevitore se i router sono multicast e rispondono?


Poi da 224.0.1.0 a 239.255.255.255 sono dinamicamente assegnati ad applicazioni multicast. Di questi gli indirizzi da 232.0.0.0 a 232.255.255.255 sono riservati per Source Specific Multicast;

probabilmente il 239.255.255.250 è il tuo mediaserver

In genere per il lease del dhcp non si scende sotto il giorno (strano che sia in secondi si usa di solito da 1 a 30 giorni)

Per il dhcp è semplice, nell'ambito dello scope (il range che gestisce), si possono anche riservare indirizzi a particolari mac-address, quelli fuori range vanno messi nel pc direttamente

Questo l'ho capito a tentativi, quindi, probabilmente in una delle mie prove, i client "resistenti" hanno ricevuto un lease molto lungo che deve ancora scadere?
Se, temporaneamente, modifico il range dhcp il 192.168.5.x, si reimposterebbe il lease per tutti i client in modo da poter, in seguito, ristrutturare l'assegnazione definitiva degli ip senza conflitti?

Grazie per le risposte, sei molto chiaro ed esaustivo.:)
Chiedo scusa per il discorso della route che ho creato ... non era una route, ho aperto le porte al firewall ... :rolleyes:

[pigi2pigi]

E perchè il media server non mi rileva il ricevitore se i router sono multicast e rispondono? Probabilmente manca la route
224.0.0.0 netmask 240.0.0.0 dev eth0 (o ip-proprio sempre a seconda della sintassi del sistema) sul mediaserver e i pc delle subnet 2 3

però andando per gradi, si potrebbe testare la comunicazione multicast attraverso i router.
Installi iperf disponibile sia per windows che per linux, metti la route detta prima nelle macchine coinvolte nella prova che stanno su sottoreti diverse e poi su una macchina (che sarà il server di questa prova) lanci
iperf -s -u -B 224.1.1.1 -i 1
e si metterà in ascolto sulla porta 5001 nel gruppo multicast 224.1.1.1

su un altro pc prima nella stessa, rete per scrupolo, e poi su una sottorete lanci
iperf -c 224.1.1.1 -u -T 32 -t 3 -i 1 che tenterà la connessione con 224.1.1.1:5001, e vedrai su entrambi comparire dati sulla comunicazione

Se riusciamo a far funzionare il multicast poi si può scendere nello specifico di come funziona il DLNA, perchè non c'è solo l'aspetto comunicazione.

Per il dhcp a fronte di lease lunghi se cambi scope al dhcp server spesso l'unica è dare un release/renew sui client, il reboot non basta, probabilmente, cambiando scope, release/renew sul client e poi rimettendo lo scope giusto release/renew, si dovrebbe risolvere (non ti preoccupare tutti hanno combattuto con indirizzi dhcp che non ne volevano sapere di cambiare, perchè c'e l'arp di entrambi che ha il vecchiio indirizzo e poi da una parte il dhcp server e dall'altra il dhcp client e un reboot pulisce la cache ma il dhcp client per prima cosa chiede il vecchio indirizzo)

[Caterpillar_WRT]

La 224.0.0.0 è già attiva perchè risulta dal "route print".
Non ho pc client disponibili dietro i router, ma solo tv.
Devo approntare un router + pc all'uopo.
Intanto provo a dare ip fisso ad una tv dietro router e ad impostare la route sul server.
Per i client con gli ip "testardi", devo intervenire direttamente su di loro.

p.s. impostata route sul server:
192.168.4.0 mask 255.255.255.0 192.168.1.11 metric 3 if 1
192.168.4.0 dovrebbe collegare tutti gli ip a valle del router
192.168.1.11 è l'ip del router

Adesso aspetto che rientri il proprietario per controllare se la tv vede il server.

[pigi2pigi]

p.s. impostata route sul server:
192.168.4.0 mask 255.255.255.0 192.168.1.11 metric 3 if 1
192.168.4.0 dovrebbe collegare tutti gli ip a valle del router
192.168.1.11 è l'ip del router


se 192.168.1.11 è (come penso) il router che connette la 192.168.4.0/24 OK

Questo però è solo un discorso di network (tradizionale unicast) in quanto il mediaserver non usa la 192 ma la 224 e il routing di quella è gestito in automatico dal multicast

[Caterpillar_WRT]

se 192.168.1.11 è (come penso) il router che connette la 192.168.4.0/24 OK

Si.