HERCPRT disconnects

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

HERCPRT disconnects

Hercules390 - Mvs mailing list
I was trying to configure HERCPRT 64bit to print output from z/os running under Hercules 3.12.
 The printer connects and I was able to get a few job outputs sent over as PDF.
 However, when the printer is idle for sometime it disconnects with no apparent reason and I need to manually reconnect it.
 Any idea why this happens ?
Reply | Threaded
Open this post in threaded view
|

RE: HERCPRT disconnects

Hercules390 - Mvs mailing list
Someone whose real name we don't know but whose email address is [hidden email] wrote:

Hello (whoever you are)!

HercPrt NEVER disconnects from Hercules once it is connected.

If HercPrt's connection to Hercules 3.12 is being terminated it is because Hercules 3.12 decided to specifically (purposely) do so.  Some device or piece of software on your network is likely not routing TCP/IP Keep Alive messages properly (or is filtering them or otherwise not responding to them).

(OR... you have a very unreliable connection!)

We know that HercPrt is running on Windows (since it's a Windows program! Duh!), but is the Hercules 3.12 that it's communicating with (spooling for) running under Windows or under Linux?

If your Herc 3.12 is running under Windows, then this is indeed strange since Windows supports TCP/IP Keep Alive.  Check your Windows Firewall rules.  There might be a bad rule that's causing the Keep Alive packets to get filtered (dropped).

If your Herc 3.12 is running under Linux, what version of which distribution?  Not all versions of all distributions support TCP/IP Keep Alive.  Yours might be one of them, in which case I can't help you; I'm not a Linux person.  But if this is the cause, then you need to find out how to add or configure or enable TCP/IP Keep Alive on your Hercules host system and then rebuild Hercules so that Keep Alive support gets properly enabled.

Note: I don't know much about Herc 3.12 either.  I have "my own" version of Hercules 4.0 Hyperion that I now support:

  https://github.com/Fish-Git/hyperion/blob/master/README.md


This is because I'm unfortunately no longer a Hercules developer:

  http://www.softdevlabs.com/news#donate


--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: [hidden email]


> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> Sent: Saturday, December 24, 2016 11:21 AM
> To: [hidden email]
> Subject: [H390-MVS] HERCPRT disconnects
> Importance: High
>
>
>
> I was trying to configure HERCPRT 64bit to print output from z/os
> running under Hercules 3.12.
>
> The printer connects and I was able to get a few job outputs sent over
> as PDF.
>
> However, when the printer is idle for sometime it disconnects with no
> apparent reason and I need to manually reconnect it.
>
> Any idea why this happens ?
>
>

Reply | Threaded
Open this post in threaded view
|

RE: HERCPRT disconnects

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
Fish wrote:

[...]
> If your Herc 3.12 is running under Windows, [...]
>
> If your Herc 3.12 is running under Linux, [...]

Another possibility is some device on your network (router, switch, etc) is filtering/dropping the TCP/IP Keep Alive packets.

Yet ANOTHER possibility is some type of specialized networking software/driver is filtering/dropping them.

BOTTOM LINE: your problem is not with HercPrt.  It's elsewhere.

--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: [hidden email]




Reply | Threaded
Open this post in threaded view
|

Re: HERCPRT disconnects

Hercules390 - Mvs mailing list
Hello,

 Thanks for the input.
 How frequently are these keep alive packets sent ?
 

 Dani Kalmar
 19 Hanegev street
 Yavne
 Israel
Reply | Threaded
Open this post in threaded view
|

Re: HERCPRT disconnects

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
Hello,

 Thanks for the input.
 How frequently are these keep alive packets sent ?
 

 Dani Kalmar
 

Reply | Threaded
Open this post in threaded view
|

Re: HERCPRT disconnects

Hercules390 - Mvs mailing list
Dani Kalmar wrote:

> Hello,
>
> Thanks for the input.
> How frequently are these keep alive packets sent ?

Hi Dani!

It's nice to have a first name I can address you by.  :)

By default, Keep Alive packets are sent every 10 seconds.

You can override their frequency and timeout values via the CONKPALV statement:

  https://fish-git.github.io/html/hercconf.html#CONKPALV


--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: [hidden email]




Reply | Threaded
Open this post in threaded view
|

Re: HERCPRT disconnects

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
Fish wrote:

[...]
> By default, Keep Alive packets are sent every 10 seconds.

Correction: every 1 second.  (Not 10)

You will be disconnected after 13 seconds if, once the probing begins, all 10 probes time out.

Thus if the original idle timeout is 3 seconds, you will be disconnected after 0:13 seconds: 3 + (10 * 1).

If you change the CONKPALV value to, say, "(5,15,10)", then you will be disconnected after 2:35 minutes: 5 seconds + 10 * 15 seconds = 155 seconds = 2:35).

As soon as any probe is responded to, the idle timeout resets, so under normal circumstances where probes are properly responded to, the probes occur every 3 seconds: your connection goes idle ... 3 seconds pass ... first probe is sent ... probe is properly responded to by the other end within 1 second ... another 3 seconds of idle time passes ... another probe is sent ... etc.

As long as each probe is properly responded to within 1 second, the connection remains open.

If the other end fails to respond to a probe within 1 second, another probe is sent.  If THAT probe also fails to be responded to within 1 second, then a third probe is sent, etc.  If, after 10 attempts, all 10 probes timeout, then you are disconnected (which, as explained, with default CONKPALV settings, will occur after a total of 13 seconds from the moment your connection goes idle).

--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: [hidden email]




Reply | Threaded
Open this post in threaded view
|

Re: HERCPRT disconnects

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
The connection to HERCPRT breaks after 10 minutes or more so I assume it is not a firewall issue. The emulator and Hercprt run on the same PC in my case.
 Is there any trace or debug info that can assist in figuring out why the connection breaks ?
 


Reply | Threaded
Open this post in threaded view
|

Re: HERCPRT disconnects

Hercules390 - Mvs mailing list
Does your printer have a time-out value where it puts itself into a
"sleep" mode?

You could also install one of the TCP-IP monitoring tools, it might shed
a clue or too.  "10 minutes" sounds to me like a device timeout of
somesort.  Some of them actually report to the user in "english" rather
than in TCP/IP lingo.

/s/ Bill Turner, wb4alm






On 12/25/2016 12:15 PM, [hidden email] [H390-MVS] wrote:
>
> The connection to HERCPRT breaks after 10 minutes or more so I assume
> it is not a firewall issue.
>
> The emulator and Hercprt run on the same PC in my case.
> Is there any trace or debug info that can assist in figuring out why
> the connection breaks ?
>
>


Reply | Threaded
Open this post in threaded view
|

Re: HERCPRT disconnects

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
[...]
> Is there any trace or debug info that can assist
> in figuring out why the connection breaks ?

Any network packet analyzer will do.  WireShark seems to be a popular free one:

  https://www.wireshark.org/
  https://en.wikipedia.org/wiki/Wireshark


Note however that WireShark can only capture packets from WIRED devices (hence its name), not wireless ones.  I am not aware of any free wireless packet analyzers.

--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: [hidden email]




Reply | Threaded
Open this post in threaded view
|

Re: HERCPRT disconnects

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
Bill Turner wrote:

> Does your printer have a time-out value where it puts
> itself into a "sleep" mode?

HercPrt is not a printer and neither is Hercules either.

But your comment did cause me think of something else that might be causing it, so thank you for that, Bill.

Most network adapters on Windows (both wired and wireless) have an option related to "power savings" (due to the popularity of battery operated devices these days).  Your network adapter might have this option enabled, causing it to drop into low-power power-saving mode thereby causing the keep-alive probes to be dropped (because your network adapter has effectively powered itself off).

That's just a guess, but it's yet another possibility.

Note too that other types of devices besides network adapters might also support a power-saving low-power mode too, so you might want to review such power related settings on each device as well as on your entire system too.

--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: [hidden email]




Reply | Threaded
Open this post in threaded view
|

Re: HERCPRT disconnects

Hercules390 - Mvs mailing list
Fish, I was thinking that the timeout was occurring between a real
printer and a "driver".  I forgot that HercPrt is an "emulated printer".
But you did catch the way I was thinking, and I also forgot that windows
loves to power down things that it thinks aren't be used anymore.
(Especially since I hardly ever use a WINDOWS system anymore.  It is so
easy now-a-days to forgot that the network adapter is a controllable
device...

Anyway, I hope that "kalda0912" can find his problem from my shotgun
approach to possible issues...

/s/ Bill


On 12/25/2016 01:04 PM, ''Fish' (David B. Trout)'
[hidden email] [H390-MVS] wrote:

>
> Bill Turner wrote:
>
> > Does your printer have a time-out value where it puts
> > itself into a "sleep" mode?
>
> HercPrt is not a printer and neither is Hercules either.
>
> But your comment did cause me think of something else that might be
> causing it, so thank you for that, Bill.
>
> Most network adapters on Windows (both wired and wireless) have an
> option related to "power savings" (due to the popularity of battery
> operated devices these days). Your network adapter might have this
> option enabled, causing it to drop into low-power power-saving mode
> thereby causing the keep-alive probes to be dropped (because your
> network adapter has effectively powered itself off).
>
> That's just a guess, but it's yet another possibility.
>
> Note too that other types of devices besides network adapters might
> also support a power-saving low-power mode too, so you might want to
> review such power related settings on each device as well as on your
> entire system too.
>
> --
> "Fish" (David B. Trout)
> Software Development Laboratories
> http://www.softdevlabs.com
> mail: [hidden email]
>

Reply | Threaded
Open this post in threaded view
|

Re: HERCPRT disconnects

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
Based on what was said, I changed the IP address to 127.0.0.1 and the printer no longer disconnects from the emulator. Thanks.
Reply | Threaded
Open this post in threaded view
|

Re: HERCPRT disconnects

Hercules390 - Mvs mailing list
Dani Kalmar wrote:

> Based on what was said, I changed the IP address to 127.0.0.1
> and the printer no longer disconnects from the emulator.
> Thanks.

You're very welcome, Dani.

I would like to thank YOU in return for letting us know how you personally resolved it.  That's good information to know.

Now when someone else reports the same or similar problem I know what to tell them.  :)

Have a safe and pleasant holiday season!

--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: [hidden email]




Reply | Threaded
Open this post in threaded view
|

Re: HERCPRT disconnects

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
Hi,
 

---In [hidden email], <david.b.trout@...> wrote :
 Note however that WireShark can only capture packets from WIRED devices (hence its name), not wireless ones. I am not aware of any free wireless packet analyzers.
 

Are you sure about that ? I always thought that wireshark on windows (well, really winpcap or its successor npcap) is able to capture wifi traffic: just not in 'promiscuous mode'. So you can capture wifi traffic, as long as the traffic you want to capture is send from or destined for the host your capturing on. of course, i could be wrong.



- Maarten



Reply | Threaded
Open this post in threaded view
|

Re: HERCPRT disconnects

Hercules390 - Mvs mailing list
Maarten wrote:
> Fish wrote :
>
> > [...]
> > Note however that WireShark can only capture packets
> > from WIRED devices (hence its name), not wireless ones.
> > I am not aware of any free wireless packet analyzers.
>
> Are you sure about that?

100%


> I always thought that wireshark on windows (well, really
> winpcap or its successor npcap) is able to capture wifi
> traffic: just not in 'promiscuous mode'.

Nope.  WireShark/WinPCap can only capture 802.3 Ethernet.  Wireless is 802.11.  They are NOT the same and the network devices for each are completely different and incompatible from one another:

  https://en.wikipedia.org/wiki/IEEE_802.3
  https://en.wikipedia.org/wiki/IEEE_802.11


> So you can capture wifi traffic, as long as the traffic you
> want to capture is send from or destined for the host you're
> capturing on.  Of course, I could be wrong.

You are.  :)

What you are in fact capturing are "fake" Ethernet packets: 802.11 user data packets (e.g. TCP/IP, etc) with "fake" 802.3 Ethernet headers constructed from the 802.11 headers.

Further, you are only capturing packets being sent specifically to/from that device but not any other traffic to/from other devices on your network.  The only way to see that traffic (which is what is REQUIRED for Hercules networking to function) is to enable "monitoring mode" (which is similar to promiscuous mode in concept but is actually quite different).

It's been quite a while since I last looked into this issue but basically the problem is there is (or was at the time I last looked into it; it looks like things might be different today so I might have to re-research this issue again) not only no way to *capture* 802.3 packets on the 802.11 wireless adapter device you are sniffing on that are being transmitted to stations OTHER THAN the one you are capturing on, NOR is there any way (at the time I last looked into it) any way to SEND (inject) 802.3 packets via the 802.11 wireless device you are sniffing on such that they get properly converted to (and transmitted as) 802.11 wireless packets that *appear* to have come from some other networking device.

And BOTH of those requirements are essential for Hercules networking to function: you need to be able to both send AND receive packets going TO, and coming FROM, devices DIFFERENT from the one being used for Hercules network device emulation (i.e. different from the adapter you are "sniffing" on and "injecting through").  At the time I last looked into this issue there did not exist any type of software/driver that would allow a program to so that.

But as I said things might be different today, I don't know.

What I *do* know is CTCI-WIN -- which uses WinPCap -- does not work on wireless devices due to the reasons previously stated: wireless devices automatically filter out all packets which aren't "theirs" (unless placed into "monitor mode" of course), which essentially breaks CTCI-WIN and thus Hercules networking on Windows.

If anyone out there knows different or has any information to the contrary then PLEASE let me know.  I'm experienced in such issues but am far from being an expert.  I could be very wrong.

HTH

--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: [hidden email]




Reply | Threaded
Open this post in threaded view
|

Re: HERCPRT disconnects

Hercules390 - Mvs mailing list
Hi,

well, that clears things up. what i got from that (too long, didn't read
TL;DR ;) :

- winpcap/npcap wifi might be able 'under circumstances' to capture the
traffic that's meant for the device/host its capturing on, but...
- CTCI-WIN *requires* to capture traffic that is not explicitly meant for
the host, 'promiscuous mode' which is not available on windows due to
hardware/driver restrictions.


- Maarten




On Tue, Dec 27, 2016 at 9:08 PM, ''Fish' (David B. Trout)'
[hidden email] [H390-MVS] <[hidden email]> wrote:

>
>
> Maarten wrote:
> > Fish wrote :
> >
> > > [...]
> > > Note however that WireShark can only capture packets
> > > from WIRED devices (hence its name), not wireless ones.
> > > I am not aware of any free wireless packet analyzers.
> >
> > Are you sure about that?
>
> 100%
>
> > I always thought that wireshark on windows (well, really
> > winpcap or its successor npcap) is able to capture wifi
> > traffic: just not in 'promiscuous mode'.
>
> Nope. WireShark/WinPCap can only capture 802.3 Ethernet. Wireless is
> 802.11. They are NOT the same and the network devices for each are
> completely different and incompatible from one another:
>
> https://en.wikipedia.org/wiki/IEEE_802.3
> https://en.wikipedia.org/wiki/IEEE_802.11
>
> > So you can capture wifi traffic, as long as the traffic you
> > want to capture is send from or destined for the host you're
> > capturing on. Of course, I could be wrong.
>
> You are. :)
>
> What you are in fact capturing are "fake" Ethernet packets: 802.11 user
> data packets (e.g. TCP/IP, etc) with "fake" 802.3 Ethernet headers
> constructed from the 802.11 headers.
>
> Further, you are only capturing packets being sent specifically to/from
> that device but not any other traffic to/from other devices on your
> network. The only way to see that traffic (which is what is REQUIRED for
> Hercules networking to function) is to enable "monitoring mode" (which is
> similar to promiscuous mode in concept but is actually quite different).
>
> It's been quite a while since I last looked into this issue but basically
> the problem is there is (or was at the time I last looked into it; it looks
> like things might be different today so I might have to re-research this
> issue again) not only no way to *capture* 802.3 packets on the 802.11
> wireless adapter device you are sniffing on that are being transmitted to
> stations OTHER THAN the one you are capturing on, NOR is there any way (at
> the time I last looked into it) any way to SEND (inject) 802.3 packets via
> the 802.11 wireless device you are sniffing on such that they get properly
> converted to (and transmitted as) 802.11 wireless packets that *appear* to
> have come from some other networking device.
>
> And BOTH of those requirements are essential for Hercules networking to
> function: you need to be able to both send AND receive packets going TO,
> and coming FROM, devices DIFFERENT from the one being used for Hercules
> network device emulation (i.e. different from the adapter you are
> "sniffing" on and "injecting through"). At the time I last looked into this
> issue there did not exist any type of software/driver that would allow a
> program to so that.
>
> But as I said things might be different today, I don't know.
>
> What I *do* know is CTCI-WIN -- which uses WinPCap -- does not work on
> wireless devices due to the reasons previously stated: wireless devices
> automatically filter out all packets which aren't "theirs" (unless placed
> into "monitor mode" of course), which essentially breaks CTCI-WIN and thus
> Hercules networking on Windows.
>
> If anyone out there knows different or has any information to the contrary
> then PLEASE let me know. I'm experienced in such issues but am far from
> being an expert. I could be very wrong.
>
> HTH
>
> --
> "Fish" (David B. Trout)
> Software Development Laboratories
> http://www.softdevlabs.com
> mail: [hidden email]
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: HERCPRT disconnects

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
Apologies.  I appear to have unintentionally morphed the topic from using WireShark to sniff for TCP/IP KeepAlive traffic into one related to CTCI-WIN and Hercules networking in general.  My bad.  A more proper response it below:


Maarten wrote:

> Are you sure about that? I always thought that wireshark
> on windows (well, really winpcap or its successor npcap)
> is able to capture wifi traffic: just not in 'promiscuous
> mode'.

Well...  Refer to my previous [morphed topic] reply regarding this claim.  :)


> So you can capture wifi traffic, as long as the traffic
> you want to capture is sent from or destined for the host
> your capturing on.

While not necessarily *technically* correct you are indeed essentially correct at least in spirit.  If I remember correctly WireShark does indeed allow you to sniff traffic on a wireless adapter, but as both you and I have explained, you can only do so for traffic sent specifically to/from that device.

But since within the original context of this thread (HercPrt disconnects and my theory regarding keep-alive packets being dropped/filtered as being one of the possible causes), such traffic is actually the only traffic we happen to be interested in!

So yeah, in this particular specific case, using WireShark might actually work.  It should in fact (at least in theory) allow us to see whether any keep-alive packets are being sent/received to/from (between) HercPrt and Hercules.


> Of course, I could be wrong.

Some technical aspects are wrong yes, but in actuality you are essentially correct, yes.

My apologies for getting off topic in my previous reply.

--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: [hidden email]




Reply | Threaded
Open this post in threaded view
|

Re: HERCPRT disconnects

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
Maarten wrote:

[...]
> TL;DR ;) :

Completely understandable.  :)

I *do* tend to "ramble" sometimes, don't I?  Sorry about that.  :)


> - winpcap/npcap wifi might be able 'under circumstances' to
> capture the traffic that's meant for the device/host its capturing
> on, but...
> - CTCI-WIN *requires* to capture traffic that is not explicitly
> meant for the host, 'promiscuous mode' which is not available on
> windows due to hardware/driver restrictions.

That's essentially it, yes.

p.s. npcap looks quite interesting.  I'm not sure yet but it may be the answer we've been looking for.  I'll have to research it further when I find time.  Thanks for mentioning it!

--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: [hidden email]




Reply | Threaded
Open this post in threaded view
|

Re: HERCPRT disconnects

Hercules390 - Mvs mailing list
In reply to this post by Hercules390 - Mvs mailing list
On 27 December 2016 at 15:08, ''Fish' (David B. Trout)'
[hidden email] wrote:
> What you are in fact capturing are "fake" Ethernet packets: 802.11 user data packets
> (e.g. TCP/IP, etc) with "fake" 802.3 Ethernet headers constructed from the 802.11
> headers.

OK. Running Wireshark on this Windows 7 laptop, connected only via
WiFi, I do see what look like Ethernet packets containing my data.
(This isn't Hercules - just routine Windows traffic.) So what you
haven't made clear is *who* creates these fake headers...? Is
Wireshark silently making them up? If so, why? Why not report reality?
Or is it some Windows component, or the WiFi driver? Or something
else?

Tony H.
12