I just setup my piaware along with other feeders on my pi2
everything works great except when I try to do http://[ipv6 address]:8080
I got connection refused
even I have a nginx server running on the pi, IPv6 connection is still not working (ipv4 are working well)
Anyone got any idea?
I check iptables there is none
Thanks
Try enabling it?
sudo su
echo ipv6 >> /etc/modules
Then reboot.
root@piaware:/home/pi# ifconfig eth0
eth0 Link encap:Ethernet HWaddr b8:27:eb:xx:xx:xx
inet addr:10.x.x.x Bcast:10.x.x.x Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4612944 errors:0 dropped:2584 overruns:0 frame:0
TX packets:4925792 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:350101967 (333.8 MiB) TX bytes:880811608 (840.0 MiB)
No IPv6 info
pi@piaware ~ $ cat /etc/modules
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
# Parameters can be specified after the module name.
snd-bcm2835
pps-gpio
pi@piaware ~ $ sudo echo ipv6 >> /etc/modules
-bash: /etc/modules: Permission denied
pi@piaware ~ $ sudo su
root@piaware:/home/pi# echo ipv6 >> /etc/modules
root@piaware:/home/pi# cat /etc/modules
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
# Parameters can be specified after the module name.
snd-bcm2835
pps-gpio
ipv6
ipv6 wasn’t enabled, so I added it.
root@piaware:/home/pi# reboot
Broadcast message from root@piaware (pts/0) (Sun Jan 31 16:55:13 2016):
The system is going down for reboot NOW!
root@piaware:/home/pi#
login as: pi
pi@piaware ~ $ ifconfig eth0
eth0 Link encap:Ethernet HWaddr b8:27:eb:xx:xx:xx
inet addr:10.x.x.x Bcast:10.x.x.x Mask:255.255.255.0
inet6 addr: fe80::x/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:807 errors:0 dropped:1 overruns:0 frame:0
TX packets:1117 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:61076 (59.6 KiB) TX bytes:690682 (674.4 KiB)
IPv6 is enabled now.
Which image? Piaware or wheezy/Debian/Jessie/noobs.
Does IPv6 work?
What does ifconfig say?
I have IPv6 working on Jessie. I haven’t tested the web interface.
The piaware sdcard image is based on wheezy, I’m not sure how good the wheezy ipv6 support is. jessie seems OK and enables ipv6 by default; on my network here it does router discovery etc and picks up a global IPv6 address from my router with no extra config needed.
dump1090 (which is what is on port 8080) is not ipv6-aware so that’s unlikely to work. (a pull request to fix that would be welcome: github.com/mutability/dump1090)
However, I’d expect nginx / lighttpd / apache / etc to be able to serve IPv6 OK if the system as a whole is ipv6-enabled. I just checked a jessie image here with a global IPv6 address + lighttpd with dump1090 integration and it works fine over ipv6.
I did know that, I do have IPv6 configured
However, packages, like dump1090, piaware, and other feeders, do not support ipv6.
that’s why I got connection error after couples days research
My feeder location network has ipv6 only network, I have to use a 6to4 tunnel + nginx reverse proxy to fix it
so i can connect to the web interface via 8080, or other ports
As obj posted above, I have at least the web page running under ipV6 on Jessie. You will need to enable ipV6 (which I think you have already done) and then edit /etc/lighttpd/lighttpd.conf so that the web server will listen on the ipV6 address.
I added the following to lighttpd.conf:
# IPV6 stuff
# The old IPV4 address for backwards compatibility
server.bind = "192.168.0.35"
$SERVER"socket"] == "[2605:6000:The IPV6: address of the Pi:63c}:8080" {
server.document-root = "/var/www/"
}
Also, if it’s present, comment out the line:
#include_shell "/usr/share/lighttpd/use-ipv6.pl" + server.port
as it just confuses things…
Reboot lighttpd using
sudo service lighttpd restart
and you should be able to access the map via ipV6:
I added IPv6 support to dump1090-mutability, it seems to work OK in my limited tests.
Same situation here: having a Raspberry Pi (running a jessie/Raspbian) with an IPv6-only address,
I have to jump hoops to feed data to FA, using a secondary host on a dual-stacked network.
Indeed, I noticed it (before even coming across this thread) and am successfully running dump1090-mutability
binding to IPv6 addresses, thanks for the good work!
So now that dump1090-mutability is IPv6 enabled, it would be really nice for the FA feed server
to start announcing its IP address (dns AAAA record) and accepting feeds over IPv6.
Along with this, the piaware and its helpers would need to grow support for the inet6 protocol family
(to avoid a need for haproxy or nc kludges). Seems the piaware ( github.com/flightaware/piaware )
and helpers are based on tcl. What would be involved to add support for IPv6 there?
And lastly, the flightaware.com web site seems to be IPv4-only as well. I wouldn’t mind 
it become
dual-stacked, would avoid tunneling from some mobile networks, and avoid having to use a web proxy
to access it from IPv6-only networks.
So, are there any plans for making piaware and the web site accessible over IPv6 too?
The development version of piaware has ipv6 support. Once that’s out we will probably add AAAA records to piaware.flightaware.com
In the meantime, you may be able to make 2.1-5 on jessie do ipv6; try running piaware with “-serverhosts hullo.hou.flightaware.com”. mlat probably won’t work, you need a newer fa-mlat-client that understands v6 addresses for that.
There’s a v6 version of the website at ipv6.flightaware.com. IIRC the main website isn’t dual-stack because of some CDN-related issues that still need solving (+ the usual problems with v6 peering being pretty flaky)
That’s great news, very nice! (And thanks for a prompt reply!)
No luck, with -serverhosts hullo.hou.flightaware.com it still connects over IPv4, and when given the address explicitly it reports Address family for hostname not supported (although the ping6 and telnet 2600:c13:1002:4::191 1200 do succeed):
# /usr/bin/piaware -p /var/run/piaware.pid -serverhosts 2600:c13:1002:4::191 -debug
04/07/2016 17:58:59 creating pidfile /var/run/piaware.pid
04/07/2016 17:58:59 ****************************************************
04/07/2016 17:58:59 piaware version 2.1-5 is running, process ID 31997
04/07/2016 17:58:59 your system info is: Linux bananapi 3.4.108-bananian #2 SMP PREEMPT Thu Aug 13 06:08:25 UTC 2015 armv7l GNU/Linux
04/07/2016 17:58:59 Connecting to FlightAware adept server at 2600:c13:1002:4::191/1200
04/07/2016 17:58:59 Connection to adept server at 2600:c13:1002:4::191/1200 failed: couldn't open socket: no such device or address (Address family for hostname not supported)
04/07/2016 17:58:59 reconnecting in 115 seconds...
Nice, it works (although the forum is still directed to discussions.flightaware.com).
Yeah, some of the the large CDN and cloud providers are still dragging their feet towards IPv6. Hopefully this gets resolved eventually.
Hm, I guess it is a tcl8.5/tcl8.6/tcllauncher interaction. You need tcl 8.6 for IPv6 support. wheezy has 8.5, jessie has both 8.5 and 8.6. I guess that the copy of tcllauncher (this is what /usr/bin/piaware is) in the package might be explicitly linked against tcl8.5.
You could try launching piaware explicitly with tcl 8.6:
$ cd /usr/lib/piaware
$ sudo tclsh8.6 ./main.tcl -serverhosts hullo.hou.flightaware.com -debug
That’s it, you are right!
Yesss, that works! (almost)
The piaware’s main.tcl starts successfully and begins feeding data to FA over IPv6, nice!
(confirmed by tcpdump)
As you have guessed, the fa-mlat-client 0.2.4 is now next in line for trouble - for a silly reason, as it seems to be confused by colons in the IPv6 address of a server and is unable to parse the command line argument --udp-transport, distinguishing a port number from an IP address (which isn’t enclosed in square brackets, as is customary for an IPv6 address):
# tclsh8.6 ./main.tcl -serverhosts hullo.hou.flightaware.com -debug
04/07/2016 23:12:12 ****************************************************
04/07/2016 23:12:12 piaware version 2.1-5 is running, process ID 864
04/07/2016 23:12:12 your system info is: Linux bananapi 3.4.108-bananian #2 SMP PREEMPT Thu Aug 13 06:08:25 UTC 2015 armv7l GNU/Linux
04/07/2016 23:12:12 Connecting to FlightAware adept server at hullo.hou.flightaware.com/1200
04/07/2016 23:12:13 ADS-B data program 'dump1090-mutabi' is listening on port 30005, so far so good
04/07/2016 23:12:13 Starting faup1090: /usr/lib/piaware/helpers/faup1090 --net-bo-ipaddr localhost --net-bo-port 30005 --stdout --lat 46.xxx --lon 14.xxx
04/07/2016 23:12:13 Started faup1090 (pid 876) to connect to dump1090-mutabi
04/07/2016 23:12:13 Connection with adept server at hullo.hou.flightaware.com/1200 established
04/07/2016 23:12:14 FlightAware server SSL certificate validated
04/07/2016 23:12:14 encrypted session established with FlightAware
04/07/2016 23:12:14 autoUpdate in adept config is enabled, allowing update
04/07/2016 23:12:14 manualUpdate in adept config is enabled, allowing update
04/07/2016 23:12:14 multilateration support enabled (use piaware-config to disable)
04/07/2016 23:12:14 piaware received a message from dump1090-mutabi!
04/07/2016 23:12:14 logged in to FlightAware as user xxx
04/07/2016 23:12:15 multilateration support enabled (use piaware-config to disable)
04/07/2016 23:12:15 multilateration data requested, enabling mlat client
04/07/2016 23:12:15 Starting multilateration client: /usr/lib/piaware/helpers/fa-mlat-client --input-connect localhost:30005 --results beast,connect,feed.adsbexchange.com:30005 --udp-transport 2600:c13:1002:4::191:8128:3575100635
04/07/2016 23:12:16 mlat(886): fa-mlat-client 0.2.4 starting up
04/07/2016 23:12:16 mlat(886): Exiting on exception
04/07/2016 23:12:16 mlat(886): Traceback (most recent call last):
04/07/2016 23:12:16 mlat(886): File "/tmp/buildd/piaware-2.1/debian/venv/bin/fa-mlat-client", line 48, in <module>
04/07/2016 23:12:16 mlat(886): File "/tmp/buildd/piaware-2.1/debian/venv/bin/fa-mlat-client", line 32, in main
04/07/2016 23:12:16 mlat(886): ValueError: too many values to unpack (expected 3)
04/07/2016 23:12:16 the system told us that process 886 exited cleanly
04/07/2016 23:12:16 the system confirmed that process 886 exited with an exit status of 0
04/07/2016 23:12:16 got EOF from multilateration client
04/07/2016 23:12:43 11 msgs recv'd from dump1090-mutabi; 3 msgs sent to FlightAware
04/07/2016 23:12:44 piaware has successfully sent several msgs to FlightAware!
Yes. that’s what you need the newer fa-mlat-client for.
Got it now! Installed (on jessie) from github source using dev branch of piaware_builder. Looks like everything is running fine, TCP and UDP feeds over IPv6, yay!
Works perfect! now i can use other feeder to get data from dump1090 via ipv6
Speaking of dump1090-mutability, I glanced at the anet.c source module where most of the networking code resides.
Historically, the dump1090 with its anet.c was written by Salvatore Sanfilippo (= antirez). He later built another project (Redis), and re-used his anet.c module, which initially was IPv4-only. Some time in the 2.8 branch of the Redis project the anet.c was upgraded to support IPv6 too, but the network code in dump1090 stayed frozen until recently in the dump1090-mutability fork.
So I wonder, was the facelifting of anet.c in dump1090-mutability done from scratch (reinventing the wheel), or was the currently maintained code of anet.c from the Redis project backported to dump1090-mutability ?
It’s evolved separately.
This setup has now been working very well for the last two weeks: dump1090-mutability_1.15~dev, and piaware with its faup1090 & fa-mlat-client as built by piaware_builder dev branch.
All three (dump1090-mutability, piaware and fa-mlat-client) now use IPv6:
dump1090-mutability --net-bind-address ::1 ...
piaware -serverhosts hullo.hou.flightaware.com ...
piaware is able to talk to hullo.hou.flightaware.com over IPv6,
faup1090 is able to receive data from dump1090 over ::1]:30005,
fa-mlat-client is able to talk to dump1090 over ::1]:30005 and ::1]:30104,
and to fa server over IPv6 (–udp-transport)
There is still one detail that needs fixing: during piaware startup when it is deciding whether to start fa-mlat-client or not, it checks if a dump1090 is present on port 30005. The dump1090-mutability is listening on 30005, but is bound to ::1 and not to 127.0.0.1, so piaware decides there is no dump1090 and refuses to start fa-mlat-client:
piaware version 3.0~dev is running, process ID 13263
your system info is: Linux sleepy-rpi3b 4.4.7-v7+ #876 SMP Tue Apr 12 22:28:41 BST 2016 armv7l GNU/Linux
...
Connecting to FlightAware adept server at hullo.hou.flightaware.com/1200
Connection with adept server at hullo.hou.flightaware.com/1200 established
FlightAware server SSL certificate validated
encrypted session established with FlightAware
no ADS-B data program seen listening on port 30005 for 3 seconds, next check in 60s
logged in to FlightAware as user xxx
multilateration data requested
no ADS-B data program is serving on port 30005, not starting multilateration client yet
0 msgs recv'd from dump1090; 0 msgs sent to FlightAware
no ADS-B data program seen listening on port 30005 for 63 seconds, next check in 60s
no ADS-B data program is serving on port 30005, not starting multilateration client yet
Nevertheless, if fa-mlat-client is then started manually (with the same arguments as when piaware would be starting it, e.g. --udp-transport 2600:c13:1002:4::191:ppp:nnn), it does work and does communicate with hullo.hou.flightaware.com over IPv6.
So the only problem is that piaware does not see that dump1090 is listening on ::1]:30005, as it only checks its presence over IPv4.
As a workaround, I can use haproxy which proxies ::1]:30005 to 127.0.0.1:30005, so that port 30005 is reachable over both protocol families. Note that after a piaware is up and running with both its child processes, the haproxy can be turned off and everything continues to be running normally.
It would be nice to solve this missing detail eventually, for a truly IPv6-only setup.
That was it, it’s perfect now! Much appreciated!