maemo.org Bugzilla – Bug 10006
Msn (Haze) changes port settings to -2147483648 by itself
Last modified: 2010-10-11 15:04:15 UTC
You need to
before you can comment on or make changes to this bug.
EXACT STEPS LEADING TO PROBLEM:
1. choose an internet connection
2. set availability of msn account to "online"
3. wait till msn connects
4. goto settings > VoIP and IM accounts > msn account > uncheck "enable"
5. press "save"
6. you will be asked for reconnect. press "no"
7. goto advanced settings of msn account
port number should be default "1863"
port number was changed to "-2147483648"
EXTRA SOFTWARE INSTALLED:
pidgin protocols plugin
with the port "-2147483648" connecting is not possible and has to be set
manually to "1863" again in order to connect.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US)
AppleWebKit/532.5 (KHTML, like Gecko) Chrome/126.96.36.1999 Safari/532.5
I installed "Extra protocol plugins for Conversations and Contacts 0.8" and
after disabling Extras-Devel repository I succeed (before in Extras-Devel I got
a "upstart-job" dependency missing error when trying to install).
I can confirm this and assume that it's a telepathy-extras issue and not a
Maemo issue. As telepathy-extras is not official part of Maemo, can you please
file a bug report at
and link to it from here?
follow this link to track development of solution for bug:
For reference, I have users of The One Ring reporting similar issues. From my
understanding Connection Managers only report what settings they accept and it
is up to the caller to store the users settings, in this case RTComm. I am not
aware of anyway (besides a CM being evil and manipulating RTComm's settings
storage) that a CM could affect these settings. The only case I can think of
where this might cause issues is if the CM changes what settings it wants. The
One Ring has not done this in a while but I got a user reporting this issue
just the other day.
RTComm stores the settings at /home/user/.rtcom-accounts/accounts.cfg
I don't know if it would matter that much but posting the section that isn't
working (except password ;) ) might be helpful to some.
Closing in this bugtracker as INVALID as this should be handled in upstream
bugtracker (see URL field).