Very strange and difficult RF gun disconection problme! !Need Helps!Thanks!

[Former Member]

HI,Experts:

We are using RF gun with SAP warehouse management(WM) in our company.

This almost runs very well,but unfortunately we have strange RF disconnection problem.

The problem is that RF gun loose their disconnection in multiple locations,disconnection happen all different times of the day, no typical situations.We have already checked that network connections are fine.

Our software environment is :

Stay-linked(as application software for RF gun with WIN CE 5.0)

Seattlelabs SLNet telnet server 4.1

Windows Server 2003

SAP console 7.10

RF gun is: MC9090

And we have already send a message on OSS to SAP and connect the Slnet server and RF vendor.

Both SAP and Slnet server found nothing about this problem,and both said there is no connection problem with SAP console and SLnet.

And more strange,we have 14 userids of SAP using the RF gun, 7 userid often have the disconnection problem,but the other 7 userids do never have any disconnections.

It seems that the disconnection problem has something with the userid of SAP. But we do not find any special settings with those user accounts.

So hope any experts give any advice on how to solve the problem!

Thanks for any reply!

[dana_schreiber]

Hello ,

Currently we are facing the same issue , Can I have OSS message reply which you already raised so ?

Thanks,

GP

[raghug]

Dana, I have been part of the installation of many many RF solutions. These kind of problems are not uncommon, but, unfortunately there is no universal answer. The issue always boils down to networking, wireless or device hardware issues. Some things to look at...

• Do disconnects happen in the same location - wireless / networking issue
• Do they only happen to certain users - Network authentication issues
• Same devices - device issues
• Only when user is moving, often in the same direction - wireless setup issues (roaming profiles) or wireless interference

Do not under-estimate the issue of wireless interference. The experts will come in and do their site surveys and charge a lot of money to say everything is fine. But, what they don't cover is - what happens when you get too close to racking, if you load racks with metallic or magnetic materials, interference during equipment operation, etc. For instance, I once caught the fact that the disconnects were happening near a break room. It happened to be a related to microwave oven turning on!

[Lakshmipathi]

Dana Schreiber

Avoid hijacking someone's thread and that too 8 years old discussion thereby, you pushed such an old discussion to top of the this area unnecessarily. Create a new discussion after searching

[Former Member]

This message was moderated.

[m_bezemer]

Hi all,

I know the original post is years old but I had similar issues last year and my solution was not mentioned yet so...

Our problem had the same symptoms: half the users in a different part of the warehouse had no problems at all and the other half got their sessions terminated every 10 minutes or so.

We tracked down the problem to the user-registration on the Windows Domain Server. Something went worng with the permissions and SLNet happily accepted any and all users and forwarded the connection to the SAP server through the Domain. Every 10 minutes the Domain Server checked logged in connections and terminated the connections of users without the right credentials.

Comparing working with broken users on the Domain Server revealed the error, but only after minutely checking them.

Guess how long it took us to reach this conclusion going down the chain from checking and swapping scanners, users, accesspoints, networksegments, etc. etc. ?

Anyway, hope this helps at least one.

Cheers!

[Former Member]

Hi Martin, I know it has been a year now since you posted this but we are in a similar situation with our users currently and can use your guidance. What does Windows domain server do in the RF handheld connections? I am not sure if I fully understand our architecture here but if you can explain a bit more, I guess I can check if we have the same exact problem tat you had...

Thanks,

Ram

[former_member291008]

Hi Ram,

The [problem was with the permissions of the user -on the domain- that was used to connect from the scanner to the SLNet server. The user-id that was used to connect from the SLNet server to SAP was OK.

In the Domain server logs we found that the user was terminated every time after about 10 minutes, this was the interval the Domain server checks all connections and terminates those that do not have the right credentials.

So my advice is to check every user-id used to connect and/or login in the chain starting at the scanner (most likely the one with the problem) all the way to the SAP system.

Cheers!

[former_member412579]

This message was moderated.

[Former Member]

We have have suffered from the random disconnect issue for a very long time. Back in 2008 the project came to a standstill and the users had to go back to the previously unsupported 3rd party mobile SAP solution.

Although I was not part of the group that handled SAP mobility back in 2008. I believe they were running an older patch version of SAPConsole 7.10 and a Seattle Labs v4.x of SLNET on a windows 2003 VM instance. Random disconnects all day long in the middle of transactions worldwide. From what I understand they exhausted resources in trying to track down the problem. The business was forced back to the unsupported system till this could be resolved. It was understood that SAPConsole was not qualified to be used in an VM environment. This would be the start of a new project where I would be involved.

In June of 2011 I got involved to deploy SAPConsole 7.10 patch 11 and slnet v5.0 on windows 2008 physical servers. This implementation did not solve any of the previous issues at first. Still random disconnects, but not quite as bad as before. Through discussions with Seattle labs, I received a proposed fix in an email. Apparently there is some sort of instability in the native shell config causing the sessions to close by themselves. This fix worked! No more random disconnects. In bold below, I have copied and pasted the solution from Seattle Labs directly from my email.

Due to recent testing that we have done with SLNet 5.0 and SAPConsole, and based on recommendations from SAP there are some changes to your configuration that we recommend.

1. If any users are logged into SLNet have them logout and then stop the SLNet Service.

2. With the SLNet Configuration panel closed, open regedit and go to HKEY_LOCAL_MACHINE\SOFTWARE\Seattle Lab\SLNet

3. Create a new Reg_DWord named "Skip Default Shell Warning" set value to 1

4. Now open the SLNet configuration panel and go to the Users tab

5. Edit the Default User.

a) Uncheck the Monitor Child Processes box.

6. Edit the SAP user

a) Change the default shell to " C:\Programme\SAP\Console\sapcnsl.exe"

7. Restart the SLNet service. Let me know if this resolves the disconnect issue.

I still wonder even now if this fix was introduced into the older 2008 environments, would it fix the random disconnects. Guess we will never know.

Mike

[former_member634702]

Hello Micheal,

We are facing some random disconnections problem on data collect, it´s happening whenever are reading barcode. We already opened a ticket on SAP but unfortunately, by now us don´t have the solution. We applied recommendations listed in this post and seems that it solve the problem, however we had collateral effects as listed below:

- When we disable “Monitor Child Processes” the disconnection stopped, however the all services like SLCon.exe, conhost.exe, sapcnsl.exe and CMD.exe remain running increasing memory consumption until the system does not have more memory available and triggers the freezing of server.

- When we change “default shell” to “C:\Programme\SAP\Console\sapcnsl.exe” we receive random alerts informing “connection lost”

Hereunder there are our scenario:

SLNet 5.3

SapConsole 7.30 Path 2

Windows 2008 R2

Data collectors: Motorola 9190, Psyon XT15 Artic and Honeywell MX7

Someone face this problem? Could you please help me with this issue?

Thanks in advance.

Regards,

Michell Longhi

[Former Member]

We had similar problem. RFGuns would disconnect several times a day. What we found is that we had four Access points whereas one was suffiecient and one for the backup. We shut down other two. Since then we are fine.

Edited by: Irfan sheikh on Sep 14, 2011 6:04 PM

[Former Member]

On last post did you find the problem, sounded like there was issue before with certain SLnet and SAP version combinations not working correctly, disconnecting users. I have an issue where the wireless signal gets too low when high rack storage is full and causes disconnects to RF handhelds in some warehouse areas, did you check wireless signal strength where they get the disconnects when its happening.

Also I'm trying to get SLnet to timeout telnet logons at 120 minutes I set this setting up in SLnet console timeout tried it and it appeared to work but sometimes get 60 minute timeout sometimes 120 minutes now any idas on what would cause this, windows telnet not running and network tech didn't find any settings there for timeout.

[former_member182609]

Check the access both the user is same or not.If yes do one thing delete the problem user ID and crete ID again and then check .Some times it may give problem So insted of deleting all user IDs delete one problem ID and create new ID and check again may be this may help you.

[former_member204746]

for your information, if I use an older server with SLNET 2.6 and an older SAPCNSL.exe from SAPGUI 6.40, I do not get this problem.

problem is with SLNET 4.1 with SAPCNSL 7.10 patch 9. I might try patch 10.

[former_member204746]

for testing purpose, Seattle Labs sent me a 5.0 version file of executable slcon.exe

this executable does not seem to have the disconnect problem. so, problem looks to be related to SLNET 4.1. I will keep this topic updated with more findings.

[former_member204746]

So far, This is what I found:

This DOES NOT work:

SLNET 4.2 (with SP2 or without it)

SAPGUI 7,10 patch 14

SAPCNSL 7.10 patch 9

this works:

SLNET 2.6

SAPGUI 7,10 patch 14

SAPCNSL 7.10 patch 9

this works:

SLNET 2.6

SAPGUI 6.40 patch 22

SAPCNSL 6.40 patch 19

this works:

SLNET 4.2 with SLcon.exe from version 5.0

SAPGUI 7,10 patch 14

SAPCNSL 7.10 patch 9

this works:

SLNET 5.0

SAPGUI 7,10 patch 14

SAPCNSL 7.10 patch 9

[former_member204746]

I also found something else. it is very important to use these steps when upgrading SLNet:

1. uninstall previous version

2. delete registry keys related to Seattle Labs

3. delete c:\program files\SL* and c:\program files\Seattle labs folders

4. reboot

5. install new product.

6. configure SLnet

7. install license

[Former Member]

Eric,

thanks for continuing to update this thread. I'm sure this will come in very useful to me at some point in the future !

Regards,

Nick

[Former Member]

A guess. If it appears that User is a factor, check with Basis which User Group/Application server the people with problems and those without are going through. It could be a lack of processors for given Application server.

[former_member204746]

Have you found any solution to that problem?

[Former Member]

Hello, I was having an issue with SLnet (nothing related to yours) and while finding information on my company of previous events, I found they had the same issue that you and the information they put as solution on the Support request was the following:

#########

The problem

Disconnections are occuring more and more often on RF terminals.

The reason

The SLNet and/or SAPConsole and/or SAPO transaction looked to be disconnecting.

A first diagnostic shows us that SLNet server is complaining about small packets and therefore casuses an error with the consequence of disconnection the SLnet client i.e. the RF device.

The solution

The SLNet Annual support has been renewed.

ITSC is currently requesting support from SeattleLab, the supplier of the software, to fix the problem.

##########

There is a high chance it is not usefull, but perhaps I can give you an idea. Sadly I have nothing more on this, since this error appeared 4 years ago.

hope it is helpfull.