Slip sockets ?

Le
Zouplaz
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)


Merci
Vos réponses
Trier par : date / pertinence
no_spam
Le #1427982
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
Le #1427980
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


Nicolas George
Le #1141940
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 :

machine virtuelle
+------------------+
| |
| | | tcp/6501
| |>---[
| | |
| |
| | | tcp/6502
| |>---[
| | |
| |
+------------------+

Ce que tu aimerais, si j'ai bien compris, c'est ceci (je ne dessine plus
qu'un port pour simplifier) :

+------------------+
| |
| | | |
| |>--------------<| programme de ton choix
| | | |
| |
+------------------+

Avec éventuellement « programme de ton choix » = pppd. Ce qu'il te faut,
donc, c'est quelque chose capable de faire ceci :

|
{------------<|
|

(où { représente une connexion réseau cliente)

Le plus dur, c'est de créer le pseudo-tty. Si « programme de ton choix est
pppd, on a vu qu'il avait déjà la partie

|
--<|
|

incorporée (avec la commande pty). Il manque la partie

{----------

que le programme socket peut très bien fournir. Donc si on donne l'option

pty "exec socket localhost 6501"

à pppd, on obtient ceci :

+------------------+
| |
| | | tcp/6501 |
| |>---[{----------- socket --<| pppd
| | | |
| |
+------------------+

Qui est bien ce qui est voulu.

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 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.


no_spam
Le #1141938
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.


Essaye ceci:
http://packages.qa.debian.org/s/socket.html



Zouplaz
Le #1141803
Merci encore pour ces explications...

Il me manque juste une brique : la commande pty, elle n'est pas dispo sur
mon système.

J'ai cherché sur rpmfind mais rien de significatif n'est sorti (à part un
rpm, pty-redir, proposé pour une disto bizarre)


Comment se fait-il que cette commande ne soit pas dispo d'origine sur mon
système ? Ca semble être une commande de base...
Nicolas George
Le #1141667
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.

Zouplaz
Le #1141522
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 receive-all novj dump logfile ./ppp.log debug pty "exec socket
localhost 6501"

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 !)...


Publicité
Poster une réponse
Anonyme