nmap network tool usage notes

 nmap notes

nmap -v -sn 192.168.xx.0/24

nmap -sn 192.168.xx.0/24

--30--

broken atomic modeset userspace detected, disabling atomic messages on raspberry pi

Occurs when running headless and no screen resolution set (never had a display attached). 

in  dmesg command log (from kernel)

 pi@pi1: $ sudo raspi-config 

  https://forums.raspberrypi.com/viewtopic.php?t=285823 

 --30--

Raspberry pi Ubuntu headless setup

 
Setting up Pi for initial run on Ubuntu.

https://linuxhint.com/raspberry_pi_headless_mode_ubuntu/

Same points as Raspbian

create 'ssh' in the boot partition.

copy and edit wpa_supplicant.conf into the boot partition.

in the rootfs /etc/hosts and /etc/hostname set the hostname

unmount and ready to go.

--30--

ESXI 6.5 on Intel Nuc (another install)

 

https://teebeedee.org/2016/11/install-vmware-esxi-6-5-intel-nuc-part-1/

https://teebeedee.org/2016/11/install-vmware-esxi-6-5-intel-nuc-part-2/

configuration:

https://teebeedee.org/2016/11/anatomy-home-lab/

Intel NUC Kit D54250WYKH – A 4th generation NUC with an i5 processor

Kingston 8GB Module DDR3L 1600MHz – Two per, maxing the NUC out at 16GB

Intel SSD 530 Series 240GB mSATA Drive – Flash storage

Western Digital WD10JPVX Blue 1TB SATA Drive – Magnetic storage

SanDisk 16GB Ultra Fit USB 3.0 Flash Drive – ESXi boot drive

Install VMware ESXi 6.5 on Intel NUC (Part 1/2)

With VMware vSphere 6.5 released recently, I decided to rebuild my Intel NUC based homelab. My preferred method is to create a bootable USB drive with the ESXi install media on it. Then install from the ESXi USB to the dedicated NUC’s boot USB. This method avoids non-unique ESXi installs, which is a common issue with the VMware Workstation pre-install method.

Prerequisites

In order to create our Intel NUC specific ESXi install media, we need to gather the necessary files. Make sure to grab the newest versions of the following:

• vSphere ESXi 6.5 Offline Bundle
  • This is a collection of all the components and packages that make up ESXi. You need the Offline Bundle, not the ISO, for this exercise.
• SATA AHCI driver
  • This driver is for the Intel NUC SATA controller. Even if your NUC doesn’t have a SATA disk or even the controller, it doesn’t hurt to add this driver.
• USB 3.0 Ethernet driver from William Lam
  • Add more NICs to your NUC via USB 3.0. Like the storage driver, if you don’t have a USB 3 ethernet adapter, it doesn’t hurt to add this driver.
• ESXi-Customizer-PS PowerShell script from Andreas Peets
  • This script will do all the heavy lifting, combining the offline bundle and driver VIBs into an ISO for us.

Create ISO

First, let’s create a project directory for our files. Let’s call it C:\esxi-nuc .

Copy the ESXi 6.5 offline bundle ZIP file (ex. VMware-ESXi-6.5.0-4564106-depot.zip ) and the ESXi-Customizer-PS script (ex. ESXi-Customizer-PS-v2.4.ps1 ) to this directory.

Create a sub-directory under our project directory to hold our VIBs. Let’s get creative and call it C:\esxi-nuc\vibs .

Copy the SATA AHCI driver VIB (ex. sata-xahci-1.38-1.x86_64.vib ) and the USB 3.0 Ethernet driver VIB (ex. vghetto-ax88179-esxi65.vib ) to this sub-directory.

If you’ve copied all the files to their respective folders properly, it should look something like this:

C:\esxi-nuc

C:\esxi-nuc\ESXi-Customizer-PS-v2.4.ps1

C:\esxi-nuc\VMware-ESXi-6.5.0-456106-depot.zip

C:\esxi-nuc\vibs

C:\esxi-nuc\vibs\sata-xahci-1.38-1.x86_64.vib

C:\esxi-nuc\vibs\vghetto-ax88179-esxi65.vib

Now we have to run the ESXi-Customizer-PS script to pull everything together and generate an ISO file. So fire up PowerShell, navigate to our project directory which is “C:\esxi-nuc” in our example, and run the following command:

.\ESXi-Customizer-PS-v2.4.ps1 -izip VMware-ESXi-6.5.0-4564106-depot.zip -pkgDir vibs -nsc

Make sure to use the version numbers that match your downloaded files. Also, don’t forget the “-nsc” flag, as that will let us ignore the unsigned driver VIBs and continue.

If everything went as planned, you should now have a new ISO file in the project directory that is an ESXi 6.5 and VIBs combination.

Next Steps

Now that we have our customized ISO, we need to turn it into a bootable USB and then install it on our NUCs. We’ll do just that in part two.

Install VMware ESXi 6.5 on Intel NUC (Part 2/2)

In the first post, we created an ISO image of VMware ESXi 6.5 to install on our Intel NUC. Now we turn that ISO into a bootable USB and do the install.

Make Bootable USB

We’re going to use an application called Rufus to create our bootable USB, so download and install it. Now start Rufus.

First, make sure that your to select your target USB flash drive in the Device drop down menu. Then, change the “Create a bootable disk using” drop down menu to “ISO Image” (call-out 1). Then click the image selection button (call-out 2) to find and open our customized ISO (ex. ESXi-6.5.0-4564106-standard-customized.iso ).

You should now see an updated new volume label which matches the ISO image you chose. Click the Start button to begin building the bootable USB (call-out 3).

A warning may pop up about an older version of the ‘menu.c32’ file. This file is part of Syslinux and helps make the ISO/USB bootable. If we don’t replace the older version of the file then our USB won’t boot properly, so click Yes (call-out 4).

Rufus will remind you, forcefully, that you’re about to wipe out all the data on the target USB drive. You backed up anything on the flash drive that you wanted to keep, right? If you’re sure you’re ready to continue, click OK (call-out 5).

The bootable USB will now be built by Rufus. Rufus basically does a bit of work to make the USB drive bootable, and then extracts the contents of the ISO file to it.

When finished, you’ll see that the device name has changed at the top, the green progress bar is full, and the status reads “READY”. Click the Close button to exit out of Rufus (call-out 6).

Now you can eject your USB drive as it’s ready for use as a vSphere ESXi installation drive.

Install ESXi on NUC

If you’ve installed ESXi before, this should be really straight forward, and I won’t bother with all the details. Essentially you need to make sure to connect your Intel NUC to a monitor and keyboard, and that the drive that you want to install ESXi into is either installed or plugged in. Remember that in my home lab example, that I’ll be installing ESXi on a USB drive. This means that both the USB drive that we’ve built to install ESXi from and the USB drive that we’ll be installing ESXi to have to be plugged into the NUC.

As a reminder, F10 will allow you to select your boot device on the Intel NUC.

In order to get the USB Ethernet adapter to work, we need to enable the ESXi Shell, login, and run the following command:

esxcli system module set -m=vmkusb -e=FALSE

Then log out of the shell, disable it again and reboot the host.

Bigger and Better Things

Now that we have successfully installed ESXi 6.5 onto our NUC, we can begin to do some fun and interesting things. Like, say, install ESXi on some more NUCs and then create a vSAN cluster. Stay tuned.

--30--

vmware esxi problems some solutions redirect to serial for boot, or merge modules. Intel NUC as server

https://communities.vmware.com/t5/ESXi-Discussions/install-ESXi-stop-on-quot-Relocating-modules-and-starting-up-the/td-p/480552

System:

**********

install ESXi, stop on "Relocating modules and starting up the kernel" 

My computer is Intel NUC5PPYH, the processor is a 14nm Pentium n3700.

Hardware: Intel® NUC Kit NUC5PPYH Specifications

**********

serial port info

I came across the same problem on a bay-trail based system.  I had to do the following:

1) set BIOS "max cpuid value limit" to disable

2) Redirect the Direct Console to a Serial Port by Setting the Boot Options Manually

     - At startup press Shift+O and append the following boot options

     "gdbPort=none logPort=none tty2Port=com1";

3) connect a null modem cable from the esxi host pc to another pc.  This will allow you to finish the install and see further messages if there are more issues.

4) after installation completes, boot up the host and repeat steps 3 and 4 (if the screen continues to show the "relocating modules" mesg)

- the relocating modules message has something with ESXI not liking the video card.  Anyways, this just means you won't be able to use the local display to manage ESXI but you can still use vshpere client to manage the system remotely.

5) setup your management ip and launch the vsphere client to manage your new esxi host.

Hope this helps.  Good luck!

************************

esxi 6.5

I successfully installed VMware ESXi 6.5 on my NUC5PPYH (Intel Pentium N3700, 8GB RAM, 256GB SSD) using these steps on Windows 10:

• Configured a static DHCP lease on my router for the MAC address of the NUC
• Updated BIOS to latest version 0059, loading BIOS defaults
• Downloaded and installed VMware-PowerCLI-6.5.0-4624819.exe
• Downloaded ESXi-Customizer-PS-v2.5.ps1
• Downloaded and installed rufus-2.12.exe
• Downloaded ESXi drivers for onboard network and SATA : net55-r8168-8.039.01-napi.x86_64.vib, sata-xahci-1.39-1.x86_64.vib
• Created an empty C:\Temp directory and put the .vib files in there
• Ran the customizer PS script like so: .\ESXi-Customizer-PS-v2.5.ps1 -pkgDir C:\Temp
• Wrote the created ESXi-6.5.0-20170104001-standard-customized.iso on a USB stick using Rufus
• Wrote a kickstart file (see below) and copied it as ks.cfg on the USB stick
• Ejected the USB stick from Windows, put it in the NUC and booted it
• Pressed Shift + O when the ESXi installer started booting up
• Changed the command line to: > runweasel ks=usb:/ks.cfg
• Waited for about 15 minutes for the installer to finish

Since the system is lacking support for the Braswell graphic chip you wont see anything on the screen happening besides that last line "Relocating modules and starting up the kernel...".

Just ignore it. :smileycool:

Please note that the ks.cfg script will erase all contents of the drive inside the NUC!

----<snip>----

# ks.cfg: scripted installation file for ESXi 6.5 installation

# Accept the VMware End User License Agreement

vmaccepteula

# Set the root password for the DCUI and Tech Support Mode

rootpw mypassword

# Install on the first local disk available on machine

clearpart --firstdisk --overwritevmfs

install --firstdisk=local --overwritevmfs

# Set the network to DHCP on the first network adapter

network --bootproto=dhcp

# reboots the host after the scripted installation is completed

reboot

# enable SSH and the ESXi shell

%firstboot --interpreter=busybox

vim-cmd hostsvc/enable_ssh

vim-cmd hostsvc/start_ssh

vim-cmd hostsvc/enable_esx_shell

vim-cmd hostsvc/start_esx_shell

----<snap>----

**************************************

This description Worked for me on my Intel NUC5PPYH

But I made a minor change in the ks.cfg:

# Set the network to DHCP on the first network adapter

network --bootproto=dhcp --device=vmnic0

**************************************

Another formula

**************************************

I had to try several times until I got it working:

THIS IS A GUIDE TO INSTALL ESXI FROM - AND INSTALL ONTO THE SAME -  USB-STICK

1.)  BIOS: reset to default ! and DISABLE UEFI boot - leave only legacy usb (if you leave uefi the shift+o commands will be ignored)

2.)  Remove ANY HDD/SSD/WHATEVER from the NUC - you will add it again later

3.)  Make the aforementioned boot stick from rhoenies post.

4.)  Make a ks.cfg file on the stick with the following content

----<snip>----

vmaccepteula

rootpw whatever

network --bootproto=dhcp

clearpart --firstdisk --overwritevmfs

install --firstdisk --overwritevmfs --novmfsondisk

reboot

----<snap>----

5.) Plug the stick into your NUC and press Shift+O at the ESXI bootloader

6.) Type:     >runweasel ks=usb:/ks.cfg ignoreHeadless=TRUE            and press Enter

7.) ESXi will now be installed (takes about 15 Minutes) - then the machine will reboot

8.) After reboot your NUC will complain: "no disk found" - reboot and enter BIOS

9.) Enable UEFI boot and check the box at "Boot usb disk first". Check "suppress alert messages" too.

11.) Save bios and shutdown -> Now you can reinstall your HDD/SSD

12.) Remove the stick from your NUC, plug it into you computer and make following change inside BOOT.CFG: "kernelopt= installerDiskDumpSlotSize=2560 no-auto-partition ignoreHeadless=TRUE"

13.) Now plug your stick back in and enjoy your fully working ESXi host by just acccessing it over https://IP-ADDRESS/ui

14.) After trying every bios option possible I gave up: you can't run a NUC5PPYH without a monitor or a vga dummy connected. So if you plan on running your NUC complete headless I recommend ordering a 5$ hdmi dummy.

If you encounter Problems it is usually related to your USB-Stick. You can try this:

>runweasel ks=usb:/ks.cfg ignoreHeadless=TRUE preferVmklinux=TRUE

But if it doesn't help try a different USB-Stick. I recommend not to use a USB 3.0 capable one.

******************************

--30--

zos on hercules tcpip thread (long) archived from yahoo groups

 

 

 

https://hercules-390.yahoogroups.narkive.com/zsirrr4N/z-os-v1r10-networking-in-hercules 

 

 This thread from 2016 on is discussing tcpip on zos-v1-r10 captured by a yahoo group archiver

 

The archive didn't redact emails, nor did I, sorry.

z/OS V1R10 Networking in Hercules

(too old to reply)

hgservers@yahoo.com [hercules-390]

5 years ago

Permalink

I'm trying to get my Hercules with z/OS to talk to my network. I'm running the emulator on Windows. Now, as far as I can see/tell, I took the right steps... but I can only ping the host machine from within z/OS, and z/OS can only be pinged from the host machine, using their respective IPs (10.0.0.6 and 10.0.0.116).


In my hercules.cnf file, I have this:
0E20-0E21 CTCI -n [MAC Address of my card] 192.168.1.116 192.168.1.6


In my TCPIP Profile, I've got this:
DEVICE CTCA1 CTC E20
LINK CTC1 CTC 1 CTCA1


HOME
192.168.1.116 CTC1


GATWAY
192.168.1.1 = CTC1 1492 HOST


DEFAULTNET 192.168.1.6 CTC1 1492 0


The route commands that I ran on my host were:
ROUTE -p ADD 192.168.1.0 MASK 255.255.255.0 192.168.1.6

ROUTE -p ADD 192.168.1.116 MASK 255.255.255.255 192.168.1.6


And like I said, pinging between z/OS and the host machine works no problem at all.


I feel like I'm missing something obvious, but don't know what it is. And TUN/TAP loaded successfully when Hercules started, running as an administrator.

Raphaël Jacquot sxpert@sxpert.org [hercules-390]

5 years ago

Permalink

Is your machine configured for forwarding IPv4 in sysctl ?

...

hgservers@yahoo.com [hercules-390]

5 years ago

Permalink

Running Hercules within Windows. I did enable routing within the registry, and made sure the Routing and Remote Access service was enabled.

Brian_Westerman@SyzygyInc.com [hercules-390]

5 years ago

Permalink

I'm not sure why you are routing 192.168.1.0 to 192.168.1.6, it should be routed to your gateway (router).

Make sure you undo your bad changes

What is the second route command supposed to be doing for you? You do need one for 192.168.1.116, but not pointing to z/OS (most of the time it won't even exist, unless you run z/OS 24x7), you just need the default one that windows built for you that should point back to itself (or your router).

You will need to delete those routes and set it correctly.
Route Print <to see what you have currently (-p will make the changes perm) get rid of the ones you added in error previously.

ROUTE -p delete 192.168.1.0
ROUTE -p delete 192.168.1.116

ROUTE -p add 192.168.1.0 MASK 255.255.255.0 192.168.1.1 <--if this is your actual router address.

ROUTE PRINT it should make sense when you look at it now.

in your TCPIP profile, HOME should be your z/OS TCPIP instance (i.e. 192.168.1.6, not your windows PC 192.168.1.116)

HOME 192.168.1.6 CTC1

You can use GATEWAY and DEFAULTNET, but you really should be using BEGIN ROUTES. Also, your default is your ROUTER 192.168.1.1, not your local z/OS instance 192.168.1.6, although maybe that's what you were trying to affect with the odd ROUTES you mentioned.:

BEGINROUTES
ROUTE 192.168.0.0 255.255.0.0 = CTC1 MTU 1492
ROUTE DEFAULT 192.168.1.1 CTC1 MTU 1492
ENDROUTES

Make sure your OMPROUTE and RESOLVER tasks are set up correctly as well.

When you are done, you should be able to type "TSO HOMETEST" (sans quotes) on your TSO session and it should come back with no errors.

Brian

'Dan Skomsky' poodles511@sbcglobal.net [hercules-390]

5 years ago

Permalink

What exactly is your Windows host platform?

Are you running CTCI-WIN?

Is your Windows host connected to your work or home network and not public network?

Have you checked your firewall settings?

Have you run TT32TEST/TT64TEST?

How many NICs are configured and running on your Windows host?

Are your running Hercules & z/OS in a Virtual Machine under Virtual PC or Hyper-V?

Have you double checked and verified your network gateway’s IP address?





From: hercules-***@yahoogroups.com [mailto:hercules-***@yahoogroups.com]
Sent: Saturday, June 18, 2016 11:47 PM
To: hercules-***@yahoogroups.com
Subject: [hercules-390] z/OS V1R10 Networking in Hercules





I'm trying to get my Hercules with z/OS to talk to my network. I'm running the emulator on Windows. Now, as far as I can see/tell, I took the right steps... but I can only ping the host machine from within z/OS, and z/OS can only be pinged from the host machine, using their respective IPs (10.0.0.6 and 10.0.0.116).



In my hercules.cnf file, I have this:

0E20-0E21 CTCI -n [MAC Address of my card] 192.168.1.116 192.168.1.6



In my TCPIP Profile, I've got this:

DEVICE CTCA1 CTC E20

LINK CTC1 CTC 1 CTCA1



HOME

192.168.1.116 CTC1



GATWAY

192.168.1.1 = CTC1 1492 HOST



DEFAULTNET 192.168.1.6 CTC1 1492 0



The route commands that I ran on my host were:

ROUTE -p ADD 192.168.1.0 MASK 255.255.255.0 192.168.1.6

ROUTE -p ADD 192.168.1.116 MASK 255.255.255.255 192.168.1.6



And like I said, pinging between z/OS and the host machine works no problem at all.



I feel like I'm missing something obvious, but don't know what it is. And TUN/TAP loaded successfully when Hercules started, running as an administrator.

somitcw@yahoo.com [hercules-390]

5 years ago

Permalink

Post by ***@yahoo.com [hercules-390]
I'm trying to get my Hercules with z/OS to talk to my network.
I'm running the emulator on Windows. Now, as far as I can see/tell,
I took the right steps... but I can only ping the host machine from
within z/OS, and z/OS can only be pinged from the host machine,
using their respective IPs (10.0.0.6 and 10.0.0.116).
0E20-0E21 CTCI -n [MAC Address of my card] 192.168.1.116 192.168.1.6

- - - remainder snipped - - -

Is zOS the unroutable 10.0.0.6 or is it the unroutable 192.168.1.6 ?

How many routers are between zOS and the network that zOS is
trying to reach?

What is the IP address of a device on the network that you are
trying to reach?

Posting both ping attempts, tracert/tracerte/traceroute from both
sides, or all three route tables might help?

'\'Fish\' (David B. Trout)' david.b.trout@gmail.com [hercules-390]

5 years ago

Permalink

Post by ***@yahoo.com [hercules-390]
I'm trying to get my Hercules with z/OS to talk to
my network. I'm running the emulator on Windows.

Which Windows? Windows 7? Windows 10?

Post by ***@yahoo.com [hercules-390]
Now, as far as I can see/tell, I took the right steps...
but I can only ping the host machine from within z/OS,
and z/OS can only be pinged from the host machine,
using their respective IPs (10.0.0.6 and 10.0.0.116).

Hmmmm...

Post by ***@yahoo.com [hercules-390]
0E20-0E21 CTCI -n [MAC Address of my card] 192.168.1.116 192.168.1.6

z/OS Guest IP Address = 192.168.1.116
Windows Host IP Address = 192.168.1.6

Okay.

Post by ***@yahoo.com [hercules-390]
DEVICE CTCA1 CTC E20
LINK CTC1 CTC 1 CTCA1

Okay, but LCS is less problematic.

Post by ***@yahoo.com [hercules-390]
HOME
192.168.1.116 CTC1

Okay.

Post by ***@yahoo.com [hercules-390]
GATWAY
192.168.1.1 = CTC1 1492 HOST

If 192.168.1.1 is the same default gateway as what your Windows host is using, then okay.

Post by ***@yahoo.com [hercules-390]
DEFAULTNET 192.168.1.6 CTC1 1492 0

Wrong.

If the subnet mask that your Windows host is using is, for example, 255.255.255.0, then your defaultNET should be 192.168.1.0.

If the subnet mask that your Windows host is using was, for example, 255.255.0.0, then your defaultNET would be 192.168.0.0.

The defaultNET value is NOT an IP address, it is a NETWORK. They're not the same thing.

Post by ***@yahoo.com [hercules-390]
ROUTE -p ADD 192.168.1.0 MASK 255.255.255.0 192.168.1.6
ROUTE -p ADD 192.168.1.116 MASK 255.255.255.255 192.168.1.6

Wrong. You should NOT need any custom routes whatsoever.

The ONLY time you would need custom routes would be if you insisted on having you Hercules guest be in its own separate subnet / network segment. If that is not the case however, then you should NOT EVER NEED any type of special route commands since both your Windows host *and* your Hercules guest would be in the same subnet. (If two systems are in the same subnet and using the same subnet mask then both systems see and talk to each other by default.)

The Golden Rule of configuring Hercules guests on Windows has always been to configure it exactly like you would any other computer that you would connect to your local network. That is to say, if you bought a new desktop or laptop computer and wanted to connect it your local network so that it could see and talk to your existing Windows system, how would you do that?

You would use a unique IP address WITHING THE SAME SUBNET as your existing Windows system, and the SAME SUBNET MASK as what your existing Windows system was using, and the SAME DEFAULT GATEWAY as what your existing Windows system was using. Right? Right!

So you should configure your Hercules guest in *exactly* the same way. No special routes needed.

And DISABLE "IP Routing" on your Windows host too, if the only reason you enabled it was because you thought you needed it. If you have it enabled for some other reason however, then you need to let us know that.

Post by ***@yahoo.com [hercules-390]
And like I said, pinging between z/OS and the host machine
works no problem at all.
I feel like I'm missing something obvious, but don't know
what it is.

See above.

Post by ***@yahoo.com [hercules-390]
And TUN/TAP loaded successfully when Hercules started, running
as an administrator.

What version of CTCI-WIN are you using?

Did you run a comprehensive TT64Test Ping Test? (*)

You should not bother with configuring Hercules or your z/OS gust until you are sure the networking values you intend to use actually work. That's what TT64Test is for. It confirms the configuration you INTEND to use are actually going to work. Once you know they're going to work, then and ONLY then should you then attempt configuring Hercules and your guest with those very same values.

--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com

(*) In both directions from two different systems on your local network as explained in the "Confirming Proper Installation" chapter of the CTCI-WIN Help file?

winkelmann@id.ethz.ch [hercules-390]

5 years ago

Permalink

Post by ***@yahoo.com [hercules-390]
GATWAY
192.168.1.1 = CTC1 1492 HOST

If 192.168.1.1 is the same default gateway as what your Windows host is using, then okay.

Well, Fish, basically I agree... But I don't think that darn thing will understand "GATWAY" instead of "GATEWAY" (although I never tried using GATWAY).


Cheers
Juergen

'\'Fish\' (David B. Trout)' david.b.trout@gmail.com [hercules-390]

5 years ago

Permalink

[...]

Post by ***@id.ethz.ch [hercules-390]

Post by ***@yahoo.com [hercules-390]
GATWAY
192.168.1.1 = CTC1 1492 HOST

If 192.168.1.1 is the same default gateway as what your
Windows host is using, then okay.

Well, Fish, basically I agree... But I don't think that darn
thing will understand "GATWAY" instead of "GATEWAY" (although
I never tried using GATWAY).

Good catch. I completely missed that one. :)

--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com

hgservers@yahoo.com [hercules-390]

5 years ago

Permalink

I think we might be getting closer. I did what Fish said and took out the routes from Windows, and set it up so that the configuration would match a normal computer being setup on my network. I also tried the earlier suggestion of using BEGINROUTES, but got no change. I also disabled forwarding from within the registry. And meanwhile, I also disabled the firewall completely for now.

These are the errors that I'm getting now:
READY
ping 192.168.1.116
CS V1R10: Pinging host 192.168.1.116
Ping #1 response took 0.002 seconds.
READY
ping 192.168.1.1
CS V1R10: Pinging host 192.168.1.1
Ping #1 timed out
READY
ping 192.168.1.6
CS V1R10: Pinging host 192.168.1.6
sendto(): EDC8130I Host cannot be reached. (errno2=0x74420291)
READY





CMD Prompt on the Host Machine:
C:\Windows\system32>ping 192.168.1.116


Pinging 192.168.1.116 with 32 bytes of data:
Reply from 192.168.1.1: Destination host unreachable.
Reply from 192.168.1.1: Destination host unreachable.
Reply from 192.168.1.1: Destination host unreachable.
Reply from 192.168.1.1: Destination host unreachable.


Ping statistics for 192.168.1.116:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),


C:\Windows\system32>




The testing applications come back with no errors, and detects/shows the interface that I need as well.


The 10.0.0.x and "GATWAY" are indeed typos on my end, and I'm sure as well that the stack would most likely throw a fit if I tried telling it to look for a GATWAY.


And just to clarify, there's only one router serving my network (that question was asked earlier in the thread).

Brian_Westerman@SyzygyInc.com [hercules-390]

5 years ago

Permalink

Since you can't reach your router 192.168.1.1 from inside z/OS (192.168.1.116), it makes sense that your can't ping z/OS from anywhere else.

It appears that you have not successfully connected up TCP/IP under z/OS yet.

Please paste the following into your reply:
1) Your complete PROFILE member (normally TCPIVP.TCPPARMS(PROFILE), but this is whatever member you are pointing to in your TCPIP JCL within proclib.
2) Your complete TCPDATA member (normally from the same dataset)
3) the line from your hercules config member that identifies the LCS or CTCI connection.
4) the complete output from a windows command prompt "ROUTE PRINT" command
5) the contents of your "S EZAZSSI,P=xxxxxxxx" entry (normally in SYS1.PARMLIB(COMMND00)'
6) the output from a "TSO HOMETEST" command. Don't expect it to work completely ight now, and since your unable to get to your router, it will hang for about 60 seconds before it completes. Eventually, this will be the signal that we have everything correct.

between these 6 things, something is still messed up, we might as well get to the bottom of the problem and fix it for you. Doing it this way will also leave a entry on the list that shows others how to set it up correctly. It's not hard to set up, but it does have to be right. Once complete, you should be able to not only connect to your z/OS from windows, but you will be able to send (and receive) email from z/OS under hercules and access your z/OS from anywhere your firewall allows via your internet connection.

Try not to just dump it in an unreadable jumble when you post these items. Remember, people will want to be able to see what you have wrong, which for debugging purposes is almost as important as seeing what you have right.

Brian Westerman

hgservers@yahoo.com [hercules-390]

5 years ago

Permalink

1) http://pastebin.com/MPXShzu8 http://pastebin.com/MPXShzu8 2) http://pastebin.com/Avn7xFBp http://pastebin.com/Avn7xFBp
3) I tried both of these.
# LCS
0E20-0E21 CTCI 192.168.1.116 192.168.1.6
#0E20-0E21 CTCI -n 00:21:00:EB:64:05 192.168.1.116 192.168.1.6

4) http://pastebin.com/K7M3V8h1 http://pastebin.com/K7M3V8h1
5) S EZAZSSI,P=ADCD
6) http://pastebin.com/ebGAxDRY http://pastebin.com/ebGAxDRY
Where would it be getting that IP from, though? I commented out the one that HOMETEST is showing.

'Dan Skomsky' poodles511@sbcglobal.net [hercules-390]

5 years ago

Permalink

Your HOMETEST output appears to be what was originally shipped with ADCD. Here is what I did; Using ISPF edit your IP, GAYEWAY, NETWORK, and HOSTS information into files TCPIP.HOSTS.LOCAL, TCPIP.TCPIP.DATA, and TCPIP.PROFILE.TCPIP. Just follow the examples within these files. Don’t forget to enter your name server IPs too. They are shown when you run IPCONFIG /ALL in Windows. Next logon to TSO as a power user, IBMUSER, and issue ‘TSO MAKESITE HLQ=TCPIP’. This will create/update two files TCPIP.HOSTS.ADDRINFO and TCPIP.HOSTS.SITEINFO. Now run HOMETEST again. It should now contain what you just entered including the name server(s).



From: hercules-***@yahoogroups.com [mailto:hercules-***@yahoogroups.com]
Sent: Friday, June 24, 2016 8:22 PM
To: hercules-***@yahoogroups.com
Subject: RE: [hercules-390] z/OS V1R10 Networking in Hercules





1) http://pastebin.com/MPXShzu8

2) http://pastebin.com/Avn7xFBp

3) I tried both of these.

# LCS

0E20-0E21 CTCI 192.168.1.116 192.168.1.6

#0E20-0E21 CTCI -n 00:21:00:EB:64:05 192.168.1.116 192.168.1.6

4) http://pastebin.com/K7M3V8h1

5) S EZAZSSI,P=ADCD

6) http://pastebin.com/ebGAxDRY

Where would it be getting that IP from, though? I commented out the one that HOMETEST is showing.

hgservers@yahoo.com [hercules-390]

5 years ago

Permalink

HOMETEST is showing correct now, however there's still no connectivity with/to the router.

READY
hometest
EZA0619I Running IBM MVS TCP/IP CS V1R10 TCP/IP Configuration Tester

EZA0621I The FTP configuration parameter file used will be "TCPIP.FTP.DATA".

EZA0602I TCP Host Name is: ADCD

EZA0605I Using Name Server to Resolve ADCD
EZA0611I The following IP addresses correspond to TCP Host Name: ADCD
EZA0612I 192.168.1.116

EZA0614I The following IP addresses are the HOME IP addresses defined in PROFIL
E
.TCPIP:
EZA0615I 192.168.1.116
EZA0615I 127.0.0.1

EZA0618I All IP addresses for ADCD are in the HOME list!

EZA0622I Hometest was successful - all Tests Passed!
READY


Only other changes that I made were to define 192.168.1.1 and 4.4.4.4 as nameservers.

'Dan Skomsky' poodles511@sbcglobal.net [hercules-390]

5 years ago

Permalink

What settings do you have set in TCPIP.PROFILE.TCPIP between BEGINRoutes and ENDRoutes? Is your Windows host NIC IP address on the same network as your Hercules/zOS IP?



Assuming your Hercules/zOS NIC IP is 192.168.1.116 with mask 255.255.255.0, your Windows host NIC IP should be 192.168.1.??? with mask 255.255.255.0 and you should have ROUTE 192.168.1.0 with mask 255.255.255.0 within the route list. ROUTE DEFAULT should be set to your router’s IP, ex. 192.168.1.254. In my case, the router is also my DHCP Server, and local DNS Server.



From: hercules-***@yahoogroups.com [mailto:hercules-***@yahoogroups.com]
Sent: Saturday, June 25, 2016 2:02 AM
To: hercules-***@yahoogroups.com
Subject: [hercules-390] Re: z/OS V1R10 Networking in Hercules





HOMETEST is showing correct now, however there's still no connectivity with/to the router.



READY

hometest

EZA0619I Running IBM MVS TCP/IP CS V1R10 TCP/IP Configuration Tester



EZA0621I The FTP configuration parameter file used will be "TCPIP.FTP.DATA".



EZA0602I TCP Host Name is: ADCD



EZA0605! I Using Name Server to Resolve ADCD

EZA0611I The following IP addresses correspond to TCP Host Name: ADCD

EZA0612I 192.168.1.116



EZA0614I The following IP addresses are the HOME IP addresses defined in PROFIL

E

.TCPIP:

EZA0615I 192.168.1.116

EZA0615I 127.0.0.1

!

EZA0618I All IP addresses for ADCD are in the HOME list!



EZA0622I Hometest was successful - all Tests Passed!

READY



Only other changes that I made were to define 192.168.1.1 and 4.4.4.4 as nameservers.

Brian_Westerman@SyzygyInc.com [hercules-390]

5 years ago

Permalink

Okay,

Lets treat things one at a time:

PROFILE dataset

DEVICE CTCA1 CTC E20
LINK CTC1 CTC 1 CTCA1 <--- 1 is write device, 0 is read device, change it to zero or define E21 device for the other one (CTCA2) and use two device and link statements and start both adapters.

HOME is okay

GATEWAY <-- replace
192.168.1.1 = CTC1 1492 HOST <-replace
DEFAULTNET 192.168.1.0 CTC1 1492 0 <--replace 192.168.1.0 is NOT your router

Replace the above with these.

BEGINROUTES
ROUTE 192.168.0.0 255.255.0.0 = CTC1 MTU 1492
ROUTE DEFAULT 192.168.1.1 CTC1 MTU 1492
ENDROUTES

All of the stuff from BEGINVTAM to ENDVTAM belongs in your TN3270 profile. You should have TN3270 set up as a separate task in your current ADCD z/OS release. It won't hurt you right now, but in the long run you should move it.

TCPDATA dataset

DOMAINORIGIN 192.168.1.1 is incorrect. It needs to point to a "name" for instance, it will make life easier if you set it to the same name as your email web site, (assuming you have one). For instance, if your email address is ***@Bobs.net, then it would be best as:

DOMAINORIGIN BOBS.NET

This will make life infinitely easier when you try to connect this thing up with using the internet. If you have your won web site, even though it's at some ISP, use that one. Don't use YAHOO or GMAIL, it's just asking for problems down the line. If you don't have one, get one, you can get a free one from one of the dynamic DNS places.

NSINTERADDR 192.168.1.1
NAMESERVER 4.4.4.4 <--- comment this one out. You already have NSINTERADDR, it's an either/or type thing for you on this platform. If your router 192.168.1.1 goes down, having google's name server won't help you. I am assuming you have a name server setup in your router already, you're able to use the internet.

RESOLVERTIMEOUT 10 <--- make this 30 or 45 seconds, 10 is too short for a PC trying to startup TCP and everyone else at the same time.

Incidentally, make sure you are starting RESOLVER, either automatically or as a started task, and ABSOLUTELY make sure that it points to THIS TCPDATA member, not some nebulous one that came with the ADCD. They absolutely MUST match. If you don't know how to change the one that gets loaded dynamically, then add the one from SAMPLIB, stop the running one and start your new one (Make sure you start it with SUB=MSTR). If you need help with this, let me know and I'll send you all of the information on how to do it. But if they don't match, then your set up will never work correctly.

LOOKUP LOCAL DNS <---uncomment or add this line. make sure it's in this order, which tells TCP to first check locally for names, THEN to check your DNS. This is VERY important because unless you are going to get a website name for your z/OS, you will want to refer to yourself internally before you go out to the internet to see who/where you are.

ROUTE TABLE:

Wow, this is really messed up.

First, you don't need the Microsoft loopback adapter, you should delete it from your devices. It will just get in the way. I have no idea if you need the VirtualBox host only adapter. If you don't, then get rid of it. You want to make sure that your Atheros 802.11 a/b/g/n Dualband Wireless adapter is first. Unless it's not a "real" adapater, then maybe you will want the Microsoft one. In any case, the one you are using to get to the internet is the one you want ot come up first in your adapter list (when you execute the TUNTAP test program (TT32Test or TT32Test64). Make sure you have it set up to be the first adapter presented to WinPcap and TUNTAP.

Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.6 281
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
169.254.0.0 255.255.0.0 On-link 169.254.70.25 286 <---remove

169.254.0.0 255.255.0.0 On-link 169.254.46.198 266 <---remove

169.254.46.198 255.255.255.255 On-link 169.254.46.198 266 <--- remove

169.254.70.25 255.255.255.255 On-link 169.254.70.25 286 <--- remove

169.254.255.255 255.255.255.255 On-link 169.254.70.25 286 <--- remove

169.254.255.255 255.255.255.255 On-link 169.254.46.198 266 <--- remove

192.168.1.0 255.255.255.0 On-link 192.168.1.6 <--- remove

192.168.1.6 255.255.255.255 On-link 192.168.1.6 281

192.168.1.255 255.255.255.255 On-link 192.168.1.6 281 <---remove

224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 169.254.70.25 286 <--- remove

224.0.0.0 240.0.0.0 On-link 169.254.46.198 266 <---remove

224.0.0.0 240.0.0.0 On-link 192.168.1.6 281
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 169.254.70.25 286 <--- remove

255.255.255.255 255.255.255.255 On-link 169.254.46.198 266 <--- remove

255.255.255.255 255.255.255.255 On-link 192.168.1.6 281
===========================================================================

After you remove all of these, you will need to add:

192.168.1.0 255.255.255.255 192.168.1.1 192.168.1.6 4

You have one similar to this now, but it doesn't have the gateway identified.

you do this via:
ROUTE -p delete 192.168.1.0
ROUTE -p add 192.168.1.0 MASK 255.255.255.0 192.168.1.1

ALSO, no matter what anyone tells you, under Windows 10, even though you ask the route to be permanent, they mostly will be replaced again the next time you reboot. Windows 10 has a hard time forgetting the old routes. There are some registry changes you can do to fix it, but they are beyond the scope of fixing this.

For now, after you have it working, you can just set up a .bat file that will do all of the route deletes and route adds that you execute when you start your z./OS up.

You basically want to end up with:
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.6 281
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255. 255 255.255.255.255 On-link 127.0.0.1 306
192.168.1.0 255.255.255.255 192.168.1.1 192.168.1.6 4 192.168.1.6 255.255.255.255 On-link 192.168.1.6 281

224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 192.168.1.6 281 255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 192.168.1.6 281 ===========================================================================


Once you have these changes made, AND you have set it up so your "REAL" adapter is the one that WinPcap and TUNTAP uses (via the TT32Test or TT32Test64 command) Actually, even with minor errors from TT32Test, it should still work with all of the above changes.

Brian Westerman

hgservers@yahoo.com [hercules-390]

5 years ago

Permalink

@Dan -

Beginroutes are currently what Brian had asked me to try. And yes, it is on the same network as the host NIC. It sounds like our networks are similar, but my address is 192.168.1.1 instead.


@Fish -


Sorry, must've overlooked those somehow by mistake.


- Windows version is Vista x64-bit SP2 (I know, I know... it's not my main production PC).
- CTCI-WIN version is 3.3.3.3285 according to TT64Test, and the Win PCap drivers are at 4.1.0.2980. I upgraded to this version last week sometime after originally trying on the original version of CTCI-WIN that I had from when I first started playing around with Hercules (Version 3.2) thinking that maybe something broke in an upgrade to Hercules, but that wasn't the case it doesn't look like.
- As far as the TT64Test, I ran TT64Test.exe - what do you mean by "comprehensive?" No errors came back in the output.


CTCI Test - Pastebin.com http://pastebin.com/p0DQHEz1


@Brian -
Okay, I made the changes to the PROFILE and TCPDATA members as told. Restarted TCPIP, but still no dice on a ping to 192.168.1.1.


Now. As far as resolver... correct me if I'm wrong, but the file I would have to modify/check that the correct prefix and member is being called is /etc/resolve.conf in OMVS, right? If I run 'F RESOLVER, DISPLAY' in the console, it comes back with all of the parameters set to "None" and NOCOMMONSEARCH set as well. Resolver proc is set to "default" in OMVS.

'Dan Skomsky' poodles511@sbcglobal.net [hercules-390]

5 years ago

Permalink

After you changed the PROFILE and TCPDATA files, did you run ‘TSO MAKESITE HLQ=TCPIP’?



Here is my ‘F RESOLVER,DISPLAY’ response:



03.07.10 F RESOLVER,DISPLAY

03.07.10 EZZ9298I DEFAULTTCPIPDATA -

ADCD.Z110S.TCPPARMS(TCPDATA)

03.07.10 EZZ9298I GLOBALTCPIPDATA - None

03.07.10 EZZ9298I DEFAULTIPNODES - None

03.07.10 EZZ9298I GLOBALIPNODES - None

03.07.10 EZZ9304I NOCOMMONSEARCH

03.07.10 EZZ9293I DISPLAY COMMAND PROCESSED



From: hercules-***@yahoogroups.com [mailto:hercules-***@yahoogroups.com]
Sent: Monday, June 27, 2016 12:13 AM
To: hercules-***@yahoogroups.com
Subject: [hercules-390] Re: z/OS V1R10 Networking in Hercules





@Dan -



Beginroutes are currently what Brian had asked me to try. And yes, it is on the same network as the host NIC. It sounds like our networks are similar, but my address is 192.168.1.1 instead.



@Fish -



Sorry, must've overlooked those somehow by mistake.



- Windows version is Vista x64-bit SP2 (I know, I know... it's not my main production PC).

- CTCI-WIN version is 3.3.3.3285 according to TT64Test, and the Win PCap drivers are at 4.1.0.2980. I upgraded to this version last week sometime after originally trying on the original version of CTCI-WIN that I had from when I first started playing around with Hercules (Version 3.2) thinking that maybe something broke in an upgrade to Hercules, but that wasn't the case it doesn't look like.

- As far as the TT64Test, I ran TT64Test.exe - what do you mean by "comprehensive?" No errors came back in the output.



CTCI Test - Pastebin.com <http://pastebin.com/p0DQHEz1>





@Brian -

Okay, I made the changes to the PROFILE and TCPDATA members as told. Restarted TCPIP, but still no dice on a ping to 192.168.1.1.





Now. As far as resolver... correct me if I'm wrong, but the file I would have to modify/check that the correct prefix and member is being called is /etc/resolve.conf in OMVS, right? If I run 'F RESOLVER, DISPLAY' in the console, it comes back with all of the parameters set to "None" and NOCOMMONSEARCH set as well. Resolver proc is set to "default" in OMVS.

Brian_Westerman@SyzygyInc.com [hercules-390]

5 years ago

Permalink

Hi,

Copy TCPIP.SEZAINST(RESOPROC) to your main proclib as member name RESOLVER

Uncomment the *SETUP (make it //SETUP) and point it to your TCPPARMS library member name RESSETUP

i.e. //SETUP DD DISP=SHR,DSN=Z22.TCPPARMS(RESSETUP) <--mine is Z22.TCPPARMS

create an IPNODES member of your TCPPARMS dataseet that contains the following card:

192.168.1.166 Z22 where 192.168.1.166 is your z/OS IP address of TCPIP and Z22 is your node name of this system

copy TCPIP.SEZAINST(RESSETUP) to the above member that you just pointed to in the RESOLVER PROC

Edit your new Z22.TCPPARMS(RESSETUP) member and make the following changes:

DEFAULTTCPIPDATA('Z22.TCPPARMS(TCPDATA)') <--- This is your exiting TCPDATA member

GLOBALTCPIPDATA('Z22.TCPPARMS(TCPDATA)') <--Same thing

GLOBALIPNODES('Z22.TCPPARMS(IPNODES)') <--- this is the IPNODES member you made above


Stop the current RESOLVER "P RESOLVER"

Start a new one (which is this new proc)

"S RESOLVER,SUB=MSTR" make sure you use the sub=mstr part.

If you still cannot ping your gateway, they you have still got something set up incorrectly, so you will need to again print off your current PROFILE, TCPDATA, RESSETUP, IPNODES entries so that we can see them.

Also, include the print of your current ROUTE Table from your Windows instance (fromt he CMD prompt you type "ROUTE PRINT".

If you have the above correct, there is no reason for it not to work, there aren't that many moving parts to this process.:)

Brian

'\'Fish\' (David B. Trout)' david.b.trout@gmail.com [hercules-390]

5 years ago

Permalink

***@yahoo.com wrote:

[...]

Post by ***@yahoo.com [hercules-390]
- As far as the TT64Test, I ran TT64Test.exe - what do
you mean by "comprehensive?" No errors came back in the
output.
CTCI Test - Pastebin.com <http://pastebin.com/p0DQHEz1>

-------------------------- Detected Adapters --------------------------

Connection = Wireless Network Connection
AdapterName = NPF_{436EF271-18AB-4E58-9F6D-4C905126A691}
Description = Atheros 802.11 a/b/g/n Dualband Wireless Network Module
[...]


CTCI-WIN does not support wireless networking.

--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com

'\'Fish\' (David B. Trout)' david.b.trout@gmail.com [hercules-390]

5 years ago

Permalink

***@yahoo.com wrote:

[...]

Post by ***@yahoo.com [hercules-390]
what do you mean by "comprehensive?"
No errors came back in the output.

(sigh) (Why do I even bother shipping a Help file?)

By comprehensive I mean a Ping test in both directions (from TT64Test to another system and from that other system to TT64Tes) from not just the same system that TT64Test is running in but ALSO from some *other* system on your network. That is to say, two separate TT64Resr Ping tests:

#1: From TT64Test to your Windows host, and from your Windows host to TT64Test.

#2: From TT64Test to a system NOT your Windows host, and from THAT system to TT64Test.

If either ping test fails in either direction then you have a problem. In your case it's because you're trying to use a wireless adapter which CTCI-WIN (WinPCap, specifically) doesn't support. If you use a wireless adapter your guest will only be able to communicate with your Windows host (and vice-versa) but you will not be able to communicate with any other system.

CTCI-WIN only works with WIRED adapters (physical WIRED networking). Wireless networking adapters devices are COMPLETELY DIFFERENT from wired networking adapter devices. They are not even remotely similar. They are not only physically different (you can't talk to them in the same way you talk to wired networking devices), but their packets are COMPLETELY DIFFERENT too.

You need to get yourself a wired networking adapter (they're quite cheap these days) and use it to connect your Windows host directly (physically, using an Ethernet cable) to your wireless router.

--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com

hgservers@yahoo.com [hercules-390]

5 years ago

Permalink

Ahh, okay. That makes sense then. I went out and got an ethernet cable, hooked up Ethernet, and have my new IP configured now and the wireless card is disabled.

Ran a test as per the help file, it pinged both the server from my desktop and my desktop from the server. So I think that it's safe to rule out the interface, Win PCap, and CTCI-WIN as the issues now. Also changed my Hercules config to reflect my new IP Address of 192.168.1.12 on the host now.


However, z/OS does not want to ping out still, even after the change and rerunning MAKESITE. I think that the issue is in the RESOLVER config, since I don't even have it pointing to my TCPDATA member like Dan does (It just shows None). How should I go about getting that setup correctly?


I've included the output from the TCPIP service in a Pastebin to see if that helps us pinpoint anything. http://pastebin.com/4y6GfuAn http://pastebin.com/4y6GfuAn

'Dan Skomsky' poodles511@sbcglobal.net [hercules-390]

5 years ago

Permalink

My ADCD.Z110S.TCPPARMS(RESSETUP) specifies these RESOLVER values.

This member is as follows:



; -----------------------------------------------------------------------------------------------

;

; IBM Communications Server for z/OS

; SMP/E distribution name: EZBRECNF

;

; 5694-A01 (C) Copyright IBM Corp. 2002, 2005,

; Licensed Materials - Property of IBM

;

; Function: Sample Resolver setup file

;

;

; The following statement defines the final search location for

; TCPIP.DATA statements. It will replace TCPIP.TCPIP.DATA

; It may be an MVS data set or HFS file.

;

DEFAULTTCPIPDATA('ADCD.Z110S.TCPPARMS(TCPDATA)')

;

# The following statement defines the first search location for

# TCPIP.DATA statements. It may be an MVS data set or HFS file.

;

; Update with the correct data set or HFS file name

;

; GLOBALTCPIPDATA('TCPCS.SYS.TCPPARMS(GLOBAL)')

;

; GLOBALTCPIPDATA(/etc/tcpipglobal.data)

;

# The following statement defines the first search location for

# IPNODES statements. It may be an MVS data set or HFS file.

;

; Update with the correct data set or HFS file name

;

; GLOBALIPNODES('TCPCS.SYS.TCPPARMS(IPNODES)')

;

; GLOBALIPNODES('TCPCS.ETC.IPNODES')

;

; GLOBALIPNODES(/etc/ipnodes)

;

# The following statement defines the final search location for

# IPNODES statements. It may be an MVS data set or HFS file.

;

; Update with the correct data set or HFS file name

;

; DEFAULTIPNODES('TCPCS.SYS.TCPPARMS(IPNODES)')

;

; DEFAULTIPNODES('TCPCS.ETC.IPNODES')

;

; DEFAULTIPNODES(/etc/ipnodes)

;

# The following statement defines if the common search order

# should be used or not.

;

NOCOMMONSEARCH

;

; COMMONSEARCH

;

; -----------------------------------------------------------------------------------------------







From: hercules-***@yahoogroups.com [mailto:hercules-***@yahoogroups.com]
Sent: Monday, June 27, 2016 6:46 PM
To: hercules-***@yahoogroups.com
Subject: [hercules-390] Re: z/OS V1R10 Networking in Hercules





Ahh, okay. That makes sense then. I went out and got an ethernet cable, hooked up Ethernet, and have my new IP configured now and the wireless card is disabled.



Ran a test as per the help file, it pinged both the server from my desktop and my desktop from the server. So I think that it's safe to rule out the interface, Win PCap, and CTCI-WIN as the issues now. Also changed my Hercules config to reflect my new IP Address of 192.168.1.12 on the host now.



However, z/OS does not want to ping out still, even after the change and rerunning MAKESITE. I think that the issue is in the RESOLVER config, since I don't even have it pointing to my TCPDATA member like Dan does (It just shows None). How should I go about getting that setup correctly?



I've included the output from the TCPIP service in a Pastebin to see if that helps us pinpoint anything. http://pastebin.com/4y6GfuAn

hgservers@yahoo.com [hercules-390]

5 years ago

Permalink

Hmm... I didn't even have that member in my dataset...

I'm wondering if I might need those instructions that Brian's talking about. Looks like it was never setup at all.

Mike Schwab Mike.A.Schwab@gmail.com [hercules-390]

5 years ago

Permalink

Hercules uses the first network device, regardless of enabled / disabled
status.
You will need to place the Ethernet interface first.

...

--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

hgservers@yahoo.com [hercules-390]

5 years ago

Permalink

"If you have the above correct, there is no reason for it not to work, there aren't that many moving parts to this process.:)"


The funny thing is that I tend to work better on things when there's more of these moving parts... lol


Anyways, I got everything copied over, however it still doesn't want to ping out.
http://pastebin.com/uV2hwAHL http://pastebin.com/uV2hwAHL

http://pastebin.com/DbLB6NLZ http://pastebin.com/DbLB6NLZ

http://pastebin.com/ihWbvg4f http://pastebin.com/ihWbvg4f

http://pastebin.com/b24PsmXa http://pastebin.com/b24PsmXa

http://pastebin.com/fcW55Kj6 http://pastebin.com/fcW55Kj6

http://pastebin.com/jYWkDsDP http://pastebin.com/jYWkDsDP


Also, the Ethernet interface is first in the list now. (@Mike)


Windows Routes Table as of right now: (It recreated some when I added the Ethernet interface)
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.12 276
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
192.168.1.0 255.255.255.0 192.168.1.1 192.168.1.12 21
192.168.1.12 255.255.255.255 On-link 192.168.1.12 276
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 169.254.46.198 266
224.0.0.0 240.0.0.0 On-link 192.168.1.12 276
255.255.255.255 255.255.255.255 On-link 192.168.1.12 276
===========================================================================
Persistent Routes:
Network Address Netmask Gateway Address Metric
0.0.0.0 0.0.0.0 192.168.1.1 Default
255.255.255.255 255.255.255.255 127.0.0.1 1
0.0.0.0 0.0.0.0 192.168.1.1 Default
192.168.1.0 255.255.255.0 192.168.1.1 1
===========================================================================



But from what Fish said, I thought that I don't need routes? (I have IP Routing disabled in my registry, so would these even matter? Also for the fact that I'm running a real router as per the CTCI help file?)


And ping testing from TT64Test:
00:44:33.948 *** Interface tap0 enabled/up... (ip="192.168.1.116", mac="")
00:44:44.207
00:44:44.207 ** START ** UNPAID TRIAL COPY ** PING TEST **
00:44:44.207
00:44:44.207 ping -c 4 -i 1000 -s 32 -w 500 192.168.1.3
00:44:44.207
00:44:44.207 Sending ping #1 bytes=32 to 192.168.1.3...
00:44:44.211 ** CTT32TestView::HandleTapARPPacket: WRITING ARP response...
00:44:44.212 Reply to ping #1 received from 192.168.1.3: bytes=32 time=<1ms TTL=128
00:44:45.209 Sending ping #2 bytes=32 to 192.168.1.3...
00:44:45.211 Reply to ping #2 received from 192.168.1.3: bytes=32 time=<1ms TTL=128
00:44:46.210 Sending ping #3 bytes=32 to 192.168.1.3...
00:44:46.212 Reply to ping #3 received from 192.168.1.3: bytes=32 time=<1ms TTL=128
00:44:47.211 Sending ping #4 bytes=32 to 192.168.1.3...
00:44:47.216 Reply to ping #4 received from 192.168.1.3: bytes=32 time=16ms TTL=128
00:44:48.216
00:44:48.216 Ping statistics for 192.168.1.3:
00:44:48.216
00:44:48.216 4 Pings Sent
00:44:48.216 4 Replies Received (Minimum = 0ms, Maximum = 16ms, Average = 4ms)
00:44:48.216 0 Pings Timeouts
00:44:48.216 0 Duplicate Replies
00:44:48.216 0 Pings Lost (0%)
00:44:48.216
00:44:48.216 Ping test successful.
00:44:48.216
00:44:48.216 ** END ** UNPAID TRIAL COPY ** PING TEST **
00:44:48.216
00:45:01.169 ** Someone is PINGing Herc!
00:45:01.169 ** Sending PING reply to 192.168.1.3
00:45:01.175 ** CTT32TestView::HandleTapARPPacket: WRITING ARP response...
00:45:02.178 ** Someone is PINGing Herc!
00:45:02.178 ** Sending PING reply to 192.168.1.3
00:45:03.182 ** Someone is PINGing Herc!
00:45:03.182 ** Sending PING reply to 192.168.1.3
00:45:04.186 ** Someone is PINGing Herc!
00:45:04.186 ** Sending PING reply to 192.168.1.3





I have a feeling that I'm overlooking something that was already said... or again, something obvious. I might just be looking too hard to find the issue. HOMETEST runs through with no issues at all.

Brian_Westerman@SyzygyInc.com [hercules-390]

5 years ago

Permalink

Mike is correct.

You don't need a new card, you can use your existing wireless card. But, whichever one you go with, it must be the first one that is seen in the list. You can check it via Fish's directions on his web site, and it's easy to change the order from the windows network and sharing center|Change adapter settings (press and release the ALT key) and select Advanced|advanced settings| and they show up on the configuration area on the top of that panel. You can move them up (or down) just make sure that you have the one you want to use for your adapter that talks to your router 192.168.1.1 as the first one in the list. If you have a software VPN (I have Juniper) they have to be active when you do this change because they don't show up until you start them up. Some other applications also have "stealth drivers" like Juniper VPN, you just have to play it by ear and make sure you get them all and make you desired adapter top of the list.

You will need to reboot after the above changes.

Also, it's quite important that your device settings for your old wireless (or your new card) are changed so that you do not do any of the checksum offloading and send offloading (i.e. disable them). This is not required on every card, (my Intel I217-V0 doesn't require it, but many cards do. It's best to turn off ALL offloading, and then after things are working, you can turn them back on if you want to one at a time until you find one that messes things up for you, then just leave that one off. If you end up having to do that, then every time Windows replaces your driver for your card, you will have to do it over again. It's not a problem for me, but some cheaper cards and motherboards (and maybe even expensive ones) may experience this issue.

You will again need to reboot for windows to reload your changes.

So, once you do that, AND make sure your other changes are in, AND your ROUTE table is in place, THEN it will all work. It seems like a lot to do, but typically once you get it right, you will know all of the pieces and be able to troubleshoot your system should things ever stop working.

If you still are having problems after all of these changes are complete and want to call me, send me a private email and I'll send you my phone number and we can go through this stuff one by one.

Brian

hgservers@yahoo.com [hercules-390]

5 years ago

Permalink

Got it working now. Apparantly either Checksum Offloading or Send Offloading on the Ethernet Card was the issue. It still doesn't want to ping out to the internet, but it is pinging everything within the LAN fine. I can deal with it pinging outside at another time if I figure that that's something that I want to do/try with it. For now, the next step is trying to figure out how to get it to print to a CUPS server cups-pdf printer using Infoprint (I got it sending jobs to CUPS, but nothing's showing up on the pages). So, for now, this issue is closed. Thanks for the help/input, guys!

Brian_Westerman@SyzygyInc.com [hercules-390]

5 years ago

Permalink

How far into the internet can you ping?

Can you ping your router 192.168.1.1, if so, can you ping google by name or IP address? Their IP is 216.58.194.64. If you can, but can't ping them as http://www.google.com http://www.google.com then it's just a name server setup issue in your TCP setup and is quite easy to fix. (it's the dns/name server setup parm that you would normally point to your router, unless you router doesn't have the name server internally listed, in which case you need to add one inside your TCP settings.)

Brian

---In hercules-***@yahoogroups.com, <***@...> wrote :

Got it working now. Apparantly either Checksum Offloading or Send Offloading on the Ethernet Card was the issue. It still doesn't want to ping out to the internet, but it is pinging everything within the LAN fine. I can deal with it pinging outside at another time if I figure that that's something that I want to do/try with it. For now, the next step is trying to figure out how to get it to print to a CUPS server cups-pdf printer using Infoprint (I got it sending jobs to CUPS, but nothing's showing up on the pages). So, for now, this issue is closed. Thanks for the help/input, guys!

hgservers@yahoo.com [hercules-390]

5 years ago

Permalink

My host PC got rebooted (it hit a BSOD, not herc related) - after the reboot, it seems to want to ping out to the internet now with both IPs and domain names.

READY
ping 192.168.1.1
CS V1R10: Pinging host 192.168.1.1
Ping #1 response took 0.005 seconds.
READY
ping 216.58.194.64
CS V1R10: Pinging host 216.58.194.64
Ping #1 response took 0.052 seconds.
READY
ping www.facebook.com.
CS V1R10: Pinging host WWW.FACEBOOK.COM. (31.13.71.36)
Ping #1 response took 0.020 seconds.
READY



Prior it wouldn't reach out past the router for either names or IPs... odd. Works now, tough.

Brian_Westerman@SyzygyInc.com [hercules-390]

5 years ago

Permalink

Normally BSOD is bad, but I guess "every cloud ..."

If you can document all of your changes for the next person to come alone and post it to this thread with a topic of ANSWER: it would benefit the next person to have a network issue. Especially since people will be able to check the whole thread and see all of the pieces they need to address.

Brian

hgservers@yahoo.com [hercules-390]

5 years ago

Permalink

Yup, I'll work on getting a PDF made up of a general troubleshooting guide or something like that summarizing the steps I took and link it here/post it here.

'\'Fish\' (David B. Trout)' david.b.trout@gmail.com [hercules-390]

5 years ago

Permalink

[...]

Post by ***@yahoo.com [hercules-390]
but I can only ping the host machine from within z/OS,
and z/OS can only be pinged from the host machine,
using their respective IPs (10.0.0.6 and 10.0.0.116).

(I'm presuming "10.0.0.6 and 10.0.0.116" is a typo)

Another reason why OTHER systems on your local network (LAN) might not be able to ping your z/OS guest (and vice versa) is because Windows Firewall (either on your Windows host or, more likely, on your other systems) might be blocking pings.

You might need to configure your Windows Firewall(s) to allow Pings through. Refer to the "Ping only one direction" section of the "Common Problems" chapter of the CTCI-WIN Help file for instructions on how to do this.

--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com

'\'Fish\' (David B. Trout)' david.b.trout@gmail.com [hercules-390]

5 years ago

Permalink

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]

Post by ***@yahoo.com [hercules-390]
I'm trying to get my Hercules with z/OS to talk to
my network. I'm running the emulator on Windows.

Which Windows? Windows 7? Windows 10?

No answer?


[...]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]

Post by ***@yahoo.com [hercules-390]
And TUN/TAP loaded successfully when Hercules started,
running as an administrator.

What version of CTCI-WIN are you using?

No answer?

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
Did you run a comprehensive TT64Test Ping Test? (*)

No answer?
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com

 

--30--