check current value
sysctl net.ipv4.ip_forward
set to enabled
sudo sysctl net.ipv4.ip_forward=1
Persist across boots
sudo nano /etc/sysctl.conf
# Uncomment the next line to enable packet forwarding for IPv4 #net.ipv4.ip_forward=1
reference:
--30--
Showing posts with label tcpip. Show all posts
Showing posts with label tcpip. Show all posts
Wednesday, September 10, 2025
enable port forwarding on ubuntu
Sunday, September 19, 2021
zos on hercules tcpip thread (long) archived from yahoo groups
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.
(too old to reply)
hgservers@yahoo.com [hercules-390]
5 years ago
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.
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
hgservers@yahoo.com [hercules-390]
5 years ago
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
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
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
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.
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
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 - - -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
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
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?I'm trying to get my Hercules with z/OS to talk to
my network. I'm running the emulator on Windows.
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...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).
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.1160E20-0E21 CTCI -n [MAC Address of my card] 192.168.1.116 192.168.1.6
Windows Host IP Address = 192.168.1.6
Okay.
Okay, but LCS is less problematic.
Okay.
If 192.168.1.1 is the same default gateway as what your Windows host is using, then okay.
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.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
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.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.
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?And TUN/TAP loaded successfully when Hercules started, running
as an administrator.
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?
"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
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
[...]
Post by ***@id.ethz.ch [hercules-390]
thing will understand "GATWAY" instead of "GATEWAY" (although
I never tried using GATWAY).
Good catch. I completely missed that one. :)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 darnWindows host is using, then okay.
thing will understand "GATWAY" instead of "GATEWAY" (although
I never tried using GATWAY).
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com
hgservers@yahoo.com [hercules-390]
5 years ago
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).
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
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
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
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.
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
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.
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
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.
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
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.
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
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
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
@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.
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
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.
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
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
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
***@yahoo.com wrote:
[...]
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.
[...]
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 --------------------------- 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>
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)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com
'\'Fish\' (David B. Trout)' david.b.trout@gmail.com [hercules-390]
5 years ago
***@yahoo.com wrote:
[...]
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.
[...]
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?)what do you mean by "comprehensive?"
No errors came back in the output.
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
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com
hgservers@yahoo.com [hercules-390]
5 years ago
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
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
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
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
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.
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
Hercules uses the first network device, regardless of enabled / disabled
status.
You will need to place the Ethernet interface first.
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?
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
"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.
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
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
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
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
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!
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
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.
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
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
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
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
[...]
(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.
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).
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).
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)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com
'\'Fish\' (David B. Trout)' david.b.trout@gmail.com [hercules-390]
5 years ago
Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
No answer?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?I'm trying to get my Hercules with z/OS to talk to
my network. I'm running the emulator on Windows.
[...]
Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
No answer?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?And TUN/TAP loaded successfully when Hercules started,
running as an administrator.
Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
Did you run a comprehensive TT64Test Ping Test? (*)
No answer?Did you run a comprehensive TT64Test Ping Test? (*)
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com
--30--
Saturday, September 18, 2021
add a route to a specific IP on linux to get to a remote emulated system
Note on how to add a route on a system remote to an host for an emulated system.
Use case. A system with TCP/IP configured is running on a host with a local IP for the emulated system, and a gateway IP on the host. The latter is on a tun/tap NIC on the host system.
one can access the emulated system from the network on the host system. But the gateway tun/tap device isn't shared on the external network.
example
[hercules guest]
ip xxx.201 NIC internal to OS
[CTCA bridge]
ip xxx.151 NIC tun/tap on host running hercules
[Host system]
ip xxx.136 NIC is enp0 ethernet NIC for host.
[subnet]
xxx/24
[remote system]
ip xxx.172
traffic for the xxx.151 ip isn't bridged out of the [Host system]
ip route add xxx.151 via xxx.136 dev enp0s25 executed on the [remote system]
allows programs on remote system access the [hercules guest]
--30--
Tuesday, June 23, 2020
enable port forwarding on ubuntu
check current value
sysctl net.ipv4.ip_forward
set to enabled
sudo sysctl net.ipv4.ip_forward=1
Persist across boots
sudo nano /etc/sysctl.conf
# Uncomment the next line to enable packet forwarding for IPv4 #net.ipv4.ip_forward=1
reference:
Friday, May 3, 2019
Zos mainframe notes
searches to find IBM tcp zos stuff thru search engines
change tcpip routing zos tso
Hercules TCP/IP
http://www.hercules-390.org/herctcp.html
TCPIP ipv4 forwarding
Current IP forwarding status
Read a current state of IP forwarding:# sysctl net.ipv4.ip_forward net.ipv4.ip_forward = 1Currently, the output number
1 indicates that the IP
forwarding is enabled. The above value is read from the Linux proc file
system and more precisely from the actual file /proc/sys/net/ipv4/ip_forward file: # cat /proc/sys/net/ipv4/ip_forward 1
Disable IP forwarding
To disable IP forwarding on a running Linux system run:# sysctl -w net.ipv4.ip_forward=0 net.ipv4.ip_forward = 0
https://hercules-390.github.io/html/herctcp.html
telnet works on TSO
Note that flashes up before entering session
EZA8265I Using Line Mode...
EZA8267I Notes on using Telnet when in Line Mode:
EZA8268I - To hide Password, Hit PF3 or PF15
EZA8269I - To enter Telnet Command, Hit PF4-12, or PF16-24
***
Subscribe to:
Posts (Atom)