What if we ignored all network cards altogether and focussed on "virtual SLIP". One can startup the emulator with emulated serial port to a Unix domain socket, e.g.
cohulip SLIP worked once if used with physical serial cards.
So in principle it should work with virtual serial, but simply test it.
No idea if it really works.
On the other hand why not use physical serial card of the host ?
ISA is not available anymore, but there are PCI COM cards and PCI COM cards work too in Coherent, as I have already mentioned on one of mu pages.
I would rather try with physical serial card.
In any case I can help as far as PCI COM configuration is Coherent is concerned.
It does not require extra driver.
What I have meant in my previous reply is , that for example in virtual box You can attach directly physical COM of the host. Like is the case with physical floppy as opposed to virtual floppy image.
Perhaps with qemu it is also possible. I cannot say if what You are trying to do is making physical serial card of the host directly available to Coherent.
If yes than it should work, I suspect.
va...@icpnet.pl wrote:
> On the other hand why not use physical serial card of the host ?
> ISA is not available anymore, but there are PCI COM cards and PCI COM
> cards work too in Coherent, as I have already mentioned on one of mu
> pages. I would rather try with physical serial card. In any case I can
> help as far as PCI COM configuration is Coherent is concerned. It does not
> require extra driver.
What I'm trying to do it "virtualize" the serial line and then hook it up to
Linux SLIP driver. If you have a kernel with the required NE2000 H/W I can
try to give it a go as well. I think a "net" executable with RealTek 8139
is more work.
Hans Bezemer wrote:
> What I'm trying to do it "virtualize" the serial line and then hook it up
> to Linux SLIP driver. If you have a kernel with the required NE2000 H/W I
> can try to give it a go as well. I think a "net" executable with RealTek
> 8139 is more work.
I think my scenario just bombed. "slattach" wants to see a DEVICE (starting
with /dev) and does some real fancy IOCTL "modemline" stuff with it. I
doubt very much it could work after looking at the "slattach" source code.
OK, now I understand what is Your goal. Hm. Although I do not know what do You mean by "hook".
What a role should this Linux driver play in the process ?
Do You want to use Linux as gateway ?
Perhaps ppp and pppd in mind ? One could eventually use ppp in Coherent and via serial port try to connect to pppd server in Linux ? Or You want to use ppp in Linux and try to connect to any pppd provider on Internet ?
I have once considered to add realtek support to net, but then I have written driver with tcp stack in kernel, so now it does not make much sense for me to do it. I am planning rather writing driver for Intel cards.
Besides having driver with sockets allows for easy porting of many gnu network applications. Net is too proprietary I would say.And not too fast.
BTW, ne2000 driver is in cohat kernel. Besides why are hesitating and not building Your own kernel with the help of ddk ? It is not difficult.
I do know the internals of Linux serial interface. So I cannot help a lot.
What about the following goal : login to linux, or generally to host.
Via serial interface. Having this one could connect to Internet using Linux lynx or mutt etc.
You attach serial physically , if it goes in qemu, and then try to connect to another Linux/Solaris box connected serially to the host computer.
Just a dust thought in the wind.
Andrzej.
va...@icpnet.pl wrote:
> What about the following goal : login to linux, or generally to host.
> Via serial interface. Having this one could connect to Internet using
> Linux lynx or mutt etc. You attach serial physically , if it goes in qemu,
> and then try to connect to another Linux/Solaris box connected serially to
> the host computer. Just a dust thought in the wind. Andrzej.
I did a quick test with the XCMALT terminal emulator:
But to no avail. If that doesn't work, real telnet does neither. Could have
been the connection timed out. Isn't a speedmonster either. ;-) But first
I'll try to compile minicom. I don't think XCMALT is something I like.
> I'll try to compile minicom. I don't think XCMALT is something I like.
> Hans Bezemer
You will find minicom somewhere in the old (tuhs,gopher archives).
What about ckermit ?
I assume that Your serial card in Linux host is connected to the modem or serially(null modem cable) to another computer's COM .
Andrzej
Is this parameter telnet:localhost:25 really neccessary ?
I would expect device name of the serial device in Linux.
I mean if we want to connect to the outside world via modem cable ?
It is just common sense , not that I know it for sure.
First of all in order to use any serial device application, let us say ckermit, etc we need the serial device to be available for Coherent.
It means during booting You should observe ifor example the following
COM1 1655a FIFO COM2 ... no uart
COM3 no uart COM4 no uart
produced by asy driver.
If You see only "no uart", it means no serial devices are available.
If I switch the serial device on in virtual box for example: COM1, IRQ 4 , 3F8
then I see ,during booting Coherent in virtual box, the above mentioned messages.
This is why I suspect , at least in virtual box, it is possible to connect to outside world from within Coherent virtual machine.
So You should achieve described minimal state of the Coherent after booting in qemu.
Andrzej
va...@icpnet.pl wrote:
> If You see only "no uart", it means no serial devices are available.
> If I switch the serial device on in virtual box for example: COM1, IRQ 4
> , 3F8 then I see ,during booting Coherent in virtual box, the above
> mentioned messages. This is why I suspect , at least in virtual box, it is
> possible to connect to outside world from within Coherent virtual machine.
> So You should achieve described minimal state of the Coherent after
> booting in qemu. Andrzej
There is nothing connected to my serial port in Linux, except for an old
Wyse-25. So I can't go outside that way. What I can try to do is figure out
whether it is possible to connect to telnet (as you suggested) and find my
way outside that way. That's what I attempted. Yes, I already found
minicom. See if the thing still compiles ;-)
Now I think , that it is not possible what You are going to do with "virtual serial". This is because Linux and Coherent cannot share "socket space".There is for example in virtualbox the possibility of sharing folders, but it will not work in Coherent.The only possibility is via real physical com device.
But if You have old wyse attached to Your Linux then try the following.
Attach in some way , using qemu, the Linux serial com to coherent virtual machine, so the coherent sees this com , and the corresponding message during boot of coherent is produced (FIFO etc). BTW did You add /dev/com1l to Your /etc/ttys ?
Then enable /dev/com1l in coherent via
enable /dev/com1l
or by setting the corrsponding byte manually in /etc/ttys to 1(better via enable).
For inbound connection this byte must be enabled, for outbound disabled.
OK, and You should see Coherent Login prompt on Your Wyse terminal.
There is another crazy scenario.
Start two virtual machines, with coherent, attach(via qemu) com1 to first and com2 to the second , then connect Your both physical ports on Your Linux with null modem cable, enable com1l in one of the coherent, and You should be able to login from coherent to another one.
OK, when You want to use real telnet, connect physically Your com1 in Linux box to com1 of another Linux box using null modem cable and You be able in principle to login into this second Linux from coherent in first linux box(after com1 in first linux was made available in qemu to coherent, but not virtually but physically).
Add-on to this scenario with two coherent virtual machines. Change it a little bit. Let the first be Coherent virtual and the second Linux virtual.And let them communicate via null modem cable. If You dont have two coms, but I think You should have, You can always add pci com card.
I don't see if my previous article made it, but I have to stop asking stupid
questions which I can answer myself. ;-) Yes, I disabled /dev/com1l and I
updated /etc/ttys and I confirmed that it's really disable right now.
Good tip though, first time I updated /etc/ttys and rebooted. Bad choice.
I did a quick test yesterday with an outbound serial port using cu. The
relevant parameters were:
(QEMU) -serial telnet:localhost:25
(Coherent) cu -l /dev/com1l dir
The SMTP server briefly identified itself, then disconnected (hung up from
Coherent's point of view). There might be a million reasons for this and
unless you have the golden tip I think I'm done and concentrate on
publishing what I got. Since this is my production machine there is only so
much tinkering I'd like to do. I depend on this thing working properly.
> Hans Bezemer wrote:
> I did a quick test yesterday with an outbound serial port using cu. The
> relevant parameters were:
> (QEMU) -serial telnet:localhost:25
> (Coherent) cu -l /dev/com1l dir
> The SMTP server briefly identified itself,
What does it mean "identified" ?
Did You observe any specific message in the system linux log ?
What exactly the message was ?
Was it after You have used cu program in Coherent machine?
This last point ic crucial.
then disconnected (hung up from
> Coherent's point of view). There might be a million reasons for this and
> unless you have the golden tip I think I'm done and concentrate on
> publishing what I got. Since this is my production machine there is only so
> much tinkering I'd like to do. I depend on this thing working properly.
> Thanks for your help.
> Hans Bezemer
As You know cu belongs to uucp family of programs, so I would expect that it awaits uucpd server on the other side.
On the other hand if really smtp server process was spawn in linux, which in itself is a good news for You, then it awaits for the specific messages from the client . And cu could not supply such messages.In other words cu and smtp server speak different languages. And in the low level smtp uses tcp. So one would have to start net in Coherent configured for serial device. As far as I can remember You do not have to start cu if You use net.You probably have checked it in net docs.
In any case cu has to have valid connection with uucpd server running in Linux , or generally on the other side of the connection, if You want to use it.
Some years ago I have even ported Taylor's uucp to coherent (can be found on my coherent page).But no support.
Getting uucpd to run in Linux is probably not extremely complicated but reading some docs or compiling is probable.
Simplest thing would be to begin from ckermit and modem.
I will try to find my old modem and I will check with ckermit in qemu or in virtual box , sometime next week.
I have no golden tip.
You could also ask in qemu forums or groups for suggestions.
Andrzej Popielewicz wrote:
> What does it mean "identified" ?
linux-471m.site ESMTP Postfix
That's what it said. Normally I expect it to say:
220 linux-471m.site ESMTP Postfix
That's what I get with a normal "telnet localhost 25". And that's exactly
what this QEMU switch should do: talk in "telnet" protocol. Note I could
not reestablish a viable connection. "cu" seemed to hang after sayig it was
connected.
> On the other hand if really smtp server process was spawn in linux,
> which in itself is a good news for You, then it awaits for the specific
> messages from the client . And cu could not supply such messages.In
> other words cu and smtp server speak different languages. And in the low
> level smtp uses tcp. So one would have to start net in Coherent
> configured for serial device. As far as I can remember You do not have
> to start cu if You use net.You probably have checked it in net docs.
Well normally SMTP sits around asking for specific ASCII commands
like "HELO".
> Simplest thing would be to begin from ckermit and modem.
Well, that was one reason I took "cu": it allows you to open a COM port
without much hanky panky and talk to the program on the other side. Just
what I needed. But maybe for this purpose ckermit and/or modem are better
suited.
> Andrzej Popielewicz wrote:
>> What does it mean "identified" ?
> linux-471m.site ESMTP Postfix
> That's what it said. Normally I expect it to say:
> 220 linux-471m.site ESMTP Postfix
> That's what I get with a normal "telnet localhost 25". And that's exactly
> what this QEMU switch should do: talk in "telnet" protocol.
Question is , who has talked to smtp server ? qemu ? For sure not cu.
Note I could
> not reestablish a viable connection. "cu" seemed to hang after sayig it was
> connected.
Question is to what it was connected ?
>> On the other hand if really smtp server process was spawn in linux,
>> which in itself is a good news for You, then it awaits for the specific
>> messages from the client . And cu could not supply such messages.In
>> other words cu and smtp server speak different languages. And in the low
>> level smtp uses tcp. So one would have to start net in Coherent
>> configured for serial device. As far as I can remember You do not have
>> to start cu if You use net.You probably have checked it in net docs.
> Well normally SMTP sits around asking for specific ASCII commands
> like "HELO".
But first IP protocol is active, then on top of it tcp connection is established and then on top of tcp smtp text protocol is used. cu is not capable of sending ip headers, not it is capable of sending tcp headers it means to establish tcp connection.Net is capable of sending ip and tcp headers and knows about smtp text protocol.
It means messages from cu could not reach ip level, it means they could not reach smtp server. If smtp process was activated it was because qemu has "done" something. I do not know qemu internals and I am not going to study this.
If You want to continue smtp way, I would try with net
>> Simplest thing would be to begin from ckermit and modem.
> Well, that was one reason I took "cu": it allows you to open a COM port
> without much hanky panky and talk to the program on the other side.
But via uucpd I suspect.
Just
> what I needed. But maybe for this purpose ckermit and/or modem are better
> suited.
ckermit was the only program with which I was able to connect in a stable way to outside server. I have used it to connect via modem with terminal server at our university .
It practically works out of the box.It is industry class program, EOL btw.
Last version ported by me is on my university page. But that older version supplied originally with Coherent is fine too.
But if You have modem , there is simple test mentioned in Coherent handbook. You do not need any program to test the connection. Simply write some characters to the com port using echo command. You should oberve change of the lights on the modem panel.
For example
echo "HELO linux pinquin" > /dev/com1l
Same result, only this time ckermit doesn't hang up. Instead it shows
TWO "ckermits" hanging on color2 both in "ttywait" mode. ckermit seems
stuck, but CRTL-\+C still works.
As I expected , it should not work with certain tcp process with port 25.
It means qemu makes no appropriate conditions available on the other side of connection.
I would suggest to test with the modem and such configuration of qemu, that serial line is made accesible to guest, but without specifying tcp port.
It would test , that coherent is at all capable of using modem under qemu.
I will try with virtual box and modem.Please allow some time for delay.
