can't access Gmail

[khallebal]

I tried with Web+, Qupzilla & Netsurf,clicking connect starts loading then it hangs there forever?

[anevilyak]

For the record, this doesn't appear to be a Haiku-specific problem. I'm seeing similar issues with various minority browsers on other OSes, only the big ones like Firefox and Chrome seem to work properly, so this may be something on GMail's end.

[khallebal]

Replying to anevilyak:

For the record, this doesn't appear to be a Haiku-specific problem. I'm seeing similar issues with various minority browsers on other OSes, only the big ones like Firefox and Chrome seem to work properly, so this may be something on GMail's end.

I usualy use only firefox on other OSs, but i just tried with qupzilla and midori for windows and they worked as expected. i'll try to binary search when this started.

[humdinger]

I see that in Web+, just not reproducibly. Sometimes logging works, sometimes it doesn't. Sometimes, after clicking the reload button a couple of times, it works, sometimes not. Sometimes loading the login page ​http://mail.google.com doesn't even work.
QupZilla always managed to connect me to GMail so far...

[pulkomandy]

NetSurf won't work for this because it lacks Javascript support. No need to even try. Web+ is known to have issues with this (and other things).

However it is strange that Qupzilla didn't work for you. Which version of Haiku and Qupzilla is that?

[khallebal]

Replying to pulkomandy:

NetSurf won't work for this because it lacks Javascript support. No need to even try. Web+ is known to have issues with this (and other things).

However it is strange that Qupzilla didn't work for you. Which version of Haiku and Qupzilla is that?

netsurf worked for me at some point when you load the HTML version.for qupzilla it doesn't since a very long time,i even compiled a new version from trunk 8.x it has the same behavior described above,just yesterday i compiled Qtweb browser and arora,it's the same. i did some binary search, so far the last rev that did work goes back to June hrev47451. I'll continue with binary search to see if there is a more recent rev that works.

[humdinger]

Works here. Maybe you're using an old qupzilla version? Here, I use the packages

• qupzilla_x86-1.7.x-4-x86_gcc2.hpkg
• libqt4_x86-4.8.6.4-1-x86_gcc2.hpkg

This just as an aside, for this ticket, only the Web+ issue is of concern. It maybe similar to #11616 and #11556.

[khallebal]

I'm using as of today hrev48365 and the same versions of Qt & Qupzilla as Humdinger's,still no joy. Was there some localization stuff introduced in Haiku or webkit back in june that would explain as to why it works for some and not for me?

[pulkomandy]

Hard to tell with an ~1000 revision range (47451-48365). If you can binary search this a bit further it would be nice :)

[khallebal]

It looks like the last rev that worked was indeed hrev:47451 ,so something had changed between 47451 & 47455,also starting from the latter web+ is not working for several nightlies (missing symbols thing) and i couldn't already access gmail with qupzilla on these nightlies.

[waddlesplash]

I don't have any problems connecting to GMail, and those revisions don't contain any ntetwork-stack changes. Still an issue?

[korli]

Replying to waddlesplash:

I don't have any problems connecting to GMail, and those revisions don't contain any ntetwork-stack changes. Still an issue?

I have met some issues with GMail (for instance works only with HTML View), and certificate popups come up again and again.

[pulkomandy]

I haven't mentionned this here, but:

• HaikuLauncher seems to work here, while Web+ doesn't. In HaikuLauncher I can use the complete gmail interface including Google Talk (there are only some drawing issues, but the network and javascript side is fine).
• The certificate popup doesn't add an exception or save the certificate anywhere yet, so it will keep opening again and again for HTTPS connections with an unverified certificate. Google's certificates should be verifiable however, so we may need to update our certificate database (and maybe also let an autocommiter script do these updates if possible).

Also, it could be yet another IPv6 problem. The HTTP code forces IPv4, but there could be problems, for example, with Web Sockets, which use a different code path.

[khallebal]

Could this be some "geographical" issue in webkit or in our network stack? (i realize i must be saying something stupid here)but i'm hopeless with this situation that's been lasting since june last year. it's abviously not a gmail issue because i can access it on other platforms with any browser i want. anything i can do to help debugging this?

[pulkomandy]

With each browser using a completely different codebase, I'm not sure there is just a single problem. It could be your DNS sending an unusually formatted record for gmail servers, it could be your timezone affecting cookies in some way (cookies use UTC times, so they rely on correct time and timezone settings on your machine), or your ISP and/or network hardware (network driver, router, modem, ...) doing something strange (failing to split packets with a too small MTU, for example).

If possible, capturing the network traffic between the Haiku machine and the router (using wireshark or tcpdump for example) maybe could give some hints. In the case of Web+, building the HTTP code with tracing enabled (there are TRACE macros to define in several files) or in debug mode (SetConfigVar DEBUG ... in the UserBuildConfig Jamfile) and running Web+ from the Terminal with this enabled would also give some info about what is being sent and received on the network.

[khallebal]

Here is some trace from web+ while loading gmail with the same modem/router as mine, it didn't work with it either until recently (i have no clue as to why it's working now), here you see web+ reloading the page several times with the error msg 305 "document moved here" the last msg is interesting because it stopped loading and hang forever again. (MESSAGE :0:0: Refused to display '​https://accounts.google.com/ServiceLogin?ui=2&view=bsp&ver=ohhl4rw8mbn4' in a frame because it set 'X-Frame-Options' to 'DENY'.). At home it still not working, i'm using a 3g dongle connected to the modem, it had always worked until june,but with this modem i'm using a normal dsl connection. i hope this could be of some help.

[pulkomandy]

What is the URL displayed in the URL bar after all the redirects are resolved? It seems there is still a problem with redirections, and the URL will not always be updated.

This could be harmless, but there is some javascript and browser built-in protections to avoid cross site scripting (XSS) attacks which will prevent things to work if the URL is not the correct one for the page.

I see several "SSL Error" messages which don't sound very good. We should probably try to solve these as well (they come from here: ​http://cgit.haiku-os.org/haiku/tree/src/kits/network/libnetapi/SecureSocket.cpp)

[khallebal]

Replying to pulkomandy:

What is the URL displayed in the URL bar after all the redirects are resolved? It seems there is still a problem with redirections, and the URL will not always be updated.

This could be harmless, but there is some javascript and browser built-in protections to avoid cross site scripting (XSS) attacks which will prevent things to work if the URL is not the correct one for the page.

I see several "SSL Error" messages which don't sound very good. We should probably try to solve these as well (they come from here: ​http://cgit.haiku-os.org/haiku/tree/src/kits/network/libnetapi/SecureSocket.cpp)

This the URL when the page is loaded ​https://mail.google.com/mail/?pli=1#inbox

And this is the URL when it's trying to reload ​https://accounts.google.com/ServiceLogin?service=mail&passive=true&rm=false&continue=https://mail.google.com/mail/&ss=1&scc=1&ltmpl=default&ltmplcache=2&emr=1&osid=1

[haiqu]

With Web+ these days I don't even get the user/pass boxen to fill in. The login page is not usable. Bon Echo (Firefox 2) works ok there.

[pulkomandy]

@haiqu: this is an entirely different issue, so please open a separate ticket (and yes, I saw this one as well here, it seems Google changed the page in a way Web+ doesn't render properly. But you can still login in the blind).

[humdinger]

The GMail web interface works since the latest webkit release (I'm on hrev50087). Can the ticket be closed then?

[khallebal]

Replying to humdinger:

The GMail web interface works since the latest webkit release (I'm on hrev50087). Can the ticket be closed then?

I just tested it again, and it still doesn't work for me, the term output shows "ssl error 2 & ssl error 5", looked at the meaning of this on the net, it turned out to be "handshake completed" for ssl error 2, and "provider problem" for ssl error 5. And that confirms the behaviour, I tried from a friend's connection and it worked. So i'd say we leave it open 'til we find what's blocking access on this provider, but we need a tool that can give us usefull info while trying to access.

[pulkomandy]

since you get problems using various different browsers, I would think the problem is somewhere down in the network stack. Maybe you can try lowering the MTU on your network interface:

ifconfig /dev/net/... mtu 1024

This will prevent from sending TCP packets larger than 1024 bytes (the default is 1500 bytes). If something in your network setup can't send packets as large as 1500 bytes, forcing them to be smaller will help with the problem. It is usually possible to discover the MTU for a given link, but Haiku doesn't do that, so manually lowering the MTU is the only option for now.

[richienyhus]

Replying to khallebal:

Any luck limiting your MTU khallebal? This seems to help a number of people with their network problems.

[khallebal]

Unfortunately that doesn't help a bit in my case,i'm suspecting an openssl & stack combined issue, something must have changed in openssl since the version we were using in hrev:47451, because this rev is still working even today, but none of the revs there after do.

[pulkomandy]

Can you try a recent nightly with haikuwebkit 1.5.3? There have been several fixes to the network code which may improve the situation.

[khallebal]

It looks like there is some progress, now the progress bar goes up to about 90% and stays there, i submitted a screenshot of the rendered page with an error message on it, i don't know if it helps?

[pulkomandy]

Please always mention the exact revision of Haiku you used. Part of your problem may be fixed already with the change in hrev50670.

When you see the "this document has moved here" text, try clicking the link before it continues loading (I really should fix that bug). Or just re-select the URL bar and press enter again. Does that help?

[khallebal]

Yeah sorry about that, anyway i just updated my system from hrev50657 to hrev50671, then i ran web+ from terminal with "LD_PRELOAD=/system/lib/libroot_debug.so WebPositive" and did access my gmail account with the follwing output:

MESSAGE ​https://plus.google.com/_/scs/apps-static/_/js/k=oz.recentposts.fr.SfSdk6hR1kU.O/m=rp_b/am=AQ/rt=j/d=1/rs=AGLTcCNBcVWC6ZIWYDjC9Ltol-11-ofoGA?:832:380: Blocked a frame with origin "​https://plus.google.com" from accessing a frame with origin "​https://mail.google.com". Protocols, domains, and ports must match. SSL error:00000005:lib(0):func(0):DH lib

But for some reason i was unable to access it when i launched web+ directly from tracker.

[pulkomandy]

Please try with hrev50917. It fixes the problems with HTTP redirects and should work better.

Also, are you using a wireless network? There is a known problem with the intel driver. And there is a known workaround:

[x86_gcc2] ~# cat config/settings/boot/launch/wifi.sh 
#! /bin/sh

# Disable "N" wifi, which doesn't work quite right with our drivers yet.
ifconfig /dev/net/iprowifi*/0 -ht

This may solve some more issues if you are using wifi.

[pulkomandy]

Hi, HaikuWebKit 1.6.1 fixed (for x86_gcc2 - 64-bit will likely get an update later) yet another issue which could lead to GMail not loading. Are you still having problems?

[waddlesplash]

No reply in over 9 months with 2 different requests for retest during that time. Assuming fixed.