Raspberry Pi 3 built-in WiFi SSH NTP Problem

[Cocacola321]

I have a problem with NTP and built-in WiFi on Raspberry Pi3.

Under Rasbian the following command solve the problem with the builtin Wifi:
/sbin/iptables -t mangle -I POSTROUTING 1 -o wlan0 -p udp --dport 123 -j TOS --set-tos 0x00

If placed in rc.local it is automatically executed at boot.

But under libreelec, this command doesn't work, the file rc.local doesn't exists and I don't know how to make the equivalent adjustment under libreelec.

Could anybody help me?

[pelwell]

This would have been a good report if you'd linked to the Forum thread that properly describes the problem (https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=141454) and left out the bit about LibreElec.

[Cocacola321]

Thanks for your feedback but how can I fix the problem under libreelec because the commands that mentioned in the thread don't work under libreelec?

[MilhouseVH]

@Cocacola321: The suggested fix (iptables) is a workaround and not really what anyone would consider a suitable fix for all users. The fact it's not possible to apply the workaround with LE underlines this point.

Understanding the underlying problem and fixing it (maybe it's a driver issue?) is the best way forward and will benefit all distributions. Now that an issue has been opened, hopefully the RPi developers can get a handle on what might be happening. However this issue doesn't affect me when using LE and RPi3 WiFi, so it might be environment/router/access point specific (my access point is a Netgrear.DGND4000, using a Raspbian-based dnsmasq DHCP/DNS server configured with the Raspbian host 192.168.0.4 as timeserver).

If/when a fix becomes available you'll probably see it first in an LE nightly build...

[Ferroin]

Under DSCP standards (which is what NTP is actually setting, not TOS), 0xC3 translates to assured forwarding class 3 with high drop probability, which is pretty typical for non-critical signaling protocols like NTP.

The fact that your not getting a time lock on any of the servers indicates your losing packets somewhere. The fact that this only happens with the build-in WiFi and the 'official' dongles indicates that it's something either in their hardware, or the drivers, and given that this did work before, I'd say it's in the drivers.

Whether or not a layer 1 driver should be interpreting a layer 2 protocol and making decisions based on that interpretation is debatable, but that appears to be what's going on here, and in this case, it's a bad thing and needs to be fixed, as this behavior is not reasonable. Given the specific behavior and the fact that most other Linux networking software doesn't set a DSCP of a class higher than 2, I'd say what's happening is that the driver is not prioritizing which packets to drop based on class (most drivers drop lower class packets first, even if they have a lower drop probability tag), but is just checking the drop probability on everything and ignoring the class. I'm not sure if this goes counter to the standards, but it does go counter to how just about every other NIC driver in existence behaves.

[pelwell]

Thanks for your input, @Ferroin. I've opened a support issue with Broadcom to see what they say.

[vrabac]

I am also facing this issue on archlinuxarm by using timedatectl from systemd on my RPi3. With same config but using Ethernet ntp sync is just fine. When I unplug the cable and setup WiFi, the time could not be setup by timedatectl. I also tested with that iptables, but it was not working. I as thinking this Fritz (connected over WiFi to it) is blocking something, but as I don't have access to it, i was not able to check it, and leaved it so. But now that issue is open, it could relay be something with driver. Thanks to everyone involved!!

[vrabac]

So after reseting Fritz!Box and new setup of the WiFi i found that there were two WiFi SSID (normal and guest one), so seems normal was disabled before and the Guest was enabled were everything was blocked expect http.
After changing to "normal" WiFi my RPi3 was able to sync time over Wireless with NTP server just fine.
I am using archlinuxarm with up2date firmware/kernel!!

[pelwell]

@Ferroin Broadcom have come back to me asking for packet logs etc. I haven't been able to reproduce the issue myself, but this is what I've found so far:

NTP packets are sent out using a Differentiated Services Field value of 0xc0 (DSCP 0x30, Class Selector 6, ECN 0x00). A DSCP of 30 decimal (0x1e) would correspond to "assured forwarding class 3 with high drop probability", but this packet's DSCP is 48 decimal (0x30), so I don't understand your analysis.

@Cocacola321 Can you install the wireshark package (sudo apt-get update; sudo apt-get install wireshark) and run it both with and without the workaround installed? You can start it like this:

sudo wireshark -i wlan0 -p -k -f "udp port 123"

You may have to click OK a few times.

Once you've seen a few NTP messages - the capture with the workaround will include server responses, the one without presumably won't - stop the capture and save it. If you can then upload the captures somewhere - Dropbox, Google Drive, etc. - or email them to me directly (phil at raspberrypi dot org) that would be really helpful.

[ghollingworth]

Either that or upload the saved file to cloudshark...

:)

Gordon

On Thu, Jun 23, 2016 at 1:24 PM, Phil Elwell notifications@github.com
wrote:

@Ferroin https://github.com/Ferroin Broadcom have come back to me
asking for packet logs etc. I haven't been able to reproduce the issue
myself, but this is what I've found so far:

NTP packets are sent out using a Differentiated Services Field value of
0xc0 (DSCP 0x30, Class Selector 6, ECN 0x00). A DSCP of 30 decimal (0x1e)
would correspond to "assured forwarding class 3 with high drop
probability", but this packet's DSCP is 48 decimal (0x30), so I don't
understand your analysis.

@Cocacola321 https://github.com/Cocacola321 Can you install the
wireshark package (sudo apt-get update; sudo apt-get install wireshark) and
run it both with and without the workaround installed? You can start it
like this:

sudo wireshark -i wlan0 -p -k -f "udp port 123"

You may have to click OK a few times.

Once you've seen a few NTP messages - the capture with the workaround will
include server responses, the one without presumably won't - stop the
capture and save it. If you can then upload the captures somewhere -
Dropbox, Google Drive, etc. - or email them to me directly (phil at
raspberrypi dot org) that would be really helpful.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#1519 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AB9CHJP3JwF7RFimfIAgyhCmPzxo5By7ks5qOnr8gaJpZM4IwTDL
.

[ksze]

I applied the iptable workaround for NTP, and that works.

How about SSH? I can't find that thread about SSH. Is there a workaround iptables rule for that?

[kukabu]

@ksze you can set QoS for ssh via ssh_config/sshd_config. Also ntpd 4.2.8 can sets any DSCP via config.

[mhdismail]

Same issue here on a fresh install. After a lot of struggle, the iptables workaround fixed it.

[david-a-wheeler]

This is a frustrating problem, because you can't access many websites with an incorrect date time... making it harder to get help. I hope this can be fixed very soon, I suspect a large number of people are having the problem but cannot figure out how to report it since they cannot get the internet working. Good luck.

[jcloudm]

I have this issue manifesting itself as problems with ssh hangs after password authentication. I have solved this issue by turning on QOS in my dlink router, but am willing to help with more details. If it would help Broadcom, I am more than willing to do a wireshark capture with some instructions.