0000344: Setting IPLevel with amulecmd makes amule loose Security Prefs

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0000344

aMule

Preferences

public

2005-03-29 03:03

2005-03-29 15:48

Reporter

s0undt3ch

Assigned To

GonoszTopi

Priority

normal

Severity

major

Reproducibility

always

Status

resolved

Resolution

fixed

Platform

OS Version

Product Version

SVN

Target Version

Fixed in Version

Summary

0000344: Setting IPLevel with amulecmd makes amule loose Security Prefs

Description

Look 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

Tags

No 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