View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000344aMulePreferencespublic2005-03-29 03:032005-03-29 15:48
Reporters0undt3ch 
Assigned ToGonoszTopi 
PrioritynormalSeveritymajorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product VersionSVN 
Target VersionFixed in Version 
Summary0000344: Setting IPLevel with amulecmd makes amule loose Security Prefs
DescriptionLook for your self:
-----------------------------------------------------------
/usr/local/bin/amulecmd -f ~/.aMule/remote.conf

Creating client...
Now, doing connection....
Using host 'blablabla.blablabla.org' port:4712
Trying to connect (timeout = 10 sec)...
Succeeded! Connection established to aMule CVS

---------------------------------
| aMule text client |
---------------------------------


Use 'Help' for command list

aMulecmd$ iplevel 50
 > Operation was successful.
 > IPFilter is OFF.
 > Current IPFilter Level is 50.
aMulecmd$
-----------------------------------------------------------

With this command it also loses the settings for:
- Who can see shared list
- Use Secure Identification
Additional Information/usr/local/bin/amulecmd --version
amulecmd CVS using wxGTK1 v2.5.4 (Snapshot: Sun Mar 27 07:01:10 CEST 2005)

Running on FC3 with latest Kernel
TagsNo tags attached.
Fixed in Revision
Operating System
Attached Files

- Relationships

-  Notes
(0000803)
ken (developer)
2005-03-29 03:16

This is due to a problem with the semantics of Boolean tags in the EC protocol.

When one issues the IPLevel command with amulecmd, a

EC_OP_SET_PREFERENCES
    EC_TAG_PREFS_SECURITY
        EC_TAG_IPFILTER_LEVEL (int8)

packet is sent (src/TextClient.cpp:433).

However, in CEC_Prefs_Packet::Apply() the absence of several boolean tags causes them to be interpreted as false, rather than unchanged. (src/ECSpecialTags.cpp:446)

Because of the semantics of Boolean, amulecmd would have to query the security preferences, modify just the one it wants to, and then write them all back. I suspect this problem appears elsewhere, too.
(0000806)
GonoszTopi (administrator)
2005-03-29 15:48

Yes, this matches the old behaviour, when missing values were treated as unchanged. Now it's fixed, and I hope noone will break it again.

- Issue History
Date Modified Username Field Change
2005-03-29 03:03 s0undt3ch New Issue
2005-03-29 03:16 ken Note Added: 0000803
2005-03-29 03:16 ken Assigned To => GonoszTopi
2005-03-29 03:16 ken Status new => assigned
2005-03-29 15:46 GonoszTopi Status assigned => resolved
2005-03-29 15:46 GonoszTopi Resolution open => fixed
2005-03-29 15:48 GonoszTopi Note Added: 0000806


Copyright © 2000 - 2019 MantisBT Team
Powered by Mantis Bugtracker