Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

Problem with LAN network

Linux Kernel, Network, and Services configuration.
Post Reply
Message
Author
acu.tm
Posts: 9
Joined: 2017-05-11 13:00

Problem with LAN network

#1 Post by acu.tm »

Hi there.

I am having problems with the network in my work. In the system there are 8 Pcs all with debian and one that is server.

Network is managed by a program in DBASEIII (yes, a little old) with DOSEMU is used by all clients always consulting the server. Both data and programs are on the server.

I was having problems with certain files that mysteriously disappeared. The folders were mounted with CIFS.

I thought I'd fix it by changing protocol and using NFS instead. But in the last days, some files disappeared again.

Checked the ping speeds from the server to all clients and all are in 0.2 - 0.3 msec response.

I am using Debian 8 on the server. Should I use a server debian version? Can it be wiring problems?

Is there any way or is there a lot more things I should check? All ip are static and with google DNS

Thank you very much
H/W path Device Class Description
============================================================
system Computer
/0 bus Motherboard
/0/0 memory 3329MiB System memory
/0/1 processor AMD Athlon(tm) 5150 APU with Radeon(tm) R3
/0/100 bridge Family 16h Processor Root Complex
/0/100/1 display Kabini [Radeon HD 8400 / R3 Series]
/0/100/1.1 multimedia Kabini HDMI/DP Audio
/0/100/2.4 bridge Family 16h Processor Functions 5:1
/0/100/2.4/0 eth0 network RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
/0/100/2.5 bridge Family 16h Processor Functions 5:1
/0/100/2.5/0 bus ASM1042A USB 3.0 Host Controller
/0/100/2.5/0/0 usb8 bus xHCI Host Controller
/0/100/2.5/0/1 usb5 bus xHCI Host Controller
/0/100/10 bus FCH USB XHCI Controller
/0/100/10/0 usb4 bus xHCI Host Controller
/0/100/10/1 usb3 bus xHCI Host Controller
/0/100/11 storage FCH SATA Controller [AHCI mode]
/0/100/12 bus FCH USB OHCI Controller
/0/100/12/1 usb6 bus OHCI PCI host controller
/0/100/12/1/3 input USB OPTICAL MOUSE
/0/100/12/1/4 input USB Keyboard
/0/100/12.2 bus FCH USB EHCI Controller
/0/100/12.2/1 usb1 bus EHCI Host Controller
/0/100/13 bus FCH USB OHCI Controller
/0/100/13/1 usb7 bus OHCI PCI host controller
/0/100/13.2 bus FCH USB EHCI Controller
/0/100/13.2/1 usb2 bus EHCI Host Controller
/0/100/13.2/1/4 scsi2 storage Flash Card Reader/Writer
/0/100/13.2/1/4/0.0.0 /dev/sdb disk SCSI Disk
/0/100/13.2/1/4/0.0.1 /dev/sdc disk SD/MMC
/0/100/13.2/1/4/0.0.1/0 /dev/sdc disk
/0/100/13.2/1/4/0.0.2 /dev/sdd disk MS/MS-PRO
/0/100/13.2/1/4/0.0.2/0 /dev/sdd disk
/0/100/13.2/1/4/0.0.3 /dev/sde disk SCSI Disk
/0/100/14 bus FCH SMBus Controller
/0/100/14.2 multimedia FCH Azalia Controller
/0/100/14.3 bridge FCH LPC Bridge
/0/101 bridge Family 16h Processor Function 0
/0/102 bridge Family 16h Processor Function 0
/0/103 bridge Family 16h Processor Function 1
/0/104 bridge Family 16h Processor Function 2
/0/105 bridge Family 16h Processor Function 3
/0/106 bridge Family 16h Processor Function 4
/0/107 bridge Family 16h Processor Function 5
/0/2 scsi0 storage
/0/2/0.0.0 /dev/cdrom disk DVDRAM GH24NSC0
/0/3 scsi1 storage
/0/3/0.0.0 /dev/sda disk 500GB WDC WD5000AZLX-0
/0/3/0.0.0/1 /dev/sda1 volume 102GiB EXT4 volume
/0/3/0.0.0/2 /dev/sda2 volume 7033MiB Extended partition
/0/3/0.0.0/2/5 /dev/sda5 volume 7033MiB Linux swap / Solaris partition
/0/3/0.0.0/3 /dev/sda3 volume 356GiB Windows NTFS volume
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 8.5 (jessie)
Release: 8.5
Codename: jessie

User avatar
dasein
Posts: 7680
Joined: 2011-03-04 01:06
Location: Terra Incantationum

Re: Problem with LAN network

#2 Post by dasein »

acu.tm wrote:Network is managed by a program in DBASEIII
It's unclear what you're trying to say here. dBase is not a network management tool. It's a database application from the early 1980s ("a little old" indeed).
acu.tm wrote:I was having problems with certain files that mysteriously disappeared.
"Disappeared" doesn't communicate as much as you think it does. Are you saying that the files were deleted? That they were intact but invisible on the network? Visible but inaccessible by applications? Something else??

You need to be specific and precise, not casual and conversational, when reporting a problem.
acu.tm wrote:Checked the ping speeds from the server to all clients and all are in 0.2 - 0.3 msec response.
What specifically makes you think that this is a network problem, much less a network performance problem? Network issues would be very low on my list of candidate causes. Performance issues wouldn't be on that list at all.

Cefiar
Posts: 18
Joined: 2017-03-25 22:50

Re: Problem with LAN network

#3 Post by Cefiar »

Regard to the posters comment of DBASE III...

I suspect that they're using some really old DOS based database program that is using file locks on a database to do database queries/writes.

This is always going to be problematic, simply because shared file systems are not meant for this sort of work. It was a hack back in the DBASE III days with network filesystems, and it's still a hack.

As for files disappearing, this could be any number of reasons:
  • File system corruption.
  • Virus/Malware/rogue process (in Linux or within your DOSEMU systems).
  • Difference in DOSEMU locking on one/any client (or on server), even if the filesystem was local.
  • Kernel filesystem changes with regard to local locks (where are the files, on the NTFS or EXT4 partition?)
  • Changes in how Samba/NFS is set up with regard to ownership or file locking.
If I was stuck with this (apart from looking for another job) I'd be looking at what happens if I run multiple copies of the application locally using DOSEMU on top of various local filesystems first. If this still fails, it's likely it's DOSEMU or the kernel with regards to local FS's.

If it works, then I'd be looking into how these locks translate to network locks and therefore what network locking operations the underlying FS's support, and making sure that they're enabled by default. If you're using SAMBA, I'd even go so far as to consider setting up Samba to use older versions of the SMB protocol all round, given that the DBASE III programs were obviously written only with that underlying network protocol in mind.

> Edited to add... <

One thing the OP didn't mention is exactly WHAT the clients are running. That in itself could explain the problems.

BTW: If local works and network fails, you could move to a server model where the clients connect to the display on the server for each DOSEMU. This takes the network completely out of the equation for files (as they're all local), and uses the network entirely for passing over the display output. Given it's text (DBASE III) then this is going to be fairly fast.

acu.tm
Posts: 9
Joined: 2017-05-11 13:00

Re: Problem with LAN network

#4 Post by acu.tm »

Sorry for my writing. Due to the language and lack of knowledge i might be wrong with explanation
dasein wrote:It's unclear what you're trying to say here. dBase is not a network management tool. It's a database application from the early 1980s ("a little old" indeed).
A program written on DBASEIII is used on my work maybe since 1990s, those days used with win95, 98, xp, etc...
what I did when moved to linux was mount the folders (first CIFS, now NFS) with the data on the clients and run the program with DOSEMU.
dasein wrote:"Disappeared" doesn't communicate as much as you think it does. Are you saying that the files were deleted? That they were intact but invisible on the network? Visible but inaccessible by applications? Something else??.
Yes, with disappeared i mean that some DB files doesn't register changes when they are modified. Those are important because they are database files with bills and refer with specific number. So if that file doesn't update, it's like the operation was never done. The curious thing is that it happens very occasionally, so I cannot determine the problem, and maybe here we notice what happen 1 or 2 days later.
dasein wrote:You need to be specific and precise, not casual and conversational, when reporting a problem.
please sorry, i'm trying to be more specific this time
dasein wrote:What specifically makes you think that this is a network problem, much less a network performance problem? Network issues would be very low on my list of candidate causes. Performance issues wouldn't be on that list at all.
i gave that info because of my poor understanding, i thought this could be a problem, issues with the network.
Last edited by acu.tm on 2017-05-12 13:27, edited 1 time in total.

acu.tm
Posts: 9
Joined: 2017-05-11 13:00

Re: Problem with LAN network

#5 Post by acu.tm »

Cefiar wrote:I suspect that they're using some really old DOS based database program that is using file locks on a database to do database queries/writes.

This is always going to be problematic, simply because shared file systems are not meant for this sort of work. It was a hack back in the DBASE III days with network filesystems, and it's still a hack.
I think the best option would be rewrite the whole program to a new language, wich is cumbersome because the program is pretty big, and have been modificated and added features on the last 20 years on the spur.
Cefiar wrote:
  • File system corruption.
  • Virus/Malware/rogue process (in Linux or within your DOSEMU systems).
  • Difference in DOSEMU locking on one/any client (or on server), even if the filesystem was local.
  • Kernel filesystem changes with regard to local locks (where are the files, on the NTFS or EXT4 partition?)
  • Changes in how Samba/NFS is set up with regard to ownership or file locking.
the files are on NTFS partition, this could be a problem too? don't think it would be a problem to migrate the FS type to EXT4, right?
I think I don't fully understand that thing with lock file. According to what I read it says that it only let one client or process to use a specific file. But what you are saying is that DOSEMU and the mount protocol have different type of file lock? and this could make the problem.
with NFS i just gave the same permission to all clients on the /etc/exports file, and on fstab file on each client i just copy and paste the line.
Cefiar wrote:If I was stuck with this (apart from looking for another job) I'd be looking at what happens if I run multiple copies of the application locally using DOSEMU on top of various local filesystems first. If this still fails, it's likely it's DOSEMU or the kernel with regards to local FS's.
Doesn't think leaving the job is an option (lol), is my family's business and I made the whole migration to linux, just as a hobby.
I could try what you said about multiple running but due to the sporadic fact i think it wouldn't be so easy to detect the problem.
Cefiar wrote:If it works, then I'd be looking into how these locks translate to network locks and therefore what network locking operations the underlying FS's support, and making sure that they're enabled by default. If you're using SAMBA, I'd even go so far as to consider setting up Samba to use older versions of the SMB protocol all round, given that the DBASE III programs were obviously written only with that underlying network protocol in mind.
that locks you said, should I have to try it manually and check or would i be able to find any info about it on the internet?
I'll check what you said about older version of SMB protocol.
Cefiar wrote:One thing the OP didn't mention is exactly WHAT the clients are running. That in itself could explain the problems.
sorry didn't understand what you mean with WHAT, the files? PCs specifications?
Cefiar wrote:BTW: If local works and network fails, you could move to a server model where the clients connect to the display on the server for each DOSEMU. This takes the network completely out of the equation for files (as they're all local), and uses the network entirely for passing over the display output. Given it's text (DBASE III) then this is going to be fairly fast.
so with this method I shouldn't mount any folder? just run the program through network? I'll check that too.
Thank you very much.

Cefiar
Posts: 18
Joined: 2017-03-25 22:50

Re: Problem with LAN network

#6 Post by Cefiar »

The SMB/CIFS protocol supports locking mechanisms on files that are specific to DOS/Windows.

If you're using using a mix of clients (eg: something in DOSEMU on the server, and a different OS or version of Linux/DOSEMU on the clients) then it's not guaranteed that everyone will handle the file locking the same way.

This is why I asked WHAT the clients are (ie: what OS, and if Linux are you running DOSEMU on them, etc).

If they're not all the same OS (ie: all Debian, and the same release) you could be hitting differences in the way versions of programs (eg: DOSEMU) or protocols/kernel (Samba/Linux Kernel) handle file locking.


Running all the programs on the server (and moving the display/input part to the client PC's) does away with the network protocol in the middle, and gets rid of a lot of issues that happen with different versions of the OS/network protocols.

acu.tm
Posts: 9
Joined: 2017-05-11 13:00

Re: Problem with LAN network

#7 Post by acu.tm »

Cefiar wrote:The SMB/CIFS protocol supports locking mechanisms on files that are specific to DOS/Windows.

If you're using using a mix of clients (eg: something in DOSEMU on the server, and a different OS or version of Linux/DOSEMU on the clients) then it's not guaranteed that everyone will handle the file locking the same way.

This is why I asked WHAT the clients are (ie: what OS, and if Linux are you running DOSEMU on them, etc).

If they're not all the same OS (ie: all Debian, and the same release) you could be hitting differences in the way versions of programs (eg: DOSEMU) or protocols/kernel (Samba/Linux Kernel) handle file locking.


Running all the programs on the server (and moving the display/input part to the client PC's) does away with the network protocol in the middle, and gets rid of a lot of issues that happen with different versions of the OS/network protocols.
OK now i think I can dismiss the Network Issue.
I opened DOSEMU several times via SSH on the clients and they worked last week like this. Now they told me in the last hours it happened again. One change on the DB wasn't registered so the program continued as the operation was never done.
I thought i could use virtualbox and install DOS or freeDOS. Could it be a solution? maybe the problem is with DOSEMU?
Most of the PCs uses Debian 8, (64 or 32 bits according the pc) and only one uses UBUNTU 12.10.

Post Reply