Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[CtrlAltDel]

First of all, thanks for the stable releases! I think regular "official" releases make everybody's life much easier =)

Anyway, I noticed some strange behavior in the latest release (2.2.2).

When I update the ipfilter list from the preferences->security menu, the download is successful. However, the log shows:

Code: [Select]

2008-08-08 22:41:57: Failed to load ipfilter.dat file '/home/amule/.aMule/ipfilter.dat', unknown format encountered.
2008-08-08 22:41:57: Loaded 0 IP-ranges from '/home/amule/.aMule/ipfilter_static.dat'. 0 malformed lines were discarded.
When I "Reload List" from the preferences->security menu, I get:

Code: [Select]

2008-08-08 22:52:36: Loading IP-filters 'ipfilter.dat' and 'ipfilter_static.dat'.
2008-08-08 22:52:38: Loaded 293555 IP-ranges from '/home/amule/.aMule/ipfilter.dat'. 1 malformed line was discarded.
2008-08-08 22:52:38: Loaded 0 IP-ranges from '/home/amule/.aMule/ipfilter_static.dat'. 0 malformed lines were discarded.
In the file IPFilter.cpp the comment caught my attention:

Code: [Select]

                // Try to unpack the file, might be an archive
                if (UnpackArchive(path, ipfilter_files).second != EFT_Text) {
                        AddLogLineM(true,
                                CFormat(_("Failed to load ipfilter.dat file '%s', unknown format encountered.")) % file);
                        return 0;
                }
Indeed, my downloaded ipfilter file is not an archive... Note: It is actually archive, a zipped file, this is important

I commented out the "return 0" from the block, and the log:

Code: [Select]

2008-08-08 23:14:36: Failed to load ipfilter.dat file '/home/amule/.aMule/ipfilter.dat', unknown format encountered.
2008-08-08 23:14:37: Loaded 293555 IP-ranges from '/home/amule/.aMule/ipfilter.dat'. 1 malformed line was discarded.
2008-08-08 23:14:37: Loaded 0 IP-ranges from '/home/amule/.aMule/ipfilter_static.dat'. 0 malformed lines were discarded.
No need to refresh manually.

Commenting out the "return 0" line is probably not the most elegant way of fixing this, but might be a clue for you guys.

Is there the same problem in ServerList.cpp as well?

Thanks!

edit: changed the topic to reflect the current understanding of the problem...

[GonoszTopi]

Somehow it didn't detect that your ipfilter.dat was a text file.

1 malformed line was discarded.

Maybe this has to do something with it. You may try what does "file ipfilter.dat" tell you, or looking into the file to see if it is corrupt in some mysterious way.

[CtrlAltDel]

Thanks for your response. I tried to find the malformed line, but did not see anything weird (the file is huge though). Anyway, it looks mostly ok, and can be reloaded manually successfully. It fails only when the file is downloaded, and actually everything works just fine if the "return 0" is commented out. I would guess there is something spooky in the return value of UnpackArchive() in case the file is not archive (?).

When downloading compressed ipfilter-file everything goes smoothly.

[CtrlAltDel]

I got now a bit more time to investigate this. Sorry to give you some incorrect information... The file I was downloading was actually zipped (it just did not have the file extension).

Let me give you a high-level trace what happens, maybe you can give your opinion:

-When the file is downloaded, it ends up to LoadFromFile() in IPFilter.cpp
-That function calls UnpackArchive() to unpack the zip-file
-UnpackArchive in FileFunctions.cpp calls GuessFileType() and correctly gets EFT_Zip
-Based on that file type a function UnpackZipFile() is called
-UnpackZipFile always returns false (is this ok?... If yes, there should not be need for "Unpack nested archives if needed" branch)
-Since UnpackZipFile() always returns false, UnpackArchive returns "UnpackResult(false, EFT_Zip)"
-Back in LoadFromFile() this return value is caught by this call:  if (UnpackArchive(path, ipfilter_files).second != EFT_Text) which can never be true, since the return value is always EFT_Zip.
-Because of this LoadFromFile() returns zero and exists, although everything has gone just fine for now...

Possible fix:
-Remove unnecessary "Unpack nested archives if needed" branch from UnpackZipFile()
-In the else-branch of that if-statement return UnpackResult(false, EFT_Text) instead of UnpackResult(false, EFT_Zip). UnpackZipFile() has just processed the file successfully, it should be text now, not zip?

Hope this make sense...

PS. As my logs in the previous posts show there is one malformed line, but it does not affect this case. I think you should be able to replicate this by just downloading zipped (not gzipped) ipfilter file.

[GonoszTopi]

I have committed a possible fix for this problem. Could you please test with next tarball?

[woutermense]

Using SVN 9371 and I think there's still a problem with this. Tried to make amule download both the zipped and unzipped versions of the pawcio ipfilter list. Both give the same result, unknown format encountered.

[Stu Redman]

Code: [Select]

#»» 0 - (main title) • Ipfilter v132 (26-12-2008) by R3Qu13M & ElChele

Well, aMule checks if the first 10 characters of the file are printable (in range 0x20 - 0x7e), but the list has 0xbb  (») in pos 1 and 2. So the check fails, because pawcio finds it cool to have funny characters in his comment. 
Maybe you can convince him to change that.

[woutermense]

Can't we just parse into the first non-comment line? Those are guaranteed to be right.

[Stu Redman]

Can't we just parse into the first non-comment line? Those are guaranteed to be right.

That's generic code. It makes no sense to boggle it just because of one strange file.

[Pitxyoki]

The ipfilter from emulepawcio doesn't contain that char anymore. - this "bug" doesn't happen anymore, at least with the recommended ipfilter at the official eMule forums.

[Stu Redman]

Yep. 
Thanks for the info.