Running Herc:
HHC842I XXXX open error: X.X.X.X on Z.Z.Z.Z: No such file or directory
Either:
- No adapter on the Windows host system has an assigned IP address of Z.Z.Z.Z.
- Certain required DLLs (most notably, FishPack and TunTap32) are either missing
(i.e. not installed on the system) or are not in Windows's search path (i.e. they may be in another
directory where Windows can't find them).
- The required WinPCap device driver is not installed.
- If running on Windows NT, Windows 2000 or Windows XP, you do not have the proper authority or privileges to start the NPF (Netgroup Packet Filter) kernel driver service.
Resolution:
- Ensure you are using the correct IP address of your adapter. You can check what the
IP address of your adapter is by entering the command ipconfig -all in a Command
Prompt window.
- Ensure that the FishPack and TunTap32 DLLs should are in the same directory as the
Hercules executables are (or alternatively, in your Windows system directory).
- Install (or un-install and re-install) WinPCap.
- Ensure you are signed on as an Administrator when attempting to start the NPF service for the first time after rebooting. For more information, see group message 22877.
Note: Please also see question #13.
Running tt32info:
LoadLibraryEx(FishPack.dll) failed; rc=126 (or rc=1157)
Either:
- You are running an old debug version of TunTap32 or FishPack by mistake.
- One of the required DLLs is missing (e.g. MFC42.dll, MSVCRT.dll, IPHLPAPI.dll, etc) or not in Windows's search path (i.e. in another directory where Windows can't find them).
- The FishPack.dll itself is missing (or not in Windows's search path, i.e. in another directory where Windows can't find it).
- You are not using the latest version of CTCI-W32. (Earlier versions had bugs)
Running Herc:
** CTunTap::OpenTunTap: Invalid initialization buffer size(s)
** CTunTap32App::OpenIPTunTap: OpenTunTap failed for process XXXXXXXX; rc=87
HHC842I XXXX open error: X.X.X.X on X.X.X.X: error 0
The buffer sizes specified on the Hercules device statement are invalid. The dll buffer size cannot exceed the device driver buffer size, and both must be within their respective limits. See the "CTCI-W32 Configuration" web page for the documented minimum amd maximum values these buffer size operands can be.
You're using an old version of CTCI-W32 with a known bug in it. Please upgrade to the latest release.
(Note: this can also be caused by not having WinPCap installed properly. See questions 1-d, 9 and 8 for more information)
Either:
- The version of Cygwin you have installed, or are using, is incompatible with
the CTCI-W32 version of Hercules. Please upgrade to Cygwin version 1.3.6 or later (i.e. the version
of your cygwin1.dll should be 1.3.6 or greater).
- or -
- You have an older version of cygwin1.dll somewhere that is accidentally being used by mistake (i.e. it's somewhere in Windows's search path where it can find it, and indeed HAS found it, and is currently using it.) Check to make sure you aren't running another Cygwin process (program) somewhere that's using the older version of cygwin1.dll. If you are, close that cygwin program and then correct your Windows search PATH and/or delete the old cygwin1.dll. Cygwin1.dll must be 1.3.6 or greater.
When running tt32info, you get the error messages:
** CFishPackApp::FishPackNtGetAdapterNames: no buffer given or given buffer too small
** CFishPackApp::FishPackGetAdapterNames: FishPackNtGetAdapterNames failed; rc=0
This is completely normal and is not an actual error. The first call to GetAdapterNames is designed to fail and get this error.
The first call to "FishPackGetAdapterNames" is purposely done with a NULL buffer pointer and a passed buffer size variable of zero bytes. FishPackGetAdapterNames will of course fail, but when it does, it returns back to the caller (in the buffer size variable) the minimum buffer size required to contain the list of adapters. The program then allocates the required minimum buffer and makes a second call that, THIS time, *should* work without error.
This is the way that many Windows WIN32 APIs in fact work, and is pretty standard when you need to have the system pass you back a bunch of information but you have no idea how much information it's going to be passing back. The first call, which "fails", tells you how much data there is going to be (so you can allocate a large enough buffer to hold it all) and then you make a second call to actually retrieve the data (after first allocating a buffer of the required size of course).
This problem has been reported as follows:
When I turn on a second machine in my LAN Hercules starts looping!
I see a lot off SIOS between the two CTC Adapters and CPU Usage
(MIPS) is high in the Hercules Control Panel. The OS390 hangs.
The user further states that everything works fine if no other workstations on the LAN are up and running (it is unknown whether any of those other workstations are also running MVS or OS/390 or not) and the problem appears to only occur whenever subsequent workstations are "brought online" to the LAN.
This problem has also been reported as follows:
I can get CTCI working OK on the local WIN2000
to a certain point. I can PING the VM TCPIP and
vice versa, but I cannot get TELNET to work.
If I PING the VM guest from the other WIN95 machine,
it does work, but then VM/TCPIP goes nuts, like it's
in a loop. I can then see hundreds of packets going
out on the WIN2000 NIC and CPU/SIO go thru the roof.
Cause:
You're using an older version of TunTap32.dll and your guest system's (VM, MVS, OS/390, etc) TCP/IP settings mistakenly have IP forwarding enabled, causing it to get stuck in a "feedback loop" wherein it reads and responds to every packet that it writes. It writes a packet, and then ends up reading and responding to that very same packet, causing yet another packet to be written, which is then read and responded to, etc...
Resolution:
Either upgrade to the latest release of TunTap32.dll (version 2.0.0.367 or greater), or else ensure that the IP Forwarding option is disabled on your guest operating system (i.e. VM, MVS, OS/390, etc). The way you do that of course varies from one operating system to another, but for VM, I've been told that you should add the statement:
ASSORTED PARMS NOFWD ENDASSORTEDPARMS
to your PROFILE TCPIP control file. For other operating systems, check your documentation.
Note: You should, however, continue to keep IP Forwarding enabled on your host system (i.e. Windows).
Also note: that this IP Forwarding and looping problem should not be an issue with the latest version of TunTap32.dll (version 2.0.0.367 or greater).
Running tt32info, you get the error message:
** tt32info: FishPackOpenAdapter("Packet_{...}") failed; rc=1060: The specified service does not exist as an installed service.
Cause:
WinPCap is not installed properly.
Apparently (due to WinPCap's poor design), simply installing WinPCap isn't good enough in order to be able to actually use the damn thing. (Stupid, I know. But that's Politecnico Di Torino for you. <shrug>)
Their packet.dll is what issues the "CreateService" API call to create the needed entry in the Windows "Service Control Manager" database. CTCI-W32 simply issues the start for the service, but if the service doesn't actually exist yet . . . well, it's not going to work too well (i.e. at all).
So, what you need to do is this: after installing WinPCap, you need to run their TESTAPP program at least once in order for the service to be created. From then on, CTCI-W32 should be able to start the service whenever it needs to.
(See also the following group message for additional information: message 22877)
Their "testapp" program can be found in their "Developers pack" at the following URL:
http://www.winpcap.org/install/default.htm
http://www.winpcap.org/install/bin/WPdpack_2_3.zip(Note: The testapp program should be in the "Examples" directory after unzipping the above file)
If WinPCap is installed properly, then an entry for "NPF" should appear in your "msinfo32" list of drivers. If it doesn't, then WinPCap is not installed properly.
Note: The entry is under the name "NPF", not nbf, npfs, etc. The nbf, npfs, ... etc, drivers are something else entirely. The WinPCap driver should be listed under the name "NPF" with a "started" status. If it isn't, then WinPCap isn't working right, and no matter what you do, ctci-w32 isn't going to work! You need to get WinPCap working first. Once WinPCap is working, then ctci-w32 should work properly for you.
When running tt32test and/or tt32info, you get the following error messages:
** CTunTap::OpenTunTap: OpenGatewayAdapter . . . failed; rc=1168: Element not found.
** CTunTap32App::OpenIPTunTap: OpenTunTap(...,...) failed for process XXXXXXXX; rc=1168: Element not found.
Possible causes:
- WinPCap is not installed properly.
- or -
- You are using version 2.3 of WinPCap on a Win9x system with an older version of CTCI-W32.
For cause (a), see question 8 immediately above for important additional information regarding the proper installation of WinPCap.
For cause (b), please upgrade CTCI-W32 to the latest release. Earlier releases had problems on Win9x systems when used with version 2.3 of WinPCap.
Yes, even though question 13 of Politecnico di Torino's WinPCap FAQ clearly states that WInPCap itself does not work on loopback adapters, it has nonetheless been reported to me that using Microsoft's built-in Loopback Adapter (that comes with WinNT/2K/XP) apparently works just fine with CTCI-W32 (although I have not personally verified this).
Apparently, even though question 15 of Politecnico di Torino's WinPCap FAQ clearly states that WInPCap itself does not work on SMP (multiple-CPU) systems (version 2.3 of WinPCap even contains a check to purposely disallow it from running if more than one processor is detected), it has nonetheless been reported to me that some CTCI-W32 users have indeed been able to successfully use CTCI-W32 on their multi-proc systems using earlier versions of WinPCap (such as version 2.2, which doesn't contain the multi-processor check in it) with no apparent ill effects.
This may be because WinPCap's "Packet.dll" is not designed nor coded with multiple threads/CPUs in mind, whereas CTCI-W32 is. That is to say, the fact that CTCI-W32 is multi-processor (and multi-thread) safe, whereas WinPCap, strictly speaking, is not, since CTCI-W32 does not use "Packet.dll" at all (and instead uses its own "FishPack.dll" to communicate with the WinPCap device driver instead), you might be able to safely use CTCI-W32 on multi-CPU systems -- but I cannot say that for sure.
Thus, running CTCI-W32 on multi-processor systems is not currently recommended, and if you choose to do so anyway, you do so at your own risk.
UPDATE
Note: according to the documentation for the latest release of WinPCap
(version 3.0), WinPCap has now been fixed so that it should work just fine on SMP (multiple CPU) systems. (See
question #15 of their FAQ).
However, in order to utilize the new SMP support in WinPCap version 3.0 you will also need the latest version of CTCI-W32 as well: FishPack v1.3.0 (or greater) and TunTap32 v2.0.3 (or greater).
Short answer is: because that's the way I chose to code it.
The slightly longer answer is: the manner in which I'm retrieving certain information from the Windows system is via certain API calls which are unsupported on WinNT systems. (I forget which they are off the top of my head).
"Gee Fish, why did you even use of those API calls if you knew they weren't supported on WinNT systems? Why didn't you use a technique that you knew would work on all Windows platforms?"
Good question. I don't know. The honest truth is, I simply didn't realize SOON enough that some of the API calls I was using (i.e. the technique I was using) weren't supported on WinNT. I only discovered it after I had already more or less had it completely coded, and at that late point, was simply too tired and exasperated to have to throw everything out and start over from scratch. Instead, I simply decided that, for now, I just wouldn't support WinNT. <shrug> Sorry.
Please note that I hope to EVENTUALLY write my own device driver to replace our current use of WinPCap's because, quite frankly, I'm not all that happy nor impressed with WinPCap's driver.
But . . . it seems that lately I'm spending all my available time making changes to CTCI-W32 to compensate for WinPCap's idiosyncrasies and answering peoples e-mail asking for help instead of spending it working on that new device driver. Hopefully this will eventually change.
Please use the TT32INFO and/or TT32TEST utilities to troubleshoot your problem.
That is to say, run TT32INFO and/or TT32TEST and lookup whatever error message(s) they produce in this FAQ. For information on how to run tt32info and/or tt32test, please refer to the utility's corresponding 'readme' document.
If you still cannot determine what the problem might be, check to make sure your network card supports promiscuous mode. Some people have discovered that their particular card doesn't support promiscuous mode, and promiscuous mode is required in order for WinPCap/CTCI-W32 to work. Check your tt32test utility output to see if maybe it's complaining that your LAN card could not be put into promiscuous mode. If so, switch to a different card which does support promiscuous mode.
Another reason why CTCI-W32 might not be working for you is because you are trying to use it with an unsupported version of WinPCap. The latest version of WinPCap is not always supported by CTCI-W32.[*]
[*] We do, after all, need a little bit of time to make whatever changes might be needed in order to support new versions of WinPCap, so just because a new version of WinPCap becomes available, that doesn't necessarily mean CTCI-W32 will support it. It should support it under normal circumstances, but if Politecnico di Torino makes some radical changes to their product that CTCI-W32 needs to know about in order to work properly with it, then it won't. Then you'll just have to wait for us to make whatever changes to CTCI-W32 might need to be made. Also, we might not always be aware that a new version of WinPCap has been released either. We don't keep that close of an eye on their product, so if you happen to notice that they've come out with a new version of WinPCap that doesn't work with the current version of CTCI-W32, please let us know about it so we can schedule whatever changes might need to be made in order to support it. Thanks.
Finally, when all else fails, be sure to read the new "Problem Reporting" web page before asking for help. It's important that your Problem Report include the necessary information in order for us to help you figure out what's going on.
Several people have reported that they've had problems getting CTCI-W32 to work at all when trying to FTP from the Windows host that Herc is running on to the guest o/s running under Herc. They report that they can FTP to/from their guest o/s just fine from other workstations on their network, but not from the workstation that Herc is running on.
Thanks to both Mark Perry and Jeff "Bomber" Broido however, we're now fairly certain why this happens with some people.
Mark discovered that some network cards support a feature called "checksum offloading" that apparently, if enabled, causes CTCI-W32 to fail. When you disable the checksum offloading feature, your problem goes away.
Version 3.1 Update: Checksum Offloading should no longer be an issue beginning with version 3.1 of CTCI-W32. You should now be able to enable any/all Transmit/Receive Checksum Offloading capabilities your adapter may support starting with version 3.1 and later of CTCI-W32.
Apparently, with the way Windows's TCP/IP stack works in conjunction with the way WinPCap works (and the unusual way we're using it), packets get written to the actual interface twice, causing problems with CTCI-W32 whenever checksum-offloading is enabled on your network card.
The "checksum offloading" feature of the network card basically asks the card itself to calculate the checksum for the packet in question rather than have Windows do it (since having the hardware do it is much more efficient since it let Windows use its valuable CPU cycles for other things instead of wasting them on calculating a checksum). What ends up happening though is, because the network card ends up "seeing" the packet twice (due to the previously mentioned unusual way in which Windows, WinPCap and CTCI-W32 all interact with one another), the network card's checksum-offloading logic ends up (re-)calculating a brand new checksum on the duplicate packet, thus leading to the packet being given an incorrect checksum value since it was calculated on a packet that already had a checksum value calculated for it!
The first time it sees the packet of course, the checksum field is still zero (since Windows didn't bother to calculate it since it expects the network card hardware to do that) and it thus calculates a correct checksum for the packet. But the next time it "sees" the same packet, it already contains a non-zero checksum value in the packet and thus ends up calculating a completely different checksum value for the "new" packet that Windows (or WinPCap, or CTCI-W32) is writing to it. The end result is the packet ends up with an invalid checksum value from the receiving system's point-of-view and the packet ends up being discarded as "damaged in transit."
Of course, I'm only speculating on all this. I can't honestly say I know for sure (for a fact) that what I said above is actually happening (although it seems completely plausable (likely) in my opinion), but what I do know is this: 1) the packet does apparently get written twice (WinPCap returns two packets for every one packet the sender sends), and 2) disabling the "checksum offloading" feature in your network card apparently corrects the problem.
For more information, please see message 24956 posted to the main hercules-390 list (which is your primary source for all Hercules support).
... then don't forget to allow traffic to/from your Hercules "virtual" system! ;-)
In my own particular case I'm running a personal [software] firewall (Kerio) and at one point I was only allowing local traffic to/from 192.168.0.1 and 192.168.0.2 (me and my wife's computer) because they're the only two systems in our little two-workstation home network. This worked fine for us until I tried using CTCI with Hercules (running at 192.168.0.4). Suddenly CTCI wasn't working for some strange reason! Huh?! WHY NOT?!?! What the heck was going on?!
The answer of course is quite simple: I had completely forgotten about my firewall! ( Doh! )
Once I added 192.168.0.4 (Hercules) to my list of trusted IP addresses, CTCI began working just fine again.
To use CTCI without being physically connected to any network (i.e. with either the network card not being physically plugged into the network (i.e. no cable plugged into the card) or else without any network adapter card at all), simply use the built-in Microsoft Loopback Adapter.
The "Loopback Adapter" is NOT the same thing as IP address 127.0.0.1. The Microsoft Loopback Adapter is a special network device driver that presents the appearance of being a network adapter to the underlying Windows operating system. You can add the Microsoft Loopback Adapter to your system via the "Add New Hardware Wizard" Control Panel applet. Simply select "Microsoft" as the hardware vendor/manufacturer and select "loopback adapter" as the device you wish to add. Once added it looks, feels and behaves exactly like a real network adapter (you can assign IP addresses to it and bind TCP/IP to it, etc). About the only thing you CAN'T do with it is use it on a real network since it's not physically "connected" to anything since it's not a real "physical" device (i.e. there's no cable you can plug into the back of it).
However, if you ALSO have a real network card in addition to the loopback adapter, then if you enable IP Forwarding on your Windows system and add the proper 'route' commands to your routing table, you CAN use it to "connect" anyone using it (including Hercules) to the rest of your real (i.e. physical) network. This technique is espcially handy for those running Hercules on their notebook computers since they can then physically 'unplug' their notebook from their network and still use Hercules (since they've configured it to use the built-in Microsoft Loopback Adapter rather than their real adapter). Then later on whenever they physically plug their notebook back into their network, they simply issue the appropriate 'route' command and their Hercules system is then able once again 'talk' to the rest of their network. (In such a configuration they're basically using their Windows system as a 'router', having it route packets to/from one adapter (the real one) to/from their other 'pseudo' adapter (i.e. the Loopback Adapter).
For more information please see the following posts:
Please note however that the built-in Microsoft Loopback Adapter is only available on Windows NT variant systems (i.e. Win2000 and WinXP). It is unfortunately not available on Windows 9x systems (i.e. Win98/WinMe).
The following information is courtesy of Bill Johnson:
MVS TCPIP configuration using CTCI-W32
--------------------------------------
The following values belong in the TCP profile. This configuration has been
tested using OS/390 2.9 through z/OS 1.1. The example uses the addresses in
the sample above.
The first entry in the TCP profile is the DEVICE entry. This is the
parameter that defines the UCB address assigned to the interface within the
MVS environment. It is related to the LINK statement to build the TCPIP
connection between the hardware and the TCPIP stack.
DEVICE CTC1 CTC E20
LINK CTC1L CTC 0 CTC1
The second entry is the HOME entry. This is where the IP address is
assigned to the device interface within the TCPIP stack. The HOME entry
connects the IP address to the hardware through the LINK defined with the
DEVICE.
HOME
192.168.0.4 CTC1L
The GATEWAY describes how the IP stack gets to the rest of the network. It
defines the physical first hop from the local interface out to the entire
network. In our example, we are defining a gateway to one physical IP
address, 192.168.0.2. 1492 is the data packet size.
GATEWAY
192.168.0.2 = CTC1L 1492 HOST
The DEFAULTNET statement instructs what path the IP stack should take to
look for address it doesn't know about. IP assumes the next hop will be
able to resolve the IP address the stack is trying to connect to.
DEFAULTNET 192.168.0.2 = CTC1L 1492 0
The final statement needed in the profile is the command to instruct TCPIP
to start the device.
START CTC1
Building the static route from the PC to the emulated environment
-----------------------------------------------------------------
In order to connect from the PC to the Hercules guest, you will need to
define a route to the TCPIP environment on the PC. This is especially
important if you are using the Microsoft Loopback Adaptor to allow
connectivity in a PC without an Ethernet adapter installed.
Using a Command Prompt window, you need to issue the command below to create
a static route between the TCPIP stack in the PC to the TCPIP interface in
the MVS environment. The ROUTE command supports making a persistent link
under Win2000 and WinXP. The format of the command will try to make the
entry persistent. If the command fails (persistent isn't supported under
Win98 SE), remove the -p after ROUTE. You will need to repeat this command
every re-boot of the PC.
ROUTE -p ADD 192.168.0.4 MASK 255.255.255.255 192.168.0.2
---
Bill Johnson
<email suppressed>
-----Original Message-----
From: Fish [email suppressed]
Sent: Thursday, February 27, 2003 3:52 AM
To: <email suppressed>
Subject: RE: CTCI-W32
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> Hey Fish,
Hey. :)
> Just a quick note to thank you for the help. I was able to get
> the loopback adaptor to work perfectly for my friend.
Great! Glad to hear it. Another satisfied customer. :)
> Would you like a sample MVS TCPIP profile for the CTCI-W32? Part
> of the problem is I am not a TCPIP config person and had to hack
> my way through the config options to get the pieces to talk.
Sure! Thanks. Would be a good addition for the FAQ I would think.
> Thanks again....
You're very welcome Bill. :)
- --
"Fish" (David B. Trout)
<email suppressed>
-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.4
iQA/AwUBPl3RuUj11/TE7j4qEQKNDQCg5hNj09mlukpV13sHoXDd1DhK9bcAnilT
5J5Up9cfqgZ/ZVp6K3YkVy0S
=5r5A
-----END PGP SIGNATURE-----
The Windows hibernate feature saves everything in memory to disk, turns off your monitor and hard drive, and then turns off your computer. When you later restart your computer, your desktop is restored exactly as it was when you hibernated it.
Due to the way WinPCap is written however, getting Windows to hibernate properly when using CTCI with Hercules has been somehow problematic. The good news however is that it CAN be done. Here's how I was told to do it:
Ok. You *can* hibernate and resume Hercules w/CTCI-W32 on WinXP! Here's
how I do it when running OS/390 R10:
1. Bring down TCPIP.
On the OS/390 console, enter "P TCPIP".
2. Vary the 3088 devices offline.
On the OS/390 console, enter "v E20-E21,offline" (or whatever your 3088
cuu's are).
3. Detach the 3088 devices.
On the Hercules console, enter "detach E20" and "detach E21".
Hibernate or Stand-by your WinXP session.
To resume:
1. Attach the 3088 devices.
On the Hercules console, enter
"attach E20 3088 CTCI-W32 192.168.2.1 192.168.1.1" and
"attach E21 3088 CTCI-W32 192.168.2.1 192.168.1.1" (or whatever your 3088
cuu's and ip addresses should be).
2. Vary the 3088 devices online.
On the OS/390 console, enter "v E20-E21,online" (or whatever your 3088
cuu's are).
3. Bring up TCPIP.
On the OS/390 console, enter "S TCPIP".
Verify all works from TSO. At a READY prompt enter "ping 192.168.1.1".
I suppose it should work with Linux/390 too.... I'm not sure how to do the
bouncing and varying there though.
It would be nice if that sequence of steps could be automated in something
like a hercules.rc type file. Everything *could* be issued from the
Herc(Gui) console. Of course, it will all be auto-magic when you write the
new WinPCap replacement, right?! ;)
BTW, thanks for helping to get the current CVS working for Cygwin
folks. That had frustrated me for a couple of weeks now.
Regards,
Note: according to the documentation for the latest release of WinPCap (version 3.0), WinPCap has now supposedly been fixed so that it now continues functioning properly even after hibernation (although they spell it "hybernation").
However, in order to use WinPCap version 3.0, you will need to have the latest version of CTCI-W32 installed as well: FishPack v1.3.0 (or greater) and TunTap32 v2.0.3 (or greater).
See Hercules-390 list message 26592.
This issue has bitten so very many people that I thought I'd give it its own FAQ entry.
Please see question #14 for more information.
Version 3.1 Update: Checksum Offloading should no longer be an issue beginning with version 3.1 of CTCI-W32. You should now be able to enable any/all Transmit/Receive Checksum Offloading capabilities your adapter may support starting with version 3.1 and later of CTCI-W32.
(Note: If you're using a wireless network adapter, please also see
the very next FAQ entry too)
This is an update of the original Networking info that appeared on
the list about a week ago. This completely replaces the original.
Included a solution for the PCMCIA Wlan cards. See step 10.
Additional information on some steps, spelling and working corrections
and a few new examples and more specific error message correlations.
Good luck with your networking implementation.
Thanks Pete.
Hercules TCPIP Network info NEW Version 08/25/05
-------------------------------------------------------------
This info pertains to WinXP Pro SP2 and Win2000 Pro SP4.
I have no other Windows systems to work with and have not
explored the others.
I assumed that you have at least read the normal install
and configuration facilities for Hercules and TCPIP support.
Where Loopback is discussed one could substitute a real Ethernet
card for a real implementation without Loopback.
I realize that many have had issues getting TCPIP to work
hopefully this will help.
Here are the problems I have run into and the resolutions
I found and implemented.
This may be posted, shared etc as you see fit.
---------------------------------------------------------------
0. Turn on IP Routing in the Windows Registry, see existing doc.
1. Installed Hercules 3.03 with MicroSoft DLL (MSVC) support
(no CYGWIN) although it probably does not matter which
Hercules version/support you use. (reasonably current)
2. Install WinPcap 3.0, if 2.3 is installed, uninstall
and REBOOT before installing 3.0. 3.0 automatically
creates the registry entries at start up, so the
WINPCAP developer pack is not needed.
3. Install latest network products FishPack and TunTap32
and HercGUI. If is helpful to be able to see the device
status in the GUI and the messages. During debugging
I used the GUI, after getting it working use native or
GUI as both work.
4. Install Windows LoopBack feature if not installed,
see the Web for instructions.
The supplied LOOP.SYS Loopback adapter on W2K dated 1999
does not work...........
It initializes ok and Hercules starts fine, just will
not forward TCPIP packets to Hercules.
If you try for an update of the W2K Loopback adapter,
Microsoft says there is not one and no reported
problems.............bull.
Get the one for XP dated 2001 and replace in
c:\winnt\systems32\driver\loop.sys.
5. Make sure that the loopback adapter under configure,
advanced, network address is set properly.
Then set the entry under TCPIP properties, network address,
mask and gateway.
If a real ethernet card then the first TCPIP address
field does not exist, just set the second one.
Also for a real ethernet card check that
"checksum offloading" is turned off under configure,
advanced.Version 3.1 Update: Checksum Offloading should no longer be an issue beginning with version 3.1 of CTCI-W32. You should now be able to enable any/all Transmit/Receive Checksum Offloading capabilities your adapter may support starting with version 3.1 and later of CTCI-W32.
6. Check your Hercules config file for more than one space
line between comments or entries and for garbage data,
tabs etc. correct before proceeding.
Example: of one that works
#Network Adapter
00A0 CTCI 192.168.001.201 192.168.001.200
00A1 CTCI 192.168.001.201 192.168.001.200
7. Start from a fresh rebooted Windows with:
Loopback enabled.
8. Exit/close Sygate Firewall if you are using it as it
will cause I/O errors and unit checks on the OPsys
output CTCI (00A1 in the example) after 12/13
TCPIP messages.
9. The Windows Firewall works fine for Telnet, if you
have it set to pass all TCPIP for Hercules.EXE
else turn it off. Some of the other Protocols/Ports
seem to have problems with Windows Firewall so if
Telnet works and another protocol does not turn off
Windows firewall.
10. If PCMCIA Network adapter continue here.
If Internal wireless adapter go to step 11.
PCMCIA WLAN enabled if Wlan does not interfere as certain
adapters do.
The presence of following adapters causes TUNTAP32 to
not properly enable the second CTCI (write port) when using
all TCPIP addresses in the CTCI defines.
Belkin PCMCIA B&G
Linksys PCMCIA B&G
IBM PCMCIA A,B,G Wireless LAN
Note: A good clue that the Wlan is interfering is that
on a failure TunTap32 reports the hardware address
of the PCMCIA Wlan instead of the Loopback adapter.
Circumvention - remove the interfering WLAN PCMCIA card.
OR use the MAC address of the Loopback adapter in the CTCI
define, see example:
00A0 3088 CTCI -n 02-00-4c-4f-4f-50 192.168.001.201 0.0.0.0
00A1 3088 CTCI -n 02-00-4c-4f-4f-50 192.168.001.201 0.0.0.0
The address above was consistently used by two different systems
one XP and one W2K, so your loopback Mac address may be the same.
The MAC address of the Loopback adapter is set by program LOOP.SYS
and is hardcoded in the program.
NOTE: 4C-4F-4F-50 = L-O-O-P
To find the address activate the loopback adapter and look in
System Information/Components/Network/Adapter/Microsoft Loopback.
So if using 2 loopback adapters in 2 different machines they will
have the same Mac address. That will work as long as they are in
separate subnets, separated by a gateway.
Example: System 1
Wlan card TCPIP address 192.168.0.100
LoopBack adapter 1 TCPIP address 192.168.1.200
OpSys TCPIP Stack TCPIP address 192.168.1.201
System 2
Wlan card TCPIP address 192.168.0.101
LoopBack adapter 2 TCPIP address 192.168.2.200
OpSys TCPIP Stack TCPIP address 192.168.2.201
NOTE: The PCMCIA WLAN interference can also stop a real Ethernet
from working just like it does a Loopback adapter.
11. The internal Thinkpad G41 Wlan PCI B&G card does not
interfere when using all TCPIP addresses in the CTCI define.
Make sure it is enabled and proceed.
12. On startup make sure that both CTCI devices are correctly
attached to Hercules and that Tun0 started correctly,
if not find and fix the problem, reboot and start over.
Cause it is not going to work. This is usually caused
by one of the issues already discussed.
The device configuration must show 2 CTCI devices in
the GUI, if not initialization failed, see the Herc
console messages for more info about why.
The above PCMCIA issues can result in the TUNTAP32
infamous error "no error" message.
13. Windows Networking is very sensitive to errors, so if you
get "hardware error" or Tun0 not initialized or "no Error"
or some such message correct the problem and reboot before
testing again.
Example: if you left Sygate up and TCPIP failed after 12 messages
with "hardware error" or a hang no response, turning Sygate
off will not make it work, a reboot is necessary.
Example: if the PCMCIA adapter was enabled and CTCI was using
TCPIP addresses and Herc at startup second CTCI gave a "no error"
condition correct and reboot before testing again.
14. If the loopback and the WLan are on the same sub network
Windows networking has problems figuring out which
one is the gateway and therefore no packets get sent to
anyone (Hercules or Windows).
There may be a fancy way to code route statements to
eliminate this but it is easier to just have them on
separate subnets. If you are going to connect multiple
WLans using the Loopback adapter they MUST be on
separate Lans, because of the duplicate Mac address.
Example Wlan card TCPIP address 192.168.0.100
LoopBack adapter TCPIP address 192.168.1.200
OpSys TCPIP Stack TCPIP address 192.168.1.201
Note: Now if you want to remote access Hercules
thru the Wlan, at the remote system add a route.
ROUTE -p ADD 192.168.1.0 mask 255.255.255.0 192.168.0.100
Make it temp or or perm (-p) as you see fit.
Note: If using a real ethernet card the same address
issues also apply, including the Route.
Example Wlan card TCPIP address 192.168.0.100
Ethernet adapter TCPIP address 192.168.1.200
OpSys TCPIP Stack TCPIP address 192.168.1.201
...then you might want to double check your network adapters binding order.
This is only because, at present, it seems that most people with wireless network adapters also seem to have a normal non-wireless network adapter as well.
That is to say, if you have more than one network adapter, then you might need to change the order of your adapter bindings in order for WinPcap to use the correct (desired) adapter.
If such is the case, then the following Hercules-390 group posts explains the issue and how to correct it:
TunTap32.dll: device not functioning (post 43714)
no response on ping from windows to herc (post 43894)
The WinPcap device driver (npf.sys) is not written to support 64-bit Windows and thus cannot be loaded and started by Windows. There is unfortunately nothing you can do until WinPcap comes out with a new 64-bit-Windows compatible version of their device driver. Sorry! :(
WinPCap version 4.0 Update: WinPCap's newest device driver (version 4.0 as of the time of this writing) now supports 64-bit Windows systems (Windows XP Professional x64 Edition, etc). You will need CTCI-W32 version 3.2.1 or later along with it in order do Hercules networking on 64-bit Windows systems.
Yes! Beginning with version 3.2.1 of CTCI-W32, 64-bit Windows systems are now supported as long as you have a version of WinPCap installed that also supports 64-bit Windows operating systems. (See the "WinPCap 4.0 Update" box in the previous question)