|
Often Asked Questions
This file contains information compiled from the sage writings of many Internet gurus in countless public and subscribed forums. Their words remain theirs and are presented here only in the helpful spirit of Internet Community. The intention of the F/X Communications copyright is to protect the rights of this entire document, or substantial portions thereof. Quoting specific passages to aid an InJoy user (or potential user) is encouraged. However, to hold down unnecessary Internet traffic: Provide the URL (http://www.fx.dk/InJoy/oaq.htm) and text search string whenever possible.
Save the host in question as default and then create a new host. The new host always inherits the settings of your default host.
All of these can appear as if there is a problem in InJoy, when there is not:
One way to learn what IS happening is to ask the modem! A user suggested: Fire up a terminal emulator such as InJoy's own (or e.g. HyperAccess), and simply ask the modem why it hung up! For a Rockwell chipset, the command is AT&V1, for a USR it's ATI6. For instance, my K56Flex shows the following in response to an AT&V1:
This indicates the connection was broken from the other end, which is correct, as I stopped it with an Alt-T termination request. By comparison, if I hang up with the Esc key, the Termination Reason is LOCAL REQUEST. Other possible reasons for disconnection include EXCESSIVE RETRANSMISSIONS and 3 RETRAINS, both of which indicate a problem with line quality rather than a terminate request from either end. There are probably other possible responses, too - those are merely the ones I've seen. USR modems give you basically the same information, but in a somewhat less user-friendly manner - you'll have to dig through the ATI6 responses, but should find the relevant information in there somewhere.
Your computer's host name is set globally at system start up (in the CONFIG.SYS). Programs that are autostarted by InJoy will inherit, and use, that host name. If you need autostarted programs to use a different host name, then set it in InJoy's 'your host name' field.
ON THE 95 MACHINE
The CONNECT.TXT file, created by InJoy at connect, should give you all the info you need.
CFOS is working great with InJoy, but CFOS versions prior to the 1.1 will require the use of the option -kx. The -kx switch goes on the device=x:\cfos.sys line in your CONFIG.SYS file. Then DTR handling will be done like SIO.
CFOS/2 from version 0.82 (a beta) through at least version 0.99 (still a beta) works. Try: In CONFIG.SYS: cfos com4 -kx In InJoy:
Then there is CFOS, which turns the CAPI into a normal COM port. There is a web page that describes the CFOS/InJoy configuration for the Teles (including screen shots): This is its recommended sample init-string:
A sample initstring is: AT &F L1 B8 X9 &C1 &D2 I just modified the default init string #2:
Here are the steps I took to be successful with NAT (with Warp Connect clients).
You missed reading in REGISTER.TXT, README.DOC and USERGUID.DOC that Network Address Translation, Dial on Demand and Host Triggered Actions are only available in the Extended Client and higher versions. (In other words, the Basic Client version, whether registered or not, does not include those functions.)
The InJoy mailing list is full of bright folks that can usually get even the most stubborn setup humming. Some might even be willing to help you get your LAN setup correctly so that NAT WILL work (but very few, if any, are willing to start from scratch teaching how to do the basic LAN setup stuff). Subscribe here:
You don't have to turn NAT off to fix it, just use the 'Disable NAT for InJoy PC' option in the NAT options. If you have strange problems trying to FTP through a NAT InJoy (or firewall) try your FTP client's "passive mode", sometimes called PASV.
There are ways. One way is to use DoD. It is very complex, but I'll try to describe how it can happen: When you dial with DoD, you get an IP address. If you had a program running using the previous routing/interface definition and that program used another IP address than the current one, then it begins to get dangerous. Here is what can happen: If a program that used the previously PPP assigned IP address was killed, then it needs to send an ip-packet to the tcp/ip proggie in the other end (we'll call that program the host). In order not let the program die fast, the IP stack will handle this.. So, the IP stack will use an old IP address to send out a TCP/IP packet with the FIN bit set.. It will do that periodically for a while (probably 30 minutes or so) until the other end ACK's that packet. This will take up an entry in the IP TABLE.... This is very complex to work around and I believe behavior might even change with IP stack level. Filtering is the way to go to solve that problem, if you have it.
There is a performance hit. And, as the table gets bigger, the bigger the hit. Its better to have *just* enough.
First remove the "LINKUP.EXE" from your "program" field, and put NR2.EXE in its place, from the "parameter" field. Then put your news-server in the "parameter field". That way you start NR/2 with these settings (for example): Program: NR2.EXE Parameters: news.globalnews.com This also counts for other programs started with the LINKUP.EXE program. (For example: Software Updates in Warp 4.0)
If you are using Warp v4.0, use the set of utilities for the LAN. Those do not use or reference the LINKUP.EXE explained here for InJoy users with Warp v3.0: The Warp v3.0 and v4.0-modem telnetPM/FTPPM templates cannot be used with InJoy since LINKUP.EXE is "hidden" in the templates and the existing Internet connection cannot be detected by the telenet and FTP programs. If you wish, you can drag a program template from your templates folder and create a new telnetPM or FTPPM icon for use without LINKUP.EXE. Place "ftppm" or "telenetpm" in the 'Path and file name:' block (without the quotes, of course). And, by using command line parameters you may set each newly created program object to connect to a different host (and never have to type an address twice again). Refer to either program's online help for the optional parameters which are available.
In your login script there should be a E71 part to login, and a N81 part for PPP. SpryNet uses an E71 connection for terminal connections, but PPP requires a N81 connection. Your login script should look like this: This script was reported to work with Compuserve:
DE: 1000 TX: \r RX: ame: TX: CIS\r RX: ID: TX: [$USERID]/GO:PPPCONNECT\r RX: ord: TX: [$PASSWORD]\r DE: 1000 PA: N81 This script was reported to work with SpryNet.
DE: 1000 TX: \r RX: ame: TX: SPRY01\r RX: UIC: TX: [$USERID]\r RX: ord: TX: [$PASSWORD]\r DE: 1000 PA: N81 First line sets a E71 connection. The DE: line takes care of a delay before the first output. With this kind of services it's needed to send a [ENTER] before starting. The following lines take care of login, and the last sets the connection to N81 for PPP. This script (modified as needed) should work for Compuserve and other online services that use the CIS system for login in.
Make sure that the fields "Destination IP" and "Your IP" list 0.0.0.0 and not a valid IP number. That way IP numbers will be negotiated with PPP.
Grab the top edge of the box with the left mouse button and drag it out of the way. If you are using Warp v4.0 or an add on which allows 'Cut & Paste' type operations in a VIO window see next item. Or, if you are using a version after 1.12, just below the [ Exit ] button on InJoy's opening face, is a line saying "Connect Box [X]" just click to remove that X and the box goes away.
Make sure that Warp 4.0's Mouse Actions is off. By default, they are ON. Change it from the menu available by clicking on the VIO window's upper left hand corner. Someone suggested that the system default should be set to OFF, to do that:
It has no UART chip and is therefore not "seen" by OS/2 as a valid COM port. Even in DOS the WinModem won't show up as a port, for example if you run MSD.EXE it will not report the modem. WinModems work only in MS-Windows ... if you want a modem which is not tied to one operating system, you need to return it.
Yes, your ISP is referring to PAP or CHAP.
PAP = Password Authentication Protocol They are two different ways that ISP's servers authenticate you (the dialing in dude) as being authorized access through their gate.. PAP and CHAP have mostly taken the place of having to manually type in your UserID and Password every time you log on. With a PAP and/or CHAP capable ISP its a simple matter of filling in the UserID/Password blocks in InJoy and turning on PAP or CHAP. And, using either means there is NO need for a script ... not even any need for InJoy to do is famous auto-learn-the-script-trick...
Yes. Just use the host name as the argument. For example:
NOTE: The host name used on the command line IS case sensitive. You must enter it exactly as recorded in InJoy's [ Host ] listing. Tip: You can also set this up in host objects and have several hosts you can 'click' to life.
Responsible for Name-resolution are the files
AFAIK InJoy writes it's DNS-config to RESOLV, but if RESOLV2 exists, RESOLV2 is used. Furthermore you can use HOSTS-file by simply:
Additionally you can edit RESOLV2 and RESOLV by your own. Format is rather simple:
Up to 3 Nameserver entries are allowed. What does OS/2 do with 3 Nameservers? If the first one can't answer your request, is uses the second, if that don't answer it uses the third. If that don't answer either, you've a problem ;-) You can, cause of that behavior place all your nameservers (the ones of your provider as one in your local network) there. But be aware: The second entry is only used, if first server can't resolve or doesn't answer. And nameserver timeout is quite long, so that sort of work is not really good solution for your problem. Absolutely overkill (but a nice one, and technically interesting ;-) would be to set up a local cache-only DNS on your private network at home. Has some benefits (it's simply fast ;-) but takes some time to configure and read man-pages and admin manuals. Use bind-port V8 here, if you want to do that. In that case you'd configure InJoy with your own IP-Address or 127.0.0.1 (loopback must then be enabled) for DNS-Request if DNS run's on your working machine. If local DNS run's in your home-network, place IP of the DNS there. This (but also the above) solution is tested by me and run's really fine.
What you must do is in your setup string to the Impact, send an S80=1 (it probably is set to S80=0 now). This will enable bonding of both B channels. Also, multi-link PPP must be enabled.
Check you microcode level (ATI8). Level 1L seems to have problems with single link PPP (@B0=1) but works with DTE speeds of 230400K. The 1K level works with single and multilink PPP but has trouble setting 230K. For single link PPP with CHAP to authorize, I use level 1K and an init string of: AT&F0&C1&D2@M2=C@B0=1
Some users of InJoy experienced a hang-up problem using this ISDN TA. Several users reported successful use of this TA with the following INIT string:
The ISDN modem plugs into a standard COM port. If you have 128kbps access add an & and the last digit of the phone number (If the number is 123-4567 then you would set up the number to dial as 123-4567&7.) This dials the number with both B channels. Also, according to this mailing list you need to add &D3 to the end of your init string. This seems to make it possible for InJoy to redial and hangup the modem (I couldn't do either before I got that tip). My modem is a Motorola Bitsurfer Pro EZ, if you have another brand this may be different.
It works fine. It will depend of your ISP. If they support Multi-PPP then the following works. The BitSurfr PRO manual has all the details.
Init String #1: AT&F It creates a 64K link, and then dials the second number to add the other 64K. You can actually make a POTS call while connected. The line simply drops down to 64K for the duration and hops back up to 128K when finished. I just have the port set to 115000 and run without problems.
Set the Init-String in InJoy to ATZ and ATB40S0=0. And, if you need CHAP/PAP add S87.2=0 to the second Init-String. Another user reported:
The Zyxel 2864i sends a 2K data block by default. I changed it to a 1K block. After this modification, no more loss of connections occurred. The AT sequence used is: AT&O2 CL1024 (&O2 puts the modem in digital mode CL1024 forces 1k data blocks) Now InJoy with two users working over the gate is very stable.
Try these initialization strings:
I think the success of these strings may depend on your version of the chip. One user wrote: For my external USR Sportster modem to work with InJoy, the modem init string must either be AT&F1 or AT&F&B1.
That is a known USR modem (NOT InJoy) problem. Add the S12=0 parameter to the modem initialization string. But, this was found on the net and is reported exactly as found: "I had the same problem when using a USR Courier I modem. Setting s12=0 in my init string cured the problem, but I was then advised to change the above to S2=25S12=255 and this also cured it. The S2=25S12=255 was recommended as a preferred solution so try it first." But another writer phrased it this way: "The problem you're having _may_ be related to a V.42 problem with some Sportsters. Try adding S12=0 and S2=255 to the init. If that cures the problem, leave them in the init. If it doesn't, remove them - you should use those commands only if they solve the problem. The other thing you could try is also related to V.42 - add S15.7=1. Again, if this doesn't help, remove it. Another user said: Modem is a 33.6 USR Courier V-everything external. I use a Modem Initialization String like this:
I was told by someone (who had a V.Everything) to use a predefined modem definition for a "V.32bis" Courier if a program had one, since the init strings for a HST Dual Standard modem won't work.... I know... it's a V.Everything but when I got it they were shipping them with a manual for the HST Dual Standard Courier, and so I basically stole this init string from some program that had a definition for Courier V.32bis, and added S11=55 at the end to make it dial faster. Another said: The cheap internal clone modem documentation says to use whatever a USR 28.8/33.6 Sportster uses for an init string. I've been using that to little avail UNTIL I found an old message from the Mail List with a truly interesting USR init string that seems to have worked on my setup: ATQ0S0=0V1X1&C1S12=0S2=12&D3 and, this alleviated the sluggishness of the modem. And still another said: If anyone else needs the init. string this is the one I got to work....
U14 is to set the modem floor speed to 28.8k. This means that it will disconnect if it can not connect at this speed of higher. But the guy with the most simple solution said: I use the same init I used prior to X2. Just the AT&F1 always works fine here.
Try setting your 'S10' register to a higher value. Maybe you have a noisy phone line. For many popular modems (yours may be different) the 'S10' register sets the delay time (in 1/10 seconds) the modem waits after a loss of carrier before hanging up. So if your disconnects are caused by a loss of carrier due to noise, increasing the delay will help to keep you connected. Try S10=20 (two seconds).
The Phoebe CMV1433VQH is a USR Sportster clone using one of the TI (Texas Instruments) chipsets. This means that you can (and should) use &F1 for your only init. string. Next I'd suggest the following:
Sometime later, the original questioner added: I finally got word from Phoebe support. The init string they gave me is AT&F&C1&D2. Yesterday, before getting the init string, I kept getting a pegged CPU and a partial lockup - that is, CAD got me out of it. After putting in the new init string this morning things seem to be OK.
Many users have reported problems when using the USR Sportsters. One user reported that the problems went away when he installed the latest firmware upgrade from USR. He also noted that one default setting was changed and that may be a clue. The default of &S1 was changed to &S0.
The AT&W2 command writes the current string to NVRAM. NVRAM is a type of memory chip that does not need a battery to store data when the power goes off. It can be read many billions of times, but written to only a few thousand times. After only a few thousand writes NVRAM won't store anything and your modem becomes an expensive paperweight. That's why the redial feature on cheap telephones dies after a few years - the phones NVRAM gives up the ghost after a few thousand numbers are dialed. Only write to a modems stored profile when absolutely necessary - never in an init or dial string!
Well, the first thing to do is to make sure we know just where the trouble is. For example, can you identify with this true life testimonial?
This stalling only occurred to me when I was 'filling the inbound pipe' completely with multiple FTP transfers at same time. When it happened it would stay stalled until the timer expired and InJoy hang up. On one occasion I called the ISP on a separate voice line and asked them what it looked like from their end: They told me that they could see the data that my end was sending, but their end was not sending anything. The tech tried pinging my IP and got no response, he said he could also see that the transmit LED on the modem at their end was not flashing . . . I asked what the CTS line was doing, he reported that it was OFF! BINGO! this is why no data was going out. How could it possibly get this way? Tech says he donno . . . but he knows how to fix it . . . Just a second he said, as he turned the modem off, and then back on. I've since switched ISP's (btw, my modem was a USR Sportster 28.8 internal...at the other end a no name clone of the month.) So, step one in solving "InJoy problems" is to *find* THE problem, and then solve it. Most problems are simple (but often hard to find) setup faults.
A freeware UNIX program which emulates a SLIP or a PPP connection. It therefore allows Internet users who have only a UNIX shell account to access the Internet with Winsock or similar applications (like Netscape) just as though they had a SLIP or PPP account. (Works great with OS/2, by the way.) For further info consult Gasparovski's (the author's) SLiRP page and related links at: http://blitzen.canberra.edu.au/~danjo/
Sometimes this can be traced it to invalid information in the login script as the result of letting the autolearn feature run too long and 'learn' too much. If you don't stop the autolearn at the right time it will record negotiation with the hosts PPP software. Removing this trash at the end of the login script should fix most problem in this area. You might see an: RX: {s{ome{garbage{{ At the end of the script.. Just remove that line and give it another try.
Your system may still be swapping (paging) during startup when it hangs. This sometimes happens in OS/2 v2.1 to Warp v4.0 when starting some programs during high paging activity. Put a sleep into your STARTUP.CMD to make you wait for the desktop to settle down before starting other programs. Likewise in startup folder I put a program reference to sleep at beginning. If you don't have a sleep program, use this REXX script:
/* sleep a little */
parse arg seconds
rc = SysSleep( seconds ); EXIT
You have the smallest of problems in the world.. A tiny little SPACE character is received from the PPP Server just before it discovers that you run PPP. When InJoy receives a space character (DOIP too), then in PPP it appears as an unsupported protocol, thus the error! If you want to get rid of this (and there is no good reason really), then do a script that waits for the final part of the string that the PPP Server sends you! (Like, some might say "Welcome" while waiting for other dial in machines to finish getting ready; but InJoy is too fast and is already wanting to PPP.)
Yes and no. No, InJoy can't do it. What's happening is that you are starting the executable for EmTec News (NEWS.EXE) just like you might from a command line. It runs fine, but so will several copies, if you start several copies . . . which is exactly what you don't want InJoy to do. But, if you were launching an EmTec News program object, you would have the option of setting the object to either begin a new copy, or 'call' the existing instance. While InJoy can't do that, it can start a different program which is specifically designed to launch a program object.
Pick up a copy of "Object Start" (at Hobbes, called objst*.zip). It
was designed to let WebExplorer start program objects, but it works
just fine with InJoy (once it is setup
Open InJoy and place it where you want it. Hold down the shift key and double click on InJoy's title bar. InJoy will open there from now on. Unfortunately, you just sat the opening position for all Warp's command line windows, so all will open at this same spot. This is an OS/2 limitation that cannot be overcome by InJoy.
In order to use the COM port with InJoy after FaxWorks Lite (from either the Warp v3 or v4 Bonus Pak) has sent or received a FAX, or while it is waiting to receive a FAX, you must manually cause FaxWorks Lite to release the COM port. This can be done only by using the menu options and causing the receive to be reset, or by exiting FaxWorks Lite - also from the menu options. To reset receive mode, select the FAX pull down, select receive, then select off. This will cause FaxWorks Lite to no longer wait for an incoming FAX. Another solution is to purchase the full retail version and use its shared COM port capabilities. In the FaxWorks Pro Version 3 User's Guide there is a section titled "Special Hardware Issues" that discusses how to share the COM port between a data program and FaxWorks Pro. Refer to the manual for the details, but there are two ways to do the port sharing and allow InJoy and FaxWorks Pro to work together. 1) Use the FaxWorks supplied COM driver FMD.SYS, do not mark the modem as private in the settings notebook of FaxWorks, and insure your system can support the ring indicator from your modem and COM port. Do not use non-standard COM support, which would preclude FaxWork's FMD.SYS driver from using the COM port. No special settings are required for InJoy if this option is used. 2) Use COM.SYS, SIO.SYS, or another COM driver for the port interface to FaxWorks Pro. The FaxWorks receive mode can be reset from the program menus, or by using the retail pack's included FxRcv.EXE utility, or by using the REXX API FxRxMode call (supplied with FaxWorks Pro). This option requires InJoy to start the FxRcv utility prior to dialing, and then to restart FaxWorks Receive with the FxRcv utility after InJoy hangs up. Since the FaxWorks' receive mode may not end immediately when the utility is run, InJoy may go into a retry loop attempting to obtain the COM port. This can be circumvented with REXX code to wait for the COM port to become free prior to releasing InJoy to initiate the dial (using the SETJOY.EXE.EXE /C command). FMD.SYS can also be used with this option if desired. Those instructions should even work with Dial On Demand!
Com.sys has a problem with some PnP modems. Try this: Use rmview /dc|more and search the list for the modem. Look for the IRQ and I/O resources used by the card. You may see something like this:
PnP Device ID: XXX1234 PnP Compatible Device ID: none I/O=0x03E8 Len=8 Flg=EXCLUSIVE Addr Lines=16 IRQ Level=15 PCI Pin=NONE Flg=EXCLUSIVE Edit the config.sys and update the parameters for the com.sys driver. For example, if your settings showed I/O = 2F8 and IRQ = 3, you would update the com.sys line to support the modem on com2. The line would look like this:
After you reboot, you should be able to access the modem on the port you setup. If you have a PnP Cardinal modem you might find that it is supplied with a pnpset.exe file (for use under DOS). Run it under Real DOS (as explained in the manual) to get the initialization string. Then make a DOS batch file to run to recognize the modem. You can add this as a minimized DOS object in your STARTUP folder.
RX: Username: TX: [$USERID] \r RX: Password: TX: [$PASSWORD] \r Yes, it does LOOK good . . . however, if you will remove the unneeded space between the ] and the \r and it will look good to the host too.
If using a TCP/IP stack prior to v4.0, there is a known problem in switching dialers without booting in between.
SetJoy MUST be executed in the same directory as InJoy's executable (IN-JOY.EXE). That means if you are running SETJOY.EXE from a script or .CMD file the script MUST CD to the InJoy directory prior to calling/running SETJOY.EXE.
The default install of Warp will place a SET ETC= statement in the AUTOEXEC.BAT file pointing to x:\TCPIP\DOS\ETC (where x: is YOUR drive) while placing a statement in the CONFIG.SYS pointing the same SET ETC= variable to x:\TCPIP\ETC. Clear? Oh, so what happens is that your win-OS/2 applications are looking to the RESOLV file in the x:\TCPIP\DOS\ETC directory while the Warp applications are looking at a different RESOLV file in the x:\TCPIP\ETC directory. AND, InJoy is UPDATING the one in the non-DOS directory, only...it is correct and the win applications are lost... The cure is simple: make the SET ETC= statement in the AUTOEXEC.BAT look exactly like the one in your CONFIG.SYS.
Yes. The IBM Internet Dialer does not work with Shiva Routers, but InJoy does, presumably because of MS-CHAP extensions that the Shiva seems to require. (Hmmm...this is pretty much quoted from an old mail...maybe by now the IBM dialer also works...) To get it to work with a 3rd party authentication, I had to enter a secondary password and UserID in the definition of the 'Host'. I got these values from the user procedures from the support people for running on Windows 95. This was distinct from the real UserID and password that I had to negotiate through the InJoy script (to the 3rd party authentication process). Two UserIDs and passwords gets confusing, but it seems to be the norm with Shiva routers. I selected PPP as the protocol and assigned 0.0.0.0 as my IP address and 0.0.0.0 as my destination IP address (InJoy fills in the real values when the connection is made). Under PPP options, it is important that MS-CHAP Authentication be selected. The other options did not appear to have importance other than getting InJoy to work well with my modem (not your problem). That should get you up and running so that, once registered, you can play with things like performance tuning and NAT (using one dial in session for your local LAN).
In addition to using "SET USE_HOSTS_FIRST=1" in your config.sys, you should use 'RESOLV2' for LAN DNS and 'RESOLV' for dial-up DNS.
A wise user wrote: Set NT to accept any authentication including clear text and don't use any scripts until that is working. Be sure to enter your fill in InJoy's UserID field using this format: DOMAINNAME\username (NOTE: All caps in the domain name.) But, in the Password block just enter your password (case sensitive). Other writer's used different terms. Like: DOMAIN_NAME\login. Enable MS-CHAP (and turn off PAP) authentication.
And a user answered: The trick in connecting via WINS is to configure MPTS as follows:
The speed goes to CONNECT.TXT but that is overwritten at each connect. You could pipe the CONNECT.TXT >> CONNECT.LOG at each connect and then each entry in the log-file will then have a similar entry in CONNECT.LOG.
It's possible your MTU is too large. What happens is Netscape sends a packet of size x which matches the MTU of the local network. It gets transmitted to the OS/2 machine where the TCP/IP stack discovers that the packet is larger than the MTU of the PPP interface and then drops the packet. Unfortunately, the packet sent from the NT machine does not include the option to fragment the packet. Try changing the MTU of your local network to match the MTU of your PPP interface. Execute "netstat -n" on the OS/2 machine to get the current MTU's. On the OS/2 machine, modify the \MPTN\BIN\SETUP.CMD (or \TCPIP\BIN\SETUP.CMD for Warp v3). On the line that resembles: ifconfig lan0 172.30.0.10 netmask 255.255.0.0 add 'mtu x' to the end where x is the size of the PPP interface. Under NT, there is a registry entry which I don't have handy. It's probably under 'Registry \ LocalMachine \ System \ CurrentControlSet \ Services \ adaptername1 \ tcpip \'. You should be able to find it by searching Microsoft's KB.
InJoy works GREAT with 56k modems. Give you modem a fast port; a good init string and a clean telephone line and you will KISS InJoy for being SO good. Look elsewhere in this OAQ for general modem initialization string setup information. If you live in North America, go to this site and learn how to test your phone line: NOTE: You do not have to be using a 3Com modem to test your line. Or, you can try dialing the USRobotics test number:
This automated test center will run all the diagnostics it can on any modem. You will need a communications package like HyperAccessPro or equivalent.
Depends on the type of computing they do. If you send lots of small packets and mostly interactive stuff, then the smaller the MTU the better your "performance". If you move lots of large packets then a larger MTU is good. Couple that with the speed and reliability of the interface. The less often you have lost packets the larger MTU sizes will outperform the smaller. Lots of lost packets and you can lose a lot of time resending large packets. Another user asked:
InJoy author wrote:
I might be totally wrong, but the bigger packets the less overhead and my own calculations and tests have supported that. Often the packets will be fragmented on other networks though and even if you set the MRU real big, you might not receive packets any bigger than 1500.. There are as many opinions as there are people, and I think the subject is getting way too much attention. I would never lower it to 296 as the PPP overhead would then grow a whole lot (that is about the only fact I can come up with). A user said:
Big packets are great if you're not getting errors. If you get a lot of errors you will be resending a lot more data for each error. This is why some people use smaller packets for dialup. And another user added:
And another said:
(And later answered himself) It was the MRU size which I had set to 4096. When I change it to 1500, the performance problem goes away. I'm not sure why the large MRU size would give such a huge performance hit, but it definitely did so. (And someone else answered: Because ethernet's MTU is 1500.) And add a twist of win95 and NAT:
I had the same problem on an nt4.0 machine running Netscape Communicator. I run InJoy on my main computer, a Warp 4.0 workstation on a combination Netware 3.12 / Peer network. The problem seems to be that if the MTU/MRU size of the win system is different than the InJoy machine, stuff starts to break on the win side. OS/2 keeps on trucking. I solved the problem by using another program besides Netscape for mail. Netscape has a *very* short timeout time on Email and bombs when a few packets get garbled. I could send short messages (a few lines) that fit into one packet, but long ones would time out without sending. I am told that you can adjust the MTU/MRU size on win systems. I was unable to find the setting in the nt registry and gave up. I hear that it is trivial to adjust MTU on Win95 systems. [Editor's note: As of the date of this writing, a shareware solution was found here. F/X Communications has not tested it, and can neither confirm nor deny its suitability for matching win/nt MTUs to InJoy's capabilities/settings.]
(After lots of help from folks on the InJoy Mail List, the original
questioner [Jonathan B. Bayer What I didn't mention was that I needed to do ppp from both OS/2 and Win95 on my laptop via a null modem cable to my PC at work. The first problem was getting a ppp connection working on my PC to OS/2 on the laptop. I needed to start ppp.exe and then after the connection was started I needed to run ifconfig to set up the network info. While there may be more elegant ways of doing this I am starting up ppp by hand and then after the connection is established I run ifconfig. The file "ppp.cmd" has the ppp.exe command and the ifconfig command rem'ed out for documentation. On the laptop side I simply created a Direct Connect configuration for InJoy which had no modem info and no phone number. I set the ppp parms to fast mode. Since I am running SIO on both systems the connection speed is 115200. On the win95 side I needed to configure a null modem. Guess What? MS doesn't include a null modem definition. After searching I found the file "mdmcbx4.inf" which sets up a null modem connection very nicely. I then created a new connection which used the null modem device and was able to connect to my PC.
Yes, this is the way we are accessing the network. You will need to get your ISP to assign you a bank of IP addresses (we got 16). One thing you might want to think about is asking you ISP to assign you a separate IP address for the dialup (so you don't have to subnet the assigned block to be able to setup the router). The optimal way would be something like this:
x.x.1.x Dialup ip address (PPP side of the router) Your lan MUST use ip addresses assigned by your ISP, so if you already have IP addresses assigned on your network you will have to reassign. Then you would need to set the LAN address of the Dialup machine up as the default route for all of the other machines on the network. And don't forget to turn on IP-FORWARDING in TCPCFG!
I had the same situation when I first started using InJoy. Someone on the mail list recommended making sure the port speed was set no higher than 115,200. Problem went away.
Are you saying you don't like InJoy's looks? Then look in a mirror and decide InJoy is beautiful! :-) Do this: 1) Make a program object with InJoy; 2) add the name of the Host (exactly as entered in InJoy) to the parameters field of the object; 3) then under the Session tab, choose start minimized; 4) done...until you wanna shut it down (Hint: set the timer, use the task list or even KillJoy.)
Take a look at http://www.alternic.net
Under Changes -> Comm Setup, enable "Re-connect after connection loss" is enabled. That should work if PPP negotiations fail.
InJoy only looks at one signal ... CARRIER!
ALT-T makes InJoy send a TERMINATE packet. A terminate packet is just some usual data, but part of the PPP protocol. It will make the PPP server drop the connection.
Try turning off the Hardward Flow Control in the InJoy "Comm Setup".
Comm programs you have loaded before it can alter the baud rate setting for a port and force a baud rate setting that is less than your IP may allow - hence allowing you to be cut off at the knees. The OS/2 solution is with the SIO utilizes from Ray Gwinn. Use his SU utility with the following command line: SU Port# LOCK 0 That will free the port locking and permit connects if some other program, such as your win-OS2 dialer has botched the works. I have other comm programs that must lock baud rate that have to be cleared, hence I run a dialer, sometimes, from inside .CMD files rather than just by program name so I can specifically get around this problem. The trick is to make sure your COM port is being used at a baud rate and in such a way as to be compatible with both your program and what your modem needs for control purposes. Be *SURE* to define hardware handshaking at these speeds!
That can easily happen if you haven't enabled hardware handshaking in the OS/2 dialer, but it is being used in the Win dialer and in the Win setup! Typically, the handshaking simply falls apart when the data begins to flow, if you are not using it on connect speeds above about 14K or so... There are other ways it can happen. I've seen this happen where the MRU unit length wasn't set properly in SLIP connects for me, and it is possible that your IP has other than a 'standard' setting of 1500 for PPP, I am told.
Look CAREFULLY at the modem setup string, BYTE for BYTE that works for you in DOS and elsewhere. When you get to the point in InJoy dialer that it needs modem information, DUPLICATE it there.
There is one very curious problem that can happen IF you have networking installed and are attempting or somehow there is a route file that has been built in your ROUTE file for OS/2 or the companion ROULTE file in the x:\TCPIP\DOS\BIN\ETC directory and.. it is conflict with haw the OS/2 dialer wants to ADD the necessary 'default' route to your IP, it can work out that you can connect all day long, but never be able to communicate with it! Another solution for those who would play with Win dialers and IE4.0 in a win-OS2 session has been, in my case to defeat their botch up of the ROUTE files by adding the following pre-loader command line in a batch file that runs launches InJoy (or you could have InJoy autostart the batch file before it dials) ROUTE -c Note that the -c is in small letters. That -c argument in the above clears the botched route statement and lets the dialer do a clean job of setting up a route... You can, at command line level in an OS/2 windowed session, use the utility NETSTAT with the -r parameter in lower case letters as well, to see what the ROUTE looks like! For beginner's purposes, if the default route for your PPP connection to your IP is not first in the stack, I've learned that bad things can happen to your connect, even though you can connect. When you enter ROUTE -c , use of NETSTAT -r will tell you the route has been cleaned out. It will be null. At that point a fresh connect will build it so that at least your connection will work, in my experience.. BTW, the SETUP.CMD in the MPTN directory, will use the SETUP.IDX, file to re-build the network route, should you be playing! That's defined, as I (a layman) know it, by how you set up networking in the TCPIP SETUP folder! IF you have gone wrong in it, it is possible to get WARP fouled up so that your dialer will connect, but doesn't have the right routing information to talk to your IP...
A user answered: Make sure that you do not have any read-only files in your InJoy directory. I backup to CDRom and restored from it and had this same problem. I finally figured it out. I removed the Read-only attribute and InJoy worked again...
You can start it in a full screen session, if you wish. Or you can experiment with this in a .cmd file (mine is named BigJoy.cmd):
cd InJoy mode co80,43 in-joy.exe exit Where x: is the drive your InJoy directory is on. You can learn more about the mode command in the online command reference (like, try numbers other than 80,43).
|