Odd problem

English Network/Internet
1

That’s about the best title I can come up with to be honest. :wink:

I’ve doubted between posting here and the networking section, but ultimately I feel this problem resides in the wireless.

So, what’s the problem: My wireless works normally, I can visit every usual site, download torrents, do whatever I want… Except use facebook.com.

What exactly happens: The first time I try to connect to facebook.com (in any browser) it will load the homescreen, when I then try to click further (messages, the buttons on the top etc.) it just loads for a long time and eventually I get a “connection reset” message when using facebook.

Edit: I forgot to mention. After this has happend, if I close the tab and then try to connect to facebook.com it just keeps loading. Won’t even show me the homescreen anymore and eventually results in a connection reset message.

Here comes the twist: I don’t have the problem when I connect to a different AP. My usual connection is towards an Eminent 4544 set up as an access point behind a Draytek 2910. However, when I make my phone a hotspot and connect there and onwards via the 3g I can browse facebook normally.

The problem began when I started using Opensuse 12.3 I think. I installed it about a week ago (moving from Windows 7), in Windows I did not encounter the problem with the same setup. Only noticed today since I don’t use facebook that much anyway.

What have I tried:

  • Tried tweaking every wireless setting on the access point
  • Changed my settings in the nm-connection-editor. Moved away from DHCP, set a hard MTU to 1500, disabled Ipv6
  • Disabled IPV6 in firefox
  • Tried using Chrome instead, no joy
  • DIsabled the firewall in Yast
  • Tried different HTTPS sites, no problems there
  • Verified AP has latest firmware

The only thing I’ve found to be working is changing to my phone’s hotspot. That takes the usual AP out of the equation and changes to a different internet connection. Other devices connected to the Eminent AP however have no problems with facebook, though none of the other wireless devices are running Linux.

I’ve been looking into my drivers on the laptop side, but they seem to be in order (ath9k). Is it possible to try other drivers for instance?

Finally, hwinfo output for my WLAN card:

14: PCI 200.0: 0282 WLAN controller
[Created at pci.319]
Unique ID: y9sn.apYiokQ9666
Parent ID: qTvu.gZlZeqGJmj2
SysFS ID: /devices/pci0000:00/0000:00:1c.1/0000:02:00.0
SysFS BusID: 0000:02:00.0
Hardware Class: network
Model: “Atheros AR9285 Wireless Network Adapter (PCI-Express)”
Vendor: pci 0x168c “Atheros Communications Inc.”
Device: pci 0x002b “AR9285 Wireless Network Adapter (PCI-Express)”
SubVendor: pci 0x1a3b
SubDevice: pci 0x1089
Revision: 0x01
Driver: “ath9k”
Driver Modules: “ath9k”
Device File: wlan0
Features: WLAN
Memory Range: 0xde800000-0xde80ffff (rw,non-prefetchable)
IRQ: 17 (no events)
HW Address: 00:08:ca:22:2e:c1
Link detected: yes
WLAN channels: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
WLAN frequencies: 2.412 2.417 2.422 2.427 2.432 2.437 2.442 2.447 2.452 2.457 2.462 2.467 2.472 2.484
WLAN encryption modes: WEP40 WEP104 TKIP CCMP
WLAN authentication modes: open sharedkey wpa-psk wpa-eap
Module Alias: “pci:v0000168Cd0000002Bsv00001A3Bsd00001089bc02sc80i00”
Driver Info #0:
Driver Status: ath9k is active
Driver Activation Cmd: “modprobe ath9k”
Config Status: cfg=no, avail=

2

I commend you on posting such an interesting and challenging question.

And I’m sorry, but after pondering on it - I’ve got nothing.

As an aside I have a somewhat similar issue: A particular Linux guest will loose http connectivity (local network and to outside) entirely at random times, calling for a reset of Dlink-DIR-632A running dd-wrt. There is nothing logged or evident on the router, no firewall issue, nothing - it just stops http traffic until you reboot it. Of course I’m sure this is dd-wrt related, and has nothing to do with your situation (unless your running dd-wrt on one of your devices?)

3

The first thing to check is whether facebook.com can be resolved by your system.
Please post the output of ‘dig facebook.com’.

4

Hi, thanks for your time!

It can actually be resolved, the first time the page loads but certain elements fail, after that it just becomes a connection reset. I’ve tried different DNS servers (google dns and provider DNS).

I also had MTR running towards facebook to check for any packetloss on the route, but came up with nothing at all.

I’m actually thinking along the lines of an incompatibility between my wlan drivers and the Eminent 4544 wireless router. Still, it’s strange that it only seems to affect facebook.

host -a facebook.com

Trying “facebook.com”
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16290
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 2

;; QUESTION SECTION:
;facebook.com. IN ANY

;; ANSWER SECTION:
facebook.com. 85986 IN NS a.ns.facebook.com.
facebook.com. 255 IN A 173.252.110.27
facebook.com. 85986 IN NS b.ns.facebook.com.

;; ADDITIONAL SECTION:
a.ns.facebook.com. 85986 IN A 69.171.239.12
b.ns.facebook.com. 85986 IN A 69.171.255.12

Received 113 bytes from 90.145.32.32#53 in 8 ms

Also,

@LewsTherinTelemon: Thanks! :slight_smile: Not running dd-wrt. There’s no support for the Eminent brand routers. I went and checked just now actually, hoping it would help if I change the routers firmware. :frowning:

5

On 08/18/2013 11:46 AM, Bryserker wrote:
> It can actually be resolved, the first time the page loads but certain
> elements fail, after that it just becomes a connection reset. I’ve tried
> different DNS servers (google dns and provider DNS).
>
> I also had MTR running towards facebook to check for any packetloss on
> the route, but came up with nothing at all.
>
> I’m actually thinking along the lines of an incompatibility between my
> wlan drivers and the Eminent 4544 wireless router. Still, it’s strange
> that it only seems to affect facebook.

It is certainly possible that your router has a bug in its firmware, and falls
over for some particular data sequence. If so, it probably affects other sites
as well, but you have not found them yet. You could discover the problem by
capturing the on-the-air data and analyzing the problem, but that would be a lot
of work for little gain. At least, you have a workaround.

6

Here’s a relevant update…

(and I’m hitting myself for not testing this sooner)

It’s not a wireless issue. I got off my lazy bum and found a RJ-45 cable and tested the following:

  • Wired connection to the Eminent 4544 wireless router: Still the same problem

  • Wired connection directly to the Draytek 2910 router (which has my WAN link): Still the same problem.

Problem is therefore not a wireless issue after all. Doesn’t solve it yet though… Looking at my Draytek’s settings now.

Funny thing is, I realised my girlfriend’s laptop had a dual boot with Windows/Ubuntu. It’s about a year old Ubuntu, with older firefox version: same problem. The windows machines aren’t having any issues however.

As it isn’t wireless related after all, how would I go about moving this to networking?

7

Well, things just got stranger… It’s magically working all of a sudden.

I was tinkering around with two things:

  • MTU settings in nm-connection-editor; dropped it down to 1472
  • Made my laptop’s IP the DMZ host in the Draytek router.

After clearing cookies and cache, it started working. So naturally I tried to see which of the two settings was the solution. Changed the MTU around to 1492, 1500 and automatic. Kept working… Changed the DMZ host back to it’s original setting… kept working.

So, not a single cause found.

Infact, as I’m typing this I’m looking at the other laptop with the old Ubuntu installation, it still had the same problem at first when I got it working on my laptop. After tinkering with DMZ and MTU there as well:

  • Set DMZ to Ubuntu laptop, cleared cookies and cache: Didn’t work
  • Changed MTU to 1472, cleared cookies and cache: Immediately it worked
  • Changed MTU back to automatic, cleared cookies and cache: Kept working

So, all in all it seems MTU related. I just don’t know why, especially since it doesn’t work on automatic or 1500 at first but when changing it to 1472 it starts working. However, then changing it back to automatic doesn’t seem to break it again. The only thing I haven’t tried yet is rebooting my system after changing it back to automatic. I’m going to do that now…

**Edit: Just rebooted, as expectected it didn’t work anymore after the reboot. Changed the MTU back to 1472 with nm-connection-editor and voila, it immediately worked again. Not sure why this is, but atleast it works.
**

8

Interesting. Nice job zeroing in on MTU as a possible issue. I’m going to try setting the mtu to 1492 on the particular host I have which magically looses connectivity, which incidentally is Ubuntu 12.10, and see how it goes. It might take a day or two to know, but if it works I post the result.

9

On 2013-08-18 20:26, Bryserker wrote:
> However, then changing it back to
> automatic doesn’t seem to break it again.

Maybe because the router doesn’t go back to a bigger MTU, it doesn’t
accept the negotiation.

(to request move of the thread, just click the report triangle at the
bottom and ask)

–
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

10

Exactly the same problems as described on the very first message have happened on my laptop that connects to my ADSL Router via wireless connection. I tested the problem on facebook mainly, and some other websites. The common features of the problematic websites are that they are interactive.

The problem has just occured on my laptop powered by opensuse 12.3 for a few weeks.

I tried the ethernet cable connection on the same router, but then the problem resolved. Actually I have another PC cable connected to the router without problem on the same web pages. And an ipad connects by the same wireless network and opens the websites, which are problematic on my laptop, very smoothly.

So it seemed to be the problem of my opensuse installation. I have no time for debugging, however I can speculate that the problem was arisen a few weeks ago after the security update of the Networkmanager of Gnome Desktop that I use. Because I had been using the same machine with the same opensuse version over the 7-8 months I think since it was released. But the problem is just new.

Fortunately, I have read this thread and just adjusted the MTU value from Automatic to 1472 in the Network Setting of the Wireless part of the Networkmanager of Gnome. Now, it is ok.

Thank you friends…

11

Unfortunately, after fresh install of opensuse 13.1, the problem has arisen again. I need to adjust the MTU value to 1472 for a proper internet connection. However, interestingly there is no option for MTU setup of wi-fi connection in the Gnomes Networkmanager of opensuse 13.1. I hope there shall be an online update for this deficiency or lets call it a bug.

12

Hm?
I do have the MTU setting here with KDE’s networkmanagement applet, but also in GNOME’s nm-applet:
http://wstaw.org/m/2013/12/04/nm.png

13

On 12/04/2013 01:16 PM, wolfi323 wrote:
>
> f_alabas;2605264 Wrote:
>> Unfortunately, after fresh install of opensuse 13.1, the problem has
>> arisen again. I need to adjust the MTU value to 1472 for a proper
>> internet connection. However, interestingly there is no option for MTU
>> setup of wi-fi connection in the Gnome`s Networkmanager of opensuse

13.1. I hope there shall be an online update for this deficiency or
let`s call it a bug.
> Hm?
> I do have the MTU setting here with KDE’s networkmanagement applet, but
> also in GNOME’s nm-applet:
> [image: http://wstaw.org/m/2013/12/04/nm.png]

It may be a bug, but it is certainly not general. Below is the ifconfig output
for my current connection:


wlp14s0   Link encap:Ethernet  HWaddr 00:E0:4C:01:93:AB
inet addr:192.168.1.105  Bcast:192.168.1.255  Mask:255.255.255.0
inet6 addr: fe80::2e0:4cff:fe01:93ab/64 Scope:Link
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
RX packets:173805 errors:0 dropped:0 overruns:0 frame:0
TX packets:118468 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:75448821 (71.9 Mb)  TX bytes:14284103 (13.6 Mb)

Note that I have had considerable traffic with an MTU of 1500.

If there is a bug, it is in your wireless driver. What one are you using?

14

It is ok for KDEs nm-applet, but mtu option is not seen in Gnomes nm-applet. I wanted to put a screenshot here, but could not do.

15

My wireless card is broadcom`s bcm4318 and I am using the automatically downloaded bcm43xx driver via b43-fwcutter.

I wonder how mtu setup option is missing in the Gnome`s nm-applet while it was available since opensuse 11.x !?

16

Just to avoid misunderstandings here: that screenshot in my previous post does show GNOME’s nm-applet on openSUSE 13.1.

I wanted to put a screenshot here, but could not do.

You have to upload the picture to SUSE Paste or something similar and post a link (or click on “Insert Image” in the toolbar and paste the URL to the dialog that pops up).

17

Here is the screenshot of my Gnome`s nm-applet of opensuse 13.1:

http://susepaste.org/15058349

18

OK, that’s something completely different then. Has GNOME now NM settings built in?

Run “nm-applet” in a terminal window, that one should look like I posted. Or use the KDE applet to change the MTU.
There’s only one set of settings for NetworkManager, it doesn’t matter if you use the KDE or GNOME or whatever applet.

19

Yes. it has…

“nm-applet” runs the Gnome`s networkmanager in the notification area where the applet is embedded in, and what the same as I put into screenshot on my previous message.

The output of “ifconfig wlan0” shows that the MTU value is fixed to 1500.

For the installation of KDE`s nm-applet, it requires the packages of almost full KDE Desktop.

By the way, Gnome`s nm-applet is still defective in another way that it does not connect to hidden wi-fi network automatically after reboot/suspend/hibernate. It needs manual intervention for connection, each time…

20

Hm, I thought you have it installed because you said the MTU setting is there with KDE’s applet.

Well, if I run nm-applet (which is the GNOME applet) in KDE I get that window shown, but under GNOME it acts differently apparently.
Try with another DE then maybe? IceWM should be installed by default, but I’m not sure atm if that default installation shows system tray icons…

Or you could edit the config file with a text editor. It should be found in /etc/NetworkManager/system-connections/.
You should add the following option to the “[802-11-wireless]” section:

mtu=1472

So f.e. mine would look like this then:

[connection]
id=PBS-46C481
uuid=5856e1ca-1c72-4c3f-85f6-95a52dfd0df4
type=802-11-wireless
timestamp=1367484515
zone=


[802-11-wireless]
ssid=PBS-46C481
mode=infrastructure
mtu=1472
security=802-11-wireless-security


[802-11-wireless-security]
key-mgmt=wpa-psk
psk=xxxxxxxxxxxxxxxxxxxx


[ipv4]
method=auto


[ipv6]
method=ignore
ip6-privacy=0

You need root rights for that, so run f.e. “gnomesu gedit”.

By the way, Gnome`s nm-applet is still defective in another way that it does not connect to hidden wi-fi network automatically after reboot/suspend/hibernate. It needs manual intervention for connection, each time…

Bug report?
This works fine for me as well (in KDE).