id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
11410	josm fails to fall back to ipv4 in case of non functional ipv6 / obscure ipv6 detection	flohoff	team	"==== What steps will reproduce the problem?

Have a OS with ipv6 enabled and be on a network without ipv6. 

My setup was - Debian/Wheezy - online with wlan0 on a ipv4 only network. Still i had
ipv6 link locals on the interfaces:

wlan0     Link encap:Ethernet  HWaddr 00:24:d7:91:9e:38  
          inet addr:192.168.177.157  Bcast:192.168.177.255  Mask:255.255.255.0
          inet6 addr: fe80::224:d7ff:fe91:9e38/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:21496 errors:0 dropped:0 overruns:0 frame:0
          TX packets:22740 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:12348871 (11.7 MiB)  TX bytes:3044331 (2.9 MiB)

and a default route to a non exitant link local ( left over from a different network
i moved away from ). Still i had no global IPv6 address.
 
flo@p2:~$ sudo route -6
Kernel IPv6 routing table
Destination                    Next Hop                   Flag Met Ref Use If
::/0                           fe80::226:2dff:fe0f:670d   UGDAe 1024 5     0 wlan0
::/0                           ::                         !n   -1  1724256 lo
::1/128                        ::                         Un   0   1   101 lo
ff00::/8                       ::                         U    256 1     0 wlan0
::/0                           ::                         !n   -1  1724256 lo

There is still a ipv6 default route because i moved (suspended - drove home - resumed) 
from a ipv6 capable to a non ipv6 network.

With this setup josm reports:

INFO: Detected useable IPv6 network, prefering IPv6 over IPv4.

and fails to contact the API persistently. This is most likely not a working ipv6 setup with only a link local address and loopback.

I then flushed the link local address from the wlan0 interface with

ip -6 addr flush dev wlan0

which resulted in josm reporting:

INFO: Detected no useable IPv6 network, prefering IPv4 over IPv6 after next restart.

and was still not able to contact the API.

i then flushed the routing table with

ip -6 route flush dev wlan0

and restarted josm which resulting in beeing able to contact the API.



The expected behaviour would be that EVERY single API call/network connection is capable of dynamically falling back to ipv4 at runtime. ipv6 can disappear in the middle of a JOSM session while moving to a different wireless network or can come back. Failing anything until restarting josm and probably cleaning the OS from autoconfiguration left overs is unacceptable.


{{{
Revision: 8327
Repository Root: http://josm.openstreetmap.de/svn
Relative URL: ^/trunk
Last Changed Author: Don-vip
Last Changed Date: 2015-05-04 23:48:52 +0200 (Mon, 04 May 2015)
Build-Date: 2015-05-04 21:53:02
URL: http://josm.openstreetmap.de/svn/trunk
Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last Changed Rev: 8327

Identification: JOSM/1.5 (8327 en) Linux Debian GNU/Linux 7.8 (wheezy)
Memory Usage: 524 MB / 1820 MB (343 MB allocated, but free)
Java version: 1.8.0_45, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Dataset consistency test: No problems found

Plugins:
- RoadSigns (30977)
- Tracer2 (30984)
- buildings_tools (31100)
- kendzi3d-jogl (37)
- kendzi3d_Improved_by_Andrei (1.0.179-SNAPSHOT)
- log4j (30892)
- measurement (30892)
- reverter (30990)
- terracer (30892)
- turnlanes (30892)
- turnrestrictions (31034)
- utilsplugin2 (31072)
}}}
"	defect	closed	normal		Core		duplicate	ipv6 api autodetection fallback regression