OpenPlotter

Bonjour
Je n'arrive pas a configurer le réseau d'OpenPloteur pour qu'il accepte le partage USB de la connexion internet de mon GSM.
Peut être que l'un d'entre vous peut me guider? Merci

L'équipage
13 jan. 2019
14 jan. 201916 juin 2020

Salut,

De mémoire c'est pas trop dur à faire fonctionner.
Tout d'abord, ouvrir un terminal (ligne de commande). Brancher le téléphone, partager la connexion en usb. Dans le terminal, taper sudo ifconfig, et vérifier que usb0 apparait bien.

Si c'est le cas, ensuite taper
sudo nano /etc/network/interfaces.d/usb

Ca permet d'éditer le fichier.
Dedans mettre:

allow-hotplug usb0
auto usb0
iface usb0 inet dhcp

Pour quitter, faire ctrl-x, ca va demander si vous voulez enregister le fichier, repondre O si c'est en francais, Y si c'est en Anglais.

Redemarrer openplotter.

Ensuite dans les paramètres openplotter, faire comme sur l'image en pièce jointe (partager internet en usb0).

De mémoire, ça marche.

14 jan. 2019

Attention, ce genre de manipulation n'est plus d'actualité, comme tous les systèmes linux étant passé à systemd, tout ce qui touche aux "services" est désormais géré par systemd, netplan, et autres saletés.
Voir la doc d'openplotter à ce sujet docs.sailoog.com[...]network

14 jan. 2019

Et on peut toujours connecter des liaisons série via USB ?
USB0; Le zéro va peut-être impliquer que cette interface soit UP avant les autres ?

14 jan. 2019

Si ça doit encore fonctionner sans soucis et sans interférences. J'ai mis ça en place en octobre, et c'était déjà systemd. A part Ubuntu, je crois que aucune distribution n'est passée à Netplan.

Pour le port série, ça n'interferera pas avec. Le seul cas c'est si il y a 2 partages réseau USB en même temps. De plus, sur openplotter, on peut fixer les ports série d'après l'id du périphérique ou d'après la position de branchement sur la carte.

14 jan. 2019

Pour avoir réalisé l'opération décrite par Khetzal sur mon propre Openplotter, je confirme que ça marche. J'ai fait la mise à jour d'Openplotter en 1.20 avec cela, et ça marche d'ailleurs toujours après la mise à jour.

14 jan. 2019

Cela marche pour le moment, mais dans un avenir proche, cela risque de créer des conflits et il vaut mieux du coup commencer à utiliser systemd.

14 jan. 2019

"A part Ubuntu, je crois que aucune distribution n'est passée à Netplan." certes mais quasi toutes les autres ont un equivalent systemd. c'est pour cela que j'ai dit "systemd, netplan et autres saletés".
systemd est un troll depuis 2012 dans le monde du libre car il "mange" progressivement tout, a tel point que l'on se demande si à force, il ne va pas y avoir GNU/linux d'un coté et systemd/linux de l'autre.
Systemd est une création de RedHat et peu de distributions sont encore épargnées.
Parmi les distributions passées sous systemd fedora, debian,leurs dérivées et j'en passe.

14 jan. 201914 jan. 2019

Je ne mélanges pas systemd et ifupdown.
Je ne suis pas un spécialiste d'oppenplotter ni de rasbian.
ifupdown est spécifique à Debian et ses dérivées, mais je ne suis pas aussi optimiste que toi quand à la durée de la rétrocompatibilité. Debian d'ailleurs est désormais par défaut sous systemd-netword (www.debian.org[...]en.html )
Toutes les autres distributions "systemd" sont aussi désormais basées sur systemd-netword par défaut( fedora, arch...)

Et quand à mes inquiétudes, ne te fais pas de soucis pour moi, je n'utilise pas Debian et ses dérivées, et n'ai dnc pas ce genre de soucis, ni avec systemd d'ailleurs.

14 jan. 2019

Debian c'est un terme américain qui veut dire "Slackware est trop compliqué pour moi"

14 jan. 201914 jan. 2019

network-manager, est l'interface graphique qui gère systemd-netword sur la plupart des distribs qui y sont passées, d'ailleurs, cette doc explique aussi que cela peut causer des conflits avec ifupdown (ce qui fait que je me demande toujours pourquoi ils ont adopté si vite systemd) .
Et je n'ai jamais dit que ta solution ne marcherai pas, j'ai voulu soulever le fait qu' à cause de systemd, on allait de plus en plus avoir des soucis, bugs et autres conflits.
Mais ça seul l'avenir le dira.
En attendant, comme tu dis si le problème est résolu, cela ne sert à rien d'épiloguer

14 jan. 2019

En fait je pense que tu mélanges systemd et ifupdown. Systemd gère le démarrage et plein d'autres choses (maintenant le journal, etc...) et peut gérer le réseau (avec systemd-networkd, mais je ne connais pas de distribution où il est par défaut, cela dit je ne me suis pas renseigné outre mesure sur ce point).
Pour le réseau plusieurs solutions peuvent cohabiter. En général dans les distributions actuelles, il s'agit de ifupdown et de network-manager (et Netplan pour ubuntu, mais netplan est une couche au dessus, il ne gère pas directement le réseau mais génère les configurations pour les outils qui gèrent le réseau). Network-manager (qui n'est pas affilié à systemd) est en général utilisé. Par contre, à partir du moment où une interface est configurée pour ifupdown (/etc/network/interfaces) elle n'est plus généré par network-manager mais par ifupdown.

Pour en revenir du coup à ta crainte de voir le support ifupdown supprimé, à mon avis tu as des années avant que la retrocompatibilité soit enlevée (voir des 10ènes d'années).
Du coup, j'ai quand même démarré mon openplotter pour vérifier si systemd-networkd était actif dessus. Il s'avère qu'il est inactif et sans aucune configuration, donc pour l'instant, des modifications faites dessus ne fonctionneront pas.
Si jamais on était sous systemd-networkd, au lieu de modifier le fichier si dessus (qui marcherait quand même vu la retrocompatibilité assurée), il suffirait de créer un fichier:

/etc/systemd/network/usb.network

avec dedans
[Match]
usb*

[Network]
DHCP=ipv4

Ca devrait fonctionner pareil.
J'ai aussi vérifié, sur mon openplotter, pas de network-manager installé.

Du coup, sur mon openplotter, il n'y a que ifupdown pour gérer le réseau, donc que la première solution que j'ai donné ci dessus.

Dans l'article que tu lis, ils disent qu'ils basculent au système de gestion de réseau de Raspian natif, qui est ifupdown. Peut être que avant justement ils utilisaient network-manager ou autre ? Donc pour l'instant, la seule méthode qui est supportée officiellement est celle que j'ai dit en premier, mais il est sûrement possible, en bidouillant et en l'activant manuellement, d'utiliser systemd-networkd à la place (mais non supporté pour l'instant).

14 jan. 201914 jan. 2019

Comment ? pas Debian ?
Au bucher !

14 jan. 2019

:-D :-D :-D

14 jan. 2019

Sur ton lien, ils disent que c'est géré par network-manager (pas par systemd-networkd).
Sur raspian (et c'est bien ce qui nous interesse, vu que Openplotter est basé dessus) et sur openplotter, on est sous ifupdown. Si on avait été sous ubuntu, j'aurais dit de faire autrement et j'aurais donné une autre solution (ce à quoi tu aurais peut être dit "attention c'est pas compatible avec les anciens systèmes" ?).

Enfin bref, j'ai apporté une réponse qui semble adaptée (attendons tout de même de voir de la part de l'auteur si ca marche). Si un jour Openplotter décide de changer de gestion de réseau, on verra pour faire autrement (mais peut être qu'il n'y aura pas besoin de faire autrement et que ça fonctionnera directement, ou peut être qu'il y aura plein de bugs dus à autre chose entre temps).

14 jan. 2019

Non c'est encore une confusion entre backend et front. Network manager n'est pas l'interface graphique (même si il en possède plusieurs). Par exemple si tu regardes la documentation Netplan, il exporte les confs soit dans network-manager, soit dans systemd-networkd

14 jan. 2019

Je précise cependant que le port USB de l'adaptateur RS232 à un nom attribué et n'est pas en usbX

14 jan. 2019

De toutes façons même en usbX ça fonctionnerait. Les ports série sont sur /dev/ttyUSBX, mais dans notre cas, on est sur une interface réseau RNDIS (protocole propriétaire microsoft de partage de connexion / ethernet via usb).
Au premier abord on pourrait donc se poser la question, mais il ne pourra pas y avoir de conflit avec des périphériques serie dans ce cas, car le periphérique réseau, dans le cas d'un partage usb, ne sera jamais monté sur /dev/ttyUsbX (c'est géré par un autre driver).

Cape Point, South Africa

Phare du monde

  • 4.5 (139)

Cape Point, South Africa

2022