vino-server & vuze just started to not accept connections is this a tcp6 thing?

wikapuki · 12-23-2009, 11:35 AM

uname -a
Linux jilldando 2.6.30-2-486 #1 Sat Sep 26 00:03:46 UTC 2009 i686 GNU/Linux

Hi,

Today after vino-server stopped accepting connections in its usual way. Connection refused (10061)

Also vuze started complaining today about another process is using 127.0.0.1:6801 and I have it using another port anyway, but it also reported a long tcp6 address error.

I did a netstat and can see the vino-server is using tcp6 but not tcp, so was wandering how this setup had changed?

netstat -l -t -p

Code:

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp6       0      0 [::]:5900               [::]:*                  LISTEN      4218/vino-server
tcp6       0      0 [::]:4206               [::]:*                  LISTEN      4374/java
tcp6       0      0 [::]:x11                [::]:*                  LISTEN      3599/X
tcp6       0      0 [::]:www                [::]:*                  LISTEN      1666/apache2

Could it be osirismd pads seahorse problems?

Can you show me a way to track this down?

nimnull22 · 12-24-2009, 08:08 PM

More interesting why does it listen IPv6 only?
Have you done some updates or any other things with your linux?

wikapuki · 12-25-2009, 12:44 PM

Hi, yes almost everyday, so looking at updates for day 2009-12-22 (there is always a full poweroff each night), I found:

Code:

Log started: 2009-12-22  23:37:54
Preparing to replace netbase 4.37 (using .../archives/netbase_4.40_all.deb) ...
Unpacking replacement netbase ...
Setting up netbase (4.40) ...
Installing new version of config file /etc/services ...
Installing new version of config file /etc/init.d/networking ...
[snip]
Setting up libhal1 (0.5.14-1) ...
Setting up libhal-storage1 (0.5.14-1) ...
Setting up hal (0.5.14-1) ...
Reloading system message bus config...done.
Starting Hardware abstraction layer: hald.

Did not include the mono update logs.

DOH, reading the windows timestamp on /etc/services not the accessed time.
No entry in there for 5900, but don't know if it ever was.

Had a look at changelog for netbase, no help:
netbase (4.40) unstable; urgency=low

* Fixed removal of /etc/sysctl.d/ on purge. (Closes: #560164)
* etc-services: added zabbix-agent (10050), zabbix-trapper (10051).
(Closes: #560175)

On the 23rd though wireshark got an update but Vino-server and azareus (Vuse) had stopped working with tcp and chosen to use tcp6.

Code:

Preparing to replace wireshark 1.2.4-3 (using .../wireshark_1.2.5-1_i386.deb) ...
[snip]
Setting up wireshark-common (1.2.5-1) ...
Setting up wireshark (1.2.5-1) ...

I did add to /etc/modprobe.d/blacklist.conf
blacklist ipv6
but that made no difference so removed it.

So its definately after the update on 22/12/2009 update.

Log ended: 2009-12-22 23:41:42
I think I was able to access on the am via vino, but may have done the wireshark update
Log started: 2009-12-23 12:47:03

and after this and a reboot (as I was testing some Main switch on/off software) that it stopped allowing access.

Can't see how wireshark would effect??
So apt-get remove wireshark and a reboot later, still no difference.
Then did a apt-get autoremove but still Vuze and Vino won't work. Vuze insist that something else is using port 127.0.0.1:6886.

wikapuki · 12-26-2009, 08:01 AM

I had the thought, re the vino-server problem, after reading this thread that as it was binding to tcp6 and there was no IPv6 address in the netstat listing;

netstat -l -t -p | grep vino

Code:

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp6       0      0 [::]:5900               [::]:*                  LISTEN      4218/vino-server

that it was binding to the loopback lo even though via the desktop I had applied allow remote access from the beginning.

So I had a look at the settings of remote_access (Vino-server's settings). NOTE there is no entry for network_interface

gconftool-2 -a /desktop/gnome/remote_access

Code:

 view_only = false
 alternative_port = 5900
 prompt_enabled = false
 icon_visibility = always
 lock_screen_on_disconnect = false
 disable_xdamage = false
 use_alternative_port = false
 mailto = 
 enabled = true
 disable_background = false
 require_encryption = false
 network_interface = 
 authentication_methods = [vnc]
 vnc_password = SOMEFING:)
 use_upnp = false

I decided to be implicit about the network_interface it should use and did the following (after checking what ehternet name was ipconfig -a):

gconftool-2 -s /desktop/gnome/remote_access/network_interface -t string eth0

Restart the machine and presto, remote desktop access via vino-server is working again. You can see the diffrenece in the netstat results.
netstat -l -t -p | grep vino

Code:

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 JillDando-00-e0-4c:5900 *:*                     LISTEN      4122/vino-server
tcp6       0      0 fe80::2e0:4cff:fe7:5900 [::]:*                  LISTEN      4122/vino-server

Hope this helps any others. Onto Vuse, probably can do similar there too.

:-) Nope its Java doing the samething

ps ax | grep azur

Code:

 6121 ?        S      0:00 /bin/bash /home/PATH/azureus/azureus
 6166 ?        Sl     0:22 /opt/java/jre1.6.0_13/bin/java -Xmx128m -cp ./azplugins_2.1.3.jar:./azrating_1.3.1.jar:./azupdaterpatcher_1.8.3.jar:./Azureus2.jar:./swt.jar:./Updater.jar -Djava.library.path=/home/PATH/azureus -Dazureus.install.path=/home/PATH/azureus -Dazureus.script=/home/PATH/azureus/azureus -Dazureus.script.version=2 org.gudy.azureus2.ui.swt.Main

netstat -l -p | grep 6166

Code:

udp6       0      0 [::]:1900               [::]:*                              6166/java
udp6       0      0 [::]:16680              [::]:*                              6166/java

Also did manual update of java to jre1.6.0_17 which did not cure. So java IPv6 hunting time.

wikapuki · 12-27-2009, 02:12 PM

Doing more TinTerNet research I found this thread and basically Debian squeeze in /etc/sysctl.d/bindv6only.conf has IPV6_V6ONLY enabled by default!

so changed to
net.ipv6.bindv6only = 0
and rebooted

vuze works fine once more

Have not bothered to try removing the implicit etho in the vino-server to see if it solve that too.

Turns out that java the applications an IPv6 enabled machines goes wrong.

Installed IPv6 on my windows XP box during all this and the facebook photo java uploader stopped working and installed Vuze and it would not work either. Also no matter what I tried in Vuze options it refused to get a socket, since it depends upon Java, I expected this.

Removed IPv6 and bingo, both apps started working once more.

So yes its a good idea to have
net.ipv6.bindv6only = 1
since that will inform developers to report this upstream to Sun/Java.

Writing a little script for the Linux box, that leaves it enabled until Vuze needs to go to work, then it disables it, restarts network. Vuze does its thing, then it enables it on Dl completion.

Opinions: Is this a bad idea?

bgoodr · 03-13-2010, 11:51 PM

Quote:

Originally Posted by wikapuki

Writing a little script for the Linux box, that leaves it enabled until Vuze needs to go to work, then it disables it, restarts network. Vuze does its thing, then it enables it on Dl completion.
Opinions: Is this a bad idea?

Seems reasonable to me. At Debian Bug 560044 I found the recipe that worked in a script:

Code:

sudo sed -i 's/net.ipv6.bindv6only = 1/net.ipv6.bindv6only = 0/' /etc/sysctl.d/bindv6only.conf && sudo invoke-rc.d procps restart

This command does not require executing ifup or ifdown.

bg