ipv6 support

[Laurent Bigonville <l.bigonville@…>]

Hi,

adding ipv6 support would be great :)

[misc@…]

as far as i know, python already support ipv6 by default, can you give

more information about what is missing, and how you tested it ?

[Laurent Bigonville <l.bigonville@…>]

Yes python has ipv6 support.

But application must be modified.

You create socket with AF_INET and the resolver doesn't query fo ipv6 adresses.

There is an example in the documentation to have dual-stack application http://docs.python.org/lib/socket-example.html

[stlman # poczta.fm]

IPv6 would be especially useful for file transfers. While c2s

communication does not suffer from NAT at all, it is hell to set up everything for file transfers.

[stlman # poczta ' fm]

gajim-ipv6-filetransfer enables (I hope) filetransfers via ipv6. I haven't

tested if it really works but it doesn't break filetransfers with psi via ipv4.

For now it can work only under linux but there are slots for other systems. I don't know how to obtain a list of available IPv6 addresses under any other OS.

There is no support for client to server ipv6 connections because NATs work well enough for c2s TCP connections.

[steelman # poczta ' fm]

enable IPv6 filetransfers

[ressu@…]

c2s connections would benefit from IPv6 too. For me the jabber server i

connect to is located in the same subnet as my client. The subnet is behind a nat. Currently i use a set of SRV records to get the client to connect to the local address. If the client had IPv6 c2s the first SVR record would be correct and everything would work without all the trickery.

[didier@…]

Add IPv6 support for transport (not for proxy)

[phil@…]

The IPv6 patch worked just fine, thank you.

[ressu@…]

I can also confirm both patches as working. I'm one happy IPv6 camper ;)

[sgala@…]

I am testing a patch to support ipv6 without breaking ipv4.

I attach it, it seems to work here.

Missing: more testing and the proxy stuff, which I'll take care of if all goes well.

[anonymous]

I get this from the tracker every time I try to insert the patch:

Python Traceback

Traceback (most recent call last):

File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 316, in

dispatch_request

dispatcher.dispatch(req)

File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 201, in

dispatch

resp = chosen_handler.process_request(req)

File "/usr/lib/python2.3/site-packages/trac/attachment.py", line 343, in

process_request

self._do_save(req, attachment)

File "/usr/lib/python2.3/site-packages/trac/attachment.py", line 456, in

_do_save

for field, message in manipulator.validate_attachment(req,

attachment):

File "build/bdist.linux-i686/egg/tracspamfilter/adapters.py", line 102,

in validate_attachment

File "build/bdist.linux-i686/egg/tracspamfilter/api.py", line 70, in

test

File "build/bdist.linux-i686/egg/tracspamfilter/filters/akismet.py",

line 64, in test

File "build/bdist.linux-i686/egg/tracspamfilter/filters/akismet.py",

line 95, in _check_comment UnicodeDecodeError?: 'ascii' codec can't decode byte 0xc3 in position 152: ordinal not in range(128)

[sgala@…]

patch to get ipv4/ipv6 transport

[didier__AT__barvaux__DOT__org]

I did not try the gajim-ipv6.patch from sgala@…, but it seems to

be wrong. The socket::connect() function is called twice for the self._sock socket.

First one is added by the patch at line 113 in function NonBlockingTcp::connect(). The second one is at line 299 in function NonBlockingTcp::_do_connect(). NonBlockingTcp::_do_connect() is called at the end of NonBlockingTcp::connect(), so there is a problem.

The patch I supplied one month ago (gajim-ipv6-20060727.patch) has not this problem. I successfully tested it with:

• an IPv4-only ejabberd server,
• an IPv4/IPv6 ejabberd server,
• an IPv6-only ejabberd server.

[asterix]

trying the first patch result in a TB here when I try to send a file (ipv6 is not supported on my machine, kernel not compiled with it):

[...]

File "/home/asterix/gajim/src/common/connection_handlers.py", line 525, in _siResultCB

self.send_socks5_info(file_props, fast = True)

File "/home/asterix/gajim/src/common/connection_handlers.py", line 181, in send_socks5_info

sha_str, self._result_socks5_sid, file_propssid?)

File "/home/asterix/gajim/src/common/socks5.py", line 85, in start_listener

self.listener.bind()

File "/home/asterix/gajim/src/common/socks5.py", line 813, in bind

self._serv = socket.socket(family, socket.SOCK_STREAM)

File "/usr/lib/python2.4/socket.py", line 148, in init

_sock = _realsocket(family, type, proto)

socket.error: (97, 'Address family not supported by protocol')

one solution could be to put the socket.socket() call in a try/except to catch the exception and fall back to IPV4, is it ok to do that ?

[sgala@…]

The approach you are trying is wrong. The right approach to ipv6/ipv4 development, as illustrated in U Drepper introduction ( http://people.redhat.com/drepper/userapi-ipv6.html ) is to use getaddrinfo for the connection parameters.

This works irrespective of ipv4/v6 configuration.

The patch I posted has, as didier pointed, a small problem, but the design is much cleaner and using the right technique. I can't send right now the updated version, as I don't have handy the hard disk of my "deceased" old laptop, but will do so soon.

[sgala]

new version, slightly changed to address small error in patch

[sgala]

I'm still trying to understand file transfer. SOCKS protocol does not make sense at all with ipv6, where everybody will have globally routable addresses by default. So I guess the socks stuff should be left ipv4 only, and use the public ipv6 for file transfer. ANy clue?

[asterix]

yes ! thanks for the patch, could some ppl try it before I commit it for 0.11 ?

[asterix]

(In [7535]) [sgala] IPV6 support for connection fith server. see #1969

[asterix]

sgala, could you do the same for filetransfert ? the first patch does that, but not with socket.getaddrinfo()

[shtrom-gajim@…]

It would be nice if Gajim could fall back on IPv4 when the IPv6 host does not seem to have a listenning Jabberd (instead of giving an error in the case of a dual stack server only listening on IPv4).

[shtrom-gajim@…]

The above problem seems to be in common/xmpp/transports_nb.py, in the connect() method lines 109 and below:

for ai in socket.getaddrinfo(server[0],server[1],socket.AF_UNSPEC,socket.SOCK_STREAM):

try:

self._sock=socket.socket(*ai[:3]) self._sock.setblocking(False) self._server=ai[4] break

except:

(...)

It is following the same scheme as in transports.py, but instead of connecting straight away, it justs sets some values, which, even if no IPv6 service exist on the server, will not raise any exception. The first address obtained via getaddrinfo will then always be used, and the connection will fail afterwards, in the _do_connect() method.

Maybe instead of the default on_connect_failure() method, a specific one should be added which will try to connect to the next address resolved for the host and, finally, call the usual on_connect_failure() only if nothing worked. Moreover, in case the connection is correctly established, it might be advisable to set back the normal on_connect_failure() method.

Just a guess, but I hope it helps (:

[junglecow]

shtrom-gajim@… wrote:

Maybe instead of the default on_connect_failure() method, a specific one should be added which will try to connect to the next address resolved

Let's not add more twistedness to xmpppy. Gajim already tries to connect to all hosts from SRV lookup, so this code should be integrated with it.

BTW, sgala, I have a question about this patch: in the try…catch block, you test for EINPROGRESS, but which call could cause this exception? And since _server is set last, doesn't this mean that _server can have the wrong value when we get EINPROGRESS?

[Laurent Bigonville <l.bigonville@…>]

Is someone still working on this?

[sgala@…]

Laurent: It seems to be "good enogh", I am using it routinely. The file transfer is still missing because I can't understand its logics (if any :P) so I can't patch it.

Other thing missing is to use some thread for the getaddrinfo so that it does not block there, and restore "pure" non-blockedness to gajim. Currently each call to getaddrinfo is a potential blocking point. Again, I'm not confident enough with python to try this in a clean way.

[sgala]

all my ipv6 (or protocol) related patches, current as of now

[asterix]

(In [8248]) [Santiago Gala] IPv6 filetransfert. see #1969

[Laurent Bigonville]

And what about the failback if the ipv6 connection is not possible?

[asterix]

it's in #2958

[sgala]

Current version of ipv6 patch