开云体育

Hello Harold,

Am 23.01.2021 um 16:48 schrieb Harold Grovesteen <h.grovsteen@...>:

Well, here is the issue. You can not separate VTAM and the Linux side of things from Hercules. That is because everything has to travel through Hercules using a device driver.

I see.

You will definitely need to use bridging from the Ethernet adapter to the tap interface.

I found a bit more information about that topic, so I came up with a mix of old brctl (being superseded by the bridge command from badly documented iproute commands):

# Adding the bridge interface
brctl addbr br0

# Preparing otherwise unused eth0: Setting it up/running, add to bridge, set state to forwarding
ifconfig eth0 up
brctl addif br0 eth0
bridge link set dev eth0 state 3

# Preparing tap0: Setting it up/running, add to bridge, set state to forwarding
ifconfig tap0 up
brctl addif br0 tap0
bridge link set dev tap0 state 3

The latter *must* be done after Hercules start (because before, there’s no tap0), and before IPL, so the tap interface also signals ?up“ into Hercules itself.

Output of bridge link show:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 4
11: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 100

I guess, this *should* do it. Because, with tcpdump -i tap0, I see packets from LAN. :-)

Bridging avoids that. That will get your SNA Ethernet frame from the network to Hercules.

Yap.

I believe you have gotten to the point of simply trying it and see what happens. VTAM will certainly tell you if it does not like the definition for the device.

Therefore I need to learn a *lot* more about VTAM. :-)

Before trying anything, I applied the change regarding a missing interrupt handler as laid out in the ?New User's Cookbook“. It required changing the parmlib member IECIOS00:

MIH TIME=00:00,DEV=(E40-E41)

I verified successfully that it works after the next IPL, with D IOS,MIH,DEV=(E40-E41):

0E40=00:00, 0E41=00:00.

(E40 is the Hercules defined LCS with a defined OAT, redirecting SNA traffic to Port 0.)

A predefined XCAE40E has this comment:

3172 (LSAPLAN) ETHERNET ADAPTER1 (E40)

and contains this port definition (wrapped to be on one line for the sake of readability in this mail):

XPE40E PORT CUADDR=E40,ADAPNO=0,SAPADDR=4,MEDIUM=CSMACD,DELAY=0,TIMER=30

shows an error after activation:

IST1023E START I/O TIMEOUT OCCURRED FOR CUA=0E40

Until it is happy with that, it will not function. If you can not get past that, then VTAM is not going to do anything with the data it presumably would receive from the Hercules LCS device driver.

Hmm. Should VTAM *send* any data by just activating a PORT, GROUP, LINE, and PU? I haven’t seen anything with tcpdump at activation time so far.

Some Hercules I/O tracing may give you an idea whether the data is getting to the Hercules guest from the host. It will definitely let you know whether VTAM is actually doing anything with the device. But, again, you will need VTAM to be happy with the configuration before it will do that.

I guess, this START I/O TIMEOUT mentioned above constitutes as ?VTAM is not happy“. Correct?

Hope that is of some help.

Yes, thanks a lot! If you have more ideas what to check (and maybe how), I’d be happy to know. I definitely will document my efforts after reaching a point of actual function, or of ?does not work because…“.

:wq! PoC

On Fri, 2021-01-22 at 21:48 +0100, Patrik Schindler wrote:

Hello David,

Am 22.01.2021 um 19:26 schrieb Fish Fish <david.b.trout@...>:

I wonder who else might have some more insight about this topic.
Someone skilled in Linux (tap devices, bridging) and VTAM
configuration, I guess.

:wq! PoC

Well, here is the issue. You can not separate VTAM and the Linux side
of things from Hercules. That is because everything has to travel
through Hercules using a device driver.

You will definitely need to use bridging from the Ethernet adapter to
the tap interface. Otherwise the Linux IP interface will get involved
with either TAP or TUN which forces only IP packets in either case.
Bridging avoids that. That will get your SNA Ethernet frame from the
network to Hercules.

I believe you have gotten to the point of simply trying it and see what
happens. VTAM will certainly tell you if it does not like the
definition for the device. Until it is happy with that, it will not
function. If you can not get past that, then VTAM is not going to do
anything with the data it presumably would receive from the Hercules
LCS device driver.

Some Hercules I/O tracing may give you an idea whether the data is
getting to the Hercules guest from the host. It will definitely let
you know whether VTAM is actually doing anything with the device. But,
again, you will need VTAM to be happy with the configuration before it
will do that.

Hope that is of some help.

Harold Grovesteen

Hi

it looks like that is the code for the MTS distribution (if you play around with MTS you have it installed).? I don't know what it would take to make it run on MVS 3.8j.
--
Marco Antoniotti
Somewhere over the rainbow

Hello David,

Am 22.01.2021 um 19:26 schrieb Fish Fish <david.b.trout@...>:

You're very welcome, Patrik! And again, I apologize for my earlier misleading claim. As I said, it's been a long time since I poked my nose into Hercules's LCS code.

No worries. :-) I perfectly understand that a single person can’t know every detail about a project that huge, and as long existing as Hercules is. So, thanks for your confirmation that at least it’s not the routing code, *if* there is actually something missing in the code.

I wonder who else might have some more insight about this topic. Someone skilled in Linux (tap devices, bridging) and VTAM configuration, I guess.

:wq! PoC

Patrik Schindler wrote:

[...]

I had a look at ctc_lcs.c of the latest official released
Hyperion, but I’m not programmer enough to fully understand
what might be missing there.

I am a Hercules developer and have done quite a bit of work on Hercules's LCS device logic over the years, but I unfortunately also know virtually *nothing* about SNA and therefore am in no position to understand what might be missing either!

But as far as I’ve seen, in line 2200, there is a commented
statement:

// "CTC: lcs device port %2.2X: SNA frame received“

Do I understand correctly that so far, the port should have been
found by then?

Yes. Looking at the code a bit more closely, it appears I was wrong in my original reply. Apparently Hercules *does* support the "SNA" OAT file keyword and *will* apparently "route" any SNA Ethernet frames that are received to the specified LCS SNA port. I apologize for the misinformation. It's been a long while since I've messed with LCS code. These days I use QETH/OSA devices.

Especially given the fact that in the OAT you can kind of hard
code the port to SNA?

Correct. Again I apologize for my original misinformation.

But as I said further above in my opening remarks, not being familiar with SNA, I cannot tell you what else, if anything, might still be missing (might still be needed) in Hercules's LCS device code either, so *technically* the statement "Note: the SNA operation mode is not currently implemented" is, *presumably*, still accurate.

In addition, ?LCS doesn’t support SNA“ raises follow-up question:
Does QETH handle SNA?

Not as far as I know, no.

Thanks for your help!

You're very welcome, Patrik! And again, I apologize for my earlier misleading claim. As I said, it's been a long time since I poked my nose into Hercules's LCS code.

Take care.

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

On Fri, 2021-01-22 at 12:09 +0100, Patrik Schindler wrote:

Does QETH handle SNA?

No. QETH is strictly IP as implemented by Hercules and Linux even on a
physical mainframe. Certain proprietary program products can provide
additional support via a true QDIO network device within Linux but is
not emulated by Hercules for the most obvious of reasons: no
documentation or code.

:wq! PoC

Harold Grovesteen

Hello David,

Am 22.01.2021 um 03:12 schrieb Fish Fish <david.b.trout@...>:

Or perhaps a better way to say it is, while ETHERNET is indeed protocol-agnostic, LCS devices are NOT. :)

They (LCS devices) need to be able to recognize and parse IP packets to extract the destination IP address so it can know which LCS "port" to deliver the Ethernet frame to. Same goes with SNA. And as documented, no one has bothered to add support to Hercules for recognizing/routing SNA packets.

Is that maybe a little clearer?

Thanks a *lot*! This is indeed very helpful to understand the issue at hand.

I had a look at ctc_lcs.c of the latest official released Hyperion, but I’m not programmer enough to fully understand what might be missing there. But as far as I’ve seen, in line 2200, there is a commented statement:

// "CTC: lcs device port %2.2X: SNA frame received“

Do I understand correctly that so far, the port should have been found by then? Especially given the fact that in the OAT you can kind of hard code the port to SNA?

In addition, ?LCS doesn’t support SNA“ raises follow-up question: Does QETH handle SNA?

Thanks for your help!

:wq! PoC

Hello Scott,

Am 22.01.2021 um 03:33 schrieb Scott Stillwell via groups.io <scottstillwell@...>:

SNA uses the SAP (Service Access Point) code of 04 in the 802.2 frame (SSAP/DSAP), and yeah, not everything supports being able to manipulate packets at that level.

Yap. As far as I’m aware, the 802.2 layer in the Linux kernel itself is implemented only to the extent that more common protocols like IP, IPv6, IPX, DECNet and AppleTalk can function.

It was a pain to write, but I giggled like a madman when I finally got it working…

I can easily imagine. :-)

:wq! PoC

Another way to see it is that SNA on Ethernet PHY is usually at 802.2 frame level and not 802.3 like TCP/IP is.

SNA uses the SAP (Service Access Point) code of 04 in the 802.2 frame (SSAP/DSAP), and yeah, not everything supports being able to manipulate packets at that level. Back in the day when I wrote PC programs to interface via SNA/APPN with AS/400 systems, you didn’t have that network support unless you had the appropriate drivers installed that came along with the 5250 client access suite. Thankfully there was also a slightly higher-level API to open SNA sessions…but you had to use x86 assembly (and write it as a TSR program so I could call into it from my application code)

It was a pain to write, but I giggled like a madman when I finally got it working…

Scott

Fish wrote:

Patrik Schindler wrote:

As far as I know, Ethernet is protocol-agnostic.

Correct. But the way LCS devices are designed...

Or perhaps a better way to say it is, while ETHERNET is indeed protocol-agnostic, LCS devices are NOT. :)

They (LCS devices) need to be able to recognize and parse IP packets to extract the destination IP address so it can know which LCS "port" to deliver the Ethernet frame to. Same goes with SNA. And as documented, no one has bothered to add support to Hercules for recognizing/routing SNA packets.

Is that maybe a little clearer?

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

Patrik Schindler wrote:

I’m a bit confused by this text snippet, taken from


[LCS]

"Rather than a point-to-point link this emulation creates a virtual
Ethernet adapter through which the guest operating system running
in the Hercules Machine can communicate. As such this mode is not
limited to TCP/IP traffic but will in fact handle any Ethernet frame.
Please note that the SNA mode is currently not implemented."

Is there some more precise information about this claim and its origin?

As far as I know, Ethernet is protocol-agnostic.

Correct. But the way LCS devices are designed (or more specifically, the way LCS devices are implemented in Hercules), Hercules needs to be able to recognize SNA packets so it can deliver them to the proper LCS port:




HTH!

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

Dear fellow readers,

I’m a bit confused by this text snippet, taken from

[LCS]
Rather than a point-to-point link this emulation creates a virtual Ethernet adapter through which the guest operating system running in the Hercules Machine can communicate. As such this mode is not limited to TCP/IP traffic but will in fact handle any Ethernet frame. Please note that the SNA mode is currently not implemented.

Is there some more precise information about this claim and its origin? As far as I know, Ethernet is protocol-agnostic.

Thanks!

:wq! PoC

Hello Rahim,

thanks for your hints.


Am 21.01.2021 um 20:32 schrieb Rahim Azizarab via groups.io <rahimazizarab@...>:

It is not running, but it is almost there.

Are you talking about yourself?

You may want to search TUN/TAP; and ARP.

This is a very broad topic. Tun is a point-to-point interface and does not utilize ARP at all. May I ask for more details what exactly you’re referring to?

I think you need to start ARP which assigns the MAC address.

ARP does not assign any MAC. Maybe you want to read

There is write up for it on the internet.

openvpn --mktun --dev tun0 --group hercules
ifconfig tun0 192.168.2.65 pointopoint 10.0.0.33
echo 1 >/proc/sys/net/ipv4/ip_forward

As Grant already said, this is for tun only, not for tap. And you don’t need to install openvpn for that. The same goal can be achieved with already system provided tools.

/sbin/ip tuntap add group hercules

I’ve this one already running. :-)

sudo tunctl -u rahim -p
sudo ifconfig tap0 192.168.122.2 up
sudo route add -host 192.168.122.2 dev tap0
sudo bash -c 'echo 1 > /proc/sys/net/ipv4/conf/tap0/proxy_arp'
sudo arp -Ds 192.168.122.2 tap0 pub
sudo echo "1" > /proc/sys/net/ipv4/conf/tap0/forwarding

I’m not primarily interested in running IP over TAP, but raw ethernet frames (802.2 DLC).

Besides that, I’ve never really understood how proxy arp configuration works within Linux. It’s easier with Cisco IOS. :-)

:wq! PoC

Drive by comment.

On 1/21/21 12:32 PM, Rahim Azizarab via groups.io wrote:

openvpn --mktun --dev tun0 --group hercules
??? ifconfig tun0 192.168.2.65 pointopoint 10.0.0.33
??? echo 1 >/proc/sys/net/ipv4/ip_forward

The tun0 device above is not the same as the tap0 device below.

sudo tunctl -u rahim -p
sudo ifconfig tap0 192.168.122.2 up
sudo route add -host 192.168.122.2 dev tap0
sudo bash -c 'echo 1 > /proc/sys/net/ipv4/conf/tap0/proxy_arp'
sudo arp -Ds 192.168.122.2 tap0 pub
sudo echo "1"? > /proc/sys/net/ipv4/conf/tap0/forwarding

--
Grant. . . .
unix || die

Hello Rahim,

Am 21.01.2021 um 15:28 schrieb Rahim Azizarab via groups.io <rahimazizarab@...>:

A TAP connection would be an LCS adaptor.

Yap. Do you have an actual running example?

I added an LCS device to hercules.cnf per configuration settings gleaned from the installation, (?VTAM 3172 emulation“) without further parameters.

After firing up Hercules, but before OS IPL, I created a bridging device to connect the hercules-made tap0 to eth0 (an unused NIC in the machine, so I fire it up with ifconfig to have it in running state).

brctl addbr br0
ifconfig eth0 up
brctl addif br0 eth0 tap0

May I ask you for confirmation about that the Linux side seems right?

In VTAM one would need some thing like the following in VTAMLST.

Thanks! I’m not yet this far. I see there is already an example (?) configuration for a type XCA.

:wq! PoC

Dear readers,

did somebody successfully configure VTAM on MVS or successors to actually make a connection via 802.2 DLC over a TAP device in Linux, bridged to a physical NIC? Maybe to an MS SNA server for a start. If yes, I’d appreciate a pointer to a how-to or other documentation.

I’m specifically *not* talking about EE.

(Aside from ?learn VTAM“, which is a very broad topic and a bit too generic for my question. :-) )

Thanks!

:wq! PoC