Turris OS 3.10.2 released

release

#22

So far logical/true.

That is not happening. Trying to login on wan port 22 is not getting a login bump (like it used prior TO 3.10.1), either sft or scp or ssh.


Don’t know why it is not present on the output of iptables -L or iptables -S, it is however present in LuCI -> Status -> Firewall

These are pre-set rules I disabled

Summary
config rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'
	option enabled '0'

config rule
	option name 'Allow-Ping'
	option src 'wan'
	option proto 'icmp'
	option icmp_type 'echo-request'
	option family 'ipv4'
	option target 'ACCEPT'
	option enabled '0'

config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option proto 'igmp'
	option family 'ipv4'
	option target 'ACCEPT'
	option enabled '0'

config rule
	option name 'Allow-DHCPv6'
	option src 'wan'
	option proto 'udp'
	option src_ip 'fe80::/10'
	option src_port '547'
	option dest_ip 'fe80::/10'
	option dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'
	option enabled '0'

config rule
	option name 'Allow-MLD'
	option src 'wan'
	option proto 'icmp'
	option src_ip 'fe80::/10'
	list icmp_type '130/0'
	list icmp_type '131/0'
	list icmp_type '132/0'
	list icmp_type '143/0'
	option family 'ipv6'
	option target 'ACCEPT'
	option enabled '0'

config rule
	option name 'Allow-ICMPv6-Input'
	option src 'wan'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	list icmp_type 'router-solicitation'
	list icmp_type 'neighbour-solicitation'
	list icmp_type 'router-advertisement'
	list icmp_type 'neighbour-advertisement'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'
	option enabled '0'

config rule
	option name 'Allow-ICMPv6-Forward'
	option src 'wan'
	option dest '*'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'
	option enabled '0'

config rule
	option src 'wan'
	option dest 'lan'
	option proto 'esp'
	option target 'ACCEPT'
	option enabled '0'

config rule
	option src 'wan'
	option dest 'lan'
	option dest_port '500'
	option proto 'udp'
	option target 'ACCEPT'
	option enabled '0'

#23

Hmmm, is haas itself running? ps | grep haas Do you have your device token set? uci -q get haas.settings.token Can you connect to the haas server? ping haas-app.nic.cz

It is part of nat table, sou you need to use iptables -S -t nat.

You are right, all of those look irrelevant to HaaS :-/


#24

pls ignore my prior post…I was able to ssh to port 22 on my router from a different network, and I got the honeypot. the haas site logged my request, so haas is working properly for me in 3.10.2.


#25

Yeah, right, missed that with being rusty on ipt after mainly working with nft these days. So the chain zone_wan_prerouting is present.

Had HaaS meantime removed and not going to install again directly. Running it on a couple of other boxes though in lxc unpriviliged containers, which makes me feel more comfortable, and having better control of the nft rules.

Might put it back on the router later on into a lxc container and having finished the nft firewall


Been wondering about their relevance or usefulness from the beginning, but that would another topic altogther


#26

Let me ask, why do you believe that disabling ICMP echo requests from the router is helpful, and why do you want to disallow ICMPv6 packet processing? The former will simply make things like smoke pinging your router impossible (without buying you much security) while the latter will make IPv6 though your router harder than it should be (things like path-MTU discovery require certain ICMP packets to reach the original sender). Finally “esp” and udp port 500 are required for IPSEC connections. I would guess that you do not use IPv6 at all and hence disabling the ICMPv6 has no negative effect on your network right now, same for ipsec.

Best Regards


#27

correct on both counts. ipv6 is disabled in the kernel (there is some other thread about it). If I need to access the router remotely I do over over an ovpn (tap) server (vps offshore) with only the ovpn client (tap) on the router.

I have no need to ping the router from the wan and so has no nobody else. Thus anything not needed is removed.

No issues with MTU. Most are set around 1500 anyway, unless that is for jumbo frames, latter not working on bridges anway


#28

Just make sure to enable ICMPv6 forwarding again once you enable IPv6 (same for IPSEC).

Again, have a look at smokeping (dslreports has a free smokeping service after a free registration) that allows you to monitor availability and RTT to your router from remote places giving you insight in your ISPs internal and/or peering congestion. Nothing one can not live without, but often nice to have when debugging transient latency issues in a network.

If in doubt throw it out :wink: (I note that this can have subtle side-effects if the disabled/removed entities are rarely used, but critical in those rare use-cases).
Your network, your rules.

Best Regards


#29

I am fortunate with my ISP, rather professional folks (and yet without ipv6 :wink:)


About MTU it might be worth mentioning that I have tcp_mtu_probing (RFC4821) enabled, which is not by default. From RFC4821 section 6.2

As a last resort, it may be possible to rely on an adjunct protocol, such as ICMP ECHO (“ping”), to send probe packets.


Tos 3.10.3 - wifi mtu settings neglected
#30

That might be related to changes in knot-resolver since 2.2.0. When a nameserver’s IP appears to be unreachable even after several retries, this unreachability gets cached for a short time (a minute).


#31

Turris Omnia, updated from version 3.9.6 to 3.10.2, but ends as follows:

INFO:Executing preupdate hooks…
INFO:Subprogram output: /etc/updater/hook_preupdate/05_schnapps.sh:
Snapshot number 189 created

INFO:End of subprogram output
INFO:Unpacking download packages
INFO:Checking for file collisions between packages
line not found
line not found
line not found
line not found
line not found
line not found
DIE:
[string “transaction”]:317: [string “transaction”]:146: Collisions:
• /usr/bin/wget: wget-nossl (new-file), wget (existing-file)


#32

Try turn off automatic updates, SSH in and run:
opkg update
opkg install --force-reinstall wget
pkgupdate

Then turn automatic updates back on.


#33

The result has not changed.

INFO:Queue removal of python-crypto
Press return to continue, CTRL+C to abort

INFO:Executing preupdate hooks…
INFO:Subprogram output: /etc/updater/hook_preupdate/05_schnapps.sh:
Snapshot number 192 created

INFO:End of subprogram output
INFO:Unpacking download packages
INFO:Checking for file collisions between packages
line not found
line not found
line not found
line not found
line not found
line not found
DIE:
[string “transaction”]:317: [string “transaction”]:146: Collisions:
• /usr/bin/wget: wget (existing-file), wget-nossl (new-file)
Aborted


#34

I suppose it might also be related to my using DNS over TLS.

I’ve been getting a couple a day at least at this point.

Is there any way to turn down the sensitivity?

I had no issues updating to 3.10.2 and otherwise it appears to be running normally.


#35

Right, for forwarding the approach is sub-optimal ATM. It should help to have multiple IPs in there, but mainly you can shorten the period for which servers are skipped, e.g. one second would seem enough for your forwarding case cache.ns_tout(1000); docs.


#36

After installing the update I am getting a strange Socat/OPENSSL error. Details are below that I have copy/pasted from my system log.

Please advise how to proceed to fix the issue.

Thanks,

Robert

Device Turris Omnia - rtrom01
Serial number XXXXXXXXXXX
Turris OS version 3.10.2
Kernel version 4.4.136-695e41116993e0a4f080354e72f13d91-0
Sending of uCollect data Offline (status updated 45 seconds ago)
Sending of firewall logs Online (status updated 70 seconds ago)
2018-06-20 09:51:55 info ucollect[13366]: Reconnecting to api.turris.cz:5679 now
2018-06-20 09:51:55 info ucollect[13366]: Socat started
2018-06-20 09:51:55 err ucollect[13366]: Error from socat: 2018/06/20 09:51:55 socat[16756] E unknown device/address "OPENSSL"
2018-06-20 09:51:55 warning ucollect[13366]: Remote closed the uplink api.turris.cz:5679, reconnecting
2018-06-20 09:51:55 warning ucollect[13366]: epoll_wait on 4 interrupted, retry
2018-06-20 09:51:55 info ucollect[13366]: Reconnecting to api.turris.cz:5679 now
2018-06-20 09:51:55 warning ucollect[13366]: Reconnecting too often, waiting a little while
2018-06-20 09:51:55 info ucollect[13366]: Going to reconnect to api.turris.cz:5679 after 256 seconds

#37

Update worked seamlessly on my two TO.


#38

solved:

DIE:
[string “transaction”]:317: [string “transaction”]:146: Collisions:
• /usr/bin/wget: wget (existing-file), wget-nossl (new-file)
Aborted

opkg update
opkg remove wget
pkgupdate

O zařízení
Zařízení Turris Omnia - rtrom01
Sériové číslo xxxxxxxxxxxxx
Verze Turris OS 3.10.2
Verze jádra 4.4.136-695e41116993e0a4f080354e72f13d91-0
Odesílání dat z uCollect Online (stav aktualizován před 22 sekundami)
Odesílání záznamů (log) z brány firewall Online (stav aktualizován před 509 sekundami)
Aktualizovat


#39