Dear Turris users,
3.7.1 is now released for all. It is a minor version that just fixes what made problems in 3.7 and it also has important security fixes included.
Changes are:
• kernel: security update to the newer version
• opnvpn: security update to the newer version (fixing CVE-2017-7521)
• knot: security update to the newer version
• luci-ssl: fix dependencies
• foris: fix data collecting
• printing: cups removed from userlist for old turris routers
• transmission-web package is included in repo again.
My router did not reboot properly after installing update. Not sure what happened exactly, but I could not connect any of my computers to wi-fi. Pressing router’s reset button did force reboot after which wi-fi works again.
root@XXX:~# gcom -d /dev/ttyUSB2
***SIM ERROR***
Check device port configuration.
Check SIM is inserted
Test SIM in a mobile phone?
root@XXX:~# gcom -d /dev/ttyUSB3
***SIM ERROR***
Check device port configuration.
Check SIM is inserted
Test SIM in a mobile phone?
root@XXX:~# uqmi -d /dev/cdc-wdm0 --get-signal-info
{
"type": "hdr",
"rssi": -125,
"ecio": 5,
"io": -106,
"type": "wcdma",
"rssi": -76,
"ecio": 16
}
root@XXX:~# mwan3 interfaces
/usr/sbin/mwan3: local: line 3: not in a function
Interface status:
interface wan is online and tracking is active
interface Lte is unknown and tracking is down
root@XXX:~# ifup Lte
root@XXX:~# cat /var/log/messages | grep -i Lte
2017-06-30T20:53:05+03:00 notice netifd[]: Lte (2360): Error setting PIN, check card manually
2017-06-30T23:53:05+03:00 info kernel[]: [ 16.092320] Netfilter messages via NETLINK v0.30.
2017-06-30T23:53:05+03:00 info kernel[]: [ 16.364618] ip6_tables: (C) 2000-2006 Netfilter Core Team
2017-06-30T23:53:05+03:00 info kernel[]: [ 30.107206] ip_tables: (C) 2000-2006 Netfilter Core Team
2017-06-30T20:53:05+03:00 notice netifd[]: Interface 'Lte' is now down
2017-06-30T20:53:20+03:00 notice vnstatd[7271]: Monitoring: 3g-Lte (100 Mbit) eth1 (100 Mbit)
2017-06-30T20:58:35+03:00 notice netifd[]: Interface 'Lte' is setting up now
2017-06-30T20:58:40+03:00 notice netifd[]: Lte (10306): Error setting PIN, check card manually
2017-06-30T20:58:40+03:00 notice netifd[]: Interface 'Lte' is now down
root@XXX:~#
That slowdown you describe when using device detection is strange.
Yes, device detection (which is a testbed for parental control backend) DOES examine traffic from local network, which MAY slow down the network, but this could become a problem with really heavy volumes of traffic. I wasn’t able to congest it during tests here.
From your description it seems to me that the first DNS request timeouted and that caused the slowdown before the ping got the IP address and actually started to ping/print something. I can’t think of a way how device detection could cause this.
Could you maybe try just DNS resolving using dig/nslookup ? They should also show some details, like how long the resolving took.
Can you some some cases of problems/slowdowns when using device detection?
I recognize it is very strange
A dig (i.e. dig -t a free.fr@213.73.91.35 - same dns that was configured on the router) or a nslookup from the client PC was immediate. A ping from the router itself was immediate
I’ll try to reinstall the experimental package to dig deeper