Category: TCPIP

How to get out to the internet. SNAT, DNAT and MASQUERADE

This follows on from concepts explained in If we all have the same IP addresses how does the internet work?

The high level problems

I have a Linux server machine connected to my laptop via Ethernet. How can I change the destination of where data flows?

I want to be able to say

  • Any traffic coming in over Ethernet for IP address 98.76.54.32, route it to the server on my other laptop with address 10.0.0.6. This is changing the Destination Address of a packet., or DNAT: (changing the) Destination Network Address Table to a specific address.
  • I want to be able to send stuff sent over Ethernet with an internal IP address, and route it to external servers. In effect I want to make the data from my server machine be sent to the internet, with the IP address of my laptop. This is changing the Source address of a packet, or SNAT: (changing the) Source Network Address Table to a specific address.

The home address of my z/OS system was 10.1.1.2. My Linux machine has IP address 192.168.1.139.

Kindergarden concepts of a router

Traffic comes in to a router. There are rules which control how traffic is routed, for example this address range should go down the Ethernet connection, anything else (the default) goes over the wireless connection.

Below the surface

I picture the router as 3 boxes in a row. Before – router – after.

  • Before: You can specify rules to be applied before the data gets to the routing code. This allows you to change information in the packet header, such as destination, or port address. The rule type for this are called PREROUTING. The packet then flows into…
  • The router: This decides where each packet goes. The packet the flows into…
  • After: You can change the packets before it gets send down the interface. This rule type is POSTROUTING.

Changing the destination

The command on my Linux laptop

iptables -t nat -A PREROUTING -p tcp --dport 1122 -j DNAT --to-destination 10.0.0.6:3344

Send all TCP traffic destined for port 1122 to the machine with IP address 10.0.0.6, and change the port to 3344.

It is PREROUTING, meaning that make the change before any routing decisions are made.

Changing the source – getting the data to the outside world

The following command on my Linux laptop

iface=wlxcc641aee92c5
sudo iptables -t nat -A POSTROUTING -s 10.1.1.2 -o $iface -j SNAT --to-source 192.168.1.139

tells Linux to take any traffic from 10.1.1.2, send it over the interface wlxcc641aee92c5 and change the Source Network Address Translation (SNAT) so it looks like it came from 192.168.1.139 ( my wireless interface).

This is POSTROUTING because the routing decision has already been made, and the data is ready to be sent over the interface(eg wireless).

This is fine as long as you know the IP address of your interface (192.168.1.139). If your router has DHCP, the Linux may get a different address every time. In this case you can use

iface=wlxcc641aee92c5
sudo iptables -t nat -A POSTROUTING -s 10.1.1.2  -o wlxcc641aee92c5 -j MASQUERADE

which I believe says for the specified source address 10.1.1.2 and use the address of the -o output device.

You might just use the MASQUERADE option every time as it is easier to type.

If you want to specify all traffic (or just want it to work) you can omit the -s

iface=wlxcc641aee92c5
sudo iptables -t nat -A POSTROUTING -o $iface -j MASQUERADE

There are some good examples here.

Problems getting out of z/OS to the outside world, unknown host

I was in OMVS trying to install some software, but it could not find and use the IP address of the server. My current /etc/hosts file is here.

What’s the problem?

I issued

ping pypi.org

and got

EZZ3111I Unknown host 'pypi.org'

There are two solutions

Capture an (IP address) resolver trace

I issued the command

export RESOLVER_TRACE=~/trace

and reran the command.
This gave 

 Resolver Trace Initialization Complete -> 2025/11/26 10:53:47.591994 
                                                                                   
 res_init Resolver values: 
  Setup file warning messages = No 
  CTRACE TRACERES option = No 
  Global Tcp/Ip Dataset  = ADCD.Z31B.TCPPARMS(GBLTDATA) 
  Default Tcp/Ip Dataset = ADCD.Z31B.TCPPARMS(GBLTDATA) 
  Local Tcp/Ip Dataset   = /etc/resolv.conf 
  Translation Table      = TCPIP.STANDARD.TCPXLBIN 
  UserId/JobName         = COLIN 
...
res_init Succeeded 
res_init Started: 2025/11/26 10:53:47.650509 
res_init Ended: 2025/11/26 10:53:47.650537 
*************************************************************************** 
GetAddrInfo Started: 2025/11/26 10:53:47.650677 
GetAddrinfo Invoked with following inputs: 
   Host Name:  pypi.org 
   No Service operand specified 
   Hints parameter supplied with settings: 
       ai_family = 0, ai_flags = 0x00000062 
       ai_protocol = 0, ai_socktype = 0 
No NameServers specified, no DNS activity 
GetAddrInfo Opening Socket for IOCTLs 
 BPX1SOC:  RetVal = 0, RC = 0, Reason = 0x00000000, Type=IPv4 
 BPX1IOC:  RetVal = 0, RC = 0, Reason = 0x00000000 
GetAddrInfo Opened Socket 0x00000004 
GetAddrInfo Only IPv4 Interfaces Exist 
GetAddrInfo Searching Local Tables for IPv4 Address 
Global IpNodes Dataset  = ADCD.Z31B.TCPPARMS(ZPDTIPN1) 
Default IpNodes Dataset = ADCD.Z31B.TCPPARMS(ZPDTIPN1) 
Search order            = CommonSearch 
 SITETABLE from globalipnodes ADCD.Z31B.TCPPARMS(ZPDTIPN1) 
 - Lookup for pypi.org 
GetAddrInfo Closing IOCTL Socket 0x00000004 
 BPX1CLO:  RetVal = 0, RC = 0, Reason = 0x00000000 
GetAddrInfo Failed:  RetVal = -1, RC = 1, Reason = 0x78AE1004 
GetAddrInfo Ended: 2025/11/26 10:53:47.664992

Where 0x78AE1004 is The GETADDRINFO call failed because the host name cannot be found in DNS, or in the z/OS host configuration files (/etc/hosts or hlq.HOSTS.ADDRINFO).

I think this message is not very helpful. It was not found in sitetable

Default IpNodes Dataset = ADCD.Z31B.TCPPARMS(ZPDTIPN1)

Use a Dynamic Name Server

You can tell TCPIP to go to a Name Server to look up the address in the internet.

The JCL for my RESOLVER started task has

//* 
//* TCPIP RESOLVER - COLINS 
//* 
//RESOLVER PROC PARMS=CTRACE(CTIRES00) 
//* 
//EZBREINI EXEC PGM=EZBREINI,REGION=0M,TIME=1440, 
// PARM=('&PARMS', 
// 'ENVAR("RESOLVER_TRACE=/var/log/resolver"/') 
//SETUP DD DISP=SHR,DSN=COLIN.TCPPARMS(GBLRESOL),FREE=CLOSE 
//SYSTCPT   DD SYSOUT=* 
//SYSPRINT  DD SYSOUT=* 
//SYSOUT     DD SYSOUT=* 
//*

The //SETUP member GBLRESOL has

  DEFAULTTCPIPDATA('COLIN.TCPPARMS(GBLTDATA)') 
  GLOBALTCPIPDATA(/etc/resolv.conf) 
; 
...

File /etc/resolv.conf has

nameserver 8.8.8.8 
nameserver 1.1.1.1

I enabled a resolver trace and pinged a new website.

The trace includes

**************************************************************************
GetAddrInfo Started: 2025/12/16 17:00:54.153989 
GetAddrinfo Invoked with following inputs: 
   Host Name:  hmrc.co.uk 
 ...
res_search(hmrc.co.uk, C_IN, T_A) 
res_search Host Alias Search found no alias 
res_querydomain(hmrc.co.uk., , C_IN, T_A) 
res_querydomain resolving name:  hmrc.co.uk. 
res_query(hmrc.co.uk., C_IN, T_A) 
 Querying resolver cache for hmrc.co.uk. 
 EZBRECFR:  RetVal = 0, RC = 0, Reason = 0x00000000 
 No cache information was available 
...
* * * * * Beginning of Message * * * * * 
...                                                                          
 Number of Question RRs:  1 
 Question 1: 
 hmrc.co.uk 
...
* * * * * End of Message * * * * * 
res_send Name Server Capabilities 
 Monitoring intervals used = 5 
 Name server 8.8.8.8 
...
 Name server 1.1.1.1 
... 
res_send Sending query to Name Server 8.8.8.8 
...
res_send received data via UDP.  Message received: 
* * * * * Beginning of Message * * * * * 
...
 Question 1: 
 hmrc.co.uk 
...                                                                              
 Number of Answer RRs:  1 
 Answer 1: 
 hmrc.co.uk 
...
 TTL:  3600 (0 days, 1 hours, 0 minutes, 0 seconds) 
 195.171.114.178 
* * * * * End of Message * * * * * 
...
 Attempting to cache results for hmrc.co.uk. 
 EZBRECAR:  RetVal = 0, RC = 0, Reason = 0x00000000 
 Cache information was saved

The TTL from the DNS server says 

 TTL:  3600 (0 days, 1 hours, 0 minutes, 0 seconds)

When there was another request to the site within this time, the trace had

GetAddrInfo Started: 2025/12/16 17:01:09.426161 
GetAddrinfo Invoked with following inputs: 
   Host Name:  hmrc.co.uk 
...
 Querying resolver cache for hmrc.co.uk. 
 EZBRECFR:  RetVal = 0, RC = 0, Reason = 0x00000000 
 Cache data from 8.8.8.8 was retrieved 
...
GetAddrInfo Succeeded:  IP Address(es) found: 
  IP Address(1) is 195.171.114.178

showing the value from the DNS was retrieved from the local cache.

Explicitly specify the name to IP address mapping

If you do not want to use the DNS you can specify your own name to IP address mapping.

I reconfigured my RESOLVER started task to have

Global IpNodes Dataset  = /etc/hosts 
Default IpNodes Dataset = COLIN.TCPPARMS(ZPDTIPN1)

and edited /etc/hosts to include

#IPAddress             Hostname   alias 
151.101.128.223        pypi.org    pip

and the ping pypi.org worked

The trace file now had

 Global IpNodes Dataset  = /etc/hosts 
 Default IpNodes Dataset = COLIN.TCPPARMS(ZPDTIPN1) 
 Search order            = CommonSearch 
  SITETABLE from globalipnodes /etc/hosts 
  - Lookup for pypi.org 
  ADDRTABLE from globalipnodes /etc/hosts 
  - Lookup for 151.101.128.223 
 GetAddrInfo Returning Zero as Port Number 
 GetAddrInfo Built 1 Addrinfos 
 GetAddrInfo Closing IOCTL Socket 0x00000004 
  BPX1CLO:  RetVal = 0, RC = 0, Reason = 0x00000000 
 GetAddrInfo Succeeded:  IP Address(es) found:

When I changed this file to have multiple examples for the pypi.org

#IPAddress             Hostname   alias 
151.101.128.223        pypi.org    pip 
151.101.192.223        pypi.org    pip

the trace file had

GetAddrinfo Invoked with following inputs: 
   Host Name:  pypi.org 
...
 SITETABLE from globalipnodes /etc/hosts 
 - Lookup for pypi.org 
 ADDRTABLE from globalipnodes /etc/hosts 
 - Lookup for 151.101.128.223 
GetAddrInfo Returning Zero as Port Number 
GetAddrInfo Built 2 Addrinfos 
GetAddrInfo Closing IOCTL Socket 0x00000004 
 BPX1CLO:  RetVal = 0, RC = 0, Reason = 0x00000000 
GetAddrInfo Succeeded:  IP Address(es) found: 
  IP Address(1) is 151.101.128.223 
  IP Address(2) is 151.101.192.223

and it returned both of them to the caller

My current /etc/hosts

After doing some Pip work to install products, my /etc/hosts file is now

#IPAddress             Hostname   alias 
151.101.128.223        pypi.org    pip 
151.101.192.223        pypi.org    pip 
151.101.192.223        files.pythonhosted.org   pipfiles 
20.26.156.215          github.com 
151.101.128.81         bbc.co.uk 
151.101.1.91           curl.se 
185.199.110.133        raw.githubusercontent.com 
185.199.110.133        release-assets.githubusercontent.com 
169.63.188.167         downloads.pyaitoolkit.ibm.net

I created this list by resolver_trace to find the hostnames which failed, then adding them to the file along with their addresses using nslookup name.

Why does one ping work, and the same ping doesn’t?

I was trying to check connectivity from z/OS running on my laptop. For some remote sites I could issue ping and get a response back. For some other sites I issue the ping and did not get a response back.

When I issued the pings from Linux – they both worked.

I noticed that for the pings from z/OS the field Timestamp from icmp data (relative): was 27 seconds behind. This was caused by z/OS adding leap seconds. It was not the problem.

By comparing all the fields in a successful and an unsuccessful ping, I could see that z/OS send 256 bytes of data, and Linux sent only 40 bytes of data.

On Linux, when I used

ping …. -s 256

it failed. When I used

ping …. -s 20

it worked.

Similarly on z/OS.

ping .... (length 20

The defaults lengths are different between z/OS and Linux.

The moral of this tale is

If ping does not return any data – try a very short ping.

If we all have the same IP addresses how does the internet work?

At home my IP address is 192.168.1.139. I went to a local cafe, and my IP address was the same. If use the internet, how does the server now which 192.168.1.139 to send the data to. (I went to the town hall and got 192.168.1.25 so it is not always the same address).

I thought it was a bit like gravity – it just works. But in gravity’s case, no one knows how it works.

With the internet, it is easy – until it is not easy. It is called Network Address Translation or NAT.

How does it work?

I access the internet through a BT Smart hub. It has an IP address on the internet of 87.65.43.21. For the moment assume this address is unique in the internet.

The IP address of my laptop is 192.168.1.139, and is unique within my home hub area. My old laptop has a different IP address on my home network.

When my laptop connects to a server, such as google, BBC etc, the browser opens a port (for example 99) to the local TCPIP, and the request goes to the hub over the wireless interface.

The hub picks a free port (123) for this session, builds an internal table of my laptop’s IP address 192.168.1.139 + port 99, and the hub’s port 123. The hub then sends the request to the destination – with the “originator” address set to 87.65.43.21 port 123. The server responds with data for 87.65.43.21 port 123. My home hub then looks in its table for port 123 and says this maps to 192.168.1.139 port 99, and sends it down to my laptop.

That’s all pretty easy. I mentioned that the address 87.65.43.21 is unique in the internet. That statement is not strictly true. It is unique in the BT network for Orkney and north Scotland. In another part of the country – such as Wales, there will also be a hub with address 87.65.43.21. So how does this work….. ? Easy, it is the same as before

Somewhere in north Scotland BT has a big router. This might only support IPV6, and this router has IP address 2000:1234:5678::99

When a request for a new connection comes in from 87.65.43.21 port 123 the big BT router builds an internal table of 87.65.43.21 port 123 mapping to 2000:1234:5678::99 port 222. This address gets send onwards to the server. The server gets the request with originator 2000:1234:5678::99 port 222, does some work, and sends the response back to the big router in Scotland. The big BT router looks up port 222, finds it is for address 87.65.43.21 port 123, and sends it down to my home hub.
My home hub gets the request looks in its internal tables and sends it on to my laptop.

There will be a big router in Wales with it’s own IP address, so the 87:65:43:21 in Wales will have a different IP address to mine, when its requests get to the server.

This way every one can have the same IP address and we all get connected to the internet.

What does a Wireshark trace look like?

I was running z/OS on zD&T on Linux.

  • The IP address of z/OS had home 10.1.1.2
  • The IP address of Linux was 192.168.1.139
  • I used Wireshark on the Wireless interface.
    • A ping from TSO on z/OS showed up as being from 192.168.1.139 – the Linx address
    • The response came back to 192.168.1.139

Is it that simple?

No. This is where I’ve made some guesses because I could not find any more information.

  • A ping from z/OS with host address 10.1.1.2 went out with source IP address of 192.168.1.139.
  • A ping from Linux went out out with source IP address of 192.168.1.139.

I think that the mapping of IP address is a little more complex that I first described.
The Linux box needs to know which requests came from z/OS and so the response needs to be sent to z/OS and which request came locally. Some TCP packets have a sequence and identifier, it may be that these are used to keep track of individual packets, and so Linux can route them.

But…

I said at the top With the internet, it is easy – until it is not easy. The route a request takes to a server can be different to the route the response takes from a server. I do not understand how this works if NAT is used. Perhaps you always have to go through “the big routers” doing NAT, but the path from my laptop to the “big routers” can vary, going through routers which do not do NAT.

My mental picture is “Hub Airport”

  • I can take any route to get to the airport from my house.
  • At the airport, I can take any airline to get to my destination, either directly or via hops.
  • At the remote airport I can take any route to drive to my hotel.

The airports are routers doing the NAT.

Where the heck is TCPIP.DATA?

I’ve been struggling to get a TCPIP function working. The TCPIP documentation repeatedly says use the configuration in TCPIP.DATA. I did – and it made no difference.

What it should say is in the //SYSTCPD data set in your TCPIP procedure.

TCPIP started tasks such as the resolver, can query TCPIP and get the name of the dataset.

As I’ve said before, it is easy when you know the answer.
I also blogged this, so when I forget this in a few months time, and look for TCPIP.DATA , a search of the internet will find it.

One minute networking: IPV6 Multi cast for people who do not want to know the details.

I picture IP multicast as groups in whatsapp, or to send a packet of data to all endpoints under a node in the network.

The maximum group is the top 104 bits of an IP V6 TCPIP address – or, to put it a different way, having a different right 24 bits.

With an IP address of 2001:0123:4567:89ab:cdef:0123:4567:89ab the maximum group is 2001:0123:4567:89ab:cdef:0123:45..:…. to send a packet to members of the group you use address ff02:0000:0000:0000:0000:0001:ff.:…. or (in abbreviated form) ff02::1:ff .

There are different groups. One of my interfaces is a member of the following “groups”

  • ff01::1 all nodes
  • ff02::2 all routers
  • ff02::1:ff67:89ab this is a group for this specific address. When an interface is started, it sends a packet saying “does anyone have this address 67:89ab” to the group ff02::1:ff67:89ab. If there is a reply – then the value you are using is a duplicate. This is known as DAD Duplicate Address Detection.
  • ff02::fb multicast DNS IPv6

IP V4

When an IP V4 interface starts it broadcasts (similar to multicast) “ARP: I am address 10.1.1.2, this is my MAC address, and I my status is UP”

Displaying multicast information on Linux

linux netstat –groups

This gives information like

IPv6/IPv4 Group Memberships
Interface       RefCnt Group
--------------- ------ ---------------------
lo              1      mdns.mcast.net
lo              1      all-systems.mcast.net
eno1            1      mdns.mcast.net
eno1            1      all-systems.mcast.net
...
lo              1      ff02::fb
lo              1      ip6-allnodes
lo              1      ff01::1
eno1            1      ff02::fb
eno1            1      ff02::1:ffa8:b879
eno1            1      ip6-allnodes
eno1            1      ff01::1
...

Where ip6-allnodes is ff02::1

For z/OS

For an interface with addresses 2001:db8:8::f and 2001:DB8::0067:89ab
TSO NETSTAT DEVLINKS

IntfName: JFPORTCP6         IntfType: IPAQENET6  IntfStatus: Ready 
...
   Multicast Specific: 
     Multicast Capability: Yes
     Group:     ff02::1:ff67:89ab 
       RefCnt:  0000000001  SrcFltMd: Exclude 
       SrcAddr: None  
     Group:     ff02::1:ff00:4 
       RefCnt:  0000000001  SrcFltMd: Exclude 
       SrcAddr: None 
     Group:     ff02::1:ff00:9 
       RefCnt:  0000000001  SrcFltMd: Exclude 
       SrcAddr: None 
     Group:     ff02::1:ffa2:a2a2 
       RefCnt:  0000000001  SrcFltMd: Exclude 
       SrcAddr: None 
     Group:     ff01::1 
       RefCnt:  0000000001  SrcFltMd: Exclude 
       SrcAddr: None 
     Group:     ff02::1 
       RefCnt:  0000000001  SrcFltMd: Exclude 
       SrcAddr: None
  • ff02::1:ff67:89ab is a group for the address 2001:DB8::0067:89ab
  • ff02::1:ff00:9 is group for the address with 2001:db8:8::9
  • ff01::1 is for all nodes.

Issuing the first ping

I have a laptop connected to a server over Ethernet. The laptop had address 2001:7::1, and the server had IP address 2001:7::2. I defined a route from the laptop to the server

The first time an IP address 2001:7::2 was used on the laptop, there was a flow to all nodes ff02::1:ff, for address 2001:7::2, and a response from 2001:7::2

2001:7::1 ff02::1:ff00:2 ICMPv6 Neighbor Solicitation for 2001:7::2 from ...
2001:7::2 2001:7::1      ICMPv6	Neighbor Advertisement 2001:7::2 (sol, ovr) is at ...

This sends a request from 2001:7::1 to all routers asking “does any one have address 2001:7::2”. Device 2001:7::2 advertises to 2001:7::1 “I have the address”.

Understanding BT Smart hub 2 and my IPv6 addresses

As part of some work trying to get IPV6 to connect, I spent too much time understanding the various IP addresses in my configuration. By accident I found the magic incantation that allowed my z/OS on zD&T to talk to the outside internet.

Under the covers the BT Smart Hub 2 has a router called Arcadyan_ae. You will see this in a Wireshark trace. My IP addresses start with 2A00:23C5:… This belongs to BT. I’ve replace the address with BT:a:b:c .

This Blog post is referred to in Connecting a zPDT z/OS to the internet to using IPV6 and explains the various IPv6 addresses

My BT Smart Hub 2

You can display configuration information from the Smart Hub by using a web browser and address 192.168.1.254.

The Smart Hub IPv6 information.

This is password protected in the Advanced Settings.

There is a section IPv6 WAN details, this was not of interest.
The section IPv6 LAN details has

  • Link local address: fe80::6a2:22ff:feae:2871/64

For my Linux Server

the information in the BT Hub was

  • Device Name: Colins Server
  • Device Icon: None
  • Connection Status: Connected
  • IP address: 192.168.1.25 I think this came from my z/OS system running on the server!
  • MAC address: CC:64…:C5
  • Connection Type: Wireless
  • Address assignment: DHCP
  • Always using this address: YES
  • IPv6 Addressing:
    • GUA(Temporary): BT:a:b:c:2f3d:acdb Assigned by device
    • GUA (Permanent) :BT:a:b:c:7cd3:8993 Assigned by device
    • Link local address:fe80::…:8c80:37a4 Assigned by device

The IPv4 address (192.168.1.25) varied from day to day. During the day, it tended to be the same value. I could not find what caused it to change.

On my Linux server

The command ip addr gave

wlxcc641aee92c5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...
    link/ether cc:64:1a...:c5 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.25/24 brd 192.168.1.255 scope global dynamic noprefixroute wlxcc641aee92c5
       ...
    inet6 BT:a:b:c:7cd3:8993/64 scope global temporary dynamic 
       ...
    inet6 BT:a:b:c:2f3d:acdb/64 scope global dynamic mngtmpaddr noprefixroute 
       ...
    inet6 fe80::...:8c80:37a4 /64 scope link noprefixroute 
       ...

Where

  • the GUA (Permanent) is the same as the address with scope global temporary dynamic
  • the GUA (Temporary) is the same as the address with scope global dynamic mngtmpaddr noprefixroute
  • the Link local address is the same as the address with scope link noprefixroute. The word link gives it away.

Configure z/OS TCPIP Interface

I configured the interface like

 INTERFACE WIRE6 
     DEFINE IPAQENET6 
     CHPIDTYPE OSD 
     IPADDR  2001:DB7:8::1 
     PORTNAME PORTB 

 INTERFACE WIRE6 
     ADDADDR BT:a:b:c::1
 START WIRE6

This interface has addresses 2001:DB7:8::1 and BT:a:b:c::1. The value BT:a:b:c is the same as the high part of the Smart Hub’s Global unicast address: BT:a:b:c:6a2:22ff:feae:2871. The value BT:a:b:cuniquely identifies my Smart Hub2 router. Any device in the subarea below this router, must have the same top part. I picked address 1(::1).

The TSO NETSTAT HOME command gave

IntfName:   WIRE6 
  Address:  2001:db7:8::1 
    Type:   Global 
    Flags: 
  Address:  BT:a:b:c::1
    Type:   Global 
    Flags: 
  Address:  fe80::cc64:1a02:ee:92c5 
    Type:   Link_Local 
    Flags:  Autoconfigured

With the two addresses I configured, and an internally generated link local address.

The TSO NETSTAT ND gave

Query Neighbor cache for fe80::6a2:22ff:feae:2871 
  IntfName: WIRE6              IntfType: IPAQENET6 
  LinkLayerAddr: 04A222AE2871  State: Reachable 
  Type: Router                 AdvDfltRtr: Yes

Where fe80::6a2:22ff:feae:2871 is the IPv6 address of the router – see the top of this blog post.

Routing

My routing table did not need an IPv6 default entry because TCPIP can deduce it.

BEGINRoutes 
;     Destination   SubnetMask    FirstHop       LinkName  Size 
ROUTE 10.0.0.0    255.0.0.0           =          TAP0 MTU 1492 

ROUTE DEFAULT                    192.168.1.254   WIRE  MTU 1492
 
ENDRoutes

TSO NETSTAT ROUTE gave me

IPv6 Destinations 
DestIP:   Default 
  Gw:     fe80::6a2:22ff:feae:2871 
  Intf:   WIRE6             Refcnt:  0000000000 
  Flgs:   UGD               MTU:     1492 
               MTU:     65535 
DestIP:   2001:db7:8::1/128 
  Gw:     :: 
  Intf:   WIRE6             Refcnt:  0000000000 
  Flgs:   UH                MTU:     1492 
DestIP:   BT:a:b:c::/64 
  Gw:     :: 
  Intf:   WIRE6             Refcnt:  0000000000 
  Flgs:   UD                MTU:     1492 
DestIP:  aBT:a:b:c::1/128 
  Gw:     :: 
  Intf:   WIRE6             Refcnt:  0000000000 
  Flgs:   UH                MTU:     1492 
DestIP:   fe80::cc64:1a02:ee:92c5/128 
  Gw:     :: 
  Intf:   WIRE6             Refcnt:  0000000000 
  Flgs:   UH                MTU:     1492 

DestIP:   ::1/128 
  Gw:     :: 
  Intf:   LOOPBACK6         Refcnt:  0000000000 
  Flgs:   UH

Where the Default is the value in TSO NETSTAT ND, and is the IP address of the Smart Hub2 – see above.

PING

When I did a TCPIP PING to an IPv6 address,

  • the source was BT:a:b:c::1
  • the destination was 2a04:abcd::81

The first ping

The first ping had the following flows

  1. Ping the address
  2. The router does not know where the originating IP address came from, so it asks all devices connected to it – Does anyone have this IP address?
  3. Z/OS replies to the router saying “I’ve got that address”
  4. The router says “Here is some data for you

In more technically

  1. From BT:a:b:c::1 ping destination 2a04:abcd::81
  2. (From the router) Source Address: fe80::6a2:22ff:feae:2871 to all devices on the subnet (ff02::1:ff00:1) Neighbour Solicitation for BT:a:b:c::1
  3. (From z/OS) Source Address: fe80::cc64:1a03:ee:92c5 to the router (fe80::6a2:22ff:feae:2871) Neighbour Advertisement BT:a:b:c::1
  4. From 2a04:abcd::81 to BT:a:b:c :1 ping response


The second ping request went directly to z/OS because the BT Hub had learned where the IP address was.

Connecting a zPDT z/OS to the internet to using IPV6

I needed to get my ZD&T machine connected to the internet so it could download some files as part of an install. Note, this allows my z/OS to contact the internet, externals machines cannot contact my machine.

I blogged

It took a while to get it working. It is based on scenario 4 of the zD&T documentation.

The configuration uses the wireless connection from my Linux server.

You need to know/configure the address of various end points. Some addresses are configured by the systems, some addresses you need to configure.

Before you start

You need to know what the IP address of your z/OS image is

I used the GUA permanent address 

   INTERFACE WIRE6 
       DEFINE IPAQENET6 
       CHPIDTYPE OSD 

       IPADDR  2001:DB7:8::1 
       PORTNAME PORTB 

   INTERFACE WIRE6 
       ADDADDR BT:a:b:c:B8CE:404B:3360:3644 
   START WIRE6

What’s my TCP configuration on Linux?

The command ip addr gave (displaying only the IP V6 entries)

1: lo: <LOOPBACK,UP,LOWER_UP> ...    
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: eno1:...
    ...
   inet6 fe80::2d8:61ff:fee9:312a/64 scope link ... 
3: wlxcc641aee92c5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...
   
    inet6 BT:a:b:c:8b43:7ce6:34d1:c0fe/64 scope global temporary dynamic ... 

    inet6 BT:a:b:c:9824:30b:2f3d:acdb/64 scope global dynamic mngtmpaddr noprefixroute    ...
    inet6 fe80::7bfc:5da1:8c80:37a4/64 scope link noprefixroute ...
4: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc ...
    link/ether ...
     ...    
     inet6 fe80::48f6:deff:fef4:c8d4/64 scope link valid_lft forever preferred_lft forever

Where

  • lo is the loop back address.
  • eno1 is the connection over an Ethernet cable to my laptop
  • wlxcc641aee92c5 is the wireless connection to my router and the outside world. The IP address of the Linux server end is BT:a:b:c… . This value is used in the z/OS configuration.
  • tap0 is the tunnel interface to z/OS from the base linux machine. It has address fe80::48f6:deff:fef4:c8d4 This address is internal to the subnet.

I think these end point addresses were all generated for me.

My devmap

The devmap file contains the definitions of the emulated devices. For the OSA I had

[manager]  # tap0 define network adapter (OSA) for communication with Linux
name awsosa 0009 --path=A0 --pathtype=OSD --tunnel_intf=y   # QDIO mode
device 400 osa osa --unitadd=0
device 401 osa osa --unitadd=1
device 402 osa osa --unitadd=2

name awsosa 0010 --path=F1 --pathtype=OSD  --interface=wlxcc641aee92c5 
device 404 osa osa --unitadd=0
device 405 osa osa --unitadd=1
device 406 osa osa --unitadd=2
device 407 osa osa --unitadd=3
device 408 osa osa --unitadd=4
device 409 osa osa --unitadd=5

Where the –interface is the same name as my wireless interface (see above).

Find_io

The find_io command gives the network configuration known by the emulation code.

FIND_IO for "colin@colin-ThinkCentre-M920s" 
     Interface         Current     MAC   IPv4    IPv6           
Path Name              State       Addr  Addr    Address        
---- ----------------  ----------- ----  ------  -------------- 
F0   eno1              UP,RUNNING 00...  10....  fe80::2d8:61ff:fee9:312a%eno1  
F1   wlxcc641aee92c5   UP,RUNNING cc...  192.... BT:a:b:c:8b43:7ce6:34d1:c0fe

We have the same information as the ip addr command

The OSAs

In the devmap file the OSAs were defined as starting at 400 and 404. They each use 3 “wires”. One for reading, one for writing, and one for data (addresses 400, 401 and 402).

[manager]  # tap0 define network adapter (OSA) for communication with Linux
name awsosa 0009 --path=A0 --pathtype=OSD --tunnel_intf=y   # QDIO mode
device 400 osa osa --unitadd=0
device 401 osa osa --unitadd=1
device 402 osa osa --unitadd=2
device 403 osa osa --unitadd=3


name awsosa 0010 --path=F1 --pathtype=OSD  --interface=wlxcc641aee92c5 
device 404 osa osa --unitadd=0
device 405 osa osa --unitadd=1
device 406 osa osa --unitadd=2
device 407 osa osa --unitadd=3 
device 408 osa osa --unitadd=4
device 409 osa osa --unitadd=5
device 40a osa osa --unitadd=6

Where wlxcc641aee92c5 is the name of the wireless interface on Linux.

In the z/OS file ADCD.Z31B.VTAMLST(OSATRL2) is 

OSATRL1 VBUILD TYPE=TRL                                                 
OSATRL1E TRLE LNCTL=MPC,READ=(0400),WRITE=(0401),DATAPATH=(0402),      X
               PORTNAME=PORTA,                                         X
               MPCLEVEL=QDIO                                            
OSATRL2E TRLE LNCTL=MPC,READ=(0404),WRITE=(0405),DATAPATH=(0406,407),  X
               PORTNAME=PORTB,                                         X
               MPCLEVEL=QDIO

Where we have the same addresses 400 and 404.
You refer to these definitions using PORTA and PORTB.

PORTB uses data paths 0406 for the TCPIP IPv4 inerface, and 0407 for the IPv6 Interface.

You can use the VTAM command D NET,TRL to display the status of them

          d net,trl                                         
STC05323  IST097I DISPLAY ACCEPTED                          
STC05323  IST350I DISPLAY TYPE = TRL                        
------------------------------------------------------------
TRL MAJOR NODE = ISTTRL                                     
TRLE = IUTIQDIO  STATUS = NEVAC       CONTROL = MPC         
TRLE = IUTSAMEH  STATUS = NEVAC       CONTROL = MPC         
2 TRLE(S) DISPLAYED                                         
------------------------------------------------------------
TRL MAJOR NODE = OSATRL2                                    
TRLE = OSATRL1E  STATUS = ACTIV       CONTROL = MPC         
TRLE = OSATRL2E  STATUS = ACTIV       CONTROL = MPC

Define the TCP/IP interfaces

Current levels of TCP define interfaces with the “INTERFACE” statement. DEVICE and LINK statements are deprecated.

My wireless definitions ar 

                                                
 INTERFACE WIRE 
     DEFINE IPAQENET 
     CHPIDTYPE OSD 
     IPADDR 192.168.1.61 
     PORTNAME PORTB 
 START WIRE 

 INTERFACE WIRE6 
     DEFINE IPAQENET6 
     CHPIDTYPE OSD 
     IPADDR  BT:a:b:c::2 
     PORTNAME PORTB 
; INTERFACE WIRE6 
;    ADDADDR BT:a:b:c::1 

 START WIRE6

This defines both IPv4 and IPv6 interfaces, both using the same port PORTB

The interfaces are started

I chose these two addresses myself. These address show up in the NETSTAT HOME command.

After it has started

The TSO NETSTAT HOME command gave

Home address list: 
LinkName:   LOOPBACK 
  Address:  127.0.0.1 
    Flags: 
IntfName:   TAP0 
  Address:  10.1.1.2 
    Flags:  Primary 
IntfName:   WIRE 
  Address:  192.168.1.61 
    Flags: 
IntfName:   WIRE6 
  Address:  BT:a:b:c::2 
    Type:   Global 
    Flags: 
  Address:  fe80::cc64:1a02:ee:92c5 
    Type:   Link_Local 
    Flags:  Autoconfigured 
IntfName:   LOOPBACK6 
  Address:  ::1 
    Type:   Loopback 
    Flags:

Where we see the interfaces and their IP addresses.

Define the TCP Routes

I created COLIN.TCPPARMS(S5ROUTE) with content

BEGINRoutes 
;     Destination   SubnetMask    FirstHop       LinkName  Size 
ROUTE 10.0.0.0    255.0.0.0       10.1.1.1       TAP0 MTU 1492 
; Default to the internet
ROUTE DEFAULT                    192.168.1.254   WIRE  MTU 1492 
;ROUTE DEFAULT6  fe80::6a2:22ff:feae:2871        WIRE6  MTU 5000 
ENDRoutes

Note there is no DEFAULT6 entry – TCPIP works this out for itself. If you have more than one IPv6 interface you should uncomment the DEFAULT6 statement to ensure the traffic goes the right way.

I used the TCPIP console command v tcpip,,obey,COLIN.TCPPARMS(S5ROUTE) to activate the routing table. If you get it wrong, edit the member, save the changes, and issue the command again.

The TSO NETSTAT ROUTE command gave me

IPv4 Destinations 
Destination        Gateway         Flags    Refcnt     Interface 
-----------        -------         -----    ------     --------- 
Default            192.168.1.254   UGS      0000000000 WIRE 
10.0.0.0/8         0.0.0.0         US       0000000000 TAP0 
10.1.1.2/32        0.0.0.0         UH       0000000000 TAP0 
127.0.0.1/32       0.0.0.0         UH       0000000000 LOOPBACK 
192.168.1.61/32    0.0.0.0         UH       0000000000 WIRE 
IPv6 Destinations 
DestIP:   Default 
  Gw:     fe80::6a2:22ff:feae:2871 
  Intf:   WIRE6             Refcnt:  0000000000 
  Flgs:   UGD               MTU:     1492 
DestIP:   ::1/128 
  Gw:     :: 
  Intf:   LOOPBACK6         Refcnt:  0000000000 
  Flgs:   UH                MTU:     65535 
DestIP:   BT:a:b:c::/64 
  Gw:     :: 
  Intf:   WIRE6             Refcnt:  0000000000 
  Flgs:   UD                MTU:     1492 
DestIP:   BT:a:b:c::2/128 
  Intf:   WIRE6             Refcnt:  0000000000 
  Flgs:   UH                MTU:     1492 
DestIP:   fe80::cc64:1a02:ee:92c5/128 
  Gw:     :: 
  Intf:   WIRE6             Refcnt:  0000000000 
  Flgs:   UH                MTU:     1492

Where fe80::6a2:22ff:feae:2871 is from the BT Hub IPv6 LAN details: Link local address:.

The command TSO NETSTAT ND gives the neighbour discovery. This gave me

Query Neighbor cache for fe80::6a2:22ff:feae:2871 
  IntfName: WIRE6              IntfType: IPAQENET6 
  LinkLayerAddr: 04A222AE2871  State: Reachable 
  Type: Router                 AdvDfltRtr: Yes

Which shows what IPv6 neighbours have been discovered.

And finally – test it

I could use the TSO PING command to ping a server the internet. Check you can ping the address from Linux before you try it from z/OS, because some servers do not respond to ping requests.

Doing a wireshark trace of a successful ping showed the originator IP address was BT:a:b:c::2, the home address of interface WIRE6 in TCPIP on my z/OS image.

Connecting a zPDT z/OS to the internet using IPv4

I needed to get my ZD&T machine connected to the internet so it could download some files as part of an install. Note, while this allows my z/OS to contact the internet, externals machines cannot contact my machine.

As a follow-on to this Blog post I wrote Connecting a zPDT z/OS to the internet to using IPV6 which extends this post.

As usual there are many strands to this, so I wrote Understanding BT home hub and my IPv6 addresses to cover some of the background knowledge.

It took a while to get it working. It is based on scenario 4 of the zD&T documentation.

The configuration uses the wireless connection from my Linux server.

You need to know/configure the address of various end points. Some addresses are configured by the systems, some addresses you need to configure.

What’s my TCP configuration on Linux?

The command ip addr gave (displaying only the IP V4 entries)

1: lo: <...> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
   
2: eno1: <...> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:...
    altname enp0s31f6
    inet 10.1.0.3/24 brd 10.1.0.255 scope global eno1
       valid_lft forever preferred_lft forever 
   
3: wlxcc641aee92c5: <...> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether cc:...
    inet 192.168.1.139/24 brd 192.168.1.255 scope global dynamic noprefixroute wlxcc641aee92c5
       valid_lft 80179sec preferred_lft 80179sec
  noprefixroute 
       valid_lft 263sec preferred_lft 83sec
    inet6 fe80::7bfc:5da1:8c80:37a4/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
5: tap0: <...> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether 46:...
    inet 10.1.1.1/24 brd 10.1.1.255 scope global tap0
       valid_lft forever preferred_lft forever

Where

  • lo is the loop back address.
  • eno1 is the connection over an Ethernet cable to my laptop with the address (on this linux machine) 10.1.0.3. The address of the other end of the Ethernet, on my laptop, is 10.1.0.2
  • wlxcc641aee92c5 is the wireless connection to my router and the outside world. The IP address of the Linux server end is 192.168.1.139.
  • tap0 is the tunnel interface to z/OS from the base linux machine. It has address 10.1.1.1

I think these end point addresses were all generated for me.

Linux Settings

I believe that you need some Linux settings. Having repeated the scenario, it works even when the values described where set to 0, so the guidance in this section may not be relevant.

sysctl net.ipv4.ip_forward

to display the value. It needs to be 1. You can set it using

sudo sysctl -w net.ipv4.ip_forward=1
#sudo sysctl -w net.ipv6.conf.all.forwarding=1

You can do commands like

sysctl -a |grep v4
sysctl -a |grep v6

My devmap

The devmap file contains the definitions of the emulated devices. For the OSA I had

[manager]  # tap0 define network adapter (OSA) for communication with Linux
name awsosa 0009 --path=A0 --pathtype=OSD --tunnel_intf=y   # QDIO mode
device 400 osa osa --unitadd=0
device 401 osa osa --unitadd=1
device 402 osa osa --unitadd=2

name awsosa 0010 --path=F1 --pathtype=OSD  --interface=wlxcc641aee92c5 
device 404 osa osa --unitadd=0
device 405 osa osa --unitadd=1
device 406 osa osa --unitadd=2
device 407 osa osa --unitadd=3
device 408 osa osa --unitadd=4
device 409 osa osa --unitadd=5

Where the –interface is the same name as my wireless interface (see above).

When I used IPv6 as well as IPv4, there were two TCPIP Interface on the same OSA. I need address 406 and 407 for one interface, and 408 and 409 for the other interface. The TCPIP documentation does not say this.

Find_io

The find_io command gives the network configuration known by the emulation code.

FIND_IO for "colin@colin-ThinkCentre-M920s" 
                                                                                                
         Interface         Current          MAC    IPv4          IPv6           
 Path    Name              State            Addr   Address       Address        
------   ----------------  ---------------- ----   ------------- --------------   
  F0     eno1              UP, RUNNING      00:..  10.1.0.3      fe80::...%eno1  
  F1     wlxcc641aee92c5   UP, RUNNING      cc:..  192.168.1.139 2a00:... 
  A0     tap0              UP, RUNNING      46:..  10.1.1.1      fe80::...@tap0
  ...
   
 End of FIND_IO

This is the same information as the ip addr command

The OSAs

In the devmap file the OSAs were defined as starting at 400 and 404. One for reading, one for writing, and several for data.

In the z/OS VTAM file ADCD.Z31B.VTAMLST(OSATRL2) (below) defines two OSAs.

The first is for my Ethernet. This has one TCPIP Interface, and so paths 402 and 403 for the data.

The second is for the wireless connection. This has two TCPIP interfaces one for IPV4 and one for IPv6. One uses path (406,407), the other uses(408,409). These addresses must match the devmap definitions.

OSATRL1 VBUILD TYPE=TRL                                                 
OSATRL1E TRLE LNCTL=MPC,READ=(0400),WRITE=(0401),DATAPATH=(0402),      X
               PORTNAME=PORTA,                                         X
               MPCLEVEL=QDIO                                            
OSATRL2E TRLE LNCTL=MPC,READ=(0404),WRITE=(0405),DATAPATH=(0406,407),  X
               PORTNAME=PORTB,                                         X
               MPCLEVEL=QDIO


You refer to these definitions using PORTA and PORTB in the TCPIP interfaces

You can use the VTAM command D NET,TRL to display the status of them

          d net,trl                                         
STC05323  IST097I DISPLAY ACCEPTED                          
STC05323  IST350I DISPLAY TYPE = TRL                        
------------------------------------------------------------
TRL MAJOR NODE = ISTTRL                                     
TRLE = IUTIQDIO  STATUS = NEVAC       CONTROL = MPC         
TRLE = IUTSAMEH  STATUS = NEVAC       CONTROL = MPC         
2 TRLE(S) DISPLAYED                                         
------------------------------------------------------------
TRL MAJOR NODE = OSATRL2                                    
TRLE = OSATRL1E  STATUS = ACTIV       CONTROL = MPC         
TRLE = OSATRL2E  STATUS = ACTIV       CONTROL = MPC

Define the TCP/IP interfaces

Current levels of TCP define interfaces with the “INTERFACE” statement. DEVICE and LINK statements are deprecated.

My definitions for IPv4 are

 INTERFACE TAP0 
     DEFINE IPAQENET 
     CHPIDTYPE OSD 
     IPADDR 10.1.1.2 
     PORTNAME PORTA 
 START TAP0 
                                                 
 INTERFACE WIRE 
     DEFINE IPAQENET 
     CHPIDTYPE OSD 
     IPADDR 192.168.1.61 
     PRIROUTER 
     PORTNAME PORTB 
 START WIRE

This defines an interface TAP0 using the PORTA definitions above, and gives the z/OS end of the connection the address 10.1.1.2. From my laptop I can ping 10.1.1.2, it gets routed to the Linux server, and into z/OS.

The interface is started

Another interface WIRE is defined using PORTB and the z/OS end of the connection is 192.168.1.61

I chose these two addresses myself. These address show up in the NETSTAT HOME command.

After it has started

The TSO NETSTAT HOME command gave

MVS TCP/IP NETSTAT CS 3.1     
Home address list: 
LinkName:   LOOPBACK 
  Address:  127.0.0.1 
    Flags: 
IntfName:   TAP0 
  Address:  10.1.1.2 
    Flags:  Primary 
IntfName:   WIRE 
  Address:  192.168.1.61 
    Flags:

Where we see the interfaces and their IP addresses.

Define the TCP Routes

I created COLIN.TCPPARMS(S5ROUTE) with content

BEGINRoutes 
;     Destination   SubnetMask    FirstHop       LinkName  Size 
ROUTE 10.0.0.0    255.0.0.0       10.1.1.1       TAP0 MTU 1492 
ROUTE 192.168.1.0 255.255.255.0       =          WIRE  MTU 1492 
ROUTE DEFAULT                    192.168.1.254   WIRE  MTU 1492 
ENDRoutes

This says for the destination IP address if it is

  • anything beginning with 10. (from the subnet mask 255.0.0.0) send it over interface TAP0. The command ip addr shows tap0 with inet 10.1.1.1/24 brd 10.1.1.255
  • anything with address 192.168.1.something (from the subnet mask 255.255.255.0) sent it over interface WIRE (note: in this case this definition is redundant because of the default below).
  • anything else, send it down the DEFAULT definition over interface WIRE. The IP address of my wireless router is 192.168.1.254. Initially I had a different address – the address in the find_io. After several pings which timed out, ping worked. It is better to specify the address of the router/hub.

I used the TCPIP console command v tcpip,,obey,COLIN.TCPPARMS(S5ROUTE) to activate the routing table. If you get it wrong, edit the member, save the changes, and issue the command again.

The TSO NETSTAT ROUTE command gave me

IPv4 Destinations 
Destination        Gateway         Flags    Refcnt     Interface 
-----------        -------         -----    ------     --------- 
Default            192.168.1.254   UGS      0000000000 WIRE 
10.0.0.0/8         0.0.0.0         US       0000000000 TAP0 
10.1.1.2/32        0.0.0.0         UH       0000000000 TAP0 
127.0.0.1/32       0.0.0.0         UH       0000000000 LOOPBACK 
192.168.1.61/32    0.0.0.0         UH       0000000000 WIRE

And finally – test it

I could use the TSO PING command to ping a server the internet. Check you can ping the address from Linux before you try it from z/OS, because some servers do not respond to ping requests.

Useful commands

On Linux

  • ip addr
  • ip route

On z/OS

VTAM operator commands
  • D NET,TRL
  • d net,trl,trle=OSATRL2E This gives information such as which OSA data ports are being used, by with TCPIP interfaces.
  • D NET,ID=…
  • D NET,ID=…,E
  • V NET,ACT,ID=….
  • V NET,INACT,ID=….
TCPIP operator commands
  • v tcpip,,obey,… for example COLIN.TCPPARMS(S5ROUTE)

TSO commands

  • TSO NETSTAT HOME
  • TSO NETSTAT ROUTE
  • TSO PING x.x.x.x
  • TSO TRACERTE x.x.x.x

Some problems I experienced

A ping did not get a response back

A wireshark trace of the wireless interface showed the ping request had an originator IP address of 10.1.1.2. This was caused by having the wrong routing table 

MVS TCP/IP NETSTAT CS 3.1       TCPIP Name: TCPIP           17:10:28 
IPv4 Destinations 
Destination        Gateway         Flags    Refcnt     Interface 
-----------        -------         -----    ------     --------- 
Default            10.1.1.1        UGS      0000000000 TAP0 
10.0.0.0/8         0.0.0.0         US       0000000000 TAP0 
10.1.0.0/24        10.1.1.1        UGS      0000000000 TAP0 
10.1.1.2/32        0.0.0.0         UH       0000000000 TAP0 
127.0.0.1/32       0.0.0.0         UH       0000000000 LOOPBACK 
192.168.1.61/32    0.0.0.0         UH       0000000000 WIRE

The default routing was via TAP0

The NETSTAT HOME gave

 MVS TCP/IP NETSTAT CS 3.1       TCPIP Name: TCPIP       
 Home address list: 
 LinkName:   LOOPBACK 
   Address:  127.0.0.1 
     Flags: 
 IntfName:   TAP0 
   Address:  10.1.1.2 
     Flags:  Primary 
 IntfName:   WIRE 
   Address:  192.168.1.61 
     Flags:

So the IP address of the TAP0 interface was 10.1.1.2, and this was used as the originating end point.

Any nodes on the route to the destination do not know where 10.1.12 is located …. 10.*.*.* it is usually an address on the local machine, and so you get no response back.

With the address 192.168.1.xx the wireless router converts it to the router’s own address, and so the intermediate nodes on the journey can use the hub’s IP address, and the reply gets back to the wireless router.

Ping failed – nothing in wireshark

  INTERFACE WIRE 
     DEFINE IPAQENET 
     CHPIDTYPE OSD 
     IPADDR 192.168.1.60 
     PRIROUTER 
     VLANID  2 
     PORTNAME PORTB

I had VLANID 2 … when I removed this statement it worked.

Sessions failed to start

When I started TCPIP I got the message

EZZ4336I ERROR DURING ACTIVATION OF INTERFACE WIRE – CODE 8010002A DIAGNOSTIC CODE 02

Using the command D U,,,400,8 showed

UNIT TYPE STATUS        VOLSER     VOLSTATE      SS  
0400 OSA  A-BSY                                   0  
0401 OSA  A                                       0  
0402 OSA  A-BSY                                   0  
0403 OSA  O                                       0  
0404 OSA  OFFLINE                                 0  
0405 OSA  OFFLINE                                 0  
0406 OSA  OFFLINE                                 0  
0407 OSA  OFFLINE                                 0

This shows the second OSA was not available (it was offline). I found I had misconfigured the OSA with addresses (404, 405, and 406) in my devmap.

Not for humans but for search engines – Comms server

Below are messages I’ve experienced and my solutions

IST1578I DEVICE INOP DETECTED FOR … BY ISTTSCMA CODE = 104

and

EZZ4338I ERROR REPORTED ON INTERFACE … – CODE 80100040
DIAGNOSTIC CODE 03

I was trying to get IPV4 and IPV6 interfaces to work with one OSA.

With

OSATRL1 VBUILD TYPE=TRL 
OSATRL2E TRLE LNCTL=MPC,READ=(0404),WRITE=(0405),DATAPATH=(0406,407),  X
               PORTNAME=PORTB,                                         X
               PORTNUM=1,                                              X
               MPCLEVEL=QDIO

it produced the above messages

with

OSATRL1 VBUILD TYPE=TRL 
OSATRL2E TRLE LNCTL=MPC,READ=(0404),WRITE=(0405),DATAPATH=(0406,408),  X
               PORTNAME=PORTB,                                         X
               PORTNUM=1,                                              X
               MPCLEVEL=QDIO

so with two paths 406 and 408, instead of 406 and 407, it worked!

My zD&T devmap had 

name awsosa 0010 --path=F1 --pathtype=OSD  --interface=wlxcc641aee92c5 
device 404 osa osa --unitadd=0
device 405 osa osa --unitadd=1
device 406 osa osa --unitadd=2
device 407 osa osa --unitadd=3 
device 408 osa osa --unitadd=4
device 409 osa osa --unitadd=5
device 40a osa osa --unitadd=6

Where wlxcc641aee92c5 is my Linux wireless interface.
find_io gave me 

         Interface         Current    MAC         IPv4          IPv6           
 Path    Name              State      Address     Address       Address        
------   ----------------  ---------- ----------  -----------   -------------- 
...
  F1     wlxcc641aee92c5   UP, RUNNING cc:64:...  192.168.1.61  2a00:23c5:...