(SOLVED) (LNet) Firewall causing problems?

[cybersmyth]

I got a little issue with LNet's FTP system and what I THINK it is my firewall, but I'm not 100% sure. My application uploads a batch of files and I'm getting an Access Violation error every now and then. I can't track it down to a specific event, it appears to be totally random. But I notice when I do get this error, my McAfee pops up and says, "A program is trying to get internet access, do you want to allow?" And, at least so far, I never gotten this Access Violation error on any other PCs, which just have a standard Windows 7 install.

One weird thing is, McAfee doesn't seems to remember the program when I click, "Always Allow". I'm thinking this might be because when I change the code and recompile, it sees it as a different program?

I wonder if there's a way to catch this Access Violation and report it? "FTP failed, please disable your firewall" - or something like that? Right now it just crashes.

[Almindor]

Can you get a backtrace of the crash? (compile with -gl settings and run via gdb/lazarus, then see call stack window and copy contents).

It shouldn't crash in any circumstance. It's probably a bug somewhere. Also, are you using lNet trunk or 0.6.5?

[cybersmyth]

I'll try, but I don't know how long it will take. Sometimes it takes awhile before I get the error. After a lot of tracking, I do know it is happening after I use the TLFTPClientComponent.Put(); method. But I go do it a 1,000 times with no problems and then out of nowhere, I suddenly get the error.

And like I say, I'm about 90% sure it's got something to do with McAfee. I'm running this beta on 6 different PCs right now for several days and only the one with McAfee is getting the error.

Oh... and using 0.6.5.

[Almindor]

Use lNet trunk please, there is a bug in 0.6.5 regarding how TLFTP handles "file download complete" logic and it causes premature closing of the file stream.

The bug is in trunk still but the examples have a workaround until I properly fix it (api change needed for it tho).

Basically if you check for file completion with .Get = 0 it's wrong. You need to also check if connection was really closed and if the file has proper size.

[cybersmyth]

Yeah, I'm familiar with the bug, I think I was the one that found it.

I also found another bug today... I'm not getting any problems with my personal FTP server, but my ISP has problems with lNet in that same code area. At home I use vsftp, they are using Pure-FTPd. It appears that it tried to send one last packet of data after lNet has already set to something other than fsRetr.

Here's my work around for the visual example, basically if the file hasn't yet be closed then I assume it hasn't completed yet.

Code: Pascal  [Select][+][-]

1. begin
2.   if (FTP.CurrentStatus = fsRetr) or (Assigned(FFile)) then begin // getting file, save to file
3.     i := FTP.GetData(Buf, SizeOf(Buf));
4.     Inc(FDLDone, i);
5.     if i > 0 then begin
6.       if Length(CreateFilePath) > 0 then begin
7.         FFile := TFileStream.Create(CreateFilePath, fmCreate or fmOpenWrite);
8.         CreateFilePath := '';
9.       end;
10.       FFile.Write(Buf, i);
11.     end else if (FDLDone > FDLSize) then begin
12.       // file download ended
13.       LeftView.UpdateFileList;
14.       FreeAndNil(FFile);
15.       CreateFilePath := '';
16.       DoList('');
17.       Test1:=false;
18.     end;
19.     ProgressBar1.Position := Round(FDLDone / FDLSize * 100);
20.   end else begin // getting listing
21.     s := FTP.GetDataMessage;
22.     if Length(s) > 0 then
23.       FDirListing := FDirListing + s
24.     else begin
25.       FList.Text := FDirListing;
26.       FDirListing := '';
27.       FindNames;
28.       FList.Clear;
29.     end;
30.   end;
31. end;
32.  

[Almindor]

Is the FTP server you have problems with public? I can try to debug the issue but I need a reproducable case.

[jixian.yang]

McAfee is a greate defender. If it is stopped, the access protection (include but not limited to net operation) still work. Stop all of the McAfee services and try again, maybe there will be a different result.

[Almindor]

Is there a free trial for the mcafree you're using? I can try it with my XP setup at home but I need exacts to get it repeated.

Thanks

[cybersmyth]

I've looked and the ISP does not have an anonymous setup. But I have tried my work-around with several FTP servers and it appears to work really well.

I don't think McAfee has a free version of their total protection service, which is what I'm using. But I've disabled the firewall and the errors appear to have gone away. I've been doing further stress testing, but I'm pretty confident that it's a problem with is McAfee and it keeps popping up because every time I recompile McAfee sees my application as a new program trying to get internet access. I think once I have it finished and I tell McAfee to allow it internet access, the problem will go away. I'll keep you posted.

On another note, I've been working on fault tolerances in my app and have a small suggestion for lNet's lftp.pp. Currently when a file is sending and there is a network outage, the ftp client eventually disconnected, but the file that was being uploaded remains locked.

Currently the code is:

Code: Pascal  [Select][+][-]

1. procedure TLFTPClient.OnControlDs(aSocket: TLSocket);
2. begin
3.   if Assigned(FOnError) then
4.     FOnError('Connection lost', aSocket);
5. end;
6.  

I changed it to this, to free up the file and it appears to work:

Code: Pascal  [Select][+][-]

1. procedure TLFTPClient.OnControlDs(aSocket: TLSocket);
2. begin
3.   if Assigned(FOnError) then
4.     FOnError('Connection lost', aSocket);
5.   if Assigned(FStoreFile) then
6.     FreeAndNil(FStoreFile);
7. end;
8.  

[cybersmyth]

I finally tracked it down! It was totally poor programming on my part. My app builds a queue of FTP and file manager actions to preform. One of the common things is for it to upload and then delete so the delete happens right after the upload finishes.

Every now and then, very rarely, the delete would get triggered before the upload was totally finished so from what I can tell the delete happened right in that millisecond where lnet was reading it's last packet of bytes.

I don't know if McAfee had anything at all to do with it or if maybe it slowed the send down to a small degree? But in any event, I put a step between finishing the upload and deleting to make sure it's finished up.

[Almindor]

I've looked and the ISP does not have an anonymous setup. But I have tried my work-around with several FTP servers and it appears to work really well.

I don't think McAfee has a free version of their total protection service, which is what I'm using. But I've disabled the firewall and the errors appear to have gone away. I've been doing further stress testing, but I'm pretty confident that it's a problem with is McAfee and it keeps popping up because every time I recompile McAfee sees my application as a new program trying to get internet access. I think once I have it finished and I tell McAfee to allow it internet access, the problem will go away. I'll keep you posted.

On another note, I've been working on fault tolerances in my app and have a small suggestion for lNet's lftp.pp. Currently when a file is sending and there is a network outage, the ftp client eventually disconnected, but the file that was being uploaded remains locked.

Currently the code is:

Code: Pascal  [Select][+][-]

1. procedure TLFTPClient.OnControlDs(aSocket: TLSocket);
2. begin
3.   if Assigned(FOnError) then
4.     FOnError('Connection lost', aSocket);
5. end;
6.  

I changed it to this, to free up the file and it appears to work:

Code: Pascal  [Select][+][-]

1. procedure TLFTPClient.OnControlDs(aSocket: TLSocket);
2. begin
3.   if Assigned(FOnError) then
4.     FOnError('Connection lost', aSocket);
5.   if Assigned(FStoreFile) then
6.     FreeAndNil(FStoreFile);
7. end;
8.  

Thanks,

I added a procedure to handle sending stops in all cases including this one