Linux Mint

empty response from https-sites through VPN

Bug #1377106 reported by Stepan on 2014-10-03

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	Linux Mint	New	Undecided	Unassigned

Bug Description

1)Mint 17 Qiana Cinnamom 32-bit

2) my action step-by-step
1. connect to VPN server (pptp) (sites with same services but without VPN connection works fine)
2. enter to site with https trought VPN connection (independently of the browser. problem happen on Chrome and Firefox)
3. reqest query of statistic data perhaps with too long string. for example "https://.../admin/stats_cdrs/process?orderby=&query[process]=1&query[id_clients]=16&query[cc_serial]=&query[account]=...&query[smartPeriod]=curDay&query[start_date]=2014-10-03&query[start_time]=00%3A00%3A00&query[stop_date]=2014-10-03&query[stop_time]=23%3A59%3A59&query[tz]=Etc%2FGMT-4&query[client_type]=0&query[id_clients_name]=...&query[code_name]=&query[code]=&query[fields][]=status&query[fields][]=call_origin&query[fields][]=call_time&query[fields][]=id_clients&query[fields][]=client_name&query[fields][]=account&query[fields][]=gw_ip&query[fields][]=gw_name&query[fields][]=id_companies&query[fields][]=company_name&query[fields][]=code_country&query[fields][]=code_name&query[fields][]=code&query[fields][]=id_packages&query[fields][]=package_name&query[fields][]=package_time&query[fields][]=src_number&query[fields][]=dst_number&query[fields][]=session_time&query[fields][]=billed_time&query[fields][]=rate&query[fields][]=cost&query[fields][]=res_status&query[fields][]=disconnect_cause&query[fields][]=id_cdrs&query[fields][]=conf_id&query[fields][]=call_id&query[fields][]=uniq_id&query[fields][]=src_number_ext&query[fields][]=src_number_bill&query[fields][]=dst_number_ext&query[fields][]=dst_number_bill&query[fields][]=setup_time&query[fields][]=connect_time&query[fields][]=disconnect_time&query[fields][]=pdd&query[fields][]=scd&query[fields][]=switch_code&query[fields][]=custom&query[fields][]=bytes_in&query[fields][]=bytes_out&query[fields][]=id_voip_hosts&query[fields][]=vh_name&query[fields][]=cdr_source&query[id_companies]=&query[id_code_decks]=&query[src_number]=&query[dst_number]=&query[conf_id]=&query[duration]=nonzero&query[match_clients]=&query[match_codes]=&query[session_time_gte]=&query[session_time_lte]=&query[id_voip_hosts]=&query[id_cdrs]=&query[call_origin]=&query[id_packages]=&query[cost]=&query[status]=&query[id_groups]=&query[res_status]=&query[disconnect_cause]=&query[output]=web&query[output_email]=&query[documents_tpl]=default"
(query like that "https://.../admin/stats_cdrs/process" works fine)

3)ERR_EMPTY_RESPONSE in chrome. and the same in ff

4) I expected page with statistic

5) problem happened always. but I think only in Mint 17. In Mint 14 Nadya everything works fine.

P.S. sorry for my English

See original description

Tags:

Stepan (st-shishkin) on 2014-10-03

description:

updated

Revision history for this message

aPlatypus (william-full-moon) wrote on 2015-11-17:

I have experienced this problem with 17.2. At first I thought it was the DNSmasq; however some experiments demonstrated there's some issue with resolving TLS SSL / HTTPS on pretty much EVERYTHING from time-to-time. It is an intermintent problem. Seems to persist for around 2 to 4 days with loosely coupled wired connections. E.g. USB modem or USB to wi-fi access point.

Where a restart or resume generally needs to get new addresses or session data(??) -- I'm speculating now. An actual example from tonight is worth 1,000 words. Take GitHub as an example.

* https://github.com -- FAIL-s

Resending:

* https://www.github.com -- will WORK

You can see more with dig. I put a simple use-case test.

System information:

Linux woodypear 3.16.0-38-generic #52~14.04.1-Ubuntu SMP Fri May 8 09:43:57 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
DISTRIB_ID=LinuxMint
DISTRIB_RELEASE=17.2
DISTRIB_CODENAME=rafaela
DISTRIB_DESCRIPTION="Linux Mint 17.2 Rafaela"

USE-CASE:
-----------------
* github.com

~ $ dig github.com

; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> github.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40526
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0

;; QUESTION SECTION:
;github.com. IN A

;; AUTHORITY SECTION:
. 42044 IN NS e.root-servers.net.
. 42044 IN NS d.root-servers.net.
. 42044 IN NS h.root-servers.net.
. 42044 IN NS m.root-servers.net.
. 42044 IN NS l.root-servers.net.
. 42044 IN NS c.root-servers.net.
. 42044 IN NS b.root-servers.net.
. 42044 IN NS a.root-servers.net.
. 42044 IN NS j.root-servers.net.
. 42044 IN NS i.root-servers.net.
. 42044 IN NS g.root-servers.net.
. 42044 IN NS f.root-servers.net.
. 42044 IN NS k.root-servers.net.

;; Query time: 91 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Nov 17 21:41:20 AEDT 2015
;; MSG SIZE rcvd: 239

-------------
* www.github.com

~ $ dig www.github.com

; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> www.github.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25458
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;www.github.com. IN A

;; ANSWER SECTION:
www.github.com. 3599 IN CNAME github.com.
github.com. 29 IN A 192.30.252.131

;; Query time: 827 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Nov 17 21:41:26 AEDT 2015
;; MSG SIZE rcvd: 73

I have experienced this problem with 17.2.  At first I thought it was the DNSmasq; however some experiments demonstrated there's some issue with resolving TLS SSL / HTTPS on pretty much EVERYTHING from time-to-time.  It is an intermintent problem.  Seems to persist for around 2 to 4 days with loosely coupled wired connections.  E.g. USB modem or USB to wi-fi access point.

Where a restart or resume generally needs to get new addresses or session data(??)  -- I'm speculating now.  An actual example from tonight is worth 1,000 words.  Take GitHub as an example.

*  https://github.com -- FAIL-s

Resending:

*  https://www.github.com -- will WORK

You can see more with dig.  I put a simple use-case test.

System information:

USE-CASE:
-----------------
*  github.com

~ $ dig   github.com

;; QUESTION SECTION:
;github.com.			IN	A

;; AUTHORITY SECTION:
.			42044	IN	NS	e.root-servers.net.
.			42044	IN	NS	d.root-servers.net.
.			42044	IN	NS	h.root-servers.net.
.			42044	IN	NS	m.root-servers.net.
.			42044	IN	NS	l.root-servers.net.
.			42044	IN	NS	c.root-servers.net.
.			42044	IN	NS	b.root-servers.net.
.			42044	IN	NS	a.root-servers.net.
.			42044	IN	NS	j.root-servers.net.
.			42044	IN	NS	i.root-servers.net.
.			42044	IN	NS	g.root-servers.net.
.			42044	IN	NS	f.root-servers.net.
.			42044	IN	NS	k.root-servers.net.

;; Query time: 91 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Nov 17 21:41:20 AEDT 2015
;; MSG SIZE  rcvd: 239

-------------
*  www.github.com

~ $ dig   www.github.com

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;www.github.com.			IN	A

;; ANSWER SECTION:
www.github.com.		3599	IN	CNAME	github.com.
github.com.		29	IN	A	192.30.252.131

;; Query time: 827 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Nov 17 21:41:26 AEDT 2015
;; MSG SIZE  rcvd: 73

Report a bug

This report contains Public information

Everyone can see this information.

You are

Subscribing...

Edit bug mail

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.