Pour mon petit script de sauvegarde via rsync sur une machine qui est la
copie conforme du PC portable que j'utilise quotidiennement, j'utilise
la commande 'arp -n' au début de ce script, ce qui est censé (selon moi)
récupérer l'adresse IP du PC vers lequel s'effectue la sauvegarde.
Mais il y a vraisemblablement quelquechose que j'ai mal compris.
Quand je viens d'allumer le PC destinataire de la sauvegarde, 'arp -n'
ne "voit" pas ce PC alors qu'il est monté sur le réseau.
Si depuis mon PC portable quotidien, j'effectue un 'ping' vers le PC
destinataire de la sauvegarde (juste pendant quelques secondes, 3 ou 4
pings) alors la commande 'arp -n' voit ce PC destinataire (et mon script
arrive Í récupérer cette IP, ce qui m'évite d'avoir Í la taper).
Je sens bien qu'il n'y a quelque chose que je ne comprends pas dans la
commande 'arp'...
Quelle commande devrais-je utiliser depuis mon PC portable quotidien
pour qu'il voit que le PC destinataire de la sauvegarde est monté sur le
réseau ?
Le réseau est un LAN tout ce qu'il y a de plus bête : les PC obtiennent
une adresse en 192.168.1.x sur ma LiveBox configurée en mode routeur.
Dans la mesure o͹ le système Linux s'est effectivement enregistré auprès du serveur DHCP et que ce dernier a mis Í jour le serveur DNS. C'est effectivement possible Í faire (de mémoire c'est l'option -I de dhclient, cf RFC-470[12]). Difficile Í dire si ça marche avec une box classique et avec un Android en mode tethering, ce qui était la demande.
Sergio <serge.laposte@delbono.net.invalid> wrote:
host toto te donnera l'ip du PC.
Dans la mesure o͹ le système Linux s'est effectivement enregistré auprès
du serveur DHCP et que ce dernier a mis Í jour le serveur DNS.
C'est effectivement possible Í faire (de mémoire c'est l'option -I de
dhclient, cf RFC-470[12]).
Difficile Í dire si ça marche avec une box classique et avec un Android
en mode tethering, ce qui était la demande.
Dans la mesure o͹ le système Linux s'est effectivement enregistré auprès du serveur DHCP et que ce dernier a mis Í jour le serveur DNS. C'est effectivement possible Í faire (de mémoire c'est l'option -I de dhclient, cf RFC-470[12]). Difficile Í dire si ça marche avec une box classique et avec un Android en mode tethering, ce qui était la demande.
Erwan David
Marc SCHAEFER écrivait :
Lulu wrote:
C'est juste pour la beauté du geste : « je n'ai même pas Í saisir l'IP du PC "destination" »
On pourrait imaginer une solution sale et simple: # pinguer en broadcast de subnet les 2 # possibilités de sous-réseau: normal et téléphone for i in 192.168.1.255 192.168.42.255 do ping -c 1 $i done
Je passerai plutÍ´t par fping -g 192.168.1.0/24 et fping -g 192.168.42.0/24, les réactions au broadcast ne sont pas toujours bien prévisibles.
# le serveur de backup répond aux pings broadcast # et qu'on connaÍ®t son adresse MAC # (Í activer dans /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts)
On peut aussi utiliser arping qui fait des requêtes arp (mais on ne peux pas faire un arping global, donc une petite boucle Í faire) Par contre une machine qui ne répond pas Í ARP n'est pas joignable du tout, donc c'est très rare. -- Les simplifications c'est trop compliqué
Marc SCHAEFER <schaefer@alphanet.ch> écrivait :
Lulu <lulu042@fry.fr.invalid> wrote:
C'est juste pour la beauté du geste : « je n'ai même pas Í saisir l'IP
du PC "destination" »
On pourrait imaginer une solution sale et simple:
# pinguer en broadcast de subnet les 2
# possibilités de sous-réseau: normal et téléphone
for i in 192.168.1.255 192.168.42.255
do
ping -c 1 $i
done
Je passerai plutÍ´t par fping -g 192.168.1.0/24 et fping -g
192.168.42.0/24, les réactions au broadcast ne sont pas toujours bien
prévisibles.
# le serveur de backup répond aux pings broadcast
# et qu'on connaͮt son adresse MAC
# (Í activer dans /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts)
On peut aussi utiliser arping qui fait des requêtes arp (mais on ne peux
pas faire un arping global, donc une petite boucle Í faire)
Par contre une machine qui ne répond pas Í ARP n'est pas joignable du
tout, donc c'est très rare.
C'est juste pour la beauté du geste : « je n'ai même pas Í saisir l'IP du PC "destination" »
On pourrait imaginer une solution sale et simple: # pinguer en broadcast de subnet les 2 # possibilités de sous-réseau: normal et téléphone for i in 192.168.1.255 192.168.42.255 do ping -c 1 $i done
Je passerai plutÍ´t par fping -g 192.168.1.0/24 et fping -g 192.168.42.0/24, les réactions au broadcast ne sont pas toujours bien prévisibles.
# le serveur de backup répond aux pings broadcast # et qu'on connaÍ®t son adresse MAC # (Í activer dans /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts)
On peut aussi utiliser arping qui fait des requêtes arp (mais on ne peux pas faire un arping global, donc une petite boucle Í faire) Par contre une machine qui ne répond pas Í ARP n'est pas joignable du tout, donc c'est très rare. -- Les simplifications c'est trop compliqué
Jacques L'helgoualc'h
Le 21-10-2021, Pascal Hambourg a écrit :
Le 21/10/2021 Í 07:23, Sergio a écrit :
Le 20/10/2021 Í 21:20, Marc SCHAEFER a écrit :
Dans ce cas /etc/hosts peut être utilisé pour pouvoir faire    ping toto plutÍ´t que    ping 192.168.1.42
ping est Í éviter pour simplement récupérer une IP (ou le contraire).
Le contraire de quoi ? Ne pas récupérer une adresse IP ?
On lui préférera host (ou nslookup sous W***)
Contrairement Í ping qui utilise le résolveur système, host et nslookup (et dig) ont l'inconvénient de n'utiliser que la résolution DNS, et non les autres sources de résolution de nom disponibles (/etc/hosts, multicast DNS, NBNS, DoH, DoT...) On peut plutÍ´t utiliser getent(1).
Bonjour, Si Lulu transporte ses deux PC sur plusieurs réseaux, et sachant par exemple que la livebox peut être capricieuse, il me semble que le plus simple est d'utiliser une configuration /constante/ : 1) s'attribuer des adresses /fixes/ privées en dehors des sentiers battus par les boxes, comme 10.2.3.75/24 et 10.2.3.22/24, 1.bis) ou activer ipv6 (si ça marche) et utiliser les links automatiques fe80::/64 dérivés des adresses mac, ou encore 1ter) s'attribuer deux adresses « ula » fixes, du genre fd00::bebe/64 et fd00::9a9a/64 C'est un peu goret, en principe on doit mettre les mêmes 40 bits aléatoires Í droite de la première paire « fd » :) Pour essayer, en root, sur le jeune PC ip -6 address add fd00::bebe/64 dev eth0 et de même sur le vieux... Ensuite, on ajoute les deux lignes dans chaque /etc/hosts fd00::bebe jeune.ula fd00::9a9a vieux.ula 2) ... et si tout va bien on bricole une fois pour toutes la configuration réseau des deux machines. Pour vérifier le réseau utilisé, la commande « ip n » est vite tapée, avec l'option -4 ou -6 si besoin. --
Le 21-10-2021, Pascal Hambourg a écrit :
Le 21/10/2021 Í 07:23, Sergio a écrit :
Le 20/10/2021 Í 21:20, Marc SCHAEFER a écrit :
Dans ce cas /etc/hosts peut être utilisé pour pouvoir faire
   ping toto
plutÍ´t que
   ping 192.168.1.42
ping est Í éviter pour simplement récupérer une IP (ou le contraire).
Le contraire de quoi ? Ne pas récupérer une adresse IP ?
On lui préférera host (ou nslookup sous W***)
Contrairement Í ping qui utilise le résolveur système, host et nslookup
(et dig) ont l'inconvénient de n'utiliser que la résolution DNS, et non
les autres sources de résolution de nom disponibles (/etc/hosts,
multicast DNS, NBNS, DoH, DoT...)
On peut plutÍ´t utiliser getent(1).
Bonjour,
Si Lulu transporte ses deux PC sur plusieurs réseaux, et sachant par
exemple que la livebox peut être capricieuse, il me semble que le plus
simple est d'utiliser une configuration /constante/ :
1) s'attribuer des adresses /fixes/ privées en dehors des sentiers
battus par les boxes, comme 10.2.3.75/24 et 10.2.3.22/24,
1.bis) ou activer ipv6 (si ça marche) et utiliser les links
automatiques fe80::/64 dérivés des adresses mac, ou encore
1ter) s'attribuer deux adresses « ula » fixes, du genre fd00::bebe/64
et fd00::9a9a/64
C'est un peu goret, en principe on doit mettre les mêmes 40 bits
aléatoires Í droite de la première paire « fd » :)
Pour essayer, en root, sur le jeune PC
ip -6 address add fd00::bebe/64 dev eth0
et de même sur le vieux...
Ensuite, on ajoute les deux lignes dans chaque /etc/hosts
fd00::bebe jeune.ula
fd00::9a9a vieux.ula
2) ... et si tout va bien on bricole une fois pour toutes la
configuration réseau des deux machines.
Pour vérifier le réseau utilisé, la commande « ip n » est vite tapée,
avec l'option -4 ou -6 si besoin.
Dans ce cas /etc/hosts peut être utilisé pour pouvoir faire    ping toto plutÍ´t que    ping 192.168.1.42
ping est Í éviter pour simplement récupérer une IP (ou le contraire).
Le contraire de quoi ? Ne pas récupérer une adresse IP ?
On lui préférera host (ou nslookup sous W***)
Contrairement Í ping qui utilise le résolveur système, host et nslookup (et dig) ont l'inconvénient de n'utiliser que la résolution DNS, et non les autres sources de résolution de nom disponibles (/etc/hosts, multicast DNS, NBNS, DoH, DoT...) On peut plutÍ´t utiliser getent(1).
Bonjour, Si Lulu transporte ses deux PC sur plusieurs réseaux, et sachant par exemple que la livebox peut être capricieuse, il me semble que le plus simple est d'utiliser une configuration /constante/ : 1) s'attribuer des adresses /fixes/ privées en dehors des sentiers battus par les boxes, comme 10.2.3.75/24 et 10.2.3.22/24, 1.bis) ou activer ipv6 (si ça marche) et utiliser les links automatiques fe80::/64 dérivés des adresses mac, ou encore 1ter) s'attribuer deux adresses « ula » fixes, du genre fd00::bebe/64 et fd00::9a9a/64 C'est un peu goret, en principe on doit mettre les mêmes 40 bits aléatoires Í droite de la première paire « fd » :) Pour essayer, en root, sur le jeune PC ip -6 address add fd00::bebe/64 dev eth0 et de même sur le vieux... Ensuite, on ajoute les deux lignes dans chaque /etc/hosts fd00::bebe jeune.ula fd00::9a9a vieux.ula 2) ... et si tout va bien on bricole une fois pour toutes la configuration réseau des deux machines. Pour vérifier le réseau utilisé, la commande « ip n » est vite tapée, avec l'option -4 ou -6 si besoin. --
Marc SCHAEFER
dyrmak wrote:
rarp -a Ce noyau ne supporte pas RARP.
En tous cas, grep -i rarp /boot/config-$(uname -r) ne propose aucune option chez moi. Je me demande si tester le dhclient -I (pour influencer le DNS) ne serait pas Í essayer. Sinon, effectivement, comme proposé ailleurs, ajouter une adresse IP de plus sur l'interface, dans un sous-réseau complètement différent.
dyrmak <dyrmak@quelite.terre.invalid> wrote:
rarp -a
Ce noyau ne supporte pas RARP.
En tous cas,
grep -i rarp /boot/config-$(uname -r)
ne propose aucune option chez moi.
Je me demande si tester le dhclient -I (pour influencer le DNS) ne
serait pas Í essayer.
Sinon, effectivement, comme proposé ailleurs, ajouter une adresse IP
de plus sur l'interface, dans un sous-réseau complètement différent.
En tous cas, grep -i rarp /boot/config-$(uname -r) ne propose aucune option chez moi. Je me demande si tester le dhclient -I (pour influencer le DNS) ne serait pas Í essayer. Sinon, effectivement, comme proposé ailleurs, ajouter une adresse IP de plus sur l'interface, dans un sous-réseau complètement différent.
Benoit Izac
Bonjour, Le 22/10/2021 Í 10:14, dyrmak a écrit dans le message  :
... Et quelqu'un sait comment compiler (avec quels options ?) le kernel afin que la commande rarp ne dise pas: rarp -a Ce noyau ne supporte pas RARP.
RTFM? | NOTE | This program is obsolete. From version 2.3, the Linux kernel no longer | contains RARP support. For a replacement RARP daemon, see | ftp://ftp.dementia.org/pub/net-tools En gros, ça fait plus de 20 ans que ça ne fonctionne plus. -- Benoit Izac
Bonjour,
Le 22/10/2021 Í 10:14, dyrmak <dyrmak@quelite.terre.invalid> a écrit
dans le message <slrnsn4smg.35l.dyrmak@quelite.terre>Â :
... Et quelqu'un sait comment compiler (avec quels options ?) le kernel
afin que la commande rarp ne dise pas:
rarp -a
Ce noyau ne supporte pas RARP.
RTFM?
| NOTE
| This program is obsolete. From version 2.3, the Linux kernel no longer
| contains RARP support. For a replacement RARP daemon, see
| ftp://ftp.dementia.org/pub/net-tools
En gros, ça fait plus de 20 ans que ça ne fonctionne plus.
Bonjour, Le 22/10/2021 Í 10:14, dyrmak a écrit dans le message  :
... Et quelqu'un sait comment compiler (avec quels options ?) le kernel afin que la commande rarp ne dise pas: rarp -a Ce noyau ne supporte pas RARP.
RTFM? | NOTE | This program is obsolete. From version 2.3, the Linux kernel no longer | contains RARP support. For a replacement RARP daemon, see | ftp://ftp.dementia.org/pub/net-tools En gros, ça fait plus de 20 ans que ça ne fonctionne plus. -- Benoit Izac
Lulu
[En-tête "Followup-To:" positionné Í fr.comp.os.linux.configuration.] Le 20-10-2021, Olivier Miakinen <om+ a écrit :
[diapublication, suivi vers fr.comp.reseaux.ip] Le 20/10/2021 19:56, Lulu a écrit :
Je n'ai donc pas été clair dans mon message original : je me promène avec mes deux PCs, "origine" avec lequel je travaille et "destination" qui sert de sauvegarde. Promène : signifie que ces deux PC se connectent au même moment sur un routeur aléatoire, soit mon téléphone configuré en AP, soit la LiveBox de ma coloc, soit sur la freebox de ma maison secondaire. Et j'imaginais qu'il était possible de scripter (en bash) la sauvegarde de "origine" vers "destination" quel que soit le réseau auquel ces machines sont connectées.
Donc tu connais l'adresse MAC de la machine qui sert de sauvegarde, mais tu ne connais pas son adresse IP car elle change en fonction du routeur (et en fait du serveur DHCP) utilisé, et c'est cette adresse IP que tu voudrais découvrir. En fait ce dont tu aurais besoin c'est une sorte de requête RARP (Reverse ARP) : <https://fr.wikipedia.org/wiki/Reverse_Address_Resolution_Protocol> <https://datatracker.ietf.org/doc/html/rfc903>. Je ne connais pas les détails du protocole DHCP, mais il me semblerait assez logique que le serveur DHCP fournisse directement ce genre de service. Je fais suivre vers fr.comp.reseaux.ip o͹ tu as plus de chances d'obtenir une réponse documentée.
J'ai fini par comprendre que je m'y prenais mal... En fait, selon le réseau sur lequel je me connecte, je connais les adresses IP de "origine" et "destination", car je me connecte toujours aux mêmes quatre ou cinq réseaux avec des adresses qui changent mais qui sont toujours les mêmes. Donc, en regardant l'adresse IP de "origine" (le PC sur lequel je travaille), je peux facilement déterminer l'adresse IP de "destination". MON_IP=$(hostname --all-ip-addresses) case "$MON_IP" in 192.168.1.146*) IP_SERVEUR_SSH="192.168.1.99"; ;; 192.168.43.99*) IP_SERVEUR_SSH="192.168.43.212"; ;; [...]
Cordialement,
Tout pareil. Merci Í tous pour votre aide.
[En-tête "Followup-To:" positionné Í fr.comp.os.linux.configuration.]
Le 20-10-2021, Olivier Miakinen <om+news@miakinen.net> a écrit :
[diapublication, suivi vers fr.comp.reseaux.ip]
Le 20/10/2021 19:56, Lulu a écrit :
Je n'ai donc pas été clair dans mon message original : je me promène
avec mes deux PCs, "origine" avec lequel je travaille et
"destination" qui sert de sauvegarde.
Promène : signifie que ces deux PC se connectent au même moment sur
un routeur aléatoire, soit mon téléphone configuré en AP, soit la
LiveBox de ma coloc, soit sur la freebox de ma maison secondaire.
Et j'imaginais qu'il était possible de scripter (en bash) la
sauvegarde de "origine" vers "destination" quel que soit le réseau
auquel ces machines sont connectées.
Donc tu connais l'adresse MAC de la machine qui sert de sauvegarde,
mais tu ne connais pas son adresse IP car elle change en fonction du
routeur (et en fait du serveur DHCP) utilisé, et c'est cette adresse
IP que tu voudrais découvrir.
En fait ce dont tu aurais besoin c'est une sorte de requête RARP (Reverse
ARP) :
<https://fr.wikipedia.org/wiki/Reverse_Address_Resolution_Protocol>
<https://datatracker.ietf.org/doc/html/rfc903>.
Je ne connais pas les détails du protocole DHCP, mais il me
semblerait assez logique que le serveur DHCP fournisse directement ce
genre de service. Je fais suivre vers fr.comp.reseaux.ip o͹ tu as
plus de chances d'obtenir une réponse documentée.
J'ai fini par comprendre que je m'y prenais mal...
En fait, selon le réseau sur lequel je me connecte, je connais les
adresses IP de "origine" et "destination", car je me connecte toujours
aux mêmes quatre ou cinq réseaux avec des adresses qui changent mais qui
sont toujours les mêmes.
Donc, en regardant l'adresse IP de "origine" (le PC sur lequel je
travaille), je peux facilement déterminer l'adresse IP de "destination".
MON_IP=$(hostname --all-ip-addresses)
case "$MON_IP" in
192.168.1.146*)
IP_SERVEUR_SSH="192.168.1.99";
;;
192.168.43.99*)
IP_SERVEUR_SSH="192.168.43.212";
;;
[...]
[En-tête "Followup-To:" positionné Í fr.comp.os.linux.configuration.] Le 20-10-2021, Olivier Miakinen <om+ a écrit :
[diapublication, suivi vers fr.comp.reseaux.ip] Le 20/10/2021 19:56, Lulu a écrit :
Je n'ai donc pas été clair dans mon message original : je me promène avec mes deux PCs, "origine" avec lequel je travaille et "destination" qui sert de sauvegarde. Promène : signifie que ces deux PC se connectent au même moment sur un routeur aléatoire, soit mon téléphone configuré en AP, soit la LiveBox de ma coloc, soit sur la freebox de ma maison secondaire. Et j'imaginais qu'il était possible de scripter (en bash) la sauvegarde de "origine" vers "destination" quel que soit le réseau auquel ces machines sont connectées.
Donc tu connais l'adresse MAC de la machine qui sert de sauvegarde, mais tu ne connais pas son adresse IP car elle change en fonction du routeur (et en fait du serveur DHCP) utilisé, et c'est cette adresse IP que tu voudrais découvrir. En fait ce dont tu aurais besoin c'est une sorte de requête RARP (Reverse ARP) : <https://fr.wikipedia.org/wiki/Reverse_Address_Resolution_Protocol> <https://datatracker.ietf.org/doc/html/rfc903>. Je ne connais pas les détails du protocole DHCP, mais il me semblerait assez logique que le serveur DHCP fournisse directement ce genre de service. Je fais suivre vers fr.comp.reseaux.ip o͹ tu as plus de chances d'obtenir une réponse documentée.
J'ai fini par comprendre que je m'y prenais mal... En fait, selon le réseau sur lequel je me connecte, je connais les adresses IP de "origine" et "destination", car je me connecte toujours aux mêmes quatre ou cinq réseaux avec des adresses qui changent mais qui sont toujours les mêmes. Donc, en regardant l'adresse IP de "origine" (le PC sur lequel je travaille), je peux facilement déterminer l'adresse IP de "destination". MON_IP=$(hostname --all-ip-addresses) case "$MON_IP" in 192.168.1.146*) IP_SERVEUR_SSH="192.168.1.99"; ;; 192.168.43.99*) IP_SERVEUR_SSH="192.168.43.212"; ;; [...]
Cordialement,
Tout pareil. Merci Í tous pour votre aide.
Lulu
Le 24-10-2021, Otomatic a écrit :
Lulu écrivait :
avec des adresses qui changent mais qui sont toujours les mêmes.
(Je savais que cette phrase était mal foutue ;-) Quand je change de routeur, les adresses de mes machines changent. Mais quand je me connecte Í un routeur donné, mes machines obtiennent toujours les mêmes adresses.
Le 24-10-2021, Otomatic <otomatic@oto.invalid> a écrit :
Lulu <lulu042@fry.fr.invalid> écrivait :
> avec des adresses qui changent mais qui sont toujours les mêmes.
(Je savais que cette phrase était mal foutue ;-)
Quand je change de routeur, les adresses de mes machines changent.
Mais quand je me connecte Í un routeur donné, mes machines obtiennent
toujours les mêmes adresses.
avec des adresses qui changent mais qui sont toujours les mêmes.
(Je savais que cette phrase était mal foutue ;-) Quand je change de routeur, les adresses de mes machines changent. Mais quand je me connecte Í un routeur donné, mes machines obtiennent toujours les mêmes adresses.
Jo Engo
Le Sun, 24 Oct 2021 15:47:58 +0200, Lulu a écrit :
des adresses qui changent mais qui sont toujours les mêmes.
C'est beau, on dirait du Verlaine. -- Il est absurde de diviser les gens en bons et en mauvais. Les gens sont ou bien charmants ou bien ennuyeux. -+- Oscar Wilde -+-
Le Sun, 24 Oct 2021 15:47:58 +0200, Lulu a écrit :
des adresses qui changent mais qui sont toujours les mêmes.
C'est beau, on dirait du Verlaine.
--
Il est absurde de diviser les gens en bons et en mauvais.
Les gens sont ou bien charmants ou bien ennuyeux.
-+- Oscar Wilde -+-
Le Sun, 24 Oct 2021 15:47:58 +0200, Lulu a écrit :
des adresses qui changent mais qui sont toujours les mêmes.
C'est beau, on dirait du Verlaine. -- Il est absurde de diviser les gens en bons et en mauvais. Les gens sont ou bien charmants ou bien ennuyeux. -+- Oscar Wilde -+-
Jacques L'helgoualc'h
Le 25-10-2021, Jo Engo a écrit :
Le Sun, 24 Oct 2021 15:47:58 +0200, Lulu a écrit :
des adresses qui changent mais qui sont toujours les mêmes.
C'est beau, on dirait du Verlaine.
Bah non, c'est presque une citation de Giuseppe Tomasi di Lampedusa, dans son unique roman, Il Gattopardo ;) --- cf. le film de Visconti. Sinon, il faut tout de même douter de la constance des boxes... A priori, c'est plutÍ´t l'adresse MAC qui est fixe (m'enfin, ça dépend de l'interface de connexion, par exemple :)
Le 25-10-2021, Jo Engo a écrit :
Le Sun, 24 Oct 2021 15:47:58 +0200, Lulu a écrit :
des adresses qui changent mais qui sont toujours les mêmes.
C'est beau, on dirait du Verlaine.
Bah non, c'est presque une citation de Giuseppe Tomasi di Lampedusa,
dans son unique roman, Il Gattopardo ;) --- cf. le film de Visconti.
Sinon, il faut tout de même douter de la constance des boxes...
A priori, c'est plutÍ´t l'adresse MAC qui est fixe (m'enfin, ça dépend
de l'interface de connexion, par exemple :)
Le Sun, 24 Oct 2021 15:47:58 +0200, Lulu a écrit :
des adresses qui changent mais qui sont toujours les mêmes.
C'est beau, on dirait du Verlaine.
Bah non, c'est presque une citation de Giuseppe Tomasi di Lampedusa, dans son unique roman, Il Gattopardo ;) --- cf. le film de Visconti. Sinon, il faut tout de même douter de la constance des boxes... A priori, c'est plutÍ´t l'adresse MAC qui est fixe (m'enfin, ça dépend de l'interface de connexion, par exemple :)
dyrmak
En 15 lignes Marc SCHAEFER a écrit dans news:sktsa9$h4n$ le vendredi, 22 octobre 2021 Í 10:21:29Â :
dyrmak wrote:
rarp -a Ce noyau ne supporte pas RARP.
En tous cas, grep -i rarp /boot/config-$(uname -r) ne propose aucune option chez moi. Je me demande si tester le dhclient -I (pour influencer le DNS) ne serait pas Í essayer.
Oui, bon, toutes ces procedures tentent d'exploiter quelque chose de la couche data-link (osi)/accès-réseau (tcp/ip) , dès que j'entends « diff réseau » . RARP simplement aurait été la bonne méthode, mais apparemment les admin n'aiment pas autoriser son utilisation, on piquerait des OS entiers en l'utilisant sans délicatesse ?
Sinon, effectivement, comme proposé ailleurs, ajouter une adresse IP de plus sur l'interface, dans un sous-réseau complètement différent.
LÍ par contre qu'on puisse ajouter une ou plusieurs adresses IP sur une interface je dirais plutÍ´t d'accord, mais il me semble qu'elles sont obligées de respecter le plan d'adressage de la Box, si la Box ne reconnaÍ®t pas l'adresse elle va tenter de la router par defaut ? Il me semble que les outils qui conviennent dans tous les cas, sans besoin de connaÍ®tre le plan d'adressage de la Box mais avec l'autorisation datée et signée de l'admin ou le consentement du détenteur de la Box sont : fping et arping fping trouve arping confirme dyrmak -- A la hora de la ahora ++++ --- ++++ Linux operating system ++++ --- ++++
En 15 lignes Marc SCHAEFER a écrit
dans news:sktsa9$h4n$1@shakotay.alphanet.ch
le vendredi, 22 octobre 2021 Í 10:21:29Â :
dyrmak <dyrmak@quelite.terre.invalid> wrote:
rarp -a
Ce noyau ne supporte pas RARP.
En tous cas,
grep -i rarp /boot/config-$(uname -r)
ne propose aucune option chez moi.
Je me demande si tester le dhclient -I (pour influencer le DNS) ne
serait pas Í essayer.
Oui, bon, toutes ces procedures tentent d'exploiter quelque chose de
la couche data-link (osi)/accès-réseau (tcp/ip) , dès que
j'entends « diff réseau » .
RARP simplement aurait été la bonne méthode, mais apparemment
les admin n'aiment pas autoriser son utilisation, on piquerait
des OS entiers en l'utilisant sans délicatesse ?
Sinon, effectivement, comme proposé ailleurs, ajouter une adresse IP
de plus sur l'interface, dans un sous-réseau complètement différent.
LÍ par contre qu'on puisse ajouter une ou plusieurs adresses IP
sur une interface je dirais plutÍ´t d'accord, mais il me semble
qu'elles sont obligées de respecter le plan d'adressage de la Box,
si la Box ne reconnaͮt pas l'adresse elle va tenter
de la router par defaut ?
Il me semble que les outils qui conviennent dans tous les cas,
sans besoin de connaͮtre le plan d'adressage de la Box
mais avec l'autorisation datée et signée de l'admin ou
le consentement du détenteur de la Box sont :
fping et arping
fping trouve
arping confirme
dyrmak
--
A la hora de la ahora
++++ --- ++++
Linux operating system
++++ --- ++++
En 15 lignes Marc SCHAEFER a écrit dans news:sktsa9$h4n$ le vendredi, 22 octobre 2021 Í 10:21:29Â :
dyrmak wrote:
rarp -a Ce noyau ne supporte pas RARP.
En tous cas, grep -i rarp /boot/config-$(uname -r) ne propose aucune option chez moi. Je me demande si tester le dhclient -I (pour influencer le DNS) ne serait pas Í essayer.
Oui, bon, toutes ces procedures tentent d'exploiter quelque chose de la couche data-link (osi)/accès-réseau (tcp/ip) , dès que j'entends « diff réseau » . RARP simplement aurait été la bonne méthode, mais apparemment les admin n'aiment pas autoriser son utilisation, on piquerait des OS entiers en l'utilisant sans délicatesse ?
Sinon, effectivement, comme proposé ailleurs, ajouter une adresse IP de plus sur l'interface, dans un sous-réseau complètement différent.
LÍ par contre qu'on puisse ajouter une ou plusieurs adresses IP sur une interface je dirais plutÍ´t d'accord, mais il me semble qu'elles sont obligées de respecter le plan d'adressage de la Box, si la Box ne reconnaÍ®t pas l'adresse elle va tenter de la router par defaut ? Il me semble que les outils qui conviennent dans tous les cas, sans besoin de connaÍ®tre le plan d'adressage de la Box mais avec l'autorisation datée et signée de l'admin ou le consentement du détenteur de la Box sont : fping et arping fping trouve arping confirme dyrmak -- A la hora de la ahora ++++ --- ++++ Linux operating system ++++ --- ++++
