aMule Bug Tracker - aMule
View Issue Details
0000344aMulePreferencespublic2005-03-29 03:032005-03-29 15:48
0000344: Setting IPLevel with amulecmd makes amule loose Security Prefs
Look for your self:
/usr/local/bin/amulecmd -f ~/.aMule/remote.conf

Creating client...
Now, doing connection....
Using host '' 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.

With this command it also loses the settings for:
- Who can see shared list
- Use Secure Identification
/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
No tags attached.
Issue History
2005-03-29 03:03s0undt3chNew Issue
2005-03-29 03:16kenNote Added: 0000803
2005-03-29 03:16kenAssigned To => GonoszTopi
2005-03-29 03:16kenStatusnew => assigned
2005-03-29 15:46GonoszTopiStatusassigned => resolved
2005-03-29 15:46GonoszTopiResolutionopen => fixed
2005-03-29 15:48GonoszTopiNote Added: 0000806

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_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.
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.