Cross compiling to an armhf target failed because the linker could not find rpl_malloc. This is due to some autotools "magic".

Feel free to cherry pick the fix on my fork here:
fabricedesre@219fdee

pressing ctrl-c on the console causes a segfault on exit. Not end of the world of course, but still tedious.

(gdb) signal SIGINT
Continuing with signal SIGINT.

Program received signal SIGSEGV, Segmentation fault.
0x77fda648 in __pthread_join (t=0x77c95d18, res=0x0) at src/thread/pthread_join.c:14
14      while ((tmp = t->tid)) __timedwait_cp(&t->tid, tmp, 0, 0, 0);
(gdb) bt
#0  0x77fda648 in __pthread_join (t=0x77c95d18, res=0x0) at src/thread/pthread_join.c:14
#1  0x77f3be2f in pkm_wait_thread (pkm=<optimized out>) at pkmanager.c:1656
#2  0x77f3f6fd in pagekite_thread_wait (pkm=<optimized out>) at pagekite.c:479
#3  0x00401035 in main (argc=<optimized out>, argv=<optimized out>) at pagekitec.c:300

Can we somehow not do that?

A solution would need to a) not lose important debug info, b) not fail to recover from network issues and c) not hard fail if libpagekite starts up before the networking subsystem.

This may actually be caused by oversized DNS responses and embedded resolver limitations. Making sure the records don't get too large at the server side might also help.

The default build attempts to run the tests, which never works in a cross compile environment.

Fortunately, it doesn't interfere with the make completing

Version: 0.91.191211

When "http" is given as the protocol twice, it fails to start, but doesn't really say why. At least in this instance, it needed to change from http to "http-8083" but that's non-obvious

root@eg-03B679:/# pagekitec 80 http blah.pagekite.me 0 averybadpassword 8083 ht
tp blah.pagekite.me 0 averybadpassword
t=2019-12-11 15:00:13.675; ts=5df1047d; tid=77f2ae84; ll=0; msg=Initialized pagekitec manager v0.91.190530C/0.91.190530C (using 495121 bytes)
t=2019-12-11 15:00:14.178; ts=5df1047e; tid=77f2ae84; ll=1; msg=pkm_lookup_and_add_frontend: getaddrinfo(fe6_091c.b5p.us, 443) failed:
t=2019-12-11 15:00:14.179; ts=5df1047e; tid=77f2ae84; ll=2; msg=Starting manager in new thread
t=2019-12-11 15:00:14.181; ts=5df1047e; tid=77b28d74; ll=3; msg=Tick!  [repeating=yes, next=16, tunnels=0, v=0.91.190530C]
t=2019-12-11 15:00:15.208; ts=5df1047f; tid=77ae2d74; ll=4; msg=pkm_lookup_and_add_frontend: getaddrinfo(fe6_091c.b5p.us, 443) failed:
t=2019-12-11 15:00:15.210; ts=5df1047f; tid=77ae2d74; ll=5; msg=Connecting to [185.112.146.199]:443 (session=new, is fast, in DNS)
t=2019-12-11 15:00:15.255; ts=5df1047f; tid=77ae2d74; ll=6; msg=5: TLSv1.2 connection established: ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD 
t=2019-12-11 15:00:15.328; ts=5df1047f; tid=77ae2d74; ll=7; msg=Connecting to [185.112.146.199]:443 (session=5df1047f:c44b8ca05403fe93969e1ef75c7f541ba0e6eda1, is fast, in DNS)
t=2019-12-11 15:00:15.371; ts=5df1047f; tid=77ae2d74; ll=8; msg=5: TLSv1.2 connection established: ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD 
t=2019-12-11 15:00:15.561; ts=5df1047f; tid=77ae2d74; ll=9; msg=Connect failed: -1
t=2019-12-11 15:00:15.562; ts=5df1047f; tid=77ae2d74; ll=a; msg=pkmanager.c: Rejected by front-end

It should be possible to run libpagekite-based front-end relays.

There is a buffer overrun in the printable_binnary function in pkutils.c. It can be triggered with the following test case:

char data[48];
int i;
data[0] = 'a';
for (i = 1; i < 48; i++)
  data[i] = -1;

pk_log_raw_data(PK_LOG_ALL, "app", data, 48);

This is probably the issue that causes #29.

Using bad credentials, I get a status file that briefly said "no network" but then switched to "flying"

kitename is non-existant,

Mon Jun 22 17:11:01 2020 user.notice et-remote: tid=77f1ae84; ll=0; msg=Initialized et-remote manager v0.91.200311C/0.91.200311C (using 495121 bytes)
Mon Jun 22 17:11:01 2020 daemon.info monit[2439]: 'et-remote' started
Mon Jun 22 17:11:01 2020 daemon.info monit[2439]: 'et-remote' monitor action done
Mon Jun 22 17:11:01 2020 user.err et-remote: tid=77f1ae84; ll=1; msg=pkm_lookup_and_add_frontend: getaddrinfo(abcd.myetactica.com, 443) failed: Name does not resolve
Mon Jun 22 17:11:01 2020 user.err et-remote: tid=77f1ae84; ll=2; msg=pkm_lookup_and_add_frontend: getaddrinfo(abcd.myetactica.com, 443) failed: Name does not resolve
Mon Jun 22 17:11:01 2020 user.err et-remote: tid=77f1ae84; ll=3; msg=pkm_lookup_and_add_frontend: getaddrinfo(abcd.myetactica.com, 443) failed: Name does not resolve
Mon Jun 22 17:11:02 2020 user.err et-remote: tid=77f1ae84; ll=4; msg=pkm_lookup_and_add_frontend: getaddrinfo(fe6_091c.myetactica.com, 443) failed: Name does not resolve
Mon Jun 22 17:11:02 2020 user.notice et-remote: tid=77f1ae84; ll=5; msg=Starting manager in new thread
Mon Jun 22 17:11:02 2020 user.notice et-remote: tid=77b18d74; ll=6; msg=Tick!  [repeating=yes, next=16, status=10, tunnels=0, v=0.91.200311C]
Mon Jun 22 17:11:03 2020 daemon.info monit[2439]: 'et-remote' process is running with pid 17405
Mon Jun 22 17:11:03 2020 user.notice et-remote: tid=77ad2d74; ll=7; msg=Connecting to [185.112.146.199]:443 (session=new, is fast)
Mon Jun 22 17:11:05 2020 user.notice et-remote: tid=77ad2d74; ll=8; msg=7: TLSv1.2 connection established: ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
Mon Jun 22 17:11:06 2020 user.notice et-remote: tid=77ad2d74; ll=9; msg=Connecting to [185.112.146.199]:443 (session=5ef0e629:8128c9079125166e7a2008c0378e048363d418c5, is fast)
Mon Jun 22 17:11:06 2020 user.notice et-remote: tid=77ad2d74; ll=a; msg=7: TLSv1.2 connection established: ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
Mon Jun 22 17:11:06 2020 user.notice et-remote: tid=77ad2d74; ll=b; msg=7: Connected!
Mon Jun 22 17:11:07 2020 user.err et-remote: tid=77ad2d74; ll=c; msg=DDNS: Update failed for abcd.myetactica.com (http://dnsup.myetactica.com/?hostname=abcd.myetactica.com&myip=185.112.146.199&sign=f31f7337f4674fbda940cecbd7fc2209abba1061b36e26c9 -> badauth)
Mon Jun 22 17:11:07 2020 user.notice et-remote: tid=77ad2d74; ll=d; msg=Network appears to be down.
Mon Jun 22 17:11:18 2020 user.notice et-remote: tid=77b18d74; ll=e; msg=Tick!  [repeating=yes, next=16, status=90, tunnels=1, v=0.91.200311C]
Mon Jun 22 17:11:34 2020 user.notice et-remote: tid=77b18d74; ll=f; msg=Tick!  [repeating=yes, next=21, status=90, tunnels=1, v=0.91.200311C]
Mon Jun 22 17:11:55 2020 user.notice et-remote: tid=77b18d74; ll=10; msg=Tick!  [repeating=yes, next=28, status=40, tunnels=1, v=0.91.200311C]
Mon Jun 22 17:12:23 2020 user.notice et-remote: tid=77b18d74; ll=11; msg=Tick!  [repeating=yes, next=37, status=40, tunnels=1, v=0.91.200311C]
Mon Jun 22 17:13:00 2020 user.notice et-remote: tid=77b18d74; ll=12; msg=Tick!  [repeating=yes, next=49, status=40, tunnels=1, v=0.91.200311C]
Mon Jun 22 17:13:49 2020 user.notice et-remote: tid=77b18d74; ll=13; msg=Tick!  [repeating=yes, next=65, status=40, tunnels=1, v=0.91.200311C]

I am using libpagekite with ir manager v0.91.171102C

After calling the 'pagekite_thread_start' function while debugging under gdb, I am seeing a segmentation fault in one of the libpagekite threads. The gdb information gives me:

Thread 6 "myprogram" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x742fe440 (LWP 1118)]
0x76a48842 in pk_connect_ai (pkc=0x74e7f6f8, ai=0x74e7f6d8, reconnecting=0, n=4, requests=0x702e7d3b, session_id=0x6674726f <error: Cannot access memory at address 0x6674726f>, ctx=0x6f696c6f,
    hostname=0x2076616e <error: Cannot access memory at address 0x2076616e>) at pkproto.c:754
754         requests[i].status = PK_KITE_FLYING;

The pagekite messages leading up to this segmentation fault are:

t=2018-06-18 10:08:29.448; ts=5b27bcdd; tid=742fe440; ll=3; msg=No front-end wanted, randomly using some.url (status=1000080)
t=2018-06-18 10:08:29.448; ts=5b27bcdd; tid=742fe440; ll=4; msg=Connecting to [nnn.nnn.nnn.nnn]:ppp (session=new)
t=2018-06-18 10:08:29.558; ts=5b27bcdd; tid=742fe440; ll=5; msg=8: TLSv1.2 connection established: ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
t=2018-06-18 10:08:31.562; ts=5b27bcdf; tid=742fe440; ll=6; msg=Connect failed: 8
t=2018-06-18 10:08:31.562; ts=5b27bcdf; tid=742fe440; ll=7; msg=pkmanager.c: Connection error -30002
t=2018-06-18 10:08:43.331; ts=5b27bceb; tid=74aff440; ll=8; msg=Tick!  [repeating=yes, next=16, tunnels=0, v=0.91.171102C]
t=2018-06-18 10:08:59.347; ts=5b27bcfb; tid=74aff440; ll=9; msg=Tick!  [repeating=yes, next=21, tunnels=0, v=0.91.171102C]
t=2018-06-18 10:08:59.592; ts=5b27bcfb; tid=742fe440; ll=a; msg=No front-end wanted, randomly using some.url (status=1000080)
t=2018-06-18 10:08:59.593; ts=5b27bcfb; tid=742fe440; ll=b; msg=Connecting to [nnn.nnn.nnn.nnn]:ppp (session=new)
t=2018-06-18 10:08:59.692; ts=5b27bcfb; tid=742fe440; ll=c; msg=8: TLSv1.2 connection established: ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD

I have disguised the url, as 'some.url' and ip address, as 'nnn.nnn.nnn.nnn:ppp' for security reasons.

Is this a known problem ?

The code calls 'pagekite_init', 'pagekite_lookup_and_add_frontend', and 'pagekite_add_kite' successfully before calling 'pagekite_thread_start' successfully. While it is possible that the frontend and the kite may not be configured correctly, I do not think a segmentation fauilt should occur in code. If this is a known problem which has been fixed I will get the latest libpagekite and build again.

Is there any way to run Pagekite on Windows Embedded Compact 7?

There are cases where pkc_flush may block forever. Here is one such scenario:

• pk_connect_ai is called.
• pk_connect_ai calls pkc_start_ssl, which in turn calls pkc_do_handshake. Let's assume pkc_do_handshake does not fail, but it does not complete the handshake immediately, and sets SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE.
• Because the TLS handshake is not completed, subsequent calls to pkc_write or pkc_read will end up calling pkc_do_handshake again. Let's assume that in the next pkc_write call there is a handshake error and pkc_do_handshakesets CONN_STATUS_BROKEN.
• This call to pkc_flush will now block forever in a busy loop.

(Note: Before the recent changes, this busy loop would break when the tunnel is disconnected. After this commit tunnels are not disconnected anymore if they are in the middle of a change, meaning this busy loop never completes.)

There are at least two cases where this call to PKS_close will attempt to close the wrong file descriptor:

1. If gethostbyname failed (here), addr will be NULL, and PKS_close will attempt to close fd 0 (which will actually close the process' stdin)

2. If gethostbyname succeeded but PKS_socket failed (here), sockfd will be <0 (typically -1) and not a valid fd, but PKS_close will attempt to close it anyway.

Case 1 was actually spotted while debugging #31: Once the process had run out of available fds, gethostbyname would fail resulting in fd 0 (stdin) being closed. Here's an excerpt of the lsof output:

COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
pagekitec 4021   tc  cwd    DIR   7,24     1024   16 /mnt/cf2/pagekite
pagekitec 4021   tc  rtd    DIR   0,11      380 1094 /
pagekitec 4021   tc  txt    REG   7,34     9892    7 /usr/local/bin/pagekitec
pagekitec 4021   tc  mem    REG   0,11    82139 1311 /lib/libresolv-2.11.1.so
pagekitec 4021   tc  mem    REG   0,11    25161 1337 /lib/libnss_dns-2.11.1.so
pagekitec 4021   tc  mem    REG   0,11    50002 1328 /lib/libnss_files-2.11.1.so
pagekitec 4021   tc  mem    REG   0,11  1524288 1353 /lib/libc-2.11.1.so
pagekitec 4021   tc  mem    REG   0,11   112629 1331 /lib/libpthread-2.11.1.so
pagekitec 4021   tc  mem    REG   0,11    13147 1348 /lib/libdl-2.11.1.so
pagekitec 4021   tc  mem    REG   7,40  1513038   22 /usr/local/lib/libcrypto.so.0.9.8
pagekitec 4021   tc  mem    REG   7,40   325555   21 /usr/local/lib/libssl.so.0.9.8
pagekitec 4021   tc  mem    REG   0,11   175870 1315 /lib/libm-2.11.1.so
pagekitec 4021   tc  mem    REG   7,33    46872    6 /usr/local/lib/libev.so.4.0.0
pagekitec 4021   tc  mem    REG   7,44  1890392   14 /lib/libpagekite.so.1.0.0
pagekitec 4021   tc  mem    REG   0,11   128707 1322 /lib/ld-2.11.1.so
pagekitec 4021   tc    0u  IPv4  71902      0t0  TCP box:45368->box:www (CLOSE_WAIT)
pagekitec 4021   tc    1u   CHR  136,0      0t0    3 /dev/pts/0
pagekitec 4021   tc    2u   CHR  136,0      0t0    3 /dev/pts/0
pagekitec 4021   tc    3u  0000    0,7        0   10 anon_inode
pagekitec 4021   tc    4u  0000    0,7        0   10 anon_inode
pagekitec 4021   tc    5u  IPv4  31506      0t0  TCP 192.168.0.200:52302->ec2-54-183-178-65.us-west-1.compute.amazonaws.com:https (CLOSE_WAIT)
pagekitec 4021   tc    6u  IPv4  27951      0t0  TCP 192.168.0.200:56740->ec2-52-63-95-185.ap-southeast-2.compute.amazonaws.com:https (CLOSE_WAIT)
[...]

If the file stops being valid, (removed externally for instance) the status file is simply never written again. https://github.com/pagekite/libpagekite/blob/master/contrib/backends/pagekitec.c#L231 opens the file, but the return value of fprintf https://github.com/pagekite/libpagekite/blob/master/contrib/backends/pagekitec.c#L147 is never checked.

https://wiki.debian.org/ReproducibleBuilds/Howto#Files_in_data.tar_contain_timestamps

The configure script fails while checking for jni.h when cross-compiling.
Looks like this is caused by ax_jni_include_dir.m4 using AC_CHECK_FILE, which dies when cross-compiling.

The PageKite protocol allows connectors to replace outdated connections (instead of being rejected as duplicate), if a matching tunnel session ID is provided. This should be implemented in libpagekite.

The changes in libpagekite/Makefile.am since v0.91.160811 break parallel builds:

arm-v4t-linux-gnueabi-gcc -DHAVE_CONFIG_H -I. -I..     -I../include -g -O2 -MT tests-tests.o -MD -MP -MF .deps/tests-tests.Tpo -c -o tests-tests.o `test -f 'tests.c' || echo './'`tests.c
make[3]: *** No rule to make target `../libpagekite/libpagekite.la', needed by `tests'.  Stop.
make[3]: *** Waiting for unfinished jobs....

It would be quite nice to be able to ship a mod_pagekite for Apache. This would simplify adding support to things like Xampp.

From e-mail (lightly edited):

I just came across this:

a2f26f6

I had not realized you were actually using CLOCK_REALTIME (and
now gettimeofday) for waiting for a timeout. This is
problematic if the system time can change (via NTP or because
of the user manually adjusts the time/date).

I would like to suggest to use clock_gettime with
CLOCK_MONOTONIC for this purpose, if available. If
clock_gettime and CLOCK_MONOTONIC are not available, then you
can fall back to gettimeofday (but this has problems).

Here's some additional background:

https://bugs.python.org/issue23428
https://blog.habets.se/2010/09/gettimeofday-should-never-be-used-to-measure-time.html
https://stackoverflow.com/questions/14248033/clock-monotonic-and-pthread-mutex-timedlock-pthread-cond-timedwait

The CLOCK_MONOTONIC support on Linux is great.

Other platforms deserve nice things too.

Currently if libpagekite decides to attempt to connect to a certain relay which is rejecting connections (either deliberately or due to intermediate firewalls), under certain circumstances it does not give up and fall back to another relay as it should.

This needs to be investigated and is probably a bug in the relay selection algorithms.

Currently the URL for the "fancy" version of the "kite offline" error page is hard coded. It should be configurable at runtime.

Hi,

Just got libpagekite working -- great stuff! Is it possible to create a new x.y.pagekite.me sub domain from the libpagekite API? Or do I need to create x.y.pagekite.me in the pagekit.net web interface before I can connect to it from libpagekite?

Thanks,
Cliff

Hi. I have been using pagekite.py with a raspberry pi and loves it. I Came across this lib and I wonder if I could use in a esp8266 firmware ? My project uses this firmware https://github.com/thorrak/brewpi-esp8266
thanks in advance

This used to build without any help, but it's less happy now...

mips-openwrt-linux-uclibc-gcc -Os -pipe -mips32 -mtune=mips32 -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float  -I/home/karlp/src/smartgate_firmware/openwrt-aa/staging_dir/target-mips_uClibc-0.9.33.2/usr/include -I/home/karlp/src/smartgate_firmware/openwrt-aa/staging_dir/target-mips_uClibc-0.9.33.2/include -I/home/karlp/src/smartgate_firmware/openwrt-aa/staging_dir/toolchain-mips_gcc-4.6-linaro_uClibc-0.9.33.2/usr/include -I/home/karlp/src/smartgate_firmware/openwrt-aa/staging_dir/toolchain-mips_gcc-4.6-linaro_uClibc-0.9.33.2/include  -shared -o libpagekite.so pkerror.o pkproto.o pkconn.o pkblocker.o pkmanager.o pklogging.o pkstate.o utils.o pd_sha1.o pkwatchdog.o -lpthread -lssl -lcrypto -lm -lev
/home/karlp/src/smartgate_firmware/openwrt-aa/staging_dir/toolchain-mips_gcc-4.6-linaro_uClibc-0.9.33.2/lib/gcc/mips-openwrt-linux-uclibc/4.6.3/../../../../mips-openwrt-linux-uclibc/bin/ld: pkerror.o: relocation R_MIPS_HI16 against `pk_error' can not be used when making a shared object; recompile with -fPIC
pkerror.o: could not read symbols: Bad value

When connecting with HTTPS, the SSL certs are not yet verified, making the whole thing insecure.

used to work in the past

log from connecting

t=2019-10-02 14:00:59.202; ts=5d94ad9b; tid=77b30d74; ll=2e; msg=Connecting to [159.69.241.209]:443 (session=new, in DNS)
t=2019-10-02 14:00:59.600; ts=5d94ad9b; tid=77b30d74; ll=2f; msg=5[pkc_start_ssl]: Failed to prepare SSL object!
t=2019-10-02 14:00:59.601; ts=5d94ad9b; tid=77b30d74; ll=30; msg=Connect failed: 5
t=2019-10-02 14:00:59.602; ts=5d94ad9b; tid=77b30d74; ll=31; msg=pkmanager.c: TLS handshake failed

Version: This is pagekitec.c from libpagekite 0.91.190530C
using musl-libc 1.1.23

Just a small enhancement for Makefile: it turns out that gcc 4.6 wants the libs on the end when linking. I wasn't able to make httpkite, I had a lot of "undefined reference" errors with cc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3

Then I moved "$(CLINK)" to the end of lines, now everything works fine.

This is an enhancement suggestion. The libpagekite library would be more useful if it were possible to call the sequence 'pagekite_thread_start'/'pagekite_thread_stop' more than once in order to start and stop pagekite, once the library is loaded when used by another library or an application. The reason that this would be very useful is because the end-user may want to control the particular cases in which he will want pagekite to be active in exposing a local URL to the Internet. Currently the library can only be used a single time to start/stop pagekite, after which pagekite can not be started again without the library failing to work properly. This makes the running of pagekite through the libpagekite API a situation where pagekite is either running a single time through the life of the application or not being run at all. I find this use of pagekite in the libpagekite API to be too rigid for the type of applications for which I want to use pagekite, where it is imperative to control when pagekite should be running and how often pagekite should be running based on other criteria related to the application itself.

I have tried, after calling the necessary libpagekite initialization functions, starting/stopping the pagekite thread more than once but while the 'pagekite_thread_start' function successfully returns a second time it does not make the connection between my kite and my frontend, and the attempt to call a subsequent 'pagekite_thread_stop' call never returns. Similarly I have tried calling the entire cycle of my pagekite initialization functions, followed by 'pagekite_thread_start'/'pagekite_thread_stop', followed by 'pagekite_free', more than once but libpagekite crashes on the second call to 'pagekite_init' so it does not succeed. This is not a criticism of the library as I understand that the library was not designed to work in either of the ways I tried, but I wanted to relate my attempts nonetheless.

This is just an enhancement suggestion to make libpagekite more useful as an API for those who want to use it in another library or application. The basic pagekite/libpagekite functionality is quite useful for end-users and programmers, to expose local web servers or data to the Internet, but without the ability to turn on or off pagekite functionality in a flexible way it is much less useful for me as a programmer.

I'm doing some stress testing to verify the fix for #31 and #35 and I am seeing pagekitec being terminated due to an assertion failure in libev. Apparently libpagekite is passing a negative fd to libev. Here are the last bits of the log output:

[...]
t=2017-02-22 17:40:58.735; ts=58adcd2a; tid=b4b3fb70; ll=122b; msg=Connecting to [54.173.41.120]:443 (session=new)
t=2017-02-22 17:41:03.499; ts=58adcd2f; tid=b733fb70; ll=122c; msg=Tick!  [repeating=yes, next=21, v=0.91.161104C]
t=2017-02-22 17:41:24.503; ts=58adcd44; tid=b733fb70; ll=122d; msg=Tick!  [repeating=yes, next=16, v=0.91.161104C]
t=2017-02-22 17:41:40.506; ts=58adcd54; tid=b733fb70; ll=122e; msg=Tick!  [repeating=yes, next=16, v=0.91.161104C]
t=2017-02-22 17:41:56.509; ts=58adcd64; tid=b733fb70; ll=122f; msg=Tick!  [repeating=yes, next=16, v=0.91.161104C]
t=2017-02-22 17:42:12.513; ts=58adcd74; tid=b733fb70; ll=1230; msg=Tick!  [repeating=yes, next=16, v=0.91.161104C]
t=2017-02-22 17:42:28.516; ts=58adcd84; tid=b733fb70; ll=1231; msg=Tick!  [repeating=yes, next=16, v=0.91.161104C]
t=2017-02-22 17:42:28.516; ts=58adcd84; tid=b4b3fb70; ll=1232; msg=6: TLS handshake failed!
t=2017-02-22 17:42:28.517; ts=58adcd84; tid=b4b3fb70; ll=1233; msg=6: Connected!
t=2017-02-22 17:42:28.517; ts=58adcd84; tid=b733fb70; ll=1234; msg=6: Disconnected, closing.
pagekitec: ev.c:3836: ev_io_start: Assertion `("libev: ev_io_start called with negative fd", fd >= 0)' failed.
Aborted

In order to better evaluate the pagekitec_update_ts field in the status message files, it would be helpful to have the #define STATUS_MIN_INTERVAL 240 value included.

Also, when the process exits, it would be nice if it could either a) remove the file, or b) write a "shutdown" state or similar, to avoid having to go and check the pid manually all the time.

When I try to connect with my own front-end, pagekitec crashes in function pk_parse_kite_request.
This happens only on 32 bit systems.
My command line: ./pagekitec -v -v -v -v -S -I 1111 http N.N.N.N 2222 12345

In my opinion, the error in this line is pkproto.c # L711:

  int llen = strlen(line);
  copy = malloc(llen+1);
  strcpy(copy, line);

  char* end = copy + llen + 1;
 *end = '\0';

An extra '\0' is written to the area outside the allocated memory.
When I remove the "+1", everything works as expected.
Sorry for my english :)

I have received logs which indicate that a very long-lived libpagekite process may fail to detect when a relay is decommissioned, and will keep trying to connect to a server which is no longer providing service.

This needs further investigation and may indicate bugs in how libpagekite evaluates the availability of relays.

As a workaround, implementors may want to restart the libpagekite thread periodically to ensure it picks up new settings.

I am using a dev machine that has Lua installed but not the dev package (so no lua.h). Despite configure not finding lua.h, pkcommon.h still wants to include it, which breaks the build:

In file included from pagekitec.c:31:0:
../../libpagekite/pkcommon.h:155:19: fatal error: lua.h: No existe el archivo o el directorio
 #  include <lua.h>
                   ^
compilation terminated.

I also tried to configure --without-lua, same results.

I looked inside pkcommon.h and found that the offending line is guarded by HAVE_LUA checks (pkcommon.h#L154). I am not sure where HAVE_LUA is defined (it is not present in config.h) but anyway I think this should be changed to check for HAVE_LUA_H instead.

Seen with a log level of PK_LOG_ALL:

#0 0x00007fea6df62428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1 0x00007fea6df6402a in __GI_abort () at abort.c:89
#2 0x00007fea6dfa47ea in __libc_message (do_abort=do_abort@entry=1, fmt=fmt@entry=0x7fea6e0bb8a2 "*** %s ***: %s terminated\n") at ../sysdeps/posix/libc_fatal.c:175
#3 0x00007fea6e04556c in __GI___fortify_fail (msg=, msg@entry=0x7fea6e0bb884 "stack smashing detected") at fortify_fail.c:37
#4 0x00007fea6e045510 in __stack_chk_fail () at stack_chk_fail.c:28
#5 0x00007fea6e304f91 in pk_log_raw_data (level=level@entry=524288, prefix=prefix@entry=0x7fea6e309ab7 "W", data=data@entry=0x7fea6e72b299, bytes=bytes@entry=48) at pklogging.c:124
#6 0x00007fea6e2ff649 in pkc_raw_write (pkc=pkc@entry=0x7fea6e7164c0, data=data@entry=0x7fea6e72b299 "\026\003\001\002", length=length@entry=517) at pkconn.c:362
#7 0x00007fea6e2ffa24 in pkc_write (pkc=pkc@entry=0x7fea6e7164c0, data=0x7fea6e72b299 "\026\003\001\002", length=517) at pkconn.c:479
#8 0x00007fea6e303f03 in pkm_chunk_cb (fe=0x7fea6e705790, chunk=0x7fea6e72af40) at pkmanager.c:234
#9 0x00007fea6e2fd709 in pk_parser_parse_new_data (parser=parser@entry=0x7fea6e72af20, length=length@entry=670) at pkproto.c:299
#10 0x00007fea6e2fd910 in pk_parser_parse (parser=0x7fea6e72af20, length=670,
data=data@entry=0x7fea6e705824 "299\r\nSID: 313\r\nProto: https\r\nHost: remote.3d1be7d141b76e117b84c154f309a9381864be00.box.knilxof.org\r\nPort: 443\r\nRIP: ::ffff:71.198.7.190\r\nRPort: 48006\r\n\r\n\026\003\001\002") at pkproto.c:346
#11 0x00007fea6e302d4b in pkm_tunnel_readable_cb (loop=, w=, revents=) at pkmanager.c:613
#12 0x00007fea6dd22d73 in ev_invoke_pending () from /usr/lib/x86_64-linux-gnu/libev.so.4
#13 0x00007fea6dd263de in ev_run () from /usr/lib/x86_64-linux-gnu/libev.so.4
#14 0x00007fea6e301885 in ev_loop (flags=0, loop=) at /usr/include/ev.h:835
#15 pkm_run (void_pkm=0x7fea6e703010) at pkmanager.c:1673
#16 0x00007fea6d45c70a in start_thread (arg=0x7fea6c710700) at pthread_create.c:333
#17 0x00007fea6e03382d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

The most recent version of pagekite.py adds the IP address of the relay itself to the query string of the page displayed when a kite is offline. This is done to allow the offline page itself to give better feedback to the user if they are connected to "the wrong relay" for some reason.

This should be added to libpagekite as well.

In scenarios with poor Internet connectivity, libpagekite seems to be leaking file descriptors. Eventually this leads to exhaustion of available fds for the process that is using libpagekite.

This can be reproduced by using dummynet / ipfw to simulate poor network connectivity conditions. For example the following commands will limit network bandwidth to 1Mbit/s and introduce a packet loss rate of 16%:

ipfw pipe 1 config bw 1Mbit/s plr 0.16
ipfw add 1000 pipe 1 ip from any to any

With this configuration, and monitoring with lsof, I see a steadily increasing number of TCP connections stalled in the CLOSE_WAIT state.

thank you size_t

pkproto.c: In function 'pk_format_chunk':
pkproto.c:439:52: warning: format '%ld' expects argument of type 'long int', but argument 4 has type 'ssize_t {aka int}' [-Wformat=]
                     bytes += sprintf(tbuf + bytes, "%s: %ld\r\n", h, v); \
                                                    ^
pkproto.c:451:22:
   _add_sst("SKB",    chunk->remote_sent_kb);
                      ~~~~~~~~                       
pkproto.c:451:3: note: in expansion of macro '_add_sst'
   _add_sst("SKB",    chunk->remote_sent_kb);
   ^~~~~~~~

intheory %zd is c99 standard, but YMMV

On fresh installs of Ubuntu 14.04 and Ubuntu 16.04, building and installing libpagekite does not update the ld cache.

$ pagekitec
pagekitec: error while loading shared libraries: libpagekite.so.1: cannot open shared object file: No such file or directory
$ ls /usr/local/lib/libpagekite.so*
/usr/local/lib/libpagekite.so    /usr/local/lib/libpagekite.so.1.0.0
/usr/local/lib/libpagekite.so.1
$ sudo ldconfig
$ pagekitec
This is pagekitec.c from libpagekite 0.91.170301C.
[...]

Manually running ldconfig after make install fixes the problem.

This is apparently due to the Makefile calling libtool -n which builds symlinks as needed but skips updating the cache.

References:

• https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684981
• esnet/iperf#153
• AravisProject/aravis#26

I don't know if it is reasonable to try to fix this but perhaps it would be a good idea to document it (for example print a message from make install)