Kermit via PPP under DOS?
Frank da Cruz
In article <om202d9...@tees.cs.ualberta.ca>,
Vladimir Alexiev <vlad...@cs.ualberta.ca> wrote:
: In article <60dt7d$d...@f1n1.spenet.wfu.edu>
: matt...@wfu.edu (Rick Matthews) writes:
: > Can anyone one tell me how to set up a PPP connection under DOS?
: >
: There's two free PPP implementations for DOS, EPPPD (in file dosppp*.zip) and
: Merit PPP (in etherppp or ethernew). EPPPD is smaller and probably more
: robust. You can find both at http://www.cs.ualberta.ca/~vladimir/dos-tcp/
: (I've put some informational files in the zips too).
:
: In article <60dveo$q16$1...@apakabar.cc.columbia.edu>
: f...@watsun.cc.columbia.edu (Frank da Cruz) writes:
:
: > 2. Read Appendix II of MSK315.DOC.
: Frank, I'd recommend dosppp05.zip (EPPPD) instead. It's smaller and probably
: more robust (it's a port of Linux pppd). If you like, I can write up
: something about the setup that worked for me.
:
Yes, please, and post it here. Thanks. We do not claim to be DOS PPP
experts. We tried many DOS PPP packages and this was the first we found
that worked at all, so we stopped there (having lots of other things to do).
Of course, additional hints, proven recipes, etc, are welcome, especially now
that many ISPs, universities, etc, are cutting off shell access and accept
only PPP logins on the assumption that the only client that matters any more
is a Web browser.
: > Begin by using MS-DOS Kermit ot dial up the terminal server at your
: > Internet Service Provider and tell it who you are and what protocol you
: > wish to use over the line.
:
: Merit PPP's dialer is probably sufficient for this step, but of course one
: could use Kermit too.
:
We just wrote up a procedure that worked, not every possible procedure;
additional contributions are most welcome.
: You then advise to quit kermit, then start it again and do "run
: startppp.bat". I don't see a reason for that, why should you quit then
: reenter kermit? On the other hand, it's probably better to run startppp.bat
: outside of kermit, so as not to put the TSR ppp on top of kermit and
: fragment the memory.
:
Exactly. DOS: The Do-It-Yourself Operating System :-)
: For Windows, one can probably run MS DOS Kermit in a DOS box, by using
: PKTMUX or some such contraption.
:
Anybody is of course welcome to experiment with building an elaborate "Shim
Wedding Cake" (PKTMUX, ODIPKT, WINPKT, NDISPKT, NDIS3PKT, etc), but you're
pretty much on your own for that (would-be PKTMUX users, in particular, are
advised to read the entire PKTMUX manual before attempting to use this
approach) -- especially in Windows 95, NT, and OS/2. We simply do not have
the resources to support it when there is another alternative that "just
works". In plain DOS of course (as opposed to a "DOS box" of Windows, OS/2,
Linux, etc), you have no other choice, and we'll do our best to help you if
you need it.
- Frank
Vladimir Alexiev
> Can anyone one tell me how to set up a PPP connection under DOS?
There's two free PPP implementations for DOS, EPPPD (in file dosppp*.zip) and
Merit PPP (in etherppp or ethernew). EPPPD is smaller and probably more
robust. You can find both at http://www.cs.ualberta.ca/~vladimir/dos-tcp/
(I've put some informational files in the zips too).
> I'll want to use Kermit for telneting, and I will also want to use a DOS pop
> mail client. Pegasus?
Yes, Pegasus can do it. However, I find it a bit bulky, and I prefer another
line of programs
- POPMail is only mail. Can't compose offline though.
- NUPop is mail and telnet (but much slower than kermit), and also gopher and
ftp in the latest version. I use version 1.03 because it's smaller.
- Minuet is mail, news, gopher, web browser.
In article <60dveo$q16$1...@apakabar.cc.columbia.edu> f...@watsun.cc.columbia.edu (Frank da Cruz) writes:
> 2. Read Appendix II of MSK315.DOC.
Frank, I'd recommend dosppp05.zip (EPPPD) instead. It's smaller and probably
more robust (it's a port of Linux pppd). If you like, I can write up something
about the setup that worked for me. Some minor points about the "Kermit+PPP"
appendix:
> Begin by using MS-DOS Kermit ot dial up the terminal server at your Internet
> Service Provider and tell it who you are and what protocol you wish to use
> over the line.
Merit PPP's dialer is probably sufficient for this step, but of course one
could use Kermit too.
You then advise to quit kermit, then start it again and do "run startppp.bat".
I don't see a reason for that, why should you quit then reenter kermit? On the
other hand, it's probably better to run startppp.bat outside of kermit, so as
not to put the TSR ppp on top of kermit and fragment the memory.
> : I'll want to use Kermit for telneting, and I will also want
> : to use a DOS pop mail client.
> Not at the same time as Kermit. If you want to have multiple TCP/IP clients
> going at once, you'll need to run Windows, Linux, OS/2, or some other
> multitasking system.
DesqView...
> And in that case you'll need a different Kermit that is a regular Winsock,
> Berkeley sockets, or IBM TCP/IP client.
For Windows, one can probably run MS DOS Kermit in a DOS box, by using PKTMUX
or some such contraption. But if your PC can run Windows, I don't see why
you'd prefer to run DOS Kermit anyway. But if you can only run DesqView or
some other task switcher (eg DoubleDOS), then PKTMUX may allow you to run more
than one TCP client.
Regards, Vlad
Frank da Cruz
In article <60dt7d$d...@f1n1.spenet.wfu.edu>,
Rick Matthews <matt...@wfu.edu> wrote:
: Can anyone one tell me how to set up a PPP connection under DOS?
:
1. Download the MS-DOS Kermit 3.15 update announced here a few days ago:
ftp://kermit.columbia.edu/kermit/archives/msk315.zip.
2. Read Appendix II of MSK315.DOC.
: I'll want to use Kermit for telneting, and I will also want
: to use a DOS pop mail client. Pegasus?
:
Not at the same time as Kermit. If you want to have multiple TCP/IP clients
going at once, you'll need to run Windows, Linux, OS/2, or some other
multitasking system. And in that case you'll need a different Kermit that is
a regular Winsock, Berkeley sockets, or IBM TCP/IP client. More info at our
website:
http://www.columbia.edu/kermit/
- Frank
Rick Matthews
Can anyone one tell me how to set up a PPP connection under DOS?
I'll want to use Kermit for telneting, and I will also want
to use a DOS pop mail client. Pegasus?
Thanks.
--
Rick Matthews matt...@wfu.edu
Department of Physics http://www.wfu.edu/%7Ematthews
Wake Forest University 910-759-5340 (Voice)
Winston-Salem, NC 27109-7507 910-759-6142 (FAX)
USA
Joe Doupnik
This is discussed in detail in the MSK release documentation. Please
have a look.
Joe D.
Vladimir Alexiev
In article <60ea00$3io$1...@apakabar.cc.columbia.edu> f...@watsun.cc.columbia.edu
(Frank da Cruz) writes:
> : Frank, I'd recommend dosppp05.zip (EPPPD) instead. If you like, I can
> : write up something about the setup that worked for me.
> Yes, please, and post it here. Thanks.
I use EPPPD, which provides a class 1 (Ethernet emulation) driver. It works ok
with a talk app which (claim to) be based on the WATTCP stack. Also, it works
ok with NUPop 1.03, a POP mail (and telnet) program, but I don't know what
TCP/IP stack it uses. Strangely, the ping from WATTCP didn't work
satisfactory. Another ping (from Trumpet?) works ok.
Unfortunately, kermit doesn't work with EPPPD. I guess I should have said in
my initial message "setup that worked for me with other tcp apps" (wattcp and
otherwise). It does BOOTP ok, but then it gives an "Unable to ARP resolve <ip
address>" error, then "Unable to contact the host. Host may be down or gateway
may be needed", and sets \v(tcpip_status) to 8 (host unreachable). (3.15 gives
much worse diagnostics. But these 123R 325T counters are nice. What do they
show, receive/transmit speed?)
Another file in the same dosppp05.zip, PPPD, provides class 6 (serial line)
driver. I now see in "APPENDIX II: MS-DOS KERMIT AND PPP" that you advise
using "/k 6" (class 6) with Merit PPP. (However, in my Merit PPP documentation
it says they support class 1 and class 15 only !?) I tried PPPD, and sure
enough it worked perfectly. Only that I had to type all the TCP params by
hand, because unlike EPPPD, PPPD doesn't provide BOOTP (is it even possible
with class 6?).
I wonder what is it in kermit that makes it fail where other TCP apps work ok
with EPPPD. (Admittedly, the Ether addresses that EPPPD synthesizes are pretty
weird-looking. Also, it figures out a netmask 255.255.0.0 for a local IP that
differs only in the last octet from the remote (gateway) IP, but that's on a
class B net, so it's perhaps ok.) I read Joe's explanations about ARP routing
in the archives of this group on DejaNews, but there's not enough technical
info to figure it out. I had a problem initially with EPPPD that was also
related to ARP, but it went away once I asked the remote pppd to do
*proxyarp*.
Is the advantage of having BOOTP sufficient incentive for the kermit team to
make kermit's stack work with class 1 emulation drivers? I don't know. In the
meanwhile, below is a first attempt at scripts to automate the process.
Please clean it up (especially error checking), my kermit scripting leaves a
lot to be desired.
USING KERMIT WITH PPPD.EXE FROM DOSPPP05.ZIP
In addition to Merit PPP (PPP.EXE that is distributed with Kermit), there's
another free PPP driver for DOS that you may want to consider. It is PPPD.EXE
in the archive MSDOS/PKTDRVR/DOSPPP05.ZIP on any SimTel mirror. It takes only
57k in memory (as opposed to 95k taken by Merit PPP), and is more robust.
However, it doesn't support Van Jacobsen header compression, so it adds more
overhead to the PPP protocol. [how much more?]
To set up PPPD.EXE, follow these steps. The text below may be of interest to
PPP.EXE users as well, since it describes how to automate the process of
connecting, and can be adapted for PPP.EXE.
1. Get DOSPPP05.ZIP. Unzip it in some directory, say \PPP. Read the fine
documentation that comes with it.
2. DOSPPP05.ZIP contains a simple dialer, CHAT.EXE, that works well with PPPD.
(If you prefer, you can use Kermit as a more sophisticated dialer with
better possibility for error checking, but it will start a bit slower.)
Create a script CHAT.SCR that consists of simple expect-send pairs, plus
some more info. I don't know if CHAT accepts comment lines, so remove the
comments below.
ABORT BUSY ABORT ERROR ; any of these will fail the script
ABORT "NO ANSWER"
ABORT "NO CARRIER"
ABORT "NO DIALTONE"
TIMEOUT 3
'' atz ; expect nothing, then reset modem
OK "atdt <phone>" ; expect OK from modem, dial the number
TIMEOUT 60 ; give it time to connect
; Insert your ISP's login sequence here. PPPD supports PAP, but not CHAP.
; If your ISP supports/requires PAP, put the username and password in
; PPPD.CFG (see below), and there will be no dialog here.
; E.g. a typical unix login goes like this:
login: <username> ;
TIMEOUT 3 ; now prompts should come quickly
Password: <password>
; A Cisco terminal server might go like this:
termserv> login
TIMEOUT 3 ; now prompts should come quickly
Username: <username>
Password: <passowrd>
; Now start a ppp server.
; If you have root access on Unix, install pppd, then go
TIMEOUT 60 ; wait for command-line prompt
$ "pppd :<myip> proxyarp"
; Note the quotes on the line above. <myip> is the IP address of your PC
; (Unix pppd can't assign it dynamically by itself). Proxyarp is very
; important: it makes the remote pppd route packets to PPPD.EXE.
; On Cisco terminal server, the command could be
termserv> "ppp default"
3. Create a configuration file PPPD.CFG:
com1 # COM port
38400 # UART (serial) DTE speed
modem # sense UART (modem) signals
#debug # only with the debugging version, PPPDD.EXE
#kdebug 1 # a good idea to turn on initially
pktvec 0x60 # packet driver interrupt vector
asyncmap 0 # send control chars as is
# asyncmap 0xA0000 # for xon/xoff flow control
# asyncmap 0x20000000 # for connection through telnet
# escape 0xFF # for connection through rlogin
#passive # don't quit if no ppp on the other side
crtscts # RTS/CTS (hardware) flow control
mru 1500 # max receive unit
mtu 1500 # max send unit
#namsrv <primary name serv>
#namsrv <secondary name serv>
user <username> # for PAP
passwd <password> # for PAP
Very important: PPPD will fail if there is a ^Z at the end of this file.
Use an editor that doesn't do this. Alternatively, you may try to end the
file by putting a comment character and no newline after it, i.e. like so:
# Don't put newline here! ^Z
4. Create a DOS batch file to start PPPD, call it PPP.BAT:
PPPD CONNECT "CHAT -f CHAT.SCR"
IF ERRORLEVEL 1 GOTO EXIT
CALL IP-UP.BAT
REM KERMIT -f PPPD.SCR ; uncomment after step 3
:EXIT
Upon successful connection PPPD creates a file IP-UP.BAT that lists the
parameters of the connection. We call it, so that the parameters are put in
the DOS environment. Use SET to check that all four of them are there (if
not, you may have insufficient environment space.)
If there's problems with the connection, enable the debug and kdebug
options in PPPD.CFG (see above) and use this instead:
PPPDD CONNECT "CHAT -f CHAT.SCR" > PPPD.LOG
then look in PPPD.LOG for clues.
5. Now write a Kermit script PPPD.SCR that transfers the parameters from the
environment into Kermit, adds some more parameters, and then connects to
the telnet host.
SET TCP/IP ADDRESS \$(myip)
SET TCP/IP SUBNETMASK \$(netmask)
SET TCP/IP DOMAIN footech.edu
SET TCP/IP GATEWAY \$(remip) ; remote IP
SET TCP/IP PRIMARY-NAMESERVER <primary nameserver IP>
SET TCP/IP SECONDARY-NAMESERVER <secondary nameserver IP>
; The nameservers are static IPs that your ISP should give you. PPPD
; Doesn't export them to IP-UP.BAT, that's why there's no point in
; specifying them in step 3 above.
; If you want to be very cool, in 3.15 you can even compute MSS as
; \feval(\$(peermru)-40)
SET TCP/IP HOST library
; This will connect you to library.footech.edu. If you prefer, you can
; put the full name here, and not specify DOMAIN. Or you can even put
; the host IP here, then you don't need nameservers.
SET PORT TCP/IP
CONNECT
Joe Doupnik
Let's go through the PPP driver situation again when the driver
presents an Ethernet Packet Driver interface.
PPP is a point to point link involving only two stations: this
end and the other end. It is not a broadcast medium, and thus ARP does not
apply. Frames do not use MAC addressing.
Ethernet is a broadcast medium. ARP is REQUIRED to identify one
of many possible stations on the wire. Also many stations can be in the
same IP subnet and thus reachable by first soliciting their hardware
(Ethernet MAC) address via ARP and then addressing frames to that address.
All frames require MAC addressing. ARPing for one's own IP address must
produce NO RESPONSE.
A PPP driver presenting an Ethernet interface is indistinguishable
from real Ethernet at the protocol stack level (i.e., by Kermit). That
driver must then FULLY simulate a broadcast medium of many stations, yet
they often fail completely to do that job. Half measures are failures too.
SLIP is a point to point link. It is not an Ethernet-style
interface. Kermit knows about SLIP and treats it as a point to point
comms pathway without MAC addresses. Use SLIP interfaces. There is no such
thing as a standardized PPP interface, alas, and thus Kermit does not have
code to deal with the many PPP interfaces out there. Use SLIP interfaces.
Avoid badly designed PPP drivers, please.
Joe D.
Christopher Mosley
Vladimir Alexiev (vlad...@cs.ualberta.ca) wrote:
: For Windows, one can probably run MS DOS Kermit in a DOS box, by using PKTMUX
: or some such contraption. But if your PC can run Windows, I don't see why
: you'd prefer to run DOS Kermit anyway. But if you can only run DesqView or
: some other task switcher (eg DoubleDOS), then PKTMUX may allow you to run more
: than one TCP client.
: Regards, Vlad
Yes, pktmux in combination with cslipper. I don't think dosppp uses
compression? (slirp can be used if you have a shell account and don't
have cslip) can be used to run mskermit as a telnet concurrently with
winsock applications. You can run a script that connects using mskermit
and runs packet driver to establish tcp/ip serial protocol, then pktmux
and pseudo-packet drivers are run for both kermit and winsock.
Finally window is run and opens with winsock running and an icon set up for
kermit telnet. Use the winsock ethernet packet driver option and a recent
version of cslipper with ethernet argument. It is very important to use a
recent version of pktmux, there are many versions of pktmux around that will
not work. I think the most recent version is "h".
You will probably have to limit or eliminate flow control including the
the initial kermit serial connection. Even so it works well and is robust-
the problems with pktmux must involve complex and difficult evironments.
Of course this is just an expediency until you make that big kermit95
purchase! or if you only have windows or wfwg.
I don't use windows but kermit and cslipper makes a great telnet for
arachne . Why not use the best instead of what is supplied. The
"kermit telnet" wrapper for arachne should be and may have to be a
compiled program. There are compilers for bat and bat-like languages at
oakland. It is somewhat surprising to find that dosppp will not work out
of the box for kermit telnet in arachne but dosppp works quite well
with _other_ wattcp based programs.
Arthur Marsh
Vladimir Alexiev (vlad...@cs.ualberta.ca) wrote:
: In addition to Merit PPP (PPP.EXE that is distributed with Kermit), there's
: another free PPP driver for DOS that you may want to consider. It is PPPD.EXE
: in the archive MSDOS/PKTDRVR/DOSPPP05.ZIP on any SimTel mirror. It takes only
: 57k in memory (as opposed to 95k taken by Merit PPP), and is more robust.
The demoware PPP at ftp://ftp.klos.com/demo/pppdemo.exe also works, but I
haven't tried the pppshare.exe at the same location.
What I did have problems with was that the MS-DOS Kermit "check TCP" command
succeeded when I had a FOSSIL driver, BNUi, loaded, but nothing else that
might resemble a TCP/IP capability for MS-DOS Kermit 3.15. Therefore, I
needed to manually change MSCUSTOM.INI between serial FOSSIL communications
and TCP/IP over the Klos ODI over PPP stack.
--
Arthur Marsh, telephone +61-8-8370-2365, fax +61-8-8223-5082
art...@dircsa.org.au
.endofsig
lacarter
On 25 Sep 1997, Rick Matthews wrote:
> Can anyone one tell me how to set up a PPP connection under DOS?
>
> I'll want to use Kermit for telneting, and I will also want
> to use a DOS pop mail client. Pegasus?
>
Hi Rick:
There are some internet utilities for dos. You might want to check out
the major sites like cdrom.com or oak.oakland.edu. I've seen them and have
a few on my BBS. But I can't remember the names of them at this time.
However, if you have windows 3.1 or WFWG you can use trumpet. It will
allow you to do slip or ppp. You can even use trumpet for tcpip on a
network. I use it to network my dos/wfwg machine to my os2/box and
linuxbox via tcpip.
As far as DOS Kermit is concerned I don't use it. I'm using the Linux
version. Maybe someone else can assist you with that. But if the dos
version has telnet access, you may be able to run it from a DOS window
under Windows to access. If there's a windows 3.x version of kermit you
might want to try using that instead. Otherwise there is a Winsock
compatible telnet program with zmodem capability called Tera Term that's
fully functional.
Toodles!
lonac
############################################################
# It is written, Man shall not live by bread alone, but by #
# every word that proceedeth out of the mouth of God #
# KJV Matthew 4:4 #
############################################################
Arthur Marsh
Arthur Marsh (art...@gateway.dircsa.org.au) wrote:
: Vladimir Alexiev (vlad...@cs.ualberta.ca) wrote:
: : In addition to Merit PPP (PPP.EXE that is distributed with Kermit), there's
: : another free PPP driver for DOS that you may want to consider. It is PPPD.EXE
: : in the archive MSDOS/PKTDRVR/DOSPPP05.ZIP on any SimTel mirror. It takes only
: : 57k in memory (as opposed to 95k taken by Merit PPP), and is more robust.
: The demoware PPP at ftp://ftp.klos.com/demo/pppdemo.exe also works, but I
: haven't tried the pppshare.exe at the same location.
That (pppshare) disconnects the modem when MS-Kermit resolves the host
address )-:.
: What I did have problems with was that the MS-DOS Kermit "check TCP" command
: succeeded when I had a FOSSIL driver, BNUi, loaded, but nothing else that
: might resemble a TCP/IP capability for MS-DOS Kermit 3.15. Therefore, I
: needed to manually change MSCUSTOM.INI between serial FOSSIL communications
: and TCP/IP over the Klos ODI over PPP stack.
I forgot that the "check tcp" only determines whether support is compiled in.
I did the following in my MSCUSTOM.INI to have a single configuration for
both serial and IP connections:
<tcp/ip setup>
set port tcp/ip <ip-address>
if success forward passedserial
<serial port setup>
:passedserial
<key assignments>
connect
Vladimir Alexiev
> Yes, pktmux in combination with cslipper. I don't think dosppp uses
> compression?
It doesn't have VJ header compression, yes. But I'm not sure if that's the
only kind of compression that PPP supports. The main benefit of PPP to SLIP is
that it's more robust, not more efficient.
In any case the choice of PPP or SLIP is already made for you by your ISP :-)
> (slirp can be used if you have a shell account and don't have cslip)
If you have a shell account, why would you want to use SLIP for kermit anyway?
> can be used to run mskermit as a telnet concurrently with winsock
> applications.
Once you have any kind of packet driver and/or emulation (no matter SLIP or
PPP), you can put two stacks (kermit's and winsock) on top of the driver,
using pktmux. With some provisos, of course.
> kermit and cslipper makes a great telnet for arachne .
Yes, if you use TCP/IP applications, then there is sense in putting a SLIP/PPP
emulator on top of a shell connection, and using Kermit over that TCP/IP link.
BTW, the emulator that's more commonly used than SLiRP is TIA. TIA has both
SLIP and PPP emulation.
> Why not use the best instead of what is supplied.
Agreed. But one should also understand the tradeoffs between different
protocols and protocol driver implementations. Eg PPP is more robust; SLIP may
be more parsimonious; EtherPPP supports VJ compression but is bulkier than
DOSPPP.
> It is somewhat surprising to find that dosppp will not work out of the box
> for kermit telnet in arachne but dosppp works quite well with _other_ wattcp
> based programs.
PPPD (class 6 driver) works out of the box, EPPPD (class 1 driver) doesn't.
Christopher Mosley
Vladimir Alexiev (vlad...@cs.ualberta.ca) wrote:
: > Yes, pktmux in combination with cslipper. I don't think dosppp uses
: > compression?
Basically I was giving _explicit_ instructions on how to to use mskermit as
a telnet in windows concurrently with winsock applications. So you can connect
to your very most favorite isp and use the best telnet. There is the notion
around that this cannot be done or shouldn't be done.
It's been a while since I did this but I believe the packet driver
option in trumpet winsock is ethernet not slip - pktmux is also ethernet.
Kermit needs a slip (6)interface with PPP therfore use c/slip. C/Slipper
is the best I've found. Why it is not the driver supplied with kermit
I don't know. The driver supplied/once supplied with kermit was the basis
for c/slipper - I believe.
: It doesn't have VJ header compression, yes. But I'm not sure if that's the
: only kind of compression that PPP supports. The main benefit of PPP to SLIP is
: that it's more robust, not more efficient.
: In any case the choice of PPP or SLIP is already made for you by your ISP :-)
: > (slirp can be used if you have a shell account and don't have cslip)
: If you have a shell account, why would you want to use SLIP for kermit anyway?
: > can be used to run mskermit as a telnet concurrently with winsock
: > applications.
: Once you have any kind of packet driver and/or emulation (no matter SLIP or
: PPP), you can put two stacks (kermit's and winsock) on top of the driver,
: using pktmux. With some provisos, of course.
: > kermit and cslipper makes a great telnet for arachne .
: Yes, if you use TCP/IP applications, then there is sense in putting a SLIP/PPP
: emulator on top of a shell connection, and using Kermit over that TCP/IP link.
: BTW, the emulator that's more commonly used than SLiRP is TIA. TIA has both
: SLIP and PPP emulation.
Slirp is completely free, has ppp/slip/cslip it is the uncommon choice of
the parsimonious.
: > Why not use the best instead of what is supplied.
Vladimir Alexiev
> Let's go through the PPP driver situation again when the driver
> presents an Ethernet Packet Driver interface.
> PPP is a point to point link involving only two stations: this
> end and the other end. It is not a broadcast medium, and thus ARP does not
> apply.
pppd with the proxyarp option allows this. Here's what the pppd(8) man page
says:
Add an entry to this system's ARP [Address Resolution
Protocol] table with the IP address of the peer and the
Ethernet address of this system.
Also, some terminal servers provide such proxy arp. At least the Cisco
terminal server that runs at our uiniversity's login server. (Interestingly,
it only does this when the user properly identified themselves to the server,
otherwise it allows PPP, but does not give proxy arp.)
> A PPP driver presenting an Ethernet interface is indistinguishable
> from real Ethernet at the protocol stack level (i.e., by Kermit). That
> driver must then FULLY simulate a broadcast medium of many stations, yet
> they often fail completely to do that job.
I'm not saying that the Kermit class 1 handling is worse than than of other
WATTCP apps. I suspect that Kermit does some more checks or expects more from
the ethernet driver than other WATTCP apps, in other words it uses the
ethernet driver more properly than other WATTCP apps. But the fact remains
that these apps can use emulated class 1 drivers, while Kermit can't.
Sometimes worse is better.
> Half measures are failures too.
Well, these half measures prove to be adequate for other WATTCP apps.
> SLIP is a point to point link. It is not an Ethernet-style
> interface. Kermit knows about SLIP and treats it as a point to point
> comms pathway without MAC addresses. Use SLIP interfaces.
What are the benefits of an ethernet interface to a SLIP interface:
- there are apps that only support ethernet interfaces. Kermit couldn't
coexist with such apps because it demands a SLIP interface.
- Ethernet interfaces support BOOTP. Is BOOTP impossible with a SLIP
interface?
- How about DHCP?
- RARP is obviously impossible with a SLIP interface, but then it doesn't even
apply.
- Is there anything else?
> There is no such thing as a standardized PPP interface, alas, and thus
> Kermit does not have code to deal with the many PPP interfaces out there.
EtherPPP's documentation mentions class 15 (SLFP). Is that an example of a
non-standardized PPP interface?
> Avoid badly designed PPP drivers, please.
Since Kermit doesn't work with EtherPPP -k 1, does that make EtherPPP a badly
designed driver too? How about Windows PPP drivers, do they support an
Ethernet interface?
Vladimir Alexiev
> "check tcp" only determines whether support is compiled in.
> I did the following in my MSCUSTOM.INI to have a single configuration for
> both serial and IP connections:
>
> set port tcp/ip <ip-address>
> if success forward passedserial
I think that this will always succeed, because the actual connection is only
attempted when CONNECT is issued. You should check "if success" after CONNECT,
and if it's failed eventually examine \v(tcpip_status).
Christopher Mosley
Christopher Mosley (cmo...@voicenet.com) wrote:
: Vladimir Alexiev (vlad...@cs.ualberta.ca) wrote:
: : In article <60hrre$t7q$1...@news3.voicenet.com> cmo...@voicenet.com (Christopher Mosley) writes:
: : > Yes, pktmux in combination with cslipper. I don't think dosppp uses
: : > compression?
: Basically I was giving _explicit_ instructions on how to to use mskermit as
: a telnet in windows concurrently with winsock applications. So you can connect
: to your very most favorite isp and use the best telnet. There is the notion
: around that this cannot be done or shouldn't be done.
: It's been a while since I did this but I believe the packet driver
: option in trumpet winsock is ethernet not slip - pktmux is also ethernet.
This is backwards, the important thing is that pktmux uses an ethernet
driver and presents an ethernet interface I believe and kermit needs a slip
interface if ethernet is going to be used . There *is*
a slip/ppp interface in winsock. Now if there is a way around this -
I don't know.
It is however simple to do this with c/slipper.
: Kermit needs a slip (6)interface with PPP therfore use c/slip. C/Slipper
Yeechang Lee
Vladimir Alexiev <vlad...@cs.ualberta.ca> wrote:
> > (slirp can be used if you have a shell account and don't have cslip)
>
> If you have a shell account, why would you want to use SLIP for
> kermit anyway?
Multiple sessions. DOS Kermit was, and is, a superb telnet client
over PPP.
--
<URL:http://www.columbia.edu/~ylee/>
Joe Doupnik
This looks more and more like an argument waiting to happen, due to
lack of specific information. I thought I explained the difficulties with
a driver purporting to be Ethernet but isn't; they are fundamental. The
paragraph above is so loose that I am discarding it.
>> Half measures are failures too.
>
> Well, these half measures prove to be adequate for other WATTCP apps.
which are tailored for a point to point link, no doubt.
>> SLIP is a point to point link. It is not an Ethernet-style
>> interface. Kermit knows about SLIP and treats it as a point to point
>> comms pathway without MAC addresses. Use SLIP interfaces.
>
> What are the benefits of an ethernet interface to a SLIP interface:
> - there are apps that only support ethernet interfaces. Kermit couldn't
> coexist with such apps because it demands a SLIP interface.
Argumentative again. No, Kermit does not "demand" SLIP, but if the
alternatives fail to meet specs then that is hardly Kermit's fault.
> - Ethernet interfaces support BOOTP. Is BOOTP impossible with a SLIP
> interface?
> - How about DHCP?
Time to read up on these guys. Both use UDP over IP. How IP gets
put onto the wire is another matter. Please do keep in mind that both
BOOTP and DHCP are sensitive to physical address, something which SLIP
lacks.
> - RARP is obviously impossible with a SLIP interface, but then it doesn't even
> apply.
> - Is there anything else?
>
>> There is no such thing as a standardized PPP interface, alas, and thus
>> Kermit does not have code to deal with the many PPP interfaces out there.
>
> EtherPPP's documentation mentions class 15 (SLFP). Is that an example of a
> non-standardized PPP interface?
>
>> Avoid badly designed PPP drivers, please.
>
> Since Kermit doesn't work with EtherPPP -k 1, does that make EtherPPP a badly
> designed driver too? How about Windows PPP drivers, do they support an
> Ethernet interface?
I think this ground was well covered in my long message on the
matter a couple of weeks ago.
Joe D.
Joe Doupnik
<omitting much>
> non-standardized PPP interface?
>
>> Avoid badly designed PPP drivers, please.
>
> Since Kermit doesn't work with EtherPPP -k 1, does that make EtherPPP a badly
> designed driver too? How about Windows PPP drivers, do they support an
> Ethernet interface?
A Class 15 Packet Driver is specific to MERIT and I have seen no
specification of it (it is not in the official Packet Driver specs other
than to note the assignment of type 1 to MERIT). Note also MERIT's software
is not revealed in source code form nor even in API form. So I stand firm on
the comment about non-standardized PPP interfaces.
Windows drivers are neither of interest or applicability to this
discussion.
Joe D.
Joe Doupnik
In article <60i3al$8...@gateway.dircsa.org.au>, art...@gateway.dircsa.org.au (Arthur Marsh) writes:
> Vladimir Alexiev (vlad...@cs.ualberta.ca) wrote:
>
> : In addition to Merit PPP (PPP.EXE that is distributed with Kermit), there's
> : another free PPP driver for DOS that you may want to consider. It is PPPD.EXE
> : in the archive MSDOS/PKTDRVR/DOSPPP05.ZIP on any SimTel mirror. It takes only
> : 57k in memory (as opposed to 95k taken by Merit PPP), and is more robust.
>
> haven't tried the pppshare.exe at the same location.
>
> succeeded when I had a FOSSIL driver, BNUi, loaded, but nothing else that
> might resemble a TCP/IP capability for MS-DOS Kermit 3.15. Therefore, I
> needed to manually change MSCUSTOM.INI between serial FOSSIL communications
> and TCP/IP over the Klos ODI over PPP stack.
The MS-DOS Kermit command CHECK TCP tells whether or not the TCP/IP
stack is built into the program, because we issue MSK with and without that
stack. Thus the CHECK <whatever> command is a test for which features are
complied into a particular issue of the program.
Referring back to other messages in the thread from Vladimir that try
to tie PPP driver behavior with the origin of the app TCP/IP stack: the
TCP/IP stack in MSK originated with Erick Engelke at the Univ of Waterloo
(wattcp). Evolution acted rapidly and the MSK TCP/IP code has been very
different from wattcp code for many years. Packet Driver material in MSK was
never from wattcp. People can check this by looking at source code for the two.
Source code for MSK 3.15 will be available shortly (delayed by travel).
Joe D.
Frank da Cruz
In article <om90wf9...@tees.cs.ualberta.ca>,
Vladimir Alexiev <vlad...@cs.ualberta.ca> wrote:
: In article <60km6a$j...@gateway.dircsa.org.au>
There is actually a better way. The way MS-DOS Kermit is structured, as
Vladimir points out, SET PORT TCP merely declares the name of the host to be
connected to, but otherwise does nothing. Various other commands like
CONNECT open the connection if it is not yet open. But of course you don't
want to use CONNECT in a script, because then the script loses control.
Another command also opens the connection if it is not open, but does nothing
more:
PAUSE 0
(or "pause" anything-else"). So a common practice is to define a TELNET
macro like this:
DEFINE TELNET SET PORT TCP \%1, PAUSE 0, IF SUCCESS CONNECT
- Frank
Vladimir Alexiev
> > the fact remains that these apps can use emulated class 1 drivers, while
> > Kermit can't. Sometimes worse is better.
> This looks more and more like an argument waiting to happen, due to
> lack of specific information.
Talk by Michael Ringe <mic...@thphys.physik.rwth-aachen.de> which is "built
upon the WATTCP library" works with EPPPD which is a class 1 PPP driver.
Kermit's TCP is also built over the WATTCP library (if information on WATTCP's
site is correct), but I guess that Joe has introduced changes that make it
incompatible with drivers emulating class 1 (Internet).
> I thought I explained the difficulties with a driver purporting to be
> Ethernet but isn't; they are fundamental.
How do you explain then that that talk program works? I also tried
successfully the telnet from NUPop over the same EPPPD driver, however NUPop
is not WATTCP-based. Would you like me to test WATTCP FTP or a WATTCP-based
telnet client (where is one)?
> > Well, these half measures prove to be adequate for other WATTCP apps.
> which are tailored for a point to point link, no doubt.
I don't think so. I don't have an ethernet connection I can try them with, but
their docs claim they work over ethernet too. It wouldn't make much sense if
they didn't.
> > - there are apps that only support ethernet interfaces. Kermit couldn't
> > coexist with such apps because it demands a SLIP interface.
> Argumentative again. No, Kermit does not "demand" SLIP,
If Kermit is to be used with a serial link (SLIP or PPP), the packet driver
has to support class 6 (SLIP) interface. Obviously all SLIP drivers do, but
only two out of the three freely available PPP drivers do (dosppp and
MeritPPP, aka etherppp or ethernew), while ppppkt does not. More important
however is that if one would like to use another TCP app together with Kermit,
that app should also support class 6, because a driver can only run in one of
the class modes that it supports at a time.
> but if the alternatives fail to meet specs then that is hardly Kermit's
> fault.
What spec does a working combination "class 1 PPP driver" - "class 1 app" fail
to meet? You seem to assert that class 1 emulating serial drivers are
impossible, yet there are at least 3 such: dosppp, MeritPPP, pppshare/pppdemo.
> > Is BOOTP impossible with a SLIP interface? How about DHCP?
> Both use UDP over IP. How IP gets put onto the wire is another matter.
Yes, I can't think of a good reason why BOOTP shouldn't work either, but the
class 6 driver in dosppp (PPPD) doesn't support it for some reason.
> Please do keep in mind that both BOOTP and DHCP are sensitive to physical
> address
Why? Isn't it only critical for RARP (which resolves an Ether address to an
IP address)? I guess it depends a lot on the remote side as well, because most
often the remote gives us our IP.
> > How about Windows PPP drivers, do they support an Ethernet interface?
(Forget about this, my mind was probably clouded when I wrote it; Windows
drivers are not packet drivers.)
Vladimir Alexiev
> A Class 15 Packet Driver is specific to MERIT and I have seen no
> specification of it... So I stand firm on the comment about non-standardized
> PPP interfaces.
I can easily believe this, because dosppp provides class 1 and class 6, but
not class 15.
> Windows drivers are neither of interest or applicability to this
> discussion.
Right.
Arthur Marsh
Frank da Cruz (f...@watsun.cc.columbia.edu) wrote:
: Another command also opens the connection if it is not open, but does nothing
: more:
: PAUSE 0
: (or "pause" anything-else"). So a common practice is to define a TELNET
: macro like this:
: DEFINE TELNET SET PORT TCP \%1, PAUSE 0, IF SUCCESS CONNECT
: - Frank
Thanks, that did the trick...
Joe Doupnik
In article <omraa16...@tees.cs.ualberta.ca>, Vladimir Alexiev <vlad...@cs.ualberta.ca> writes:
> In article <XrKuqa...@cc.usu.edu> j...@cc.usu.edu (Joe Doupnik) writes:
>
>> > the fact remains that these apps can use emulated class 1 drivers, while
>> > Kermit can't. Sometimes worse is better.
>> This looks more and more like an argument waiting to happen, due to
>> lack of specific information.
>
> Talk by Michael Ringe <mic...@thphys.physik.rwth-aachen.de> which is "built
> upon the WATTCP library" works with EPPPD which is a class 1 PPP driver.
> Kermit's TCP is also built over the WATTCP library (if information on WATTCP's
> site is correct), but I guess that Joe has introduced changes that make it
> incompatible with drivers emulating class 1 (Internet).
Kermit's TCP/IP stack is based upon the WATTCP of over six years ago
and followed its own development/evolutionary path to be a different set of
code. Similarly the WATTCP of that era has itself developed and evolved to
be the WATTCP of today. Neither is even nearly the same as their 1991 versions.
Today the two sets of code are very different indeed. I've said this before.
Class 1 Packet Drivers have no identification with "Internet"; we
presume that's your name for IP packets. They purport to deal with frames on
Ethernet. MS-DOS Kermit runs just fine over Class 1 Ethernet Packet Drivers,
if those drivers do their job correctly.
Again here are fundamentals and I hope you pause to understand this.
A Packet Driver advertisizing itself as Ethernet (Class 1) on the top tells
the application protocol stack that Ethernet is the lan topology and hence
Ethernet rules apply. Amongst them are supporting MAC addresses, identifying
stations in the same broadcast domain (and hence IP subnet) by physical layer
broadcasts and direct MAC addressing (no router), and having an IP gateway to
contact stations not in the same broadcast domain. An ARP for one's own IP
address, for example, must fail to yield a response, and an ARP for another
station on the same IP subnet must yield a proper response (or none if the
station is not reachable by IP at that time). This is in addition to framing
details. Ethernet runs this way.
Let me emphasize this point again. Frame construction is only part
of the situation. Supporting a broadcast medium via physical addresses is
another part, and it is the part that is easily broken in emulation. Both
parts are intrinsic components of Ethernet. See my comment on "fundamentals"
below.
If a PPP or carrier-pigeon or whatever driver advertisizes itself
as Ethernet to the protocol stack then it must emulate Ethernet
characteristics to the protocol stack.
>> I thought I explained the difficulties with a driver purporting to be
>> Ethernet but isn't; they are fundamental.
>
> How do you explain then that that talk program works? I also tried
> successfully the telnet from NUPop over the same EPPPD driver, however NUPop
> is not WATTCP-based. Would you like me to test WATTCP FTP or a WATTCP-based
> telnet client (where is one)?
>
I have not the slightest idea of what code is in those programs.
Have you looked at them to see what they do internally? How about the
internals of those PPP drivers? What are those drivers really doing?
>> > Well, these half measures prove to be adequate for other WATTCP apps.
>> which are tailored for a point to point link, no doubt.
> I don't think so. I don't have an ethernet connection I can try them with, but
> their docs claim they work over ethernet too. It wouldn't make much sense if
> they didn't.
>
>> > - there are apps that only support ethernet interfaces. Kermit couldn't
>> > coexist with such apps because it demands a SLIP interface.
>> Argumentative again. No, Kermit does not "demand" SLIP,
> If Kermit is to be used with a serial link (SLIP or PPP), the packet driver
> has to support class 6 (SLIP) interface. Obviously all SLIP drivers do, but
> only two out of the three freely available PPP drivers do (dosppp and
> MeritPPP, aka etherppp or ethernew), while ppppkt does not. More important
> however is that if one would like to use another TCP app together with Kermit,
> that app should also support class 6, because a driver can only run in one of
> the class modes that it supports at a time.
We do not support any attempt to run two TCP/IP stacks over the same
lan driver, period. Folks may be succussful at times with pktmux, but that
is not an item or area we are prepared to support in any way. Why? Because
it is not possible to cleanly separate two or more stack's this way, despite
the good work in pktmux.
>> but if the alternatives fail to meet specs then that is hardly Kermit's
>> fault.
> What spec does a working combination "class 1 PPP driver" - "class 1 app" fail
> to meet? You seem to assert that class 1 emulating serial drivers are
> impossible, yet there are at least 3 such: dosppp, MeritPPP, pppshare/pppdemo.
No such assertion has been made by me. You are the guy going to
extremes.
>> > Is BOOTP impossible with a SLIP interface? How about DHCP?
>> Both use UDP over IP. How IP gets put onto the wire is another matter.
> Yes, I can't think of a good reason why BOOTP shouldn't work either, but the
> class 6 driver in dosppp (PPPD) doesn't support it for some reason.
>
>> Please do keep in mind that both BOOTP and DHCP are sensitive to physical
>> address
> Why? Isn't it only critical for RARP (which resolves an Ether address to an
> IP address)? I guess it depends a lot on the remote side as well, because most
> often the remote gives us our IP.
It might be beneficial to review the specs of BOOTP and DHCP.
>
>> > How about Windows PPP drivers, do they support an Ethernet interface?
>
> (Forget about this, my mind was probably clouded when I wrote it; Windows
> drivers are not packet drivers.)
Joe D.
Vladimir Alexiev
In article <4TpKBo...@cc.usu.edu> j...@cc.usu.edu (Joe Doupnik) writes:
Joe, the discussion is getting unnecessarily antagonistic, and I would hate
that. I understand very well that you're the driving force behind MS Kermit,
and I'm very grateful for what you've done for it. But I think that making it
work with emulated class 1 (if possible and feasible) would make it slightly
better. Of course, it should be first determined whether this is really a
desideratum (that's why I asked what are the benefits of class 1, if any), and
whether the effort required is worth it. Now, I know squat about TCP stacks,
but I have this gut feeling (whatever that's worth) that it is something
pretty small that prevents Kermit from doing it. After all, all the required
functionality for class 1 is thre, and all the required functionality for
serial line drivers is there.
If you decide such a task is worth pursuing, I'm offering my help with testing
and experiments, and if you prefer, we can switch this discussion offline.
> Class 1 Packet Drivers have no identification with "Internet"; we
> presume that's your name for IP packets.
Sorry, it's a typo, I meant Ethernet.
> Again here are fundamentals and I hope you pause to understand this.
> A Packet Driver advertisizing itself as Ethernet (Class 1) on the top tells
> the application protocol stack that Ethernet is the lan topology and hence
> Ethernet rules apply.
Right. Something often used in the Unix world is "proxy ARPing". In that case
a gateway host G that's connected to an ethernet and further to the internet,
serves as a proxy to a client C that's connected to D through a PPP link. When
another host X from G's ethernet ARPs with the IP of C, G returns its own MAC,
and then takes care to forward any packets received as a result of that fake
to C. (see eg http://www.med2000.com:457/NetAdminG/pppC.proxy_arp.html)
I don't know how do EPPPD and PPP -k 1 emulate class 1, but I suppose it's
somethign similar.
> Amongst them are supporting MAC addresses, identifying stations in the same
> broadcast domain
Proxy ARPing makes C appear to be connected to G's ethernet.
> Frame construction is only part of the situation.
It is my understanding that class 1 emulators do take care of ARP issues.
> If a PPP or carrier-pigeon or whatever driver advertisizes itself
> as Ethernet to the protocol stack then it must emulate Ethernet
> characteristics to the protocol stack.
Which ethernet characteristics do those emulators fail to emulate, and are
they critical for the operation of a telnet application?
> I have not the slightest idea of what code is in those programs.
> Have you looked at them to see what they do internally?
No. I was hoping that we could determine what is the problem by looking at
Kermit "from the outside" and/or by using some packet analyzers.
> > if one would like to use another TCP app together with Kermit, that app
> > should also support class 6
> We do not support any attempt to run two TCP/IP stacks over the same
> lan driver, period. Folks may be succussful at times with pktmux...
Consider this: a user may want to first run telnet, then close Kermit down and
read their email using the same PPP connection. This is impossible if the
telnet and the mail reader don't use the same driver class.
> > You seem to assert that class 1 emulating serial drivers are impossible,
> No such assertion has been made by me. You are the guy going to
> extremes.
Ok, maybe I chose my words wrong, but what you've written so far is:
- class 1 is supposed to work this way: <a non-technical description>
- Kermit works ok with real class 1
- ergo, there must be something wrong with class 1 emulators
Of course, what I wrote isn't more technical either:
- these other apps work with class 1 emulators
- ergo, it should be easy to change Kermit to also work with them
> >> > Is BOOTP impossible with a SLIP interface? How about DHCP?
dosppp class 6 doesn't support it. How about MeritPPP class 6?
Joe Doupnik
In article <omvhza9...@tees.cs.ualberta.ca>, Vladimir Alexiev <vlad...@cs.ualberta.ca> writes:
> In article <4TpKBo...@cc.usu.edu> j...@cc.usu.edu (Joe Doupnik) writes:
>
> Joe, the discussion is getting unnecessarily antagonistic, and I would hate
> that. I understand very well that you're the driving force behind MS Kermit,
> and I'm very grateful for what you've done for it. But I think that making it
> work with emulated class 1 (if possible and feasible) would make it slightly
> better. Of course, it should be first determined whether this is really a
> desideratum (that's why I asked what are the benefits of class 1, if any), and
> whether the effort required is worth it. Now, I know squat about TCP stacks,
> but I have this gut feeling (whatever that's worth) that it is something
> pretty small that prevents Kermit from doing it. After all, all the required
> functionality for class 1 is thre, and all the required functionality for
> serial line drivers is there.
Feeling isn't going to cut this particular piece of mustard. It is
clear those PPP drivers are not simulating Ethernet to the extent they should.
I have no source code nor significant docs on those drivers. I suggest you
continue the conversation with the authors of those drivers and see if they
will reveal the extent to which they perform the required emulation.
You are welcome to apply TRACE and DUMP of the Cyrnwr Packet Driver
collection to capture Packet Driver traffic (limit is about 50KB of stuff).
That might provide a little additional information.
>
> If you decide such a task is worth pursuing, I'm offering my help with testing
> and experiments, and if you prefer, we can switch this discussion offline.
>
>> Class 1 Packet Drivers have no identification with "Internet"; we
>> presume that's your name for IP packets.
> Sorry, it's a typo, I meant Ethernet.
>
>> Again here are fundamentals and I hope you pause to understand this.
>> A Packet Driver advertisizing itself as Ethernet (Class 1) on the top tells
>> the application protocol stack that Ethernet is the lan topology and hence
>> Ethernet rules apply.
>
> Right. Something often used in the Unix world is "proxy ARPing". In that case
> a gateway host G that's connected to an ethernet and further to the internet,
> serves as a proxy to a client C that's connected to D through a PPP link. When
> another host X from G's ethernet ARPs with the IP of C, G returns its own MAC,
> and then takes care to forward any packets received as a result of that fake
> to C. (see eg http://www.med2000.com:457/NetAdminG/pppC.proxy_arp.html)
>
Proxy ARP et al have not the slightest to do with Kermit (or other
client) internals. That is outside of and unknowable to these clients.
> I don't know how do EPPPD and PPP -k 1 emulate class 1, but I suppose it's
> somethign similar.
>
>> Amongst them are supporting MAC addresses, identifying stations in the same
>> broadcast domain
> Proxy ARPing makes C appear to be connected to G's ethernet.
Once again, this is a problem for "the other guys" on the wire.
The application/client has no knowledge that it occurs.
>> Frame construction is only part of the situation.
> It is my understanding that class 1 emulators do take care of ARP issues.
>
>> If a PPP or carrier-pigeon or whatever driver advertisizes itself
>> as Ethernet to the protocol stack then it must emulate Ethernet
>> characteristics to the protocol stack.
> Which ethernet characteristics do those emulators fail to emulate, and are
> they critical for the operation of a telnet application?
Golly, I thought I was plain enough the previous two times round.
If they fail to do the job then that's their problem. Telnet is a TCP over
IP application. If the Ethernet part of things fails because the driver
does not do its part, or the far end of the wire fails to play the game,
then that's pretty much that: Telnet, TCP, and IP, all gone.
I don't know what their real problems are. I don't have their
source code, and I haven't signed a consulting arrangement to fix whatever
problems they may have. Persistent badgering that somehow this is all my fault
makes me less inclined to pursue the matter.
>> I have not the slightest idea of what code is in those programs.
>> Have you looked at them to see what they do internally?
> No. I was hoping that we could determine what is the problem by looking at
> Kermit "from the outside" and/or by using some packet analyzers.
I don't have most of those PPP drivers. I can say is MERIT's PPP
driver fails to work in non-SLIP mode in tests here and does work in SLIP
mode. MSK will report if it is unable to register with the Packet Driver
for IP and ARP packets, if another station responds to an ARP for MSK's
own IP address, and if it is unable to receive a response to an ARP. If
those conditions are met and the driver proclaims to be Ethernet then the
driver had better behave like Ethernet (Kermit has no information to the
contrary). Thus Kermit does tell you if interfacing conditions fail, but
it cannot tell anyone about Ethernet simulation failures in an external
driver. If the interfacing conditions pass muster as Ethernet then the
rest is in the hands of the PPP driver and other gear on the wire.
>> > if one would like to use another TCP app together with Kermit, that app
>> > should also support class 6
>> We do not support any attempt to run two TCP/IP stacks over the same
>> lan driver, period. Folks may be succussful at times with pktmux...
>
> Consider this: a user may want to first run telnet, then close Kermit down and
> read their email using the same PPP connection. This is impossible if the
> telnet and the mail reader don't use the same driver class.
Again, I recommend talking with the authors/vendors of those PPP
drivers to get the matter straightened out.
>> > You seem to assert that class 1 emulating serial drivers are impossible,
>> No such assertion has been made by me. You are the guy going to
>> extremes.
> Ok, maybe I chose my words wrong, but what you've written so far is:
> - class 1 is supposed to work this way: <a non-technical description>
> - Kermit works ok with real class 1
> - ergo, there must be something wrong with class 1 emulators
> Of course, what I wrote isn't more technical either:
> - these other apps work with class 1 emulators
> - ergo, it should be easy to change Kermit to also work with them
Please let's skip the ergos; we need technical facts. This is not a
people or legal problem.
>> >> > Is BOOTP impossible with a SLIP interface? How about DHCP?
> dosppp class 6 doesn't support it. How about MeritPPP class 6?
I say once more, BOOTP and DHCP require a local MAC address to work
with, by design of those protocols. The MAC address is accompanied by a media
type identifier (such as Ethernet, ARCnet, Token Ring, FDDI etc). The
BOOTP/DHCP client is obliged to provide both items. SLIP has no MAC address
and no media type.
Joe D.
Kees Hendrikse
In <omvhza9...@tees.cs.ualberta.ca> Vladimir Alexiev writes:
> Ok, maybe I chose my words wrong, but what you've written so far is:
> - class 1 is supposed to work this way: <a non-technical description>
> - Kermit works ok with real class 1
> - ergo, there must be something wrong with class 1 emulators
> Of course, what I wrote isn't more technical either:
> - these other apps work with class 1 emulators
> - ergo, it should be easy to change Kermit to also work with them
Your argument has a serious flaw: both the 'other apps' and the emulator
might be doing things that only vaguely resemble class 1 and still work
happy together. Please let's stick to wel documented standard interfaces.
There's already too much broken network software out there.
--
Kees Hendrikse | email: ke...@echelon.nl
|
ECHELON consultancy and software development | phone: +31 (0)53 48 36 585
PO Box 545, 7500AM Enschede, The Netherlands | fax: +31 (0)53 43 37 415
David Lane
In article <omn2kcq...@tees.cs.ualberta.ca>
Vladimir Alexiev <vlad...@cs.ualberta.ca> writes:
[snip]
> > Proxy ARP et al have not the slightest to do with Kermit (or other
> > client) internals. That is outside of and unknowable to these clients.
> I know that. I was trying to figure out how does class 1 emulation work.
>
> For a PPP link, Kermit`s job is pretty simple: it has to send all it wants to
> send down the link, without caring mcuh about MAC addresses. That's why I
> think it would be an easy fix: Kermit could simply disregard some of its
> "doubts" about the faithfulness of the class 1 emulation and just go ahead.
[snip]
Now this may be a boneheaded question, but why would a PPP packet driver
emulate a class 1 driver and not a class 6 driver? The major difference
between the two in terms of presented data is the presence of MAC
addresses and non-IP packets. The differences in behavior that follow
from this are more significant. One is emulating a broadcast medium
on a point-to-point connection. The other is emulating a point-to-point
connection of somewhat lesser capabilities, but still enough for
straight IP (meaning ICMP, TCP).
> I was hoping that we can figure out what more does Kermit expect from a class
> 1 emulator compared to other TCP apps (and you're starting this, with the 3
> conditions above). Now I'll try from the other end, ask emulator authors what
> less do these emulators provide compared to true ethernet drivers.
I would suspect that much of it has to do with ARP and other such
broadcast things (especially ARP, since it's a different protocol type
than IP.) On ethernet you do arp, or you're not doing it right. On
PPP, you do some minor negotiation at connect time, but you don't do
ARP per se.
David.
--
David Lane dl...@contactpt.com
Senior Software Engineer http://dlane.contactpt.com
Contact Point Technologies http://www.contactpt.com
Vladimir Alexiev
> >> >> > Is BOOTP impossible with a SLIP interface? How about DHCP?
> BOOTP and DHCP require a local MAC address to work with, SLIP has no MAC
> address
Ok, now: Is BOOTP availability over PPP links sufficient incentive to warrant
pursuing this issue?
> continue the conversation with the authors of those drivers and see if they
> will reveal the extent to which they perform the required emulation.
Ok, I'll try that.
> Proxy ARP et al have not the slightest to do with Kermit (or other
> client) internals. That is outside of and unknowable to these clients.
I know that. I was trying to figure out how does class 1 emulation work.
For a PPP link, Kermit`s job is pretty simple: it has to send all it wants to
send down the link, without caring mcuh about MAC addresses. That's why I
think it would be an easy fix: Kermit could simply disregard some of its
"doubts" about the faithfulness of the class 1 emulation and just go ahead.
> MSK will report
> 1. if it is unable to register with the Packet Driver for IP and ARP packets
> 2. if another station responds to an ARP for MSK's own IP address,
> 3. and if it is unable to receive a response to an ARP.
This is the kind of info I need to figure it out (if at all possible from
external observation only). Does the message "Unable to ARP resolve" mean item
3 above? Will these conditions appear in the order listed, so can I assume
that 1 and 2 do not happen?
> If those conditions are met and the driver proclaims to be Ethernet then the
> driver had better behave like Ethernet... Kermit does tell you if
> interfacing conditions fail
What other errors can happen from that point on? (Ok, perhaps this is a stupid
question :-) Can you think of other interfacing conditions that can fail,
apart from the listed 3?
> it cannot tell anyone about Ethernet simulation failures in an external
> driver.
Vladimir Alexiev
> > - these other apps work with class 1 emulators
> > - ergo, it should be easy to change Kermit to also work with them
> Your argument has a serious flaw: both the 'other apps' and the emulator
> might be doing things that only vaguely resemble class 1 and still work
But those other apps are known to work with real class 1 too. So we know it's
possible to have both.
> There's already too much broken network software out there.
Don't you consider the impossibility to use BOOTP over PPP in Kermit a
breakage?
Vladimir Alexiev
Alright!
Joe, you were right on these points:
- It's EPPPD's fault, not Kermit's fault
- I should have talked earlier to EPPPD's author
I was right on these points:
- It's easy to fix.
- Other apps work because they don't check something that should be checked.
Kermit fails because it's right, but "too righteous". Worse is better :-)
Something that threw me off is that MeritPPP also failed. Two drivers against
one kermit, it's "natural" to assume it's kermit's fault :-) I wonder if
MeritPPP has the same bug as EPPPD, and if we can get someone at Merit to fix
it.
I'll give it a try and inform you.
Regards, Vlad
Date: Wed, 15 Oct 1997 23:41:36 +0100 (GMT+0100)
From: Toni <ton...@redestb.es>
Subject: Re: Class 1 PPP drivers under DOS vs true Ethernet
Hello Vladimir,
I already knew of the Dospppd + Kermit problem, as some users reported the
failure to me some time ago. The problem is corrected now, there is a pre-beta
of Dospppd v0.6 package at the following URL:
http://www.redestb.es/personal/tonilop/dosppp06.zip
Please don't redistribute this package, as it is incomplete and subject to
changes before I release the publicly available one. However, I'm interested in
knowing how well it performs, or if it has bugs, so let me know how it goes in
case you have the time for testing it. You may want to inform Joe Dupnik also.
A summary of what I've discovered and the solution follows:
Real Ethernet ARP reply packets include the source address (the address for the
machine which is responding to the ARP request) in two places, one is in the
Ethernet header source address field, and the other is in the ARP packet source
hardware address field.
It seems that most applications look at the source hardware field of the ARP
packet, so the ARP emulation in Dospppd was filling only this one with the fake
Ethernet address.
On the other hand, Kermit seems to look at the Ethernet header source address
field, or maybe it is doing a consistency check by ensuring that both fields
contain the same value (I don't know for sure, maybe Mr. Dupnik would give some
insight on this issue).
The solution was to put the same fake Ethernet address in both fields, Kermit
started to work fine after that. It is not a Kermit problem though, an Ethernet
emulation should fill both fields in order to be acurate. The fact that most
other WATTCP applications worked doesn't imply that Kermit was wrong, maybe
WATTCP developers decided to relax the Ethernet address checks after detecting
that the stack didn't work with Ethernet emulation drivers.
Best regards.
Toni
Vladimir Alexiev
> why would a PPP packet driver emulate a class 1 driver and not a class 6
> driver?
Two reasons:
- there are apps that work with class 1, but not class 6. TVDog says "many
apps are like so".
- RARP/BOOTP/DHCP are only possible with class 1.
Also, I'm not sure whether PPP packets fit better in a class 6 or a class 1
frame. (Some PPP drivers provide class 15, but as Joe D says, class 15 is not
standardized, thus mostly unusable.)
> The differences in behavior that follow from this are more significant. One
> is emulating a broadcast medium on a point-to-point connection.
A class 1 emulator with proxy ARP on the other side makes the p-p connection
look like an extension of the remote LAN.
> The other is emulating a point-to-point connection of somewhat lesser
> capabilities
Does one know what is the difference between SLIP and PPP at the packet
interface level? How bad a match is class 6 for class 15?
> On ethernet you do arp, or you're not doing it right. On PPP, you do some
> minor negotiation at connect time, but you don't do ARP per se.
A broadcast over a line that has only one other machine connected to it (the
gateway) is pretty much the same as a p-p connection, isn't it?
Vladimir Alexiev
Toni, congratulations on a great new release!
With the new features (CHAP, VJ compression, BOOTP working for Minuet, Ether
working for Kermit), the small footprint, the robustness coming from Linux,
and your active development, DOSPPP is certain to become *the* PPP driver for
DOS.
I tried all four DOSPPP06 non-debugging versions (class1/class6, with/without
CHAP) with Kermit 3.14/3.15 and they work ok. A pleasant surprise: even though
class1 doesn't support BOOTP, you may still use BOOTP with class1 if the
*remote* provides a BOOTP server.
> >I'm interested in knowing how well it performs
Splendidly. Now, it appears to me as if class6 is giving slower performance
than class1 (over the same link). Is this possible, or is it a subjective
mistake of mine? Probably throughput is the same, but response time seems
worse. (Of course, both are worse than the underlying shell account
connection.)
Joe D wrote:
> MS-DOS Kermit rejects incoming frames whose MAC address is the same
> as Kermit's own. Might this be the situation you had in dospppd? In any
> case, MSK does not compare frame destination MAC address with internals of
> the ARP reply.
Don't know how, but it works now. Uninformed guess: maybe the header field
that EPPPD was not initializing the same as the ARP field, contained the own
MAC address by accident? This would be possible if the packet buffer of the
request is reused to allocate the reply.
Regards, Vlad
Joe Doupnik
In article <omn2kcq...@tees.cs.ualberta.ca>, Vladimir Alexiev <vlad...@cs.ualberta.ca> writes:
> In article <5jzp7S...@cc.usu.edu> j...@cc.usu.edu (Joe Doupnik) writes:
>
>> >> >> > Is BOOTP impossible with a SLIP interface? How about DHCP?
>> BOOTP and DHCP require a local MAC address to work with, SLIP has no MAC
>> address
> Ok, now: Is BOOTP availability over PPP links sufficient incentive to warrant
> pursuing this issue?
>
>> continue the conversation with the authors of those drivers and see if they
>> will reveal the extent to which they perform the required emulation.
> Ok, I'll try that.
>
>> Proxy ARP et al have not the slightest to do with Kermit (or other
>> client) internals. That is outside of and unknowable to these clients.
> I know that. I was trying to figure out how does class 1 emulation work.
>
> For a PPP link, Kermit`s job is pretty simple: it has to send all it wants to
> send down the link, without caring mcuh about MAC addresses. That's why I
> think it would be an easy fix: Kermit could simply disregard some of its
> "doubts" about the faithfulness of the class 1 emulation and just go ahead.
You are still grasping the problem by the wrong end. "Just disregard"
may seem to be convenient for your situation but is plain wrong in general.
The problem is very likely improper emulation of Ethernet by the PPP drivers,
as I have speculated each time this thread has a new message.
>> MSK will report
>> 1. if it is unable to register with the Packet Driver for IP and ARP packets
>> 2. if another station responds to an ARP for MSK's own IP address,
>> 3. and if it is unable to receive a response to an ARP.
> This is the kind of info I need to figure it out (if at all possible from
> external observation only). Does the message "Unable to ARP resolve" mean item
> 3 above? Will these conditions appear in the order listed, so can I assume
> that 1 and 2 do not happen?
Unable to ARP resolve means just what it says: ARP request sent, no
matching ARP reply received. Malformed ARP replies are the same as no reply.
>> If those conditions are met and the driver proclaims to be Ethernet then the
>> driver had better behave like Ethernet... Kermit does tell you if
>> interfacing conditions fail
> What other errors can happen from that point on? (Ok, perhaps this is a stupid
> question :-) Can you think of other interfacing conditions that can fail,
> apart from the listed 3?
I say again, the emulation is likely broken. Understanding the overall
situation does require some knowledge of TCP/IP on Ethernet, and this is not
the place to provide a course on that. The authors of those PPP drivers are
the ones to take on the task, as has been nicely demonstrated today.
Joe D.
John Rushby
In article <omen5m8...@tees.cs.ualberta.ca>,
Vladimir Alexiev <vlad...@cs.ualberta.ca> wrote:
>............ thread about Kermit not working over dosppp
My experience is that Kermit over epppd from dosppp05 works for some
ISPs and not for others:
It works when dialed in to my office (fixed IP)
It works with Eunet Traveller (excellent service with POPs all over
Europe, I've used it with Kermit to connect to my office from the UK,
Switzerland, Austria, and USA). Dynamic IP.
It does not work with Ricochet (wireless modem service in
the Bay Area and a few other places). Dynamic IP.
The symptom is that Kermit cannot contact the nameservers and times out.
NCSA Telnet and WATTCP applications have no problems at all (nor does
Linux, but my old Libretto 20 is a bit too feeble to run Linux).
(The reason I'd like to use Kermit is that NCSA Telnet does not let me
map the alt-key combinations to work with Emacs; the Telnet is
excellent in other respects and includes a very fast FTP client, so
you can FTP back in to DOS for file transfer in the middle of a session).
>Hello Vladimir,
>
>I already knew of the Dospppd + Kermit problem, as some users reported the
>failure to me some time ago. The problem is corrected now, there is a pre-beta
>of Dospppd v0.6 package at the following URL:
>
>http://www.redestb.es/personal/tonilop/dosppp06.zip
>
I'm afraid v0.6 made no difference to my difficulty with Ricochet.
I've not tried other PPP drivers, since dospppd is so excellent in all
other respects.
Anyone got any ideas or suggestions?
John Rushby (make obvious adjustment to get my true email address)
PS. Does anyone have experience with IBM Globalnet while travelling?
Eunet Traveller has no service in Japan, so I'm thinking of switching.
Vladimir Alexiev
> My experience is that Kermit over epppd from dosppp05 works for some
> ISPs and not for others:
VERY interesting. How the heck is that possible? As Toni explained, EPPPD's
bug is that in an ARP reply, it leaves the MAC address as it was in the
request; then Kermit drops that packet because it has its own MAC. How can
this depend on the ISP?
> The symptom is that Kermit cannot contact the nameservers and times out.
Does it say "cannot ARP" or somesuch?
> (The reason I'd like to use Kermit is that NCSA Telnet does not let me
> map the alt-key combinations to work with Emacs
If you want, I can mail you a nice set of mappings.
> >http://www.redestb.es/personal/tonilop/dosppp06.zip
> I'm afraid v0.6 made no difference to my difficulty with Ricochet.
Then it might be a setup problem. What does Kermit report? Do any other apps
work over that connection? What happens if you don't use nameservers, and
specify the telnet host's IP instead? Does "show net" report reasonable values
after you try to amke a connection (i.e. was bootp successful)?
John Rushby
I previously reported that I was happily using Kermit over epppd from
dosppp05, whereas others had complained that the combination did not
work. The reason this worked for me, apparently, was that I'm using
Kermit Version 3.13. It seems that Kermit 3.15 does not work with
dosppp05, but it does work with dosppp06.
I also reported that I couldn't get (any) kermit to work with (any)
epppd over a Ricochet wireless modem, though all other TCP/IP software
(NCSA telnet, Arachne, WATTCP applications) works fine. I've since
fixed that problem (I'm using it to post this message), but the
solution (which I found by accident) is bizarre.
The Ricochet modem connects to a serial port, which is COM1 on my
Libretto. The appropriate epppd incantation is
epppd com1 38400 asyncmap 0 namsrv 168.253.48.19 namsrv 198.6.1.1 modem crtscts
If I then tell kermit "set line tcp" AND "set port 2", everything is fine.
Yes, that was port 2--which does not exist (unless I've got a PCMCIA modem
in the slot, which I did not for these experiments). Kermit complains,
but correctly connects via epppd through the Ricochet mode. Failing to do
"set port 2", or doing "set port 1", results in Kermit being unable to
reach anything. This behavior is the same in 3.13 and 3.15.
I'm mildly curious why this works, but happy that it does.
John Rushby
John Rushby
In article <62b6sj$3g2$1...@argon.csl.sri.com>,
John Rushby <rus...@news.csl.sri.com> wrote:
....Bizarre details of getting Kermit to work with ppp and Ricochet
(involving use of nonexistent com port) deleted
Here's the true explanation.
I have a mskermit.ini file that I haven't looked at for many years.
As well as setting up the alt keys for use with Emacs, it sets baud
rate, flow control etc. for use with a direct modem connection.
When I use kermit over ppp, I invoke it with a batch file that
overrides the line parameter to use TCP/IP:
kermit set line tcp, stay
The problem is that when kermit loads, the line parameter initially
defaults to 1, and the stuff in mskermit.ini modifies the
communications parameters on COM1 before the command line argument
changes the line parameter to TCP/IP.
This wasn't a problem before because I was using a PCMCIA modem on
COM2, and modifying the comms parameters of COM1 was harmless.
But the Ricochet modem is on COM1, and epppd doesn't want Kermit
messing with its comms parameters. Putting set line 2 at the top of
mskermit.ini obviously "fixed" the problem by causing the set baud
rate and other commands to be harmlessly redirected away from COM1.
The correct solution is, of course, to leave these parameters alone
when using a TCP/IP connection.
John Rushby
Mike Freeman
In article <62bdfs$3iq$1...@argon.csl.sri.com>,
John Rushby <rus...@news.csl.sri.com> wrote:
>
>The correct solution is, of course, to leave these parameters alone
>when using a TCP/IP connection.
>
doesn't matter if one diddles baud-rate etc. if one is talking TCP/IP over
an Ethernet card. I have Com1 set up as a serial port to talk to my
Vaxstation and an Ethernet card with packet driver to talk over Ethernet
to a TCP/IP-driven network. Am using MS-Kermit 3.15.
Different strokes, etc.
--
Mike Freeman; Internet: mi...@pacifier.com; Amateur Radio Callsign: K7UIJ
President, National Federation of the Blind of Washington
/* PGP2.6.2 Public Key available via my ".plan" file */
.. A professor is someone who talks in someone else's sleep.
Joe Doupnik
In article <628mq4$2tg$1...@argon.csl.sri.com>, rus...@news.csl.sri.com (John Rushby) writes:
> In article <omen5m8...@tees.cs.ualberta.ca>,
> Vladimir Alexiev <vlad...@cs.ualberta.ca> wrote:
>>............ thread about Kermit not working over dosppp
>
> ISPs and not for others:
Might we ask specifically which version of MS-DOS Kermit?
V 3.15 is the current release, and it has signficantly enhanced
DHCP support to accomodate the major DHCP RFC changes made this
past spring.
> It works when dialed in to my office (fixed IP)
>
> It works with Eunet Traveller (excellent service with POPs all over
> Europe, I've used it with Kermit to connect to my office from the UK,
> Switzerland, Austria, and USA). Dynamic IP.
>
> It does not work with Ricochet (wireless modem service in
> the Bay Area and a few other places). Dynamic IP.
>
> The symptom is that Kermit cannot contact the nameservers and times out.
> NCSA Telnet and WATTCP applications have no problems at all (nor does
> Linux, but my old Libretto 20 is a bit too feeble to run Linux).
Perhaps an incorrect IP subnet mask has been provided. But
that is just a wild guess.
> (The reason I'd like to use Kermit is that NCSA Telnet does not let me
> map the alt-key combinations to work with Emacs; the Telnet is
> excellent in other respects and includes a very fast FTP client, so
> you can FTP back in to DOS for file transfer in the middle of a session).
>
Arthur Marsh
John Rushby (rus...@news.csl.sri.com) wrote:
: I've not tried other PPP drivers, since dospppd is so excellent in all
: other respects.
: Anyone got any ideas or suggestions?
Download the timelimited demo from www.klos.com / ftp.klos.com and try
it out.
: John Rushby (make obvious adjustment to get my true email address)
: PS. Does anyone have experience with IBM Globalnet while travelling?
: Eunet Traveller has no service in Japan, so I'm thinking of switching.
Vladimir Alexiev
In article <62b6sj$3g2$1...@argon.csl.sri.com> rus...@news.csl.sri.com (John Rushby) writes:
> happily using Kermit [3.13] over epppd from dosppp05
Ok, maybe 3.13 was more lenient towards the TCP driver.
> epppd com1 38400 asyncmap 0 namsrv 168.253.48.19 namsrv 198.6.1.1 modem crtscts
> If I then tell kermit "set line tcp" AND "set port 2", everything is fine.
Mystifying! The docs don't describe a "set line" command, but from the list of
options after "set line" it seems that it's a synonym of "set port". I would
think that "set port 2" nullifies "set line tcp", and makes kermit try to
connect serially over com2. What does "show net" report?