5 Replies Latest reply on Sep 27, 2016 8:41 AM by Matt Dermody

    Telnet emulator session block

    Rookie

      Hello,

       

      Our warehouse logistics are handled through an internal ERP application ensuring a proper flow of the reception and distribution of auto parts.

      For this purpose we use around 110 mobile terminals with barcode scanners (RF Guns) of which 50 are deployed in the central warehouse.

       

      The models used are:

      Motorola MC2100

      Datalogic Falcon X3

      Datalogic Skorpio

       

      In the central warehouse we are currently using 50 Motorola MC2100 scanners with Windows CE 6.0 operating system. As an emulator we are using Wavelink Corporation’s Telnet version 7.3.63 for Motorola MC2100 terminals.

      Lately, the following problem began to manifest itself:

      On a daily basis every Motorola MC2100 device suffers one or more unexplainable telnet session blocks.

      When this happens, the terminal cannot interact with the application any more, the keyboard stops working and after a few minutes the display shows the "disconnected session" message. The terminal’s log doesn’t record any loss of connection to the access point.

      The Access Points are all newly acquired from Motorola in order to ensure maximum compatibility between them and the mobile terminals.

       

      Our question is:

      To what extent the Telnet emulator may influence these session blocks, taking into account the following:

      1. Telnet version

      2. Certain parameters of the telnet configuration

      3. “Avalanche Enable” configuration – we are using the Avalanche platform version 5.3.0.572 to manage our terminals

      4. Having a large number of sessions (high load) on an Access Point.

       

      Can you please help us with any idea in tackling this problem? Is there a log monitoring tool that can help us to identify the cause of these problems?

      The situation is very critical and this seriously influences the process of delivery and reception of goods.

       

      Thank you,

       

      Florian Baloi

      FlorianBaloi@augsburg.ro

        • 1. Re: Telnet emulator session block
          Matt Dermody SSMMVPGroup

          Florian,

           

          For starters I would make sure that you are updated to the latest version of the Fusion radio driver on those devices. You can build an avalanche package to push down the Fusion installer cab and run the installer for you. It would also be a good idea to confirm that the latest Firmware version is running on your devices.

           

          To what extent the Telnet emulator may influence these session blocks, taking into account the following:

          1. Telnet version - From the looks of it you have the latest TelnetCE version for that particular device. With that being said, the MC2100 is not a very common device in the industry and thus, Wavelink has not produced as regular of software updates for it as they have for say the MC92N0 or WT41N0 series devices (release dates of 2011 vs 2015). Its possible that you're encountering a bug that Wavelink has fixed in more recent releases of TelnetCE for other Moto devices, just not for your MC2100. If that is the case you'll need to open a support case with Wavelink as they may need to escalate to engineering.

          2. Certain parameters of the telnet configuration - If you are using SSH connections instead of Telnet then you may be experiencing some form of SSH based lock. Maybe your SSH keys are expiring, or your using a loadbalancer and the SSH idle timeout is set to short.

          3. “Avalanche Enable” configuration – The enabler acts totally independent of your TelnetCE client and connections and therefore I think can be eliminated as a potential culprit.

          4. Having a large number of sessions (high load) on an Access Point. - Highly unlikely scenario. You're using the wireless infrastructure to basically send small packets of text information back and forth between the devices and your host application server. Industrial wireless networks can handle enormous amount of this kind of traffic without bogging down. While I doubt this issue is due to a high load on an individual AP it could be the result of :

               - Poor network coverage or cross channel interference causing the devices to consistently roam and/or reauthenticate.

               - Potentially bad or outdated WING firmware on your APs.

               - Some form of inactivity timeout triggering a disconnect of your sessions.

           

          Other questions:

          - Have you tried using ConnectPro/TermProxy for session persistence?

          - Are you using SSH or Telnet for connectivity?

          - Have you tried looking at the TelnetCE logs? You'll have to enable logging first in the Emulation Parameters of the TelnetCE config.

          • 2. Re: Telnet emulator session block
            Rookie

            Hi all,

            I am experiencing the same problem in our customer warehouse using MC2100 with Telnet version 7.3.63.

            I have already opened a case (00901270) but it seems to be a connection error:

             

            2009-01-01 04:08:57: Session 1 - Wrote 15 Byte(s) (to TermProxy)

               0:  00 0D 12 A0 00 00 04 00 : 00 03 07 03 37 FF EF     ...µ..........Õ

             

            2009-01-01 04:10:00: Session 1 - Closed Connection (Read Socket Error, Winsock error 10054)

             

            2009-01-01 04:10:00: Session 1 - Opened Connection

             

            2009-01-01 04:10:03: Idle Handlers took 3002 milliseconds to process

             

            2009-01-01 04:10:03: 3075 millisecond delay between Idle calls

             

            2009-01-01 04:10:06: Idle Handlers took 3001 milliseconds to process

             

            2009-01-01 04:10:07: 3087 millisecond delay between Idle calls

             

            2009-01-01 04:10:21: Session 1 - Closed Connection (No Traffic Timeout, Winsock error 10060)

             

            2009-01-01 04:10:21: Session 1 - Opened Connection

             

            2009-01-01 04:10:24: Idle Handlers took 3002 milliseconds to process

             

            2009-01-01 04:10:25: 3075 millisecond delay between Idle calls

             

            2009-01-01 04:10:42: Session 1 - Closed Connection (No Traffic Timeout, Winsock error 10060)

             

            2009-01-01 04:10:42: Session 1 - Opened Connection

             

            2009-01-01 04:10:45: Idle Handlers took 3002 milliseconds to process

             

            2009-01-01 04:10:46: 3079 millisecond delay between Idle calls

             

            2009-01-01 04:11:03: Session 1 - Closed Connection (No Traffic Timeout, Winsock error 10060)

             

            2009-01-01 04:11:03: Session 1 - Opened Connection

             

            2009-01-01 04:11:07: Idle Handlers took 3002 milliseconds to process

             

            2009-01-01 04:11:07: 3075 millisecond delay between Idle calls

             

            2009-01-01 04:11:25: Session 1 - Closed Connection (No Traffic Timeout, Winsock error 10060)

             

            2009-01-01 04:11:25: Session 1 - Opened Connection

             

            2009-01-01 04:11:25: Session 1 - Wrote 161 Byte(s)

               0:  2A 48 53 50 30 30 30 31 : 35 31 64 32 39 64 32 65  *HSP000151d29d2e

              10:  31 61 34 35 66 65 61 61 : 30 38 34 37 38 66 65 32  1a45feaa08478fe2

              20:  30 35 34 37 37 64 37 35 : 32 61 68 73 70 76 65 72  05477d752ahspver

              30:  3B 32 3B 70 72 6F 74 6F : 63 6F 6C 3B 31 3B 68 6F  ;2;protocol;1;ho

              40:  73 74 3B 31 30 2E 32 31 : 36 2E 32 37 2E 31 3A 32  st;10.216.27.1:2

              50:  33 3B 64 69 73 63 6F 6E : 6E 65 63 74 68 6F 73 74  3;disconnecthost

              60:  3B 32 3B 73 65 73 73 69 : 6F 6E 69 64 3B 34 31 64  ;2;sessionid;41d

              70:  35 33 30 37 30 37 63 36 : 37 33 35 34 35 31 62 35  530707c6735451b5

              80:  34 39 34 36 61 32 31 37 : 39 65 62 31 34 3B 64 61  4946a2179eb14;da

              90:  74 61 72 65 63 65 69 76 : 65 64 3B 31 30 32 39 33  tareceived;10293

              A0:  33                                                 3

             

            Do you have any updates ?

            Thank you.

             

            Nicolò

            • 3. Re: Telnet emulator session block
              cachilli SupportEmployee

              These WinSock errors are HOST related.. TE is just reporting the winsock numbers.. You should focus on what the HOST is doing and its log files

               

              • 4. Re: Telnet emulator session block
                Rookie

                Hi,

                I know, but AS400 specialist says that everything works correctly.

                Which kind of check can I ask to do in order to discover any anomalies?

                 

                Thank you.

                • 5. Re: Telnet emulator session block
                  Matt Dermody SSMMVPGroup

                  Do you experience any connection issues from putty on a laptop? What if you put that laptop on the same wireless network as the devices?

                   

                  Have you selected the correct emulation type for your AS400 connection (ie. 5292, 5251, etc)?

                   

                  Is the host expecting some sort of startup string?