Certain wireless devices only work once in a blue moon

December 12, 2015 8:25 AM

My blu ray player and wireless camera almost never work on the WiFi network, but things aren't completely broken because they worked for a day last week. The setup is a Netgear R6250 in Access Point mode connected to a linux server which does NATing and DHCP for my home devices.

I have two devices that almost never work on the wireless network. One is a Samsung Blu Ray player and the other is a D-Link webcam.

Here's everything I've tried:
Blu Ray player and Wifi router firmwares are up to date.

I tried a different router from a different brand.

Plugging the blu ray player into the wired network (through a port on the wireless router) works, which is odd because the wireless router is set to Access Point mode and the server doesn't differentiate wired and wireless traffic, so there should be no difference between the two.

That lead me to think that the wireless card was the problem, but I've ruled that out too.

I plugged my mbp into the wired network and turned on Internet Sharing over WiFi and connected the blu ray player to that. The player worked with that configuration.

When I have weird networking problems, I tend to think MTU issues, but I've set the lan and wan NICs on the server to different MTUs with no change (and often that just caused other devices to break).

I had given up hope months ago and was using a chromecast for netflix. Then last week, I thought I had a breakthrough. Out of boredom, I started googling my problem, and thought that maybe the devices weren't discovering the MTU properly. I turned on MSS clamping (iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu) (I also set it on the mangle table). And when I turned on my devices, they both worked! I watched netflix all day on the blu ray player and the webcam was working.

A few days later, I was setting up xorg and had to recompile the kernel and restarted the server with the new kernel. I can't say for sure that the blu ray player was still working at this point (I hadn't tried it for a day or two), but it certainly wasn't working after the restart. I reloaded the old kernel, but to no avail. I made sure I applied the same settings I had tried before, but still no luck.

I watch tcpdump when the blu ray player is starting, and everything looks ok. It makes the DHCP REQ, receives it and acknowledges it, but then I can't ping it from the gateway (it does respond to ping when it's working). Setting the IP manually in the blu ray player doesn't help either.

All other devices (a smart TV, a couple smart phones, etc.) work fine.

I hope someone here has some insight, because I am all out of ideas.

Thanks in advance!

posted by chndrcks to Computers & Internet (8 answers total)

Are they all on the same channel?
posted by essexjan at 8:41 AM on December 12, 2015

Where in your domicile is the Wi-Fi located in relation to these devices?
posted by rhizome at 9:27 AM on December 12, 2015

Response by poster: Right now they're on separate floors, but the signal strength is ok and I did test the bd player in close proximity to the wireless router

No channel settings for the devices, but I've tried the wireless router on both auto and on an open channel
posted by chndrcks at 10:29 AM on December 12, 2015

Have you tried resetting the router, and letting it run as the DHCP server in just well, standard router mode?

I ask because i was having almost identical problems at my partners parents house for months, and i had tried another router/AP... But i eventually solved it by bringing in a third brand of router. After a total factory reset and firmware upgrade, everything miraculously worked perfectly.

The last time i had a linux box router like this was probably about 2006, but i gave up on it because i kept having stupid arbitrary problems like this that i could solve, but that would creep back up and the previous solution wouldn't work because ??? The last at least 3 times i had arbitrary router problems like this, it was the router.

I've had a lot of issues with everything from chromecasts to embedded weird/proprietary devices like blu ray players or rokus(and even some android STBs like the ouya) that fall in to the "small embedded device thing with wifi" category having weird issues with wireless networks or routers. Sometimes if you split up the AP and the routing it's one or the other. All the time, it always feels like it wasn't really worth it to do anything other than just set up a new router.

Would you find having a separate sublayer of NAT, and letting some cheapo consumer router create a separate network just for these picky devices an acceptable solution? Because i'd be buying something like this and daisy chaining it off your main router so fast it would break the sound barrier. Just let it think your LAN is the "WAN", connect the picky devices to it, and forget this ever happened. DMZ or port forward the IP cam and just target the software to the IP of the router.
posted by emptythought at 11:27 AM on December 12, 2015 [1 favorite]

Could you post the output from the following commands on the router?

ip link
ip addr
ip route
iptables-save

posted by flabdablet at 5:52 AM on December 13, 2015

Response by poster: plato ~ # ip link
1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ethlan: mtu 1500 qdisc pfifo_fast master br0 state UP mode DEFAULT group default qlen 1000
link/ether 6c:62:6d:c2:50:05 brd ff:ff:ff:ff:ff:ff
3: ethwan: mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether 00:0f:b5:8a:d7:e5 brd ff:ff:ff:ff:ff:ff
4: sit0@NONE: mtu 1480 qdisc noop state DOWN mode DEFAULT group default
link/sit 0.0.0.0 brd 0.0.0.0
5: tap0: mtu 1500 qdisc pfifo_fast master br0 state DOWN mode DEFAULT group default qlen 500
link/ether 5e:d3:82:68:88:f8 brd ff:ff:ff:ff:ff:ff
6: tap1: mtu 1500 qdisc pfifo_fast master br0 state DOWN mode DEFAULT group default qlen 500
link/ether 16:0e:01:a5:86:ec brd ff:ff:ff:ff:ff:ff
12: br0: mtu 1500 qdisc noqueue state UP mode DEFAULT group default
link/ether 16:0e:01:a5:86:ec brd ff:ff:ff:ff:ff:ff

plato ~ # ip addr
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ethlan: mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000
link/ether 6c:62:6d:c2:50:05 brd ff:ff:ff:ff:ff:ff
inet6 fe80::6e62:6dff:fec2:5005/64 scope link
valid_lft forever preferred_lft forever
3: ethwan: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:0f:b5:8a:d7:e5 brd ff:ff:ff:ff:ff:ff
inet xxx.xxx.xxx.xxx/22 brd 255.255.255.255 scope global ethwan
valid_lft forever preferred_lft forever
inet6 fe80::f38e:44a9:7e91:d7b9/64 scope link
valid_lft forever preferred_lft forever
4: sit0@NONE: mtu 1480 qdisc noop state DOWN group default
link/sit 0.0.0.0 brd 0.0.0.0
5: tap0: mtu 1500 qdisc pfifo_fast master br0 state DOWN group default qlen 500
link/ether 5e:d3:82:68:88:f8 brd ff:ff:ff:ff:ff:ff
6: tap1: mtu 1500 qdisc pfifo_fast master br0 state DOWN group default qlen 500
link/ether 16:0e:01:a5:86:ec brd ff:ff:ff:ff:ff:ff
12: br0: mtu 1500 qdisc noqueue state UP group default
link/ether 16:0e:01:a5:86:ec brd ff:ff:ff:ff:ff:ff
inet 10.0.1.1/24 brd 10.0.1.255 scope global br0
valid_lft forever preferred_lft forever
inet6 fe80::140e:1ff:fea5:86ec/64 scope link
valid_lft forever preferred_lft forever

plato ~ # ip route
default via xxx.xxx.xxx.1 dev ethwan metric 3
10.0.1.0/24 dev br0 proto kernel scope link src 10.0.1.1
xxx.xxx.xxx.0/22 dev ethwan proto kernel scope link src xxx.xxx.xxx.xxx metric 3
127.0.0.0/8 dev lo scope host

plato ~ # iptables-save
# Generated by iptables-save v1.4.21 on Sun Dec 13 13:48:38 2015
*security
:INPUT ACCEPT [473565267:632749281948]
:FORWARD ACCEPT [5261203841:5797977299733]
:OUTPUT ACCEPT [132454471:129832246684]
COMMIT
# Completed on Sun Dec 13 13:48:38 2015
# Generated by iptables-save v1.4.21 on Sun Dec 13 13:48:38 2015
*nat
:PREROUTING ACCEPT [89501:8625139]
:INPUT ACCEPT [6928:950567]
:OUTPUT ACCEPT [640:93538]
:POSTROUTING ACCEPT [4095:1274859]
-A POSTROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
-A POSTROUTING -s 10.0.1.0/24 -o ethwan -j MASQUERADE
COMMIT
# Completed on Sun Dec 13 13:48:38 2015
# Generated by iptables-save v1.4.21 on Sun Dec 13 13:48:38 2015
*mangle
:PREROUTING ACCEPT [15670989:17942323405]
:INPUT ACCEPT [25652:2440270]
:FORWARD ACCEPT [15628625:17937514318]
:OUTPUT ACCEPT [21906:4147238]
:POSTROUTING ACCEPT [15648082:17940648821]
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
COMMIT
# Completed on Sun Dec 13 13:48:38 2015
# Generated by iptables-save v1.4.21 on Sun Dec 13 13:48:38 2015
*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [71064:13769380]
:logdrop - [0:0]
-A INPUT -i br0 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i ethlan -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -j DROP
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
-A FORWARD -i br0 -j ACCEPT
-A FORWARD -i ethlan -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -j DROP
COMMIT
posted by chndrcks at 11:50 AM on December 13, 2015

What's your rationale for having the MSS clamp occur in three places?

What are the chances that something funky is going on with IPv6?

Have you tried forcing an MTU for DHCP-connected clients using DHCP option 26?
posted by flabdablet at 5:49 PM on December 13, 2015

Could you use wireshark on your MBP to capture all your wifi traffic, and compare that with what tcpdump on your router says is going over the port connected to your WAP?
posted by flabdablet at 5:53 PM on December 13, 2015