Haiku has trouble to connect to some webservers

[HaiColon]

I noticed this with YouTube.com and Schnoogle.com

YouTube works every few minutes for a few minutes (sometimes only for a few seconds), then Youtube doesn't load anymore in BeZilla. It's not a problem with BeZilla though, other programs aren't able to connect to YouTube as well when this happens. I also tried pinging YouTube when this happens and every package is displayed as lost.

On Schnoogle (a fanfiction website), when reading a fanfic, sometimes only a blank page is displayed, sometimes nearly the whole website is loaded but a portion at the bottom is missing, sometimes half the site is missing from the bottom. I saw this with YouTube too but only once. Some parts of the website were there but the part where all the content is, the list of videos etc, was missing, even after reloading a few times.

This happens to me on two completely different computers with different network cards. One has Haiku installed on the harddisk, the other has Haiku running in VMware, so it's not a hardware problem.

I tried opening the YouTube website on Linux at the same time when I saw in VMware that YouTube didn't work anymore in Haiku. On Linux it worked without problems while at the same time on Haiku it still didn't work so it's not a problem with my internet connection either but seems to be a problem with Haiku. Other websites, for example Google.com, work when YouTube doesn't. So it's not that the network connection would break down completely, this is limited to certain websites.

So I guess the problem lies somwhere with networking in Haiku in general. It doesn't look like it has something to do with drivers since this happened on two completely different network cards who should be using different drivers. The Network card in the computer which I have installed Haiku on has a 3COM network card and VMware emulates an IPRO1000 card.

I first noticed this about three or four days ago. I build Haiku from SVN once every day. I usually don't visit the YouTube website that often (only for the last week or so I've been on there daily) so maybe I just didn't notice it before.

I'll attach the syslog from my version of Haiku running in VMware (hrev30417). It's freshly built and the syslog is from a couple of minutes after this error happened again (with YouTube). Don't know if this helps.

[bga]

There is a different bug reporting this problem already. I don't know the ticket number offhand but, if this is any consolation, you are not alone. TCP/IP seems very broken but in a way that is not immediately evident as it seems to work most of the time.

[HaiColon]

Replying to bga:

There is a different bug reporting this problem already. I don't know the ticket number offhand but, if this is any consolation, you are not alone. TCP/IP seems very broken but in a way that is not immediately evident as it seems to work most of the time.

Hmm I did ask in IRC and looked through any ticket that had the search term "network" or "youtube" in it but found nothing like this. I should have searched for TCP instead I guess. I'll try to find the other bug report you mentioned.

But yeah thanks, knowing that I'm not the only one who has trouble with this is great because I thought I was mad when I wrote the bug report. Some websites work, some don't? Crazy :)

[axeld]

If pinging did not work either, this cannot really be TCPs fault, though.

[bga]

Well, that's why I said TCP/IP. ;) Anyway, I never tried to ping after I saw the problem but one of the side-effects can be easily visible if you visit ​http://www.bug-br.org.br. Every single time the page has problems. The most visible one is that images are only half downloaded or not downloaded at all (and yes, works fine in Windows, Linux and MacOS). Check the left nav bar and you will see what I mean. Sometimes it seems not even the full HTML is downloaded!

You are probably thinking: Ah, but that could be a Firefox bug!

Except that:

[/boot/home]> wget -vvv http://www.bug-br.org.br/img/menu/menu_beos.gif
--2009-04-30 20:09:49--  http://www.bug-br.org.br/img/menu/menu_beos.gif
Resolving www.bug-br.org.br... 69.73.189.194
Connecting to www.bug-br.org.br|69.73.189.194|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2063 (2.0K) [image/gif]
Saving to: `menu_beos.gif'

70% [==========================>            ] 1,448       --.-K/s   in 0s      

2009-04-30 20:09:49 (11.8 MB/s) - Connection closed at byte 1448. Retrying.

--2009-04-30 20:09:49--  (try: 2)  http://www.bug-br.org.br/img/menu/menu_beos.gif
Connecting to www.bug-br.org.br|69.73.189.194|:80... connected.
HTTP request sent, awaiting response... 206 Partial Content
Length: 2063 (2.0K), 615 remaining [image/gif]
Saving to: `menu_beos.gif'

70% [+++++++++++++++++++++++++++            ] 1,448       --.-K/s   in 0s      

2009-04-30 20:09:50 (0.00 B/s) - Connection closed at byte 1448. Retrying.

--2009-04-30 20:09:50--  (try: 3)  http://www.bug-br.org.br/img/menu/menu_beos.gif
Connecting to www.bug-br.org.br|69.73.189.194|:80... connected.
HTTP request sent, awaiting response... 206 Partial Content
Length: 2063 (2.0K), 615 remaining [image/gif]
Saving to: `menu_beos.gif'

70% [+++++++++++++++++++++++++++            ] 1,448       --.-K/s   in 0s      

2009-04-30 20:09:50 (0.00 B/s) - Connection closed at byte 1448. Retrying.

--2009-04-30 20:09:50--  (try: 4)  http://www.bug-br.org.br/img/menu/menu_beos.gif
Connecting to www.bug-br.org.br|69.73.189.194|:80... connected.
HTTP request sent, awaiting response... 206 Partial Content
Length: 2063 (2.0K), 615 remaining [image/gif]
Saving to: `menu_beos.gif'

70% [+++++++++++++++++++++++++++            ] 1,448       --.-K/s   in 0s

This is just a snippet, it just continues trying to download and fails at exactly the same point all the time.

And yes, at the exact same time I downloaded the same file in 3 different computers here at home and all worked without any problems whatsoever.

Hope this helps.

[HaiColon]

I just remembered that ping doesn't work from within a virtual machine (due to the bridged or NAT networking I guess, can't remember, it is explained in the VirtualBox manual). I can't remember now if I have tried pinging when I was using Haiku in VMWare or when I was using Haiku installed to harddisk, so maybe pinging just didn't work because of VMWare.

The harddisk in the computer I had Haiku installed on is dead so I can't test it there but I'll make room on a partition on my other computer and try it out there.

Additionally, I found out that Twitter.com also has problems in Haiku. Sometimes Haiku doesn't even connect (or rather, tries to connect for a long time, don't know if it ever timeouts), sometimes it downloads only part of the html source (or xml when using curl and the Twitter API), sometimes it downloads everything as it should.

[mmlr]

Replying to bga:

​http://www.bug-br.org.br. Every single time the page has problems. The most visible one is that images are only half downloaded or not downloaded at all

I'm not able to reproduce it with that side. It works just fine for me.

boot/home> wget -vvv ​http://www.bug-br.org.br/img/menu/menu_beos.gif

This one works fine as well, even if trying over and over.

Since the download is indicated to stop at 1448. This somehow looks close to the common MTU values, so maybe this is a MTU problem? Depending on the route to a target you'd be able to reproduce or not. Maybe you could try playing around with your MTU setting and see if this changes anything.

[HaiColon]

I tried it again in VMware because I get a KDL with the newest revision of Haiku that I installed to disk. Ping does in fact work in VMWare. Maybe it's just VirtualBox where it doesn't work.

So, just disregard my last comment :)

I can't help with trying out different MTU settings because I don't know how to do that. I only found tutorials on how to do that with ping in Windows, but not on Linux. So hopefully bga or someone else who also encountered this problem will try this out.

[axeld]

An MTU related problem sounds indeed probable.

What kind of KDL are you running into now? Is that like #3847?

[axeld]

You can change the MTU setting either with the "route" command, or for the whole interface via "ifconfig". Something like "ifconfig /dev/net/ipro1000/0 mtu 1448" should do the trick.

[bga]

It is definitly MTU related, but changing the MTU does not help:

[/boot/home]> ifconfig /dev/net/marvell_yukon/1 mtu 1448
[/boot/home]> ifconfig
/dev/net/marvell_yukon/1
        Hardware Type: Ethernet, Address: 00:1e:8c:3a:65:24
        Media Type: 100 MBit, 100BASE-TX
        inet addr: 192.168.0.2, Bcast: 192.168.0.255, Mask: 255.255.255.0
        MTU: 1448, Metric: 0, up broadcast link
        Receive: 9356 packets, 0 errors, 7580362 bytes, 0 mcasts, 0 dropped
        Transmit: 8814 packets, 0 errors, 746182 bytes, 0 mcasts, 0 dropped
        Collisions: 0

loop    Hardware Type: Local Loopback, Address: none
        inet addr: 127.0.0.1, Mask: 255.0.0.0
        MTU: 16384, Metric: 0, up loopback link
        Receive: 0 packets, 0 errors, 0 bytes, 0 mcasts, 0 dropped
        Transmit: 0 packets, 0 errors, 0 bytes, 0 mcasts, 0 dropped
        Collisions: 0

The first time I tried to download a problematic image with this, it worked. But then I tried again:

[/boot/home]> wget -vvv http://www.bug-br.org.br/img/menu/menu_beos.gif
--2009-05-01 10:06:24--  http://www.bug-br.org.br/img/menu/menu_beos.gif
Resolving www.bug-br.org.br... 69.73.189.194
Connecting to www.bug-br.org.br|69.73.189.194|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2063 (2.0K) [image/gif]
Saving to: `menu_beos.gif.2'

67% [=========================>             ] 1,396       --.-K/s   in 0s      

2009-05-01 10:06:25 (25.1 MB/s) - Connection closed at byte 1396. Retrying.

Then I changed the MTU again, just in case:

[/boot/home]> ifconfig /dev/net/marvell_yukon/1 mtu 1300
[/boot/home]> ifconfig
/dev/net/marvell_yukon/1
        Hardware Type: Ethernet, Address: 00:1e:8c:3a:65:24
        Media Type: 100 MBit, 100BASE-TX
        inet addr: 192.168.0.2, Bcast: 192.168.0.255, Mask: 255.255.255.0
        MTU: 1300, Metric: 0, up broadcast link
        Receive: 9569 packets, 0 errors, 7685679 bytes, 0 mcasts, 0 dropped
        Transmit: 9018 packets, 0 errors, 769910 bytes, 0 mcasts, 0 dropped
        Collisions: 0

loop    Hardware Type: Local Loopback, Address: none
        inet addr: 127.0.0.1, Mask: 255.0.0.0
        MTU: 16384, Metric: 0, up loopback link
        Receive: 0 packets, 0 errors, 0 bytes, 0 mcasts, 0 dropped
        Transmit: 0 packets, 0 errors, 0 bytes, 0 mcasts, 0 dropped
        Collisions: 0

And tried again:

[/boot/home]> wget -vvv http://www.bug-br.org.br/img/menu/menu_beos.gif
--2009-05-01 10:07:35--  http://www.bug-br.org.br/img/menu/menu_beos.gif
Resolving www.bug-br.org.br... 69.73.189.194
Connecting to www.bug-br.org.br|69.73.189.194|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2063 (2.0K) [image/gif]
Saving to: `menu_beos.gif.3'

60% [======================>                ] 1,248       --.-K/s   in 0s      

2009-05-01 10:07:35 (10.2 MB/s) - Connection closed at byte 1248. Retrying.

As you can see, the failure point is always some bytes before the MTU size.

Other than that, I am connected to a cable connection so there is no framing involved (protocol is straight ATM/Ethernet), so the MTU size of 1500 should be fine.

Anyway, decreasing the MTU file seems to have improved things a bit as wget tries to download the files 3 or four times and then succeeds.

[mmlr]

It's not just "some bytes" before the MTU size, it seems to always be exactly 52 bytes. So there's probably some buffer size that is miscalculated in some circumstances. It might be interesting to have a dump of the traffic such a wget download triggers and analyze if there is something fishy about the content.

[HaiColon]

Replying to axeld:

An MTU related problem sounds indeed probable.

What kind of KDL are you running into now? Is that like #3847?

Yeah that's the error I get. Thanks for the link, now I don't have to borrow a digital camera :)

[HaiColon]

Don't know if that helps with locating the problem, I was playing around with curl and the Twitter API and had the same connection trouble there that I have with YouTube but when I started accessing Twitter through the https link instead of the http link there were no connection errors at all, works fine all the time with SSL.

[HaiColon]

Looks like I just had a good day yesterday, now I have the same trouble when using SSL. But it does at least work better (more often) with SSL.

[pulkomandy]

Can anyone still reproduce this? Things are working fine here, at least.

[waddlesplash]

Never saw this happen.

[waddlesplash]

No reply in 2 (really 8) years. Assuming fixed.