Opened 11 years ago

Closed 7 years ago

Last modified 5 years ago

#4121 closed Bug report (outdated)

Fails to check for newer version

Reported by: Kerry Owned by:
Priority: normal Component: FileZilla Client
Keywords: update check Cc: kerrykurtz@…
Component version: Operating system type: Windows
Operating system version: XP SP3

Description

After click on Check for Updates the check will always fail even if there is a newer version. The problem appears to be the URL used to check for updates. There is no ampersand (&) separators between the parameters as seen in the attached image. The URL is to updatecheck.php with a single parameter (platform) with a value of i586-pc-mingwmscversion=3.1.6osversi...

Attachments (1)

FZ-UpdateCheck.jpg (21.3 KB) - added by Kerry 11 years ago.

Download all attachments as: .zip

Change History (10)

Changed 11 years ago by Kerry

Attachment: FZ-UpdateCheck.jpg added

comment:1 Changed 11 years ago by Tim Kosse

Status: newmoreinfo

Assuming you use the same IP address for submitting this report and checking for updates, your request to check for updates didn't even reach this server.

comment:2 Changed 11 years ago by Kerry

Cc: kerrykurtz@… added
Status: moreinfonew

Yet, when I put the following into my browser I get a response:
http://update.filezilla-project.org/updatecheck.php?platform=i586-pc-mingw32msvc&version=3.1.6&osversion=5.1&beta=1

In tracing the TCP requests I noted the following:
With Browser: the HTTP request is GET /updatecheck.php (with params)
With FZ: the HTTP request is GET http://update.filezilla-project.org/updatecheck.php?platform=i586-pc-mingw32msvc&version=3.1.6&osversion=5.1&beta=1
Following is the basics of the TCP trace (the first is FZ, 2nd is from browser, 3rd is FZ):

  • IPv4 (192.168.32.2 - update.filezilla-project.org)
    • TCP (1786 - 80) ConvID = 321

HTTP GEThttp://update.filezilla-project.org/updatecheck.php

  • TCP (1791 - 80) ConvID = 341

HTTP GET/updatecheck.php

  • TCP (1794 - 80) ConvID = 373

HTTP GEThttp://update.filezilla-project.org/updatecheck.php

The (bad) HTTP frame is:

Frame:

+ Ethernet: Etype = Internet IP (IPv4)

  • Ipv4: Next Protocol = TCP, Packet ID = 29772, Total IP Length = 259
    • UINT8 Versions: IPv4, Internet Protocol; Header Length = 20

UINT8 Version: (0100....) IPv4, Internet Protocol
UINT8 HeaderLength: (....0101) 20 bytes (0x5)

  • UINT8 DifferentiatedServicesField: DSCP: 0, ECN: 0

UINT8 DSCP: (000000..) Differentiated services codepoint 0
UINT8 ECT: (......0.) ECN-Capable Transport not set
UINT8 CE: (.......0) ECN-CE not set

UINT16 TotalLength: 259 (0x103)
UINT16 Identification: 29772 (0x744C)

+ UINT16 FragmentFlags: 16384 (0x4000)

UINT8 TimeToLive: 64 (0x40)
UINT8 NextProtocol: TCP, 6(0x6)
UINT16 Checksum: 12553 (0x3109)
IPv4Address SourceAddress: 192.168.32.2
IPv4Address DestinationAddress: 213.239.222.5

  • Tcp: Flags=...PA..., SrcPort=1786, DstPort=HTTP(80), Len=219, Seq=3093195786 - 3093196005, Ack=2191301078, Win=64240 (scale factor 2) = 256960

UINT16 SrcPort: 1786
UINT16 DstPort: HTTP(80)
UINT32 SequenceNumber: 3093195786 (0xB85E6C0A)
UINT32 AcknowledgementNumber: 2191301078 (0x829C99D6)

  • UINT8 DataOffset: 80 (0x50)

UINT8 DataOffset: (0101....) (20 bytes)
UINT8 Reserved: (....000.)
UINT8 NS: (.......0) Nonce Sum not significant

+ TCPFlags Flags: ...PA...

UINT16 Window: 64240 (scale factor 2) = 256960
UINT16 Checksum: 61743 (0xF12F)
UINT16 UrgentPointer: 0 (0x0)

AsciiStringTerm Command: GET

AsciiStringTerm Location: http://update.filezilla-project.org/updatecheck.php
AsciiStringTerm platform: i586-pc-mingw32msvc
AsciiStringTerm version: 3.1.6
AsciiStringTerm osversion: 5.1
AsciiStringTerm beta: 1

AsciiStringTerm ProtocolVersion: HTTP/1.1
AsciiStringTerm Host: update.filezilla-project.org:80
AsciiStringTerm UserAgent: FileZilla 3.1.6
AsciiStringTerm Connection: close
UINT16 HeaderEnd: CRLF

The Good HTTP frame is:

  • HTTP: Request, GET /updatecheck.php

AsciiStringTerm Command: GET

  • AsciiStringTerm URI: /updatecheck.php?platform=i586-pc-mingw32msvc&version=3.1.6&osversion=5.1&beta=1

AsciiStringTerm Location: /updatecheck.php
AsciiStringTerm platform: i586-pc-mingw32msvc
AsciiStringTerm version: 3.1.6
AsciiStringTerm osversion: 5.1
AsciiStringTerm beta: 1

AsciiStringTerm ProtocolVersion: HTTP/1.1
AsciiStringTerm Host: update.filezilla-project.org
AsciiStringTerm UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7 VRE Toolbar 1.42
AsciiStringTerm Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
AsciiStringTerm Accept-Language: en-us,fr-ca;q=0.8,zh-cn;q=0.7,es-mx;q=0.5,de-de;q=0.3,zh;q=0.2
AsciiStringTerm Accept-Encoding: gzip,deflate
AsciiStringTerm Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
AsciiStringTerm Keep-Alive: 300
AsciiStringTerm Connection: keep-alive
AsciiStringTerm X-OPENID-ANTI-PHISHING: VeriSign's OpenID SeatBelt/1.0.0.3705
AsciiStringTerm Cache-Control: max-age=0
UINT16 HeaderEnd: CRLF

Seems to me that FZ is sending the URL instead of the URI.
Have you reviewed the server errors?

comment:3 Changed 11 years ago by Tim Kosse

Status: newmoreinfo

Your attempts with the browser do appear in my Apache logs, but your attamps from withing FileZilla do not appear at all, not even in the error log.

I think you have a broken router and/or firewall that sabotages the connection. Uninstall all firewalls and plug your computer directly into the modem, bypassing all consumer grade routers.

comment:4 Changed 11 years ago by Tim Kosse

Remark: URLs are a subset of URIs, so that cannot be the problem.

comment:5 Changed 11 years ago by Kerry

Status: moreinfonew

I did have my firewall turned off firewalls, except the inbuilt one on my router and it is an inbound firewall wall. Besides, if it was a firewall issue it would not effect the other 4 pc's I have connected (each with a different firewall) and it would also effect access via browser. (BTW: URIs (resource within a domain) are a subset of URLs (domain and resource) not the other way around - you can get the URI from the URL, but you cannot extrapolate a URL just knowing the URI).
That said, I did try direct connection to my DSL modem. Exact same result. FZ failed.

comment:6 Changed 11 years ago by Tim Kosse

Status: newmoreinfo

You want to read http://en.wikipedia.org/wiki/URI

Every URL is also a valid URI, hence URLs are a subset of URIs

comment:7 Changed 11 years ago by Kerry

Status: moreinfonew

OK, going by that link... FZ is sending the request formatted as an absoluteURI for going through a proxy (according to http://tools.ietf.org/html/rfc2616 section 5.1.2) which all HTTP/1.1 servers must accept.
However, it appears that your server is just bit-bucketing for some reason and not even logging that fact. I say that because FZ fails when direct connected (there is no response from the server which is Apache version 2.2.3 (Debian) which is HTTP/1.1 (as far as I know).
Big, question... Does it work for you? (it used to work for me until an upgrade - not sure if it was to 3.0 or 3.1).

comment:8 Changed 11 years ago by Tim Kosse

Status: newmoreinfo

Works fine for me and hundreds of thousands of users that checked for updates during the previous week.

It has to be something unique to your networking environment. Put a network sniffer between your router and the modem to check what's going on.

comment:9 Changed 7 years ago by Alexander Schuch

Resolution: outdated
Status: moreinfoclosed

No reply for more than 28 days.

Please retry with the most recent version of FileZilla.
If you still have this problem, please reopen this issue.

Note: See TracTickets for help on using tickets.