Bonjour, il n'y a pas très longtemps certains d'entre vous m'on donné des
infos très intéressantes sur comment mettre en place un loopback sur port
série. Mais j'ai besoin de plus d'infos...
Je vous explique mon projet : je souhaite développer des applis pour un
vieux 8bits et pour se faire utiliser un emulateur qui fonctionne sous
linux (xkegs en l'occurence). En effet, développer et tester sur la machine
réelle est trop fastidieux et inefficace.
Cette émulateur peut émuler les ports séries de deux façons :
- en utilisant les ports réels
- via deux sockets (une pour chaque port série de la machine émulée)
La première solution serait la plus simple, avec d'un côté un serveur slip
et de l'autre l'émulateur (soit par un loopback virtuel, soit par un cable
null modem entre les deux ports séries du PC)
Manque de pot, l'émulation des ports séries est plus ou moins bien
implémentées dans l'émulateur (dixit l'auteur) et chez moi en tout cas la
première solution ne fonctionne pas du tout. Il me reste donc les sockets
(j'ai testé, ça marche).
L'idée serait de trouver une solution permettant d'établir un lien entre le
serveur slip et le socket, quitte à écrire une petite application en C pour
y arriver.
Mais je ne sais vraiment pas par où commencer... D'ailleurs sur ma
distribution (RH9) je ne dispose même pas de slip (bon je vais fouiner sur
rpmfind).
Il y a aussi d'autres idées :
- utiliser slattach puis ifconfig pour créer une interface (reste ensuite à
trouver un moyen de communiquer avec les sockets)
- développer une appli en C qui capture tous les trames ethernet, envoi
celles qui le concernent à l'émulateur (écrire dans le socket), et réaliser
le contraire : lire le socket et forger des trames.
Le problème avec la deuxième solution c'est que j'ai l'impression que ça
devient extrêmement spécifique à l'émulateur alors que l'objectif final est
que ça puisse tourner sur la machine réelle...
Voila, c'est un peu en vrac mais si vous avez des idées (surtout sur la
possibilité de mettre en relation slip et un socket)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
no_spam
On Thu, 09 Sep 2004 08:33:11 +0000, Zouplaz wrote:
Bonjour, il n'y a pas très longtemps certains d'entre vous m'on donné des infos très intéressantes sur comment mettre en place un loopback sur port série. Mais j'ai besoin de plus d'infos...
Je vous explique mon projet : je souhaite développer des applis pour un vieux 8bits et pour se faire utiliser un emulateur qui fonctionne sous linux (xkegs en l'occurence). En effet, développer et tester sur la machine réelle est trop fastidieux et inefficace.
Cette émulateur peut émuler les ports séries de deux façons : - en utilisant les ports réels - via deux sockets (une pour chaque port série de la machine émulée)
La première solution serait la plus simple, avec d'un côté un serveur slip et de l'autre l'émulateur (soit par un loopback virtuel, soit par un cable null modem entre les deux ports séries du PC)
Manque de pot, l'émulation des ports séries est plus ou moins bien implémentées dans l'émulateur (dixit l'auteur) et chez moi en tout cas la première solution ne fonctionne pas du tout. Il me reste donc les sockets (j'ai testé, ça marche).
Tu peux peut-être l'aider à améliorer l'émulation des ports séries. Si ce sont des ports série de type PC, le code de Bochs ou qemu te tends les bras. Si ce sont des ports série de type Mac, le code de Basilik devrait faire l'affaire...
L'idée serait de trouver une solution permettant d'établir un lien entre le serveur slip et le socket, quitte à écrire une petite application en C pour y arriver.
J'ai une question: pourquoi utilises tu slip ? Il me semble que ppp serait plus souple d'emploi et plus générique. Si ton serveur est capable d'écrire sur sa sortie standard ou un autre fd, le programme socket fera ton affaire: il permet de rediriger un fd vers une socket ou l'inverse.
On Thu, 09 Sep 2004 08:33:11 +0000, Zouplaz wrote:
Bonjour, il n'y a pas très longtemps certains d'entre vous m'on donné des
infos très intéressantes sur comment mettre en place un loopback sur port
série. Mais j'ai besoin de plus d'infos...
Je vous explique mon projet : je souhaite développer des applis pour un
vieux 8bits et pour se faire utiliser un emulateur qui fonctionne sous
linux (xkegs en l'occurence). En effet, développer et tester sur la machine
réelle est trop fastidieux et inefficace.
Cette émulateur peut émuler les ports séries de deux façons :
- en utilisant les ports réels
- via deux sockets (une pour chaque port série de la machine émulée)
La première solution serait la plus simple, avec d'un côté un serveur slip
et de l'autre l'émulateur (soit par un loopback virtuel, soit par un cable
null modem entre les deux ports séries du PC)
Manque de pot, l'émulation des ports séries est plus ou moins bien
implémentées dans l'émulateur (dixit l'auteur) et chez moi en tout cas la
première solution ne fonctionne pas du tout. Il me reste donc les sockets
(j'ai testé, ça marche).
Tu peux peut-être l'aider à améliorer l'émulation des ports séries.
Si ce sont des ports série de type PC, le code de Bochs ou qemu te tends
les bras. Si ce sont des ports série de type Mac, le code de Basilik
devrait faire l'affaire...
L'idée serait de trouver une solution permettant d'établir un lien entre le
serveur slip et le socket, quitte à écrire une petite application en C pour
y arriver.
J'ai une question: pourquoi utilises tu slip ? Il me semble que ppp serait
plus souple d'emploi et plus générique.
Si ton serveur est capable d'écrire sur sa sortie standard ou un autre
fd, le programme socket fera ton affaire: il permet de rediriger un fd
vers une socket ou l'inverse.
On Thu, 09 Sep 2004 08:33:11 +0000, Zouplaz wrote:
Bonjour, il n'y a pas très longtemps certains d'entre vous m'on donné des infos très intéressantes sur comment mettre en place un loopback sur port série. Mais j'ai besoin de plus d'infos...
Je vous explique mon projet : je souhaite développer des applis pour un vieux 8bits et pour se faire utiliser un emulateur qui fonctionne sous linux (xkegs en l'occurence). En effet, développer et tester sur la machine réelle est trop fastidieux et inefficace.
Cette émulateur peut émuler les ports séries de deux façons : - en utilisant les ports réels - via deux sockets (une pour chaque port série de la machine émulée)
La première solution serait la plus simple, avec d'un côté un serveur slip et de l'autre l'émulateur (soit par un loopback virtuel, soit par un cable null modem entre les deux ports séries du PC)
Manque de pot, l'émulation des ports séries est plus ou moins bien implémentées dans l'émulateur (dixit l'auteur) et chez moi en tout cas la première solution ne fonctionne pas du tout. Il me reste donc les sockets (j'ai testé, ça marche).
Tu peux peut-être l'aider à améliorer l'émulation des ports séries. Si ce sont des ports série de type PC, le code de Bochs ou qemu te tends les bras. Si ce sont des ports série de type Mac, le code de Basilik devrait faire l'affaire...
L'idée serait de trouver une solution permettant d'établir un lien entre le serveur slip et le socket, quitte à écrire une petite application en C pour y arriver.
J'ai une question: pourquoi utilises tu slip ? Il me semble que ppp serait plus souple d'emploi et plus générique. Si ton serveur est capable d'écrire sur sa sortie standard ou un autre fd, le programme socket fera ton affaire: il permet de rediriger un fd vers une socket ou l'inverse.
Zouplaz
no_spam - :
On Thu, 09 Sep 2004 08:33:11 +0000, Zouplaz wrote:
Manque de pot, l'émulation des ports séries est plus ou moins bien implémentées dans l'émulateur (dixit l'auteur) et chez moi en tout cas la première solution ne fonctionne pas du tout. Il me reste donc les sockets (j'ai testé, ça marche).
Tu peux peut-être l'aider à améliorer l'émulation des ports séries. Si ce sont des ports série de type PC, le code de Bochs ou qemu te tends les bras. Si ce sont des ports série de type Mac, le code de Basilik devrait faire l'affaire...
Heu je m'en sens pas vraiment capable...
L'idée serait de trouver une solution permettant d'établir un lien entre le serveur slip et le socket, quitte à écrire une petite application en C pour y arriver.
J'ai une question: pourquoi utilises tu slip ? Il me semble que ppp serait plus souple d'emploi et plus générique. Si ton serveur est capable d'écrire sur sa sortie standard ou un autre fd, le programme socket fera ton affaire: il permet de rediriger un fd vers une socket ou l'inverse.
Parce qu'écrire un client slip est sans doute plus simple (m'enfin d'après ce qu'on m'a dit)
Le serveur c'est l'émulateur, et il écrit et lit sur deux sockets (6501 et 6502, chacun simule un port série)... Mon but c'est d'écrire du code qui fonctionne dans l'émulateur et qui écrive et lise sur le port série (donc le client slip ou ppp).
Je dois donc trouver un moyen d'interconnecter le serveur slip ou ppp avec le socket utilisé... Et pour l'instant je n'y arrive pas malgré deux bonnes heures passées à googeliser !
Si avec ppp c'est faisable, je suis preneur !
Tu parle du programme "socket", est-ce une commande particulière ? Si oui, où puis-je la télécharger ? J'ai tenté une recherche mais le terme est trop générique.
Merci
no_spam - l_indien_no_more_spams@magic.fr :
On Thu, 09 Sep 2004 08:33:11 +0000, Zouplaz wrote:
Manque de pot, l'émulation des ports séries est plus ou moins bien
implémentées dans l'émulateur (dixit l'auteur) et chez moi en tout
cas la première solution ne fonctionne pas du tout. Il me reste donc
les sockets (j'ai testé, ça marche).
Tu peux peut-être l'aider à améliorer l'émulation des ports séries.
Si ce sont des ports série de type PC, le code de Bochs ou qemu te
tends les bras. Si ce sont des ports série de type Mac, le code de
Basilik devrait faire l'affaire...
Heu je m'en sens pas vraiment capable...
L'idée serait de trouver une solution permettant d'établir un lien
entre le serveur slip et le socket, quitte à écrire une petite
application en C pour y arriver.
J'ai une question: pourquoi utilises tu slip ? Il me semble que ppp
serait plus souple d'emploi et plus générique.
Si ton serveur est capable d'écrire sur sa sortie standard ou un autre
fd, le programme socket fera ton affaire: il permet de rediriger un fd
vers une socket ou l'inverse.
Parce qu'écrire un client slip est sans doute plus simple (m'enfin d'après
ce qu'on m'a dit)
Le serveur c'est l'émulateur, et il écrit et lit sur deux sockets (6501 et
6502, chacun simule un port série)... Mon but c'est d'écrire du code qui
fonctionne dans l'émulateur et qui écrive et lise sur le port série (donc
le client slip ou ppp).
Je dois donc trouver un moyen d'interconnecter le serveur slip ou ppp avec
le socket utilisé... Et pour l'instant je n'y arrive pas malgré deux bonnes
heures passées à googeliser !
Si avec ppp c'est faisable, je suis preneur !
Tu parle du programme "socket", est-ce une commande particulière ?
Si oui, où puis-je la télécharger ? J'ai tenté une recherche mais le terme
est trop générique.
On Thu, 09 Sep 2004 08:33:11 +0000, Zouplaz wrote:
Manque de pot, l'émulation des ports séries est plus ou moins bien implémentées dans l'émulateur (dixit l'auteur) et chez moi en tout cas la première solution ne fonctionne pas du tout. Il me reste donc les sockets (j'ai testé, ça marche).
Tu peux peut-être l'aider à améliorer l'émulation des ports séries. Si ce sont des ports série de type PC, le code de Bochs ou qemu te tends les bras. Si ce sont des ports série de type Mac, le code de Basilik devrait faire l'affaire...
Heu je m'en sens pas vraiment capable...
L'idée serait de trouver une solution permettant d'établir un lien entre le serveur slip et le socket, quitte à écrire une petite application en C pour y arriver.
J'ai une question: pourquoi utilises tu slip ? Il me semble que ppp serait plus souple d'emploi et plus générique. Si ton serveur est capable d'écrire sur sa sortie standard ou un autre fd, le programme socket fera ton affaire: il permet de rediriger un fd vers une socket ou l'inverse.
Parce qu'écrire un client slip est sans doute plus simple (m'enfin d'après ce qu'on m'a dit)
Le serveur c'est l'émulateur, et il écrit et lit sur deux sockets (6501 et 6502, chacun simule un port série)... Mon but c'est d'écrire du code qui fonctionne dans l'émulateur et qui écrive et lise sur le port série (donc le client slip ou ppp).
Je dois donc trouver un moyen d'interconnecter le serveur slip ou ppp avec le socket utilisé... Et pour l'instant je n'y arrive pas malgré deux bonnes heures passées à googeliser !
Si avec ppp c'est faisable, je suis preneur !
Tu parle du programme "socket", est-ce une commande particulière ? Si oui, où puis-je la télécharger ? J'ai tenté une recherche mais le terme est trop générique.
Merci
Nicolas George
Zouplaz wrote in message :
Je dois donc trouver un moyen d'interconnecter le serveur slip ou ppp avec le socket utilisé... Et pour l'instant je n'y arrive pas malgré deux bonnes heures passées à googeliser !
On va reprendre les petits dessins de là dernière fois. Ton émulateur fait ainsi :
Si tu veux un autre programme à la place de pppd, il va falloir faire l'ensemble de tout ceci toi-même :
| {------------<| |
La partie réseau se fait avec les fonctions socket et connect, la partie pseudo-tty avec posix_openpt (ou open sur /dev/ptmx), grantpt, unlockpt et ptsname, dont l'usage est décrit dans la Single Unix Specification (page décrivant posix_openpt sur <URL: http://www.unix.org/version3/ >, consultable gratuitement après inscription sans spam).
Une méthode alternative peut être simplement de lancer :
socket localhost 6501 0<>/dev/ptyp0 >&0
Dans ce cas, le pseudo-tty à utiliser est /dev/ttyp0, tout simplement. Mais c'est un peu moins fiable.
Tu parle du programme "socket", est-ce une commande particulière ?
Description: Multi purpose socket tool The socket program is a simple tool for socket based connections. It can be used to create simple daemons (in both standalone and inetd mode), to connect to other daemons or to redirect ports.
<URL: ftp://ftp.cs.tu-berlin.de/ >
Zouplaz wrote in message <Xns955F79390551FZoupla@212.27.42.78>:
Je dois donc trouver un moyen d'interconnecter le serveur slip ou ppp avec
le socket utilisé... Et pour l'instant je n'y arrive pas malgré deux bonnes
heures passées à googeliser !
On va reprendre les petits dessins de là dernière fois. Ton émulateur fait
ainsi :
Si tu veux un autre programme à la place de pppd, il va falloir faire
l'ensemble de tout ceci toi-même :
|
{------------<|
|
La partie réseau se fait avec les fonctions socket et connect, la partie
pseudo-tty avec posix_openpt (ou open sur /dev/ptmx), grantpt, unlockpt et
ptsname, dont l'usage est décrit dans la Single Unix Specification (page
décrivant posix_openpt sur <URL: http://www.unix.org/version3/ >,
consultable gratuitement après inscription sans spam).
Une méthode alternative peut être simplement de lancer :
socket localhost 6501 0<>/dev/ptyp0 >&0
Dans ce cas, le pseudo-tty à utiliser est /dev/ttyp0, tout simplement. Mais
c'est un peu moins fiable.
Tu parle du programme "socket", est-ce une commande particulière ?
Description: Multi purpose socket tool
The socket program is a simple tool for socket based connections. It
can be used to create simple daemons (in both standalone and inetd
mode), to connect to other daemons or to redirect ports.
Je dois donc trouver un moyen d'interconnecter le serveur slip ou ppp avec le socket utilisé... Et pour l'instant je n'y arrive pas malgré deux bonnes heures passées à googeliser !
On va reprendre les petits dessins de là dernière fois. Ton émulateur fait ainsi :
Si tu veux un autre programme à la place de pppd, il va falloir faire l'ensemble de tout ceci toi-même :
| {------------<| |
La partie réseau se fait avec les fonctions socket et connect, la partie pseudo-tty avec posix_openpt (ou open sur /dev/ptmx), grantpt, unlockpt et ptsname, dont l'usage est décrit dans la Single Unix Specification (page décrivant posix_openpt sur <URL: http://www.unix.org/version3/ >, consultable gratuitement après inscription sans spam).
Une méthode alternative peut être simplement de lancer :
socket localhost 6501 0<>/dev/ptyp0 >&0
Dans ce cas, le pseudo-tty à utiliser est /dev/ttyp0, tout simplement. Mais c'est un peu moins fiable.
Tu parle du programme "socket", est-ce une commande particulière ?
Description: Multi purpose socket tool The socket program is a simple tool for socket based connections. It can be used to create simple daemons (in both standalone and inetd mode), to connect to other daemons or to redirect ports.
<URL: ftp://ftp.cs.tu-berlin.de/ >
no_spam
On Thu, 09 Sep 2004 09:54:57 +0000, Zouplaz wrote:
no_spam - :
On Thu, 09 Sep 2004 08:33:11 +0000, Zouplaz wrote:
Manque de pot, l'émulation des ports séries est plus ou moins bien implémentées dans l'émulateur (dixit l'auteur) et chez moi en tout cas la première solution ne fonctionne pas du tout. Il me reste donc les sockets (j'ai testé, ça marche).
Tu peux peut-être l'aider à améliorer l'émulation des ports séries. Si ce sont des ports série de type PC, le code de Bochs ou qemu te tends les bras. Si ce sont des ports série de type Mac, le code de Basilik devrait faire l'affaire...
Heu je m'en sens pas vraiment capable...
Souffle le dans l'oreille de l'auteur, alors ;-)
L'idée serait de trouver une solution permettant d'établir un lien entre le serveur slip et le socket, quitte à écrire une petite application en C pour y arriver.
J'ai une question: pourquoi utilises tu slip ? Il me semble que ppp serait plus souple d'emploi et plus générique. Si ton serveur est capable d'écrire sur sa sortie standard ou un autre fd, le programme socket fera ton affaire: il permet de rediriger un fd vers une socket ou l'inverse.
Parce qu'écrire un client slip est sans doute plus simple (m'enfin d'après ce qu'on m'a dit)
Sans doute, en effet. Quoi qu'il parait que ppp, si on implémente juste la base nécessaire, est assez simple.
[...]
Tu parle du programme "socket", est-ce une commande particulière ? Si oui, où puis-je la télécharger ? J'ai tenté une recherche mais le terme est trop générique.
On Thu, 09 Sep 2004 09:54:57 +0000, Zouplaz wrote:
no_spam - l_indien_no_more_spams@magic.fr :
On Thu, 09 Sep 2004 08:33:11 +0000, Zouplaz wrote:
Manque de pot, l'émulation des ports séries est plus ou moins bien
implémentées dans l'émulateur (dixit l'auteur) et chez moi en tout
cas la première solution ne fonctionne pas du tout. Il me reste donc
les sockets (j'ai testé, ça marche).
Tu peux peut-être l'aider à améliorer l'émulation des ports séries.
Si ce sont des ports série de type PC, le code de Bochs ou qemu te
tends les bras. Si ce sont des ports série de type Mac, le code de
Basilik devrait faire l'affaire...
Heu je m'en sens pas vraiment capable...
Souffle le dans l'oreille de l'auteur, alors ;-)
L'idée serait de trouver une solution permettant d'établir un lien
entre le serveur slip et le socket, quitte à écrire une petite
application en C pour y arriver.
J'ai une question: pourquoi utilises tu slip ? Il me semble que ppp
serait plus souple d'emploi et plus générique.
Si ton serveur est capable d'écrire sur sa sortie standard ou un autre
fd, le programme socket fera ton affaire: il permet de rediriger un fd
vers une socket ou l'inverse.
Parce qu'écrire un client slip est sans doute plus simple (m'enfin d'après
ce qu'on m'a dit)
Sans doute, en effet. Quoi qu'il parait que ppp, si on implémente juste
la base nécessaire, est assez simple.
[...]
Tu parle du programme "socket", est-ce une commande particulière ?
Si oui, où puis-je la télécharger ? J'ai tenté une recherche mais le terme
est trop générique.
On Thu, 09 Sep 2004 09:54:57 +0000, Zouplaz wrote:
no_spam - :
On Thu, 09 Sep 2004 08:33:11 +0000, Zouplaz wrote:
Manque de pot, l'émulation des ports séries est plus ou moins bien implémentées dans l'émulateur (dixit l'auteur) et chez moi en tout cas la première solution ne fonctionne pas du tout. Il me reste donc les sockets (j'ai testé, ça marche).
Tu peux peut-être l'aider à améliorer l'émulation des ports séries. Si ce sont des ports série de type PC, le code de Bochs ou qemu te tends les bras. Si ce sont des ports série de type Mac, le code de Basilik devrait faire l'affaire...
Heu je m'en sens pas vraiment capable...
Souffle le dans l'oreille de l'auteur, alors ;-)
L'idée serait de trouver une solution permettant d'établir un lien entre le serveur slip et le socket, quitte à écrire une petite application en C pour y arriver.
J'ai une question: pourquoi utilises tu slip ? Il me semble que ppp serait plus souple d'emploi et plus générique. Si ton serveur est capable d'écrire sur sa sortie standard ou un autre fd, le programme socket fera ton affaire: il permet de rediriger un fd vers une socket ou l'inverse.
Parce qu'écrire un client slip est sans doute plus simple (m'enfin d'après ce qu'on m'a dit)
Sans doute, en effet. Quoi qu'il parait que ppp, si on implémente juste la base nécessaire, est assez simple.
[...]
Tu parle du programme "socket", est-ce une commande particulière ? Si oui, où puis-je la télécharger ? J'ai tenté une recherche mais le terme est trop générique.
Il me manque juste une brique : la commande pty, elle n'est pas dispo sur mon système.
Ce n'est pas une commande, c'est une option à pppd, à passer en ligne de commande ou dans le fichier d'options.
Zouplaz
Nicolas George - nicolas$ :
Zouplaz wrote in message :
Il me manque juste une brique : la commande pty, elle n'est pas dispo sur mon système.
Ce n'est pas une commande, c'est une option à pppd, à passer en ligne de commande ou dans le fichier d'options.
Merci j'avais pas compris...
Mais ça fonctionne !!!
- D'abord le test avec socket localhost 6501 : les données transitent bien entre l'émulateur et l'hote linux (j'ai vérifié dans les deux sens, ça fonctionne stdin -> série in et série out -> stdout)
- Ensuite j'ai fait plusieus essais pour en arriver au final à :
pppd tourne quelques instants puis "raccroche", normal vu qu'il n'y a rien au bout MAIS, au miracle, durant ce temps je vois apparaitre sur l'écran du 8bits émulé l'équivalent ASCII des données émises par pppd... Et c'est le top !
Encore une fois un grand merci, j'y serais jamais arrivé tout seul !
Maintenant je n'ai "plus" qu'à affiner la config pppd et me mettre à programmer du côté du 8bits (haaaa quel bain de jouvence !)...
Nicolas George - nicolas$george@salle-s.org :
Zouplaz wrote in message <Xns955F8C08BB370Zoupla@212.27.42.74>:
Il me manque juste une brique : la commande pty, elle n'est pas dispo
sur mon système.
Ce n'est pas une commande, c'est une option à pppd, à passer en ligne
de commande ou dans le fichier d'options.
Merci j'avais pas compris...
Mais ça fonctionne !!!
- D'abord le test avec socket localhost 6501 : les données transitent bien
entre l'émulateur et l'hote linux (j'ai vérifié dans les deux sens, ça
fonctionne stdin -> série in et série out -> stdout)
- Ensuite j'ai fait plusieus essais pour en arriver au final à :
pppd tourne quelques instants puis "raccroche", normal vu qu'il n'y a rien
au bout MAIS, au miracle, durant ce temps je vois apparaitre sur l'écran du
8bits émulé l'équivalent ASCII des données émises par pppd... Et c'est le
top !
Encore une fois un grand merci, j'y serais jamais arrivé tout seul !
Maintenant je n'ai "plus" qu'à affiner la config pppd et me mettre à
programmer du côté du 8bits (haaaa quel bain de jouvence !)...
Il me manque juste une brique : la commande pty, elle n'est pas dispo sur mon système.
Ce n'est pas une commande, c'est une option à pppd, à passer en ligne de commande ou dans le fichier d'options.
Merci j'avais pas compris...
Mais ça fonctionne !!!
- D'abord le test avec socket localhost 6501 : les données transitent bien entre l'émulateur et l'hote linux (j'ai vérifié dans les deux sens, ça fonctionne stdin -> série in et série out -> stdout)
- Ensuite j'ai fait plusieus essais pour en arriver au final à :
pppd tourne quelques instants puis "raccroche", normal vu qu'il n'y a rien au bout MAIS, au miracle, durant ce temps je vois apparaitre sur l'écran du 8bits émulé l'équivalent ASCII des données émises par pppd... Et c'est le top !
Encore une fois un grand merci, j'y serais jamais arrivé tout seul !
Maintenant je n'ai "plus" qu'à affiner la config pppd et me mettre à programmer du côté du 8bits (haaaa quel bain de jouvence !)...
