[opensuse-fr] Communication Leap 42.3 avec un Raspberry Pi Zero
Bonjour la gang ! Je viens de créer ce sujet : https://www.alionet.org/showthread.php?33646-Communication-Leap-42-3-avec-un-Raspberry-Pi-Zero&s=04b937a96f1c73e084f73cf293b8a9ac&p=294984#post294984 Si quelqu'un pouvait regarder ça, je lui en serait bien reconnaissant. Mon interrogation est à la fin de ce long "post". Je pense en particulier à Bruno ! Merci pour votre attention, Patrick / Bidy -- To unsubscribe, e-mail: opensuse-fr+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-fr+owner@opensuse.org
Bonjour tous, Mes essais sont infructueux. Pour mémoire, la configuration yast du réseau donne (la route est 192.168.1.1) : ______________________________________________________________________________ nom Adresse IP Périphérique Remarque Linux-USB Ethernet/RNDIS Gadget 192.168.7.3 Pont réseau 192.168.1.3 br1 RTL8111/8168/8411 PCIe Gigabit NONE eth0 asservi dans br1 VT6105/VT6106D [Rhine-III] 192.168.0.3 eth1 ______________________________________________________________________________ J'ai modifié le script de Chistophe Blaess pour que l'effet soit visible. Je le joins. Son exécution affiche : ______________________________________________________________________________ Configuration OK. Chain INPUT (policy ACCEPT 1 packets, 179 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- usb0 eth0 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 MASQUERADE all -- * eth0 0.0.0.0/0 0.0.0.0/0 Chain PREROUTING (policy ACCEPT 929 packets, 251K bytes) pkts bytes target prot opt in out source destination Chain INPUT (policy ACCEPT 906 packets, 251K bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 539 packets, 65351 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 539 packets, 65351 bytes) pkts bytes target prot opt in out source destination ______________________________________________________________________________ Quelqu'un accepterait-il de m'aider, s'il vous plaît ? Merci pour votre attention, Patrick NB SVP excusez la faute dans le post précédent : "…je lui en serais reconnaissant…" - -------------------------------------- Le mercredi 11 avril 2018, Patrick Serru a écrit :
Bonjour la gang !
Je viens de créer ce sujet : https://www.alionet.org/showthread.php?33646-Communication-Leap-42-3-avec-u n-Raspberry-Pi-Zero&s=04b937a96f1c73e084f73cf293b8a9ac&p=294984#post294984
Si quelqu'un pouvait regarder ça, je lui en serait bien reconnaissant. Mon interrogation est à la fin de ce long "post". Je pense en particulier à Bruno !
Merci pour votre attention,
Patrick / Bidy
On jeudi, 12 avril 2018 03.46:59 h CEST Patrick Serru wrote:
Bonjour tous,
Mes essais sont infructueux. Pour mémoire, la configuration yast du réseau donne (la route est 192.168.1.1) :
____________________________________________________________________________ __ nom Adresse IP Périphérique Remarque Linux-USB Ethernet/RNDIS Gadget 192.168.7.3 Pont réseau 192.168.1.3 br1 RTL8111/8168/8411 PCIe Gigabit NONE eth0 asservi dans br1 VT6105/VT6106D [Rhine-III] 192.168.0.3 eth1 ____________________________________________________________________________ __
J'ai modifié le script de Chistophe Blaess pour que l'effet soit visible. Je le joins. Son exécution affiche : ____________________________________________________________________________ __ Configuration OK. Chain INPUT (policy ACCEPT 1 packets, 179 bytes) pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- usb0 eth0 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination
Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 MASQUERADE all -- * eth0 0.0.0.0/0 0.0.0.0/0 Chain PREROUTING (policy ACCEPT 929 packets, 251K bytes) pkts bytes target prot opt in out source destination
Chain INPUT (policy ACCEPT 906 packets, 251K bytes) pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 539 packets, 65351 bytes) pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 539 packets, 65351 bytes) pkts bytes target prot opt in out source destination ____________________________________________________________________________ __
Quelqu'un accepterait-il de m'aider, s'il vous plaît ?
Merci pour votre attention,
Patrick
NB SVP excusez la faute dans le post précédent : "…je lui en serais reconnaissant…" - --------------------------------------
Le mercredi 11 avril 2018, Patrick Serru a écrit :
Bonjour la gang !
Je viens de créer ce sujet : https://www.alionet.org/showthread.php?33646-Communication-Leap-42-3-avec-> > u
n-Raspberry-Pi-Zero&s=04b937a96f1c73e084f73cf293b8a9ac&p=294984#post294984
Si quelqu'un pouvait regarder ça, je lui en serait bien reconnaissant.
Mon interrogation est à la fin de ce long "post". Je pense en particulier à Bruno !
Merci pour votre attention,
Patrick / Bidy
Malheureusement je n'ai aucune connaissance dans la manipulation de ces petites bêtes ... Je suppose que la solution n'est pas loin, juste vérifier que d'un côté le desktop est une carte réseau (et une route) pour joindre le rasp et vis versa -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-fr+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-fr+owner@opensuse.org
Le 12/04/2018 à 10:16, Bruno Friedmann a écrit :
On jeudi, 12 avril 2018 03.46:59 h CEST Patrick Serru wrote:
Bonjour tous,
Mes essais sont infructueux. Pour mémoire, la configuration yast du réseau donne (la route est 192.168.1.1) :
____________________________________________________________________________ __ nom Adresse IP Périphérique Remarque Linux-USB Ethernet/RNDIS Gadget 192.168.7.3 Pont réseau 192.168.1.3 br1 RTL8111/8168/8411 PCIe Gigabit NONE eth0 asservi dans br1 VT6105/VT6106D [Rhine-III] 192.168.0.3 eth1 ____________________________________________________________________________ __
J'ai modifié le script de Chistophe Blaess pour que l'effet soit visible. Je le joins. Son exécution affiche : ____________________________________________________________________________ __ Configuration OK. Chain INPUT (policy ACCEPT 1 packets, 179 bytes) pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- usb0 eth0 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination
Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 MASQUERADE all -- * eth0 0.0.0.0/0 0.0.0.0/0 Chain PREROUTING (policy ACCEPT 929 packets, 251K bytes) pkts bytes target prot opt in out source destination
Chain INPUT (policy ACCEPT 906 packets, 251K bytes) pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 539 packets, 65351 bytes) pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 539 packets, 65351 bytes) pkts bytes target prot opt in out source destination ____________________________________________________________________________ __
Quelqu'un accepterait-il de m'aider, s'il vous plaît ?
Merci pour votre attention,
Patrick
NB SVP excusez la faute dans le post précédent : "…je lui en serais reconnaissant…" - --------------------------------------
Le mercredi 11 avril 2018, Patrick Serru a écrit :
Bonjour la gang !
Je viens de créer ce sujet : https://www.alionet.org/showthread.php?33646-Communication-Leap-42-3-avec-> > u
n-Raspberry-Pi-Zero&s=04b937a96f1c73e084f73cf293b8a9ac&p=294984#post294984
Si quelqu'un pouvait regarder ça, je lui en serait bien reconnaissant.
Mon interrogation est à la fin de ce long "post". Je pense en particulier à Bruno !
Merci pour votre attention,
Patrick / Bidy
Malheureusement je n'ai aucune connaissance dans la manipulation de ces petites bêtes ...
Ce n'est pas un problème Raspberry, mais plutôt un problème "Linux", je pense. ;) Guillaume
Je suppose que la solution n'est pas loin, juste vérifier que d'un côté le desktop est une carte réseau (et une route) pour joindre le rasp et vis versa
-- To unsubscribe, e-mail: opensuse-fr+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-fr+owner@opensuse.org
Le jeudi 12 avril 2018, Bruno Friedmann a écrit :
On jeudi, 12 avril 2018 03.46:59 h CEST Patrick Serru wrote:
Bonjour tous,
Mes essais sont infructueux. Pour mémoire, la configuration yast du réseau donne (la route est 192.168.1.1) :
... Quelqu'un accepterait-il de m'aider, s'il vous plaît ?
Merci pour votre attention,
Patrick
--------------------------------------
Malheureusement je n'ai aucune connaissance dans la manipulation de ces petites bêtes ...
Je suppose que la solution n'est pas loin, juste vérifier que d'un côté le desktop est une carte réseau (et une route) pour joindre le rasp et vis versa
--
Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot
Bonjour Bruno et merci pour cette triste (-: réponse, La communication Desktop-RPi0 s’établie via SSH, ce qui est déjà énorme, vu la nature autistique du RPi0 sans écran, souris et clavier. Tout va bien sauf que le desktop m’envoie des : [ xxxx.xxxxxx] cdc_ether 4-1:1.0 usb0: kevent 12 may have been dropped au re-démarrage au petit matin alors que le RPi0 était allumé toute la nuit. La communication semble alors impossible. Le RPi0 semble impliqué parce qu’après un "tu coupe et tu rallume", tout repart "normalement". Pour ce qui est de l’accès à internet une fois la communication ssh étable, je suppose que c’est bien le destop faisant routeur qui ne va pas, et c’est pourquoi j’ai joins l’affichage des règles iptables. Je n’y comprends pas grand-chose. Bien entendu, quand je lance yast ensuite, yast croit qu’un autre pare-feu est utilisé puisqu’il n’y trouve pas ce qu’il y met quand le pare-feu est désactivé. Rien à voir avec le sujet, mais je vous invite à vous (faire) offrir cette petite carte sous la forme W (c’est-à-dire avec une électronique WiFi à bord). C’est un jouet que j’ai trouvé très impressionnant ! Bon, je suis probablement facilement impressionnable. Cordialement, Patrick -- To unsubscribe, e-mail: opensuse-fr+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-fr+owner@opensuse.org
On jeudi, 12 avril 2018 15.15:11 h CEST Patrick Serru wrote:
Le jeudi 12 avril 2018, Bruno Friedmann a écrit :
On jeudi, 12 avril 2018 03.46:59 h CEST Patrick Serru wrote:
Bonjour tous,
Mes essais sont infructueux. Pour mémoire, la configuration yast du
réseau donne (la route est 192.168.1.1) : ...
Quelqu'un accepterait-il de m'aider, s'il vous plaît ?
Merci pour votre attention,
Patrick
--------------------------------------
Malheureusement je n'ai aucune connaissance dans la manipulation de ces petites bêtes ...
Je suppose que la solution n'est pas loin, juste vérifier que d'un côté le desktop est une carte réseau (et une route) pour joindre le rasp et vis versa
--
Bruno Friedmann
Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot
-------------------------------------- Bonjour Bruno et merci pour cette triste (-: réponse,
La communication Desktop-RPi0 s’établie via SSH, ce qui est déjà énorme, vu la nature autistique du RPi0 sans écran, souris et clavier. Tout va bien sauf que le desktop m’envoie des : [ xxxx.xxxxxx] cdc_ether 4-1:1.0 usb0: kevent 12 may have been dropped au re-démarrage au petit matin alors que le RPi0 était allumé toute la nuit. La communication semble alors impossible. Le RPi0 semble impliqué parce qu’après un "tu coupe et tu rallume", tout repart "normalement".
Pour ce qui est de l’accès à internet une fois la communication ssh étable, je suppose que c’est bien le destop faisant routeur qui ne va pas, et c’est pourquoi j’ai joins l’affichage des règles iptables. Je n’y comprends pas grand-chose. Bien entendu, quand je lance yast ensuite, yast croit qu’un autre pare-feu est utilisé puisqu’il n’y trouve pas ce qu’il y met quand le pare-feu est désactivé.
Rien à voir avec le sujet, mais je vous invite à vous (faire) offrir cette petite carte sous la forme W (c’est-à-dire avec une électronique WiFi à bord). C’est un jouet que j’ai trouvé très impressionnant ! Bon, je suis probablement facilement impressionnable.
Cordialement,
Patrick
Bah comme Guillaume disait, il me semble donc que tu as plus un pb réseau sur la box linux. pourrais-tu envoyer les résultats suivants ip link ip addr ip ro puis la même chose depuis le raspy Ensuite dans Yast, si ta box linux doit servir de routeur j'activerai la case à cocher (routage) de forward (me souviens plus comment ç'est traduit :-) au niveau firewall, il faut considérer que l'interface du py doit être naté pour l'extérieur (ce qui permettra aussi le retour des paquets vers le py) au niveau de py, il doit avoir une route qui passe forcément par l'openSUSE et aussi l'ip de l'openSUSE comme route par défaut Bon allez ça va marcher, c'est vrai que c'est mignon ces trucs (bon surtout le W avec bluetooth et wifi après je sais vraiment pas à quoi ça pourrait me servir ? des idées... -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-fr+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-fr+owner@opensuse.org
Le jeudi 12 avril 2018, Bruno Friedmann a écrit :
On jeudi, 12 avril 2018 15.15:11 h CEST Patrick Serru wrote:
Le jeudi 12 avril 2018, Bruno Friedmann a écrit :
On jeudi, 12 avril 2018 03.46:59 h CEST Patrick Serru wrote:
Bonjour tous,
Mes essais sont infructueux. Pour mémoire, la configuration yast du
réseau donne (la route est 192.168.1.1) : ...
Quelqu'un accepterait-il de m'aider, s'il vous plaît ?
Merci pour votre attention,
Patrick
--------------------------------------
Malheureusement je n'ai aucune connaissance dans la manipulation de ces petites bêtes ...
Je suppose que la solution n'est pas loin, juste vérifier que d'un côté le desktop est une carte réseau (et une route) pour joindre le rasp et vis versa
--
Bruno Friedmann
Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot
-------------------------------------- Bonjour Bruno et merci pour cette triste (-: réponse,
La communication Desktop-RPi0 s’établie via SSH, ce qui est déjà énorme, vu la nature autistique du RPi0 sans écran, souris et clavier. Tout va bien sauf que le desktop m’envoie des : [ xxxx.xxxxxx] cdc_ether 4-1:1.0 usb0: kevent 12 may have been dropped au re-démarrage au petit matin alors que le RPi0 était allumé toute la nuit. La communication semble alors impossible. Le RPi0 semble impliqué parce qu’après un "tu coupe et tu rallume", tout repart "normalement".
Pour ce qui est de l’accès à internet une fois la communication ssh étable, je suppose que c’est bien le destop faisant routeur qui ne va pas, et c’est pourquoi j’ai joins l’affichage des règles iptables. Je n’y comprends pas grand-chose. Bien entendu, quand je lance yast ensuite, yast croit qu’un autre pare-feu est utilisé puisqu’il n’y trouve pas ce qu’il y met quand le pare-feu est désactivé.
Rien à voir avec le sujet, mais je vous invite à vous (faire) offrir cette petite carte sous la forme W (c’est-à-dire avec une électronique WiFi à bord). C’est un jouet que j’ai trouvé très impressionnant ! Bon, je suis probablement facilement impressionnable.
Cordialement,
Patrick
Bah comme Guillaume disait, il me semble donc que tu as plus un pb réseau sur la box linux.
pourrais-tu envoyer les résultats suivants
ip link
ip addr
ip ro
puis la même chose depuis le raspy Ensuite dans Yast, si ta box linux doit servir de routeur j'activerai la case à cocher (routage) de forward (me souviens plus comment ç'est traduit :-)
au niveau firewall, il faut considérer que l'interface du py doit être naté pour l'extérieur (ce qui permettra aussi le retour des paquets vers le py)
au niveau de py, il doit avoir une route qui passe forcément par l'openSUSE et aussi l'ip de l'openSUSE comme route par défaut
Bon allez ça va marcher, c'est vrai que c'est mignon ces trucs (bon surtout le W avec bluetooth et wifi après je sais vraiment pas à quoi ça pourrait me servir ? des idées...
--
Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot
Bonjour Bruno et merci pour cette réponse, Adresse externe INDÉTERMINÉE ________ eth0 _____ _____ ------------ | .1.3|<--------->| |<--->| | ______ |desktop | |hub | |modem| _/ \_ | | |ether| |câble| ( ) | | ·-->|_____|--- |_____|<->( INTERNET ) | | | 192.168.1.0 (_ _) | | | _____ \______/ | | usb0 | | | | .7.3|<--------->|.7.2 | | | | |usb | | | | | | | | | |RPi0 | | | | |_____| | | | Adresse externe FIXE | | eth1 | _____ ---- | .0.3|<--------------------->| | ______ |________| | |modem| _/ \_ ________ epn2s1| |câble| ( ) | .1.4|<------' |_____|<->( INTERNET ) | laptop | 192.168.0.0 · (_ _) | serv | wlp1s0 · \______/ | .0.4|<·························· |________| La partie inférieure du schéma n'est là que pour "expliquer" la présence de deux cartes réseau. Desktop : -------------------------------------------------- $ sudo ip link 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br1 state UP mode DEFAULT group default qlen 1000 link/ether 08:62:66:47:6c:ee brd ff:ff:ff:ff:ff:ff 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 1000 link/ether 5c:d9:98:f6:81:ec brd ff:ff:ff:ff:ff:ff 4: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 16:86:09:8a:f5:1e brd ff:ff:ff:ff:ff:ff 5: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 08:62:66:47:6c:ee brd ff:ff:ff:ff:ff:ff $ sudo ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br1 state UP group default qlen 1000 link/ether 08:62:66:47:6c:ee brd ff:ff:ff:ff:ff:ff 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether 5c:d9:98:f6:81:ec brd ff:ff:ff:ff:ff:ff inet 192.168.0.3/24 brd 192.168.0.255 scope global eth1 valid_lft forever preferred_lft forever inet6 fe80::5ed9:98ff:fef6:81ec/64 scope link valid_lft forever preferred_lft forever 4: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 16:86:09:8a:f5:1e brd ff:ff:ff:ff:ff:ff inet 192.168.7.3/24 brd 192.168.7.255 scope global usb0 valid_lft forever preferred_lft forever inet6 fe80::1486:9ff:fe8a:f51e/64 scope link valid_lft forever preferred_lft forever 5: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 08:62:66:47:6c:ee brd ff:ff:ff:ff:ff:ff inet 192.168.1.3/24 brd 192.168.1.255 scope global br1 valid_lft forever preferred_lft forever inet6 fe80::a62:66ff:fe47:6cee/64 scope link valid_lft forever preferred_lft forever $ sudo ip ro default via 192.168.1.1 dev br1 192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.3 192.168.1.0/24 dev br1 proto kernel scope link src 192.168.1.3 192.168.7.0/24 dev usb0 proto kernel scope link src 192.168.7.3 RPi0 (via ssh) : -------------------------------------------------- root@rpi0:~# ip link 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether a6:2a:f8:76:a6:24 brd ff:ff:ff:ff:ff:ff root@rpi0:~# ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether a6:2a:f8:76:a6:24 brd ff:ff:ff:ff:ff:ff inet 192.168.7.2/24 brd 192.168.7.255 scope global usb0 valid_lft forever preferred_lft forever inet6 fe80::a42a:f8ff:fe76:a624/64 scope link valid_lft forever preferred_lft forever root@rpi0:~# ip ro default via 192.168.7.1 dev usb0 onlink 192.168.7.0/24 dev usb0 proto kernel scope link src 192.168.7.2 -------------------------------------------------- De retour sur le Desktop, dans Yast en français, "Paramètres réseau", onglet "Routage" : Passerelle IPv4 par défaut : 192.168.1.1 ; Périphérique "-" Passerelle IPv6 par défaut : ; Périphérique "-" Table de routage | Destination | Passerelle | Masque réseau | Périphérique | Options | (vide) ☐ Activer la transmission IPv4 ✔ Activer la transmission IPv6 Hé oui, j’aurais dû regarder là plus tôt ! J’aurais au moins coché la case "Activer la transmission IPv4", mais je ne sais fichtre pas quoi mettre dans le tableau qui est certainement à remplir. Il devrait y être dit que : - ce qui vient de l’extérieur 192.168.7.2 et entrant par 192.168.7.3 doit pouvoir être redirigé vers 192.168.1.3 (ssh) ou la route 192.168.1.1 - ce qui viens de 192.168.1.1 doit être envoyé vers 192.168.1.3 ou 192.168.7.2 via 192.168.7.3. C’est le "pont" qui fait la traduction 192.168.7.0 en 192.168.1.3, si j'ai bien compris. Cocher la case "Activer la transmission IPv4" n’aura pas suffit )-: Aucun pare-feu n’est actif. Des idées… - pour l’entreprise ? Partout où un PC+linux de faible puissance devrait être mobilisé, surtout s’il n’a rien à afficher sur son propre écran. C’est vrai que les entreprises clientes ont des tonnes de PC trop faibles pour héberger Windows 12 ou 13, et qui pourraient remplir une telle tâche, et tant pis pour le bilan carbone. S’il n’y a pas d’électronicien dans le personnel, pas grand-chose à faire. N’oubliez pas qu’il est facile de le faire fonctionner sur batterie. - pour le fun, beaucoup de bidouilleur s’en serve de petit serveur local : ils y placent musique et images et même l’ouvre parfois au web et courrier. Mais en simplifiant l’approche de Linux pour l’électronicien (voir "wiring", et même NOOBS), toutes les applications Arduino peuvent être réalisée avec un Raspberry, au moins dix fois plus puissant (et moins "pervers" dans l'esprit). Un classique en matière de sécurité : surveillance vidéo et envoi de SMS. Dans mon cas, je voudrais l’attacher à un module GSM et qu'on communique avec lui par SMS, dans le cadre d’un projet de sécurisation d’un quartier de ville. Quand j’aurais le temps : un ampli audio relié aux HP idoines : je voudrais faire une comtoise, battant gravement les seconde paire d’un "tic" et les impaires d’un "toc", les quart d’heure d’un "ding" et les heures par un judicieux nombre de "dong". Sympa, non ? Les comtoises, au Pérou ça court pas les rues ! Plus d’idées pour l’informaticien en suivant ce lien : https://fr.aliexpress.com/wholesale?catId=0&SearchText=modules+arduino Patrick -- To unsubscribe, e-mail: opensuse-fr+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-fr+owner@opensuse.org
participants (3)
-
Bruno Friedmann -
Guillaume Gardet -
Patrick Serru