IPv6 support

[hrzr]

Am I able to use IPv6 addresses in reverse-proxy xml mapping?

[Tanganelli]

Yes, of course. The overall implementation is quite agnostic to IPv4 or IPv6 address. Did you try it?

[hrzr]

Yes. For the date of Oct 26 I've tried to put an IPv6 address into xml mapping file just to find out, that IPv6 address wouldn't even parse (parsing code). I've tried to rewrite this part to parse IPv6 adresses, but even after that I've encountered errors. If it will help, I could duplicate everything I've done and post it here for further discussion and improvement.

[gromain]

For the record, the URI parser here doesn't work either with the IPv6 convention, where the IP is encased in [].

The URI usually looks like this: coap://[fd01::315e:1253:681f:a123]/test.

[darkopetrovic]

Same here.

I just tried python coapclient.py -o GET -p coap://[aaaa::212:4b00:63a:7631]:5683/sensors and get:

Traceback (most recent call last):
  File "coapclient.py", line 162, in <module>
    main()
  File "coapclient.py", line 101, in main
    host, port, path = parse_uri(path)
  File "D:\projects\smartgrid\sft\python\CoAPthon\coapthon\utils.py", line 115, in parse_uri
    port = int(t[1])
ValueError: invalid literal for int() with base 10: ':212:4b00:63a:7631]:5683'

[Tanganelli]

Well, I'll check this. It could happen that I made some mistakes in the client part. IPv6 should work fine for the server part.

[Tanganelli]

Ok I fixed it.

[gromain]

I'm sorry for reopening this issue, but there is still a little bug.

It's when you do a request with a full IPv6 (example fd01:0000:0000:3ead:c5b2:bad0:6bb1:6dbf) but when the response received only gives back the shortened address (aka fd01::3ead:c5b2:bad0:6bb1:6dbf).

I believe the trouble starts here (or end here ;-) ), line 108 in messagelayer.py, function receive_response. This function hashes the tuple (host, port, response.mid), with the data received in the response, and then tries to compare it with the hash made in the function send_request, in the same file at line 216.

So I believe the function parse_uri (here) could be modified to include a contraction of the consecutive 0 in IPv6 addresses.