Forum > Networking and Web Programming
(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 [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---begin if (FTP.CurrentStatus = fsRetr) or (Assigned(FFile)) then begin // getting file, save to file i := FTP.GetData(Buf, SizeOf(Buf)); Inc(FDLDone, i); if i > 0 then begin if Length(CreateFilePath) > 0 then begin FFile := TFileStream.Create(CreateFilePath, fmCreate or fmOpenWrite); CreateFilePath := ''; end; FFile.Write(Buf, i); end else if (FDLDone > FDLSize) then begin // file download ended LeftView.UpdateFileList; FreeAndNil(FFile); CreateFilePath := ''; DoList(''); Test1:=false; end; ProgressBar1.Position := Round(FDLDone / FDLSize * 100); end else begin // getting listing s := FTP.GetDataMessage; if Length(s) > 0 then FDirListing := FDirListing + s else begin FList.Text := FDirListing; FDirListing := ''; FindNames; FList.Clear; end; end;end;
Navigation
[0] Message Index
[#] Next page