Freebox Player (Revolution / V6)

  • État Nouveau
  • Pourcentage achevé
    0%
  • Type Évolution
  • Catégorie Entrées/sorties → Réseau
  • Assignée à Personne
  • Système d'exploitation Tous
  • Sévérité Moyenne
  • Priorité Très Basse
  • Basée sur la version 1.0.1
  • Due pour la version Non décidée
  • Échéance Non décidée
  • Votes
  • Privée
Concerne le projet: Freebox Player (Revolution / V6)
Ouverte par JSM - 20/01/2011
Dernière modification par nipo - 30/05/2013

FS#4336 - Une IP fixe pour le Player sans DHCP

Par défaut le FBS a le service DHCP activé.
Si on désactive ce service alors le FBP n’obtient pas d’IP.
Ce qui a pour conséquence une incapacité à sortir sur Internet (navigateur, applications ou services Free).

Par contre la télévision fonctionne car le flux passe par un autre réseau privé.

Il faudrait alors ajouter une option de configuration réseau sur le FBP (IP fixe ou DHCP).
Ainsi qu’afficher le détail de la configuration.

janus39 a commenté le 20.01.2011 23:43

ça m’intéresse aussi.

jiremek a commenté le 21.01.2011 22:17

+1

zoum21 a commenté le 25.01.2011 06:42

+1

Est-ce que :
- re-activer le serveur DHCP
- restreindre la plage DHCP à 1 IP
- affecter un bail permanent au Player
serait une alternative acceptable pour vous?

JSM a commenté le 05.02.2011 09:38

Ici la demande est de permettre la configuration du mode de connexion réseau du Player pour qu’elle soit conforme à la configuration réseau de l’environnement dans lequel il se trouve.
Car l’accès Internet et la visibilité des partages locaux du Player dépendent directement de la configuration du FB Server ainsi que de la configuration réseau dans lequel se trouve le FB Player.

Alors de mon point de vue nous avons 3 possibilités:

  1. Le FB Player utilise le service DHCP (seul mode dispo actuellement) si la FB Server a le service d’activé ou si un autre composant du réseau local fournit ce service
  2. Le FB PLayer autorise la configuration manuelle d’une IP (+ serveurs DNS,+ passerelle) si le réseau local ne contient aucun serveur DHCP
  3. Ne plus autoriser la désactivation du service DHCP sur la FB Server

Fournir un bail DHCP permanent au Player peut être utile si la FB Server a son service DHCP activé.
Ceci pourrait par exemple éviter que tous les baux DHCP soient pris et que le Player ne puisse plus en obtenir.

Faire passer l’accès à Internet v4 du Player par le LAN utilisateur ça a des avantages et un inconvénient :
- nécessitée d’allouer une IP LAN au Player dans la config DHCP
+ possibilité de connecter le Player à un NAT-routeur perso (attention, pour utilisateur avancé uniquement!)
+ possibilité de définir la passerelle du Player comme un PC de l’utilisateur et non comme le Server
+ possibilité de proxifier l’accès Web : filtrage anti-pub, anonymisation, torification...

Ne plus autoriser la désactivation du service DHCP sur la FB Server

Qu’est-ce que tu appelles “la désactivation du service DHCP sur la FB Server” exactement?

Faire passer l’accès à Internet v4 du Player par le LAN utilisateur ça a des avantages et DEUX inconvénient :
- nécessitée d’allouer une IP LAN au Player dans la config DHCP (avoir une plage dynamique non saturée ou bien définir un bail permanent)
j’ajoute :
- découvrir un bail DHCP qu’on n’a pas configuré soi-même, et dont on ne sait pas d’où il sort, ça peut être franchement flippant, dans le genre : devine qui est là? (surtout si la Freebox Server n’affiche que des numéros et pas des noms dans la colonne MAC)

JSM a commenté le 05.02.2011 15:44
Ne plus autoriser la désactivation du service DHCP sur la FB Server

Ce que je veux dire à travers cette phrase c’est que dans le cas ou un utilisateur désactive volontairement ou non le service DHCP de la FB Server ET qu’il n’y a pas d’autres services DHCP sur son réseau local alors le Player n’obtient plus de configuration réseau. Il ne peut alors plus sortir sur Internet ou partager les services réseau locaux (ex: DLNA, NFS).

Pour les autres points je suis d’accord avec toi.
C’est pour cela que l’objectif ici est d’être FREE sur la configuration réseau du Server ET du Player pour répondre à toutes les configurations possibles. Après la bonne configuration ainsi que sa sécurisation est à la charge de l’utilisateur.

al31_h a commenté le 14.02.2011 06:17
C’est pour cela que l’objectif ici est d’être FREE sur la configuration réseau du Server ET du Player

D’accord avec JSM. Je préfèrerais pouvoir fixer les adresses du réseau (y compris changer l’adresse de la FBS, par exemple en 192.168.0.254 ce qui, pour l’instant, provoque la perte de la FBP).

De mon point de vue, je préfèrerai une adresse IP fixe sans DHCP pour le Player, quitte à ce que le serveur le paramètre de lui même. C’est vrai que l’on verra dans les paramètres une IP liée à une adresse MAC que l’on aura pas configuré nous même, mais l’adresse MAC du player étant inscrite sur le player, cela permet de savoir ce que c’est et de ne pas s’inquiéter du “devine qui est la”

De mon point de vue, je préfèrerai une adresse IP fixe sans DHCP pour le Player,

Pourquoi?

C’est vrai que l’on verra dans les paramètres une IP liée à une adresse MAC que l’on aura pas configuré nous même,

Dans quels paramètres?

“> De mon point de vue, je préfèrerai une adresse IP fixe sans DHCP pour le Player,

Pourquoi?”

j’ai toujours eu mes paramètres réglés en manuel dans les freebox. c’est peut être une illusion, mais cela me semble que le réseau soit plus sécurisé que les adresses IP soient attribués à des adresses MAC qui sont théoriquement unique, avec DHCP désactivé. DHCP activé, même avec une plage d IP réstreinte au nombre de machine, si un appareil est éteint il est facile pour quelqu’un de faire un coucou qui est la. après c’est un avis personnel

“> C’est vrai que l’on verra dans les paramètres une IP liée à une adresse MAC que l’on aura pas configuré nous même,

Dans quels paramètres?”

dans les parametres de la freebox dans l attribution des baux statiques, à moins que free le mette invisible.

J’ai essayé d’attribuer une IP fixe au player via adresse MAC, ne fonctionne pas, à moins que je ne soit pas sur la bonne plage. Je n’ai trouvé nulle part non plus l’adresse que le serveur attribut au player, mais peut être pas cherché au bon endroit.

j’ai toujours eu mes paramètres réglés en manuel dans les freebox. c’est peut être une illusion, mais cela me semble que le réseau soit plus sécurisé que les adresses IP soient attribués à des adresses MAC qui sont théoriquement unique, avec DHCP désactivé.

Si DHCP est désactivé je n’arrive pas à voir comment tu attribues des adresses IP à des adresses Ethernet!

Quel est le niveau de sécurité relatif d’un LAN avec un serveur DHCP disponible?

Si un intrus a accès à ton LAN, il peux en effet commencer par chercher le serveur DHCP. Ce n’est pas forcément l’option la plus furtive, parce que son adresse Ethernet apparaitra dans les logs du serveur DHCP, ou dans l’état actuel des bauds DHCP sur la Freebox.

Il peut de toute façon chercher à s’attribuer directement une adresse IP, sans passer par DHCP. Pour cela, il doit :
1) trouver la plage du sous-réseau
2) choisir une IP non utilisée

Tout d’abord, sur un réseau Ethernet traditionnel (en coaxial) il est trivial d’écouter le segment Ethernet puisque que toutes les stations reçoivent toutes les paquets Ethernet.

C’est aussi le cas sur un réseau base-T (sur câble torsadé) avec un “hub” Ethernet.

Ce n’est pas le cas avec un switch Ethernet, qui va essayer de n’envoyer les paquets qu’à l’endroit où ils doivent arriver.

Cependant certains paquets sont diffusés sur tous les ports d’un switch Ethernet : ceux envoyés à l’adresse de broadcast Ethernet (ff:ff:ff:ff:ff:ff) ou une adresse de multicast. En pratique, on trouve :

A. des paquets IPv4 envoyés à :

A.1. l’adresse de broadcast limité (adresse 255.255.255.255)
A.2. à une adresse de broadcast dirigé (sur Freebox c’est 192.168.x.255)
A.3. à une adresse de multicast (adresse IP supérieure à 224.0.0.0)

B. des paquets IPv6 multicasts

C. les paquets ARP envoyés à l’adresse broadcast Ethernet (ff:ff:ff:ff:ff)

Reprenons :

A.1. paquets IPv4 envoyés à l’adresse de broadcast limité (adresse 255.255.255.255)

Ces paquets sont envoyés à l’adresse de broadcast Ethernet (ff:ff:ff:ff:ff).

Les seuls paquets envoyés en broadcast limité correspondent au trafic DHCP/BOOTP. Par hypothèse, il n’y en a pas.

A.2. paquets IPv4 envoyés à une adresse de diffusion dirigée

L’adresse de broadcast dirigé est constituée du préfixe d’adresse du sous-réseau suivi de que des 1. Une adresse de diffusion dirigée a donc un suffixe tout-1.

Ces paquets sont envoyés à l’adresse de broadcast Ethernet (ff:ff:ff:ff:ff).

Des protocoles de découvertes limités au sous-réseau local utilisent le broadcast dirigé (notamment Windows).

Pour reconnaitre un tel paquet, il faut a priori connaitre l’adresse de diffusion dirigée, qu’on cherche justement à trouver. En fait si on filtre les paquets IP envoyés à l’adresse de diffusion Ethernet, en enlevant la diffusion locale, je pense qu’il ne doit rester que la diffusion dirigée.

La réception d’un tel paquet permet de connaitre l’adresse de diffusion dirigée IP; à partir de là :
- sous l’hypothèse que le préfixe de sous-réseau fait 24 bits (cas de toutes les box que je connais), on le déduit trivialement;
- si on refuse de faire des hypothèses, on peut trouver plusieurs préfixes possibles de différentes tailles.

On a au moins un majorant de la taille de la partie locale de l’adresse IP, c’est le nombre de 1 finaux dans l’adresse de broadcast; cela nous donne donc un minorant de la taille du préfixe de sous-réseau.

Exemple 1

Si on voit l’adresse de diffusion dirigée 10.1.255.255 (0000 1010 0000 0001 1111 1111 1111 1111) on voit que le suffixe tout-1 est 1 1111 1111 1111 1111 et le préfixe “par tout-1” est 0000 1010 0000 000. Donc le préfixe de sous-réseau commence par 0000 1010 0000 000, autrement dit 0000 1010 0000 000 est un préfixe du préfixe de sous-réseau. La taille du préfixe de sous-réseau est donc au moins 15.

A.3. à une adresse de multicast (adresse supérieure à 224.0.0.0)

Sert pour des protocoles de découverte, p.ex. la découverte de périphérique en UPnP.

Permet dans la plupart des cas d’apprendre une adresse IP appartenant à un équipement connecté.

Si l’adresse multicast est de la forme 224.0.0.x, l’adresse IP source doit forcément appartenir au réseau local. Pour d’autres adresses IP multicast ce n’est pas forcément le cas.

B. des paquets IPv6 multicasts

Encore très peu répandu.

Avec la Freebox, il suffit d’envoyer une sollicitation de routeur, d’attendre de recevoir la réponse (RA), de se choisir une adresse IPv6 et de vérifier que personne d’autre ne l’utilise (pas de DHCP en IPv6 sur Freebox).

C. les paquets ARP envoyés à l’adresse broadcast Ethernet (ff:ff:ff:ff:ff)

Les demandes ARP doivent forcément être envoyés en broadcast puisque c’est le protocole de découverte de l’adresse Ethernet (utilisé quand on ignore une adresse Ethernet).

En écoutant les demandes ARP il est possible de découvrir les adresse IP utilisées sur le réseau Ethernet, passivement donc de façon indétectable. Une demande ARP a la forme :

« Coucou tout le monde, je suis mon-adresse-IP, écrivez moi à mon-adresse-Ethernet, je voudrais écrire à adresse-IP-de-mon-correspondant, pourrait-il m’indiquer son adresse Ethernet? Merci par avance. »

On voit que la couche ARP est polie, mais elle a aussi une mémoire de poisson rouge : une association ARP est oubliée après 10 minutes en général. Donc en écoutant 10 min, on observe toutes les IP utilisées, les adresses Ethernet correspondantes, et on sait même qui parle à qui.

On obtient donc une liste d’adresses IP appartenant obligatoirement au sous-réseau (puisque l’ARP ne sort pas du sous-réseau) : autrement dit ces adresses ont toutes pour préfixe le préfixe de sous-réseau.

On peut calculer le plus long commun préfixe (PLCP) de ces adresse; le préfixe du sous-réseau est évidemment un préfixe du PLCP. On peut déduire un majorant de la taille du préfixe de sous-réseau.

Exemple 2

On observe les adresses 10.1.2.3 (0000 1010 0000 0001 0000 0010 0000 0011); 10.1.3.1 (0000 1010 0000 0001 0000 0011 0000 0001); le PLCP est 10.1.2/23 (0000 1010 0000 0001 0000 001) : le préfixe de sous-réseau est forcément un préfixe de 0000 1010 0000 0001 0000 001.

Quels sont les paramètres importants transmis par DHCP?

- le préfixe de sous-réseau
- une adresse IP disponible
- l’adresse de la passerelle IP

De quoi a besoin un intrus :

- d’une adresse IP utilisable
- de l’adresse de la passerelle IP

En connaissant le préfixe de sous-réseau, il est possible d’énumérer les adresses IP unicast possible (l’adresse IP dont la partie locale ne comporte que des 0 est l’adresse du réseau lui-même, quoi que ça puisse vouloir dire, et l’adresse IP dont la partie locale ne comporte que des 1 est l’adresse de broadcast).

Pour chaque adresse IP possible, on commence par retirer celles qu’on a vu utilisées récemment (comme adresse source d’une trame IP ou comme adresse IP apparaissant dans une requête ARP).

Pour chaque adresse IP restante, on cherchera activement à savoir si elle est utilisée : pour cela on va “ping-er” cette adresse, sauf qu’en fait de ping on peut se contenter d’une recherche ARP. C’est le même principe que Bonjour/APIPA en IPv4 (adresse lien-local de la forme 169.254.x.y) et que l’auto-configuration sans état en IPv6. La technique de vérification est expliquée dans la RFC 3927 : http://tools.ietf.org/html/rfc3927#section-2.2.1

 A host probes to see if an address is already in use by broadcasting
 an ARP Request for the desired address.  The client MUST fill in the
 'sender hardware address' field of the ARP Request with the hardware
 address of the interface through which it is sending the packet.  The
 'sender IP address' field MUST be set to all zeroes, to avoid
 polluting ARP caches in other hosts on the same link in the case
 where the address turns out to be already in use by another host.
 The 'target hardware address' field is ignored and SHOULD be set to
 all zeroes.  The 'target IP address' field MUST be set to the address
 being probed.  An ARP Request constructed this way with an all-zero
 'sender IP address' is referred to as an "ARP Probe".

Remarque :

Je ne pense pas qu’un “ARP Probe” soit normal sur un réseau routable comme celui derrière un box. Cette requête pourrait donc révéler une activité anormale sur le réseau. Pour améliorer la furtivité, il faudrait considérer si une adresse IP bidon devrait être utilisées comme adresse source. Je ne crois pas trop à cette histoire de pollution de cache ARP sur l’adresse IP source. Il faudrait faire des tests.

Si on ne connait pas le préfixe de sous-réseau, on connait quand même ses “bornes”.

Dans l’exemple 1 : 0000 1010 0000 000 est un préfixe du préfixe de sous-réseau.

Dans l’exemple 2 : le préfixe de sous-réseau est un préfixe de 0000 1010 0000 0001 0000 001

Exemple 3 = exemple 1 + exemple 2

Les préfixes de sous-réseau possibles sont donc :

0000 1010 0000 000
0000 1010 0000 0001
0000 1010 0000 0001 0
0000 1010 0000 0001 00
0000 1010 0000 0001 000
0000 1010 0000 0001 0000
0000 1010 0000 0001 0000 0
0000 1010 0000 0001 0000 00
0000 1010 0000 0001 0000 001

Il suffit de les essayer dans l’ordre jusqu’à trouver une adresse IP utilisable.

Comment trouver l’adresse de la passerelle IP?

S’il y a très peu d’adresses IP vues sur le LAN, il suffit de les essayer! Pour essayer une adresse, on envoie un paquet IP à l’adresse Ethernet correspondant à une adresse IP candidat passerelle IP avec une adresse IP externe : si c’est bien une passerelle IP, elle l’enverra à l’adresse IP et éventuellement on obtiendra une réponse; si non, le paquet sera détruit.

Mais on peut faire un peu mieux : la passerelle locale, c’est une adresse avec laquelle la plupart des hôtes vont communiquer souvent. On a donc intérêt à commencer par essayer les adresses les plus utilisées sur le réseau local.

On peut faire plus simple dans la plupart des cas : la passerelle locale est très souvent une box ou un NAT-routeur. Les marques sont connues, donc les préfixes constructeurs des adresses Ethernet aussi. Il suffit de chercher parmi les adresses Ethernet relevées celle d’une box ou d’un équipement servant de passerelle IP.

Conclusion?

Tout cela est de l’ordre de B-A-BA du réseau IP/Ethernet. Cela peut paraitre un peu compliqué, mais c’est parce que j’ai été vraiment très général. En pratique si on suppose que le réseau local est en 192.168.x/24 comme sur la Freebox et la plupart des autres box, on simplifie beaucoup les choses.

Mais surtout :

Comment un intrus arriverait à ce connecter à ton réseau local?

Pourquoi penses-tu que c’est une hypothèse vraisemblable?

francois.94120 :

De mon point de vue, je préfèrerai une adresse IP fixe sans DHCP pour le Player, quitte à ce que le serveur le paramètre de lui même. C’est vrai que l’on verra dans les paramètres une IP liée à une adresse MAC que l’on aura pas configuré nous même,

corrector :

> C’est vrai que l’on verra dans les paramètres une IP liée à une adresse MAC que l’on aura pas configuré nous même,
>
> Dans quels paramètres?

francois.94120 :

dans les parametres de la freebox dans l attribution des baux statiques, à moins que free le mette invisible.

Je comprends de moins en moins ce que tu voudrais :

1) tu dis que tu veux paramétrer l’adresse IP du Player SANS utiliser le DHCP

2) puis tu parles de l’attribution des baux statiques

De quel bail s’agit-il? d’un bail DHCP? autre chose?

francois.94120 :

J’ai essayé d’attribuer une IP fixe au player via adresse MAC, ne fonctionne pas, à moins que je ne soit pas sur la bonne plage.

Tu as créé un bail DHCP permanent pour la Freebox Player et ça ne marche pas?

Tu peux décrire exactement ce que tu as fait?

Je n’ai trouvé nulle part non plus l’adresse que le serveur attribut au player, mais peut être pas cherché au bon endroit.

Cette information doit être sur la page qui affiche les bauds DHCP.

Le lecteur aura corrigé de lui même les erreurs de mon avant-dernier message (l’adresse Ethernet de diffusion est évidemment ff:ff:ff:ff:ff:ff et non ff:ff:ff:ff:ff...).

Alors, je vais essayer de faire plus simple dans mes explications:

Je voudrais que l’adresse IP soit allouée manuellement pour l’adresse MAC du player, comme tous les appareils reliés à ma box en fait (ex: 192.168.X.Y pour l’adresse mac AA:AA:AA:AA:AA:AA et ainsi de suite).

A une époque, en laissant le DHCP activé et en ayant juste limité le nombre d’adresse au nombre d’appareils, le pc portable m’a gentiment dit que mon adresse IP (qui étaient sur les machines en manuel) était déjà utilisée, hors aucun de MES appareils n’avait la même. Depuis, j’ai attribué dans mes diverses freebox les IP à chaque adresse MAC et plus de problèmes. Je préfère desormer que tout soit en manuel.

En effet, l’adresse IP allouée au player est dans les bauds dynamiques, et c’est cette adresse exacte que j’avait essayé de mettre en baud statique et qui ne fonctionnait pas.

J’espère être plus clair dans mon explication, de ta longue explication, j’en ai déduit que j’avais mélanger la signification de certains termes, mea culpa.

A une époque, en laissant le DHCP activé et en ayant juste limité le nombre d’adresse au nombre d’appareils, le pc portable m’a gentiment dit que mon adresse IP (qui étaient sur les machines en manuel) était déjà utilisée, hors aucun de MES appareils n’avait la même.

Mouais... c’est difficile de dire ce qui s’est passé exactement, mais est-ce que le portable n’avait pas :
- une interface Wifi
- ET une interface Ethernet filaire
et est-ce que tu as utilisé l’une et l’autre successivement, sur le même réseau avec la même adresse IP?

Je pense que le portable voyait un “autre” PC avec la même adresse IP, et que cet autre PC était le portable en question.

Ce ne serait pas la première fois que ça arrive.

C’était quel OS?

Le portable était en wifi sous xp sp2, et je n’utilisais pas le réseau filaire sur celui ci, seulement sur le pc de bureau, également sous xp sp2

Il y a plein de comportements surprenants voir carrément étranges avec la gestion réseau de Windows. C’est un problème classique avec les systèmes qui se veulent “user friendly” et essaient d’automatiser plein de choses. (Et vu l’incompétence reconnues des programmeurs de MS, ils automatisent mal et ont parfois des idées complètement débiles mais qui sont implémentées quand même.)

Pour prendre des parts de marché à Windows, certaines distributions linux se sont mises à faire des systèmes “user friendly” mal fichus où en cas d’erreur on ne comprend rien non plus. Le but étant bien sûr de faire aussi bloaté et buggué que Windows. (But non atteint.) Au moins sur un linux on peut contourner le bloat user-friendly et manipuler le noyau directement.

Tout ceci pour dire que je n’ai aucune idée pourquoi tu as observé que “le pc portable m’a gentiment dit que mon adresse IP (qui étaient sur les machines en manuel) était déjà utilisée, hors aucun de MES appareils n’avait la même.” et que je ne vais pas plus spéculer sur cette question.

clam a commenté le 26.09.2011 13:47

Bonjour,

Je rencontre le problème sus-cité depuis que j’ai reconfiguré le réseau sur lequel se trouve la Freebox.

En gros il s’agit d’un réseau d’entreprise sur lequel il y a un DHCP+Firewall sous la forme d’un PC faisant tourner SmoothWall. Le tout est connecté sur une fibre (offre pro chez un FAI B2B).

Sur le réseau on a également une Freebox qui me sert de passerelle Wifi et de retour TV (oui on est une chaîne TV diffusé sur Freebox TV et on a besoin de ce retour). Le server est connecté à son ADSL, au player via Ethernet, au reste du réseau par Ethernet et le Wifi est activé.

Donc la Freebox sert de :
- retour TV sur une vraie TV
- passerelle Wifi pour le LAN
- retour TV via VLC sur certains postes critiques (sur lesquels une route statique est configurée pour que ça fonctionne).

Par exemple le retour TV sous VLC va me permettre à l’avenir d’avoir un monitoring sur un PC qui envoie des alertes SMS/e-mails en cas d’incident de diffusion.

Jusque là c’était très pratique et ça fonctionne, sauf que je viens de me rendre compte qu’on a pas accès au freestore ni au net via le Player (on voulait se renseigner sur le fonctionnement du freestore). Le Player nous dit qu’il n’a pas de connexion internet ; j’ai l’impression que le fait que ce soit le DHCP de SmoothWall et pas le DHCP du Server ne lui plaît pas (du coup sa connexion à internet se fait via un autre FAI, ou alors il ne récupère pas d’IP tout court, je suis incapable de le savoir). Comme il n’y a pas trop d’outil de configuration et de monitoring sur le Player je ne sais pas trop ce qu’il se passe.

Est-ce qu’il y a une solution sans remettre en route le DHCP du Server ? (je refuse de le faire sinon ça va nous faire deux serveurs DHCP sur le réseau)

Merci :)

Est-ce que le Player obtient bien une IP sur le LAN?

Que le navigateur Web du Player ne fonctionne pas me surprend un peu.

clam a commenté le 26.09.2011 17:29

Ah, au temps pour moi, le web marche (j’avais fait des modifs encore ce matin sur le réseau). C’est le freestore qui ne fonctionne pas car le Player doit essayer d’y accéder par la connexion non-Free.

Pour l’IP j’ai l’impression qu’il n’y a nulle part où on peut avoir cette info dans l’interface du Player.

C’est le freestore qui ne fonctionne pas car le Player doit essayer d’y accéder par la connexion non-Free.

Il n’est pas possible d’attribuer une IP Free au Player au niveau du DHCPd?

Pour l’IP j’ai l’impression qu’il n’y a nulle part où on peut avoir cette info dans l’interface du Player.

Vous ne pouvez pas voir ça sur le DHCPd?

clam a commenté le 26.09.2011 18:11

J’ai un peu fouillé dans les logs du DHCPd mais finalement je me suis rendu compte que l’adresse MAC était inscrite sur un sticker à l’arrière du player. Du coup maintenant le Player a une adresse IP statique, par contre je n’ai apparemment pas moyen de changer le réglage du DHCP pour lui indiquer une passerelle différente du reste du réseau.

C’est quel logiciel?

clam a commenté le 26.09.2011 19:13

SmoothWall Express (distribution Linux spécialisée) sur un PC en config basique 2 cartes LAN+WAN (le WAN étant chez notre autre FAI).
http://www.smoothwall.org/

Bon ceci dit sinon c’est pas grave, on va laisser tomber le freestore pour l’instant, de toute façon c’était juste pour voir à quoi ressemblait les applis. Comme il n’y a pas trop de doc sur ce qui est possible ou pas on voulait tâter un peu de ce qui a déjà été fait. Si jamais à l’avenir il y a un moyen de configurer le réseau du Player en manuel ça nous débloquera ça :)

Chargement...

Activer les raccourcis clavier

Liste des tâches

Détails de la tâche

Édition de la tâche