[SOLVED] Android randomly stopped connecting to IPv6 proftpd server ONLY over 4G????

psycroptic · 09-13-2014, 03:32 PM

here's a weird one. as usual, i changed absolutely nothing about either my proftpd server config or my Verizon Galaxy S4 phone. I have a proftpd server hosted on a Linux server connected directly to a Comcast modem, no router involved. The server runs on port 30000, and forces passive mode with a required password login, and only gives read-access to a non-writable NTFS-formatted hard drive. Everything was working fine yesterday; i wake up today, and the phone will not connect. Weirdly, it WILL connect if it is on a Wi-Fi connection with IPv6. But if the phone is connected via LTE, i cannot.

Nothing is shown in the logs, and packet traces show 0-length TCP packets being exchanged between the server and client on port 30000, until the client gives up; passive mode never begins. I have tried 3 different FTP clients on the phone, and none are able to access. The phone can access the server via IPv4 absolutely fine.

/etc/proftpd.conf:

Code:

ServerName                      ""
ServerType                      standalone
DefaultServer                   on
Port                            30000
LogFormat                       %a %h %l %u %t \"%r\" %s %b
UseIPv6                         on
Umask                           022
MaxInstances                    100
User                            nobody
Group                           nobody
AllowOverwrite                  off
AllowRetrieveRestart            on
RequireValidShell               off
TimeoutIdle                     300
TimeoutNoTransfer               300
TimeoutLogin                    300
UseReverseDNS                   off
SystemLog                       /var/log/ftp.log
#SystemLog                      /dev/null
TransferLog                     /var/log/transfer.log
ExtendedLog                     /var/log/extftp.log

<Limit SITE_CHMOD>
  DenyAll
</Limit>

<Limit WRITE>
  DenyAll
</Limit>

<Limit LOGIN>
  AllowUser ftp
  DenyAll
</Limit>

<Limit EPRT PORT>
    DenyAll
</Limit>

<Anonymous /mnt/usb>
  User                          ftp
  Group                         ftp
  UserAlias                     anonymous ftp
  AnonRequirePassword           yes
</Anonymous>

packet trace during a connection attempt:

Code:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on external, link-type EN10MB (Ethernet), capture size 65535 bytes
15:20:11.212553 IP6 2600:1004:b109:85db:6cb6:7a19:70ef:b527.55874 > 2001:558:6016:29:----:----:----:----.30000: Flags [S], seq 3994604824, win 13680, options [mss 1368,sackOK,TS val 132791 ecr 0,nop,wscale 6], length 0
15:20:11.212711 IP6 2001:558:6016:29:----:----:----:----.30000 > 2600:1004:b109:85db:6cb6:7a19:70ef:b527.55874: Flags [S.], seq 1799640472, ack 3994604825, win 28560, options [mss 1440,sackOK,TS val 1704336614 ecr 132791,nop,wscale 5], length 0
15:20:12.006118 IP6 2600:1004:b109:85db:6cb6:7a19:70ef:b527.55874 > 2001:558:6016:29:----:----:----:----.30000: Flags [S], seq 3994604824, win 13680, options [mss 1368,sackOK,TS val 132891 ecr 0,nop,wscale 6], length 0
15:20:12.006216 IP6 2001:558:6016:29:----:----:----:----.30000 > 2600:1004:b109:85db:6cb6:7a19:70ef:b527.55874: Flags [S.], seq 1799640472, ack 3994604825, win 28560, options [mss 1440,sackOK,TS val 1704336852 ecr 132791,nop,wscale 5], length 0
15:20:13.214152 IP6 2001:558:6016:29:----:----:----:----.30000 > 2600:1004:b109:85db:6cb6:7a19:70ef:b527.55874: Flags [S.], seq 1799640472, ack 3994604825, win 28560, options [mss 1440,sackOK,TS val 1704337215 ecr 132791,nop,wscale 5], length 0
15:20:14.043706 IP6 2600:1004:b109:85db:6cb6:7a19:70ef:b527.55874 > 2001:558:6016:29:----:----:----:----.30000: Flags [S], seq 3994604824, win 13680, options [mss 1368,sackOK,TS val 133091 ecr 0,nop,wscale 6], length 0
15:20:14.043787 IP6 2001:558:6016:29:----:----:----:----.30000 > 2600:1004:b109:85db:6cb6:7a19:70ef:b527.55874: Flags [S.], seq 1799640472, ack 3994604825, win 28560, options [mss 1440,sackOK,TS val 1704337463 ecr 132791,nop,wscale 5], length 0
15:20:16.414147 IP6 2001:558:6016:29:----:----:----:----.30000 > 2600:1004:b109:85db:6cb6:7a19:70ef:b527.55874: Flags [S.], seq 1799640472, ack 3994604825, win 28560, options [mss 1440,sackOK,TS val 1704338175 ecr 132791,nop,wscale 5], length 0
15:20:18.101615 IP6 2600:1004:b109:85db:6cb6:7a19:70ef:b527.55874 > 2001:558:6016:29:----:----:----:----.30000: Flags [S], seq 3994604824, win 13680, options [mss 1368,sackOK,TS val 133492 ecr 0,nop,wscale 6], length 0
15:20:18.101698 IP6 2001:558:6016:29:----:----:----:----.30000 > 2600:1004:b109:85db:6cb6:7a19:70ef:b527.55874: Flags [S.], seq 1799640472, ack 3994604825, win 28560, options [mss 1440,sackOK,TS val 1704338681 ecr 132791,nop,wscale 5], length 0
15:20:22.414138 IP6 2001:558:6016:29:----:----:----:----.30000 > 2600:1004:b109:85db:6cb6:7a19:70ef:b527.55874: Flags [S.], seq 1799640472, ack 3994604825, win 28560, options [mss 1440,sackOK,TS val 1704339975 ecr 132791,nop,wscale 5], length 0
15:20:26.112054 IP6 2600:1004:b109:85db:6cb6:7a19:70ef:b527.55874 > 2001:558:6016:29:----:----:----:----.30000: Flags [S], seq 3994604824, win 13680, options [mss 1368,sackOK,TS val 134294 ecr 0,nop,wscale 6], length 0
15:20:26.112139 IP6 2001:558:6016:29:----:----:----:----.30000 > 2600:1004:b109:85db:6cb6:7a19:70ef:b527.55874: Flags [S.], seq 1799640472, ack 3994604825, win 28560, options [mss 1440,sackOK,TS val 1704341084 ecr 132791,nop,wscale 5], length 0
^C

Proftpd logs absolutely nothing in /var/log/ftp.log. i would post client connection logs from Android, but none of the (horridly wretched, btw) FTP clients i've tried give you access to any. (I've tried AndFTP, Astaro File Manager, and ES File Explorer). Both the proftpd daemon and the server itself have been restarted, as has the phone.

Ser Olmy · 09-13-2014, 05:43 PM

There's nothing in the Proftpd log because the TCP handshake is never completed. The client sends a SYN packet to the server, which responds with a SYN/ACK, and that's it. The next thing that happens is that the client resends the same SYN packet.

Something, possibly (or even probably) a router/component on the 4G provider network, is filtering the SYN/ACK response from the server and prevents it from ever reaching the client.

It is possible for a routing error to manifest itself in one direction only. Have you tried a traceroute6 from the server to the phone?

psycroptic · 09-13-2014, 05:54 PM

server to phone:

Code:

traceroute to 2600:1004:b107:5eff:5071:60ba:feec:bfae (2600:1004:b107:5eff:5071:60ba:feec:bfae), 30 hops max, 80 byte packets
 1  * * *
 2  xe-3-2-0-32767-sur01.ruralhillrd.tn.nash.comcast.net (2001:558:162:50::1)  9.446 ms  9.398 ms  9.319 ms
 3  xe-4-1-11-0-ar03.nashville.tn.nash.comcast.net (2001:558:160:52::1)  10.804 ms xe-5-1-11-0-ar01.goodslettvll.tn.nash.comcast.net (2001:558:160:45::1)  10.273 ms  10.209 ms
 4  he-5-6-0-0-cr01.56marietta.ga.ibone.comcast.net (2001:558:0:f696::1)  24.707 ms he-2-13-0-0-cr01.350ecermak.il.ibone.comcast.net (2001:558:0:f691::1)  29.969 ms he-5-6-0-0-cr01.56marietta.ga.ibone.comcast.net (2001:558:0:f696::1)  24.961 ms
 5  2001:559::46e (2001:559::46e)  26.575 ms 2001:559::1022 (2001:559::1022)  74.433 ms 2001:559::46e (2001:559::46e)  26.804 ms
 6  vl-51.car2.Atlanta2.Level3.net (2001:1900:1c:1::4)  21.119 ms 2001:1900:4:1::42a (2001:1900:4:1::42a)  22.396 ms vl-52.car2.Atlanta2.Level3.net (2001:1900:1c:2::4)  16.852 ms
 7  2001:1900:4:1::435 (2001:1900:4:1::435)  31.149 ms  30.151 ms  30.054 ms
 8  vl-11.car2.Nashville1.Level3.net (2001:1900:4:1::365)  20.863 ms  28.268 ms  26.126 ms
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * *^C

looks like a timeout at a Level3 router, then?

Ser Olmy · 09-13-2014, 06:02 PM

Not necessarily. The last router to respond is a Level3 router, but what about the next one?

A trace in the other direction may tell you what the next step is supposed to be. Remember you'll be seeing the same routers from the opposite side, so the IPv6 addresses will differ from those in the first trace. The networks will be the same, though... unless routing is asymmetric, in which case the trace will tell you absolutely nothing.

A BGP looking glass server should tell you if 2600:1004:b107:5eff::/64 (or 2600:1004:b107::/48 or whatever) is being advertised properly. In any case, the fault most likely lies with the 4G provider, and you should report the problem to them.

psycroptic · 09-13-2014, 06:26 PM

phone to server, using some app called "IPv6 and More"

Code:

Traceroute from this device to 2001:558:6016:29:----:----:----:----
Max Hops : 30

[1] 2600:1004:b107:5eff:0:30:5e8f:fd40

[2]  *

[3] 2001:4888:22:2010:208:d:0:2

[4] 2001:4888:22:2060:208:25::

[5] 2001:4888:22:2000:208:2a1::

[6] 2001:4888:22:2005:208:1::

[7] 2001:4888:22:2005:208:1::

[8] 2001:4888:22:1001:208:24::

[9]  *

[10]  *

[11]  *

[12]  *

[13]  *

[14]  *

[15]  *

that last address "2001:4888:22:1001:208:24::" has WHOIS data showing it belonging to "Cellco Partnership DBA Verizon Wireless,US"

and head is spinning with the BGP stuff

will investigate "looking glass".

psycroptic · 09-15-2014, 02:41 PM

magically started working again today, looks like it was a temporary Verizon IPv6 fail. Thanks for the info.