Re: [OpenWrt-Devel] OpenWrt 19.01 plans
On 09/27/2018 04:22 PM, Hauke Mehrtens wrote: On 09/26/2018 09:38 AM, Koen Vandeputte wrote: On 2018-09-23 00:42, Hauke Mehrtens wrote: Hi, We talked about plans for the next OpenWrt releases in this mail thread: http://lists.infradead.org/pipermail/openwrt-adm/2018-July/000849.html This mail is more or less a summary of the conclusions, this is still open for change especially the dates as this depends on people having time to do the work. The next release, lets call it OpenWrt 19.01, should happen in January 2019, we would branch off from master in December 2018. This is the current plan, but based on past experience it could also happen later. OpenWrt 19.01 will ship with kernel 4.14 only, we encourage everyone to update the targets to kernel 4.14, support for kernel 4.19 will probably be added to OpenWrt master soon, but we will not select it as the default kernel for any target till OpenWrt 19.01 is branched off, to get more testing on 4.14. The release after 19.01, which should happen in late summer 2019, should then use kernel 4.19 only. For OpenWrt 19.01 GCC will stay on the 7.X branch, binutils and musl already got some upgrades after the 18.06 release and could get some more updates. We are currently working on updating the wireless drivers and getting them closer to upstream. The wireless driver in OpenWrt 19.01 will be taken from kernel 4.19 or later and we want to update them more frequently in master. Otherwise we will have the normal changes in all places like with every release. LEDE 17.01 will get security updates and occasional bug fixes till OpenWrt 19.01 was released, but we encourage everyone to upgrade to 18.06 to get full security support already now, as especially some of the packages are not well maintained any more. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel Hi Hauke, Hi All, Some targets are still on (EOL) kernel 3.18 today. This kernel also still exists by the grace of Greg K-H but could be dropped any moment. I've bumped it a few times (untested) just for the sake of security updates. But afaict, nobody attempted/requested to update these to a newer kernel version. These targets were also dropped in 18.06 branch. Maybe we should also consider dropping support for these targets in master? adm5120 xburst mcs814x au1000 ppc40x adm8668 ppc44x I vote for removing them if on one wants to take care of these targets. If something breaks kernel < 4.9 I anyway do not care any more. Hauke Considering that OpenWrt is volunteer spare time and hobby support, it is probably prudent to aggressively drop old and less popular targets. Considering 802.11ax is around the corner and (ac) is well established, it won't be hard to find for example ath79 compatible devices in (ac) or (n) as either new-overstock or used. They may not be able to push lots of bandwidth, but if you have <~100Mbps internet they don't need to. If you have >~200Mbps internet for example with DOCSIS3.1 provider, then you probably need a newer dual-core device to take advantage of it. Bottom line is it probably won't hurt to drop many targets, because small budget users will still have plenty to chose from. Eric ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Quick question about firewall patch
I’m looking at: https://git.openwrt.org/?p=project/firewall3.git;a=commitdiff;h=c03e20d7f594058ff223f30cf34de1b5e8210b8d;hp=b59934331c4b9271ceb5e30b793a552618299d39 and wondering, why not just do: v4->s_addr = htonl(~(UINT_MAX >> bits)); For instance, with bits == 14, we get: UINT_MAX >> 14 == 0x0003 ~0x0003 == 0xfffc Checking the case for bits == 0, we get: UINT_MAX >> 0 == 0x ~0x == 0x And for bits == 32, we get: UINT_MAX >> 32 == 0x ~0x == 0x ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Tarpit support in firewall
Jo-Philipp, Felix, et al:
I’ve added the following to my /etc/firewall.user but I was thinking it might
be useful for others, and worth integrating into the firewall.
It’s currently implemented in Shell, but should be trivial in C.
The relevant config (/etc/config/firewall) looks like:
config tarpit
option name 'misc'
option src wan
option dest_port
'22,23,113,119,123,161,220,222,389,397,515,623,873,1433,1720,1723,1812,2323,2375-2376,3128,3306,3388-3398,5000-5001,5038,5060,5351,5353,5358,5431,,5900-5959,6000-6063,6379,7000-7009,7547,9000,9200,10250,11211'
config tarpit
option name 'mail'
option src wan
option dest_port '110,143,465,995'
config tarpit
option name 'web'
option src wan
option dest_port '81-94,1080,8000-8001,8080-8088,8181,'
config tarpit
option name 'netbios'
option src wan
option dest_port '137-139’
The scripting looks like:
…
tarpit_add() {
local cfg="$1"
local name src ports
config_get name "$cfg" name
[ -n "$name" ] || return 0
config_get src "$cfg" "src"
[ -n "$src" ] || return 0
local initial="${src:0:1}"
iptables -D "input_${src}_rule" -m set --match-set "tarpit_${name}" dst
-j "i${initial}r_${name}" 2>/dev/null
iptables -F "i${initial}r_${name}" 2>/dev/null
iptables -X "i${initial}r_${name}" 2>/dev/null
ipset list "tarpit_${name}" >/dev/null 2>&1 && ipset destroy
"tarpit_${name}"
ipset create "tarpit_${name}" bitmap:port range 0-65535
config_get ports "$cfg" "dest_port"
local port IFS=', '
for port in $ports; do
ipset add "tarpit_${name}" "${port}" \
|| echo "Couldn't add ${port} to tarpit_${name}" >&2
done
iptables -N "i${initial}r_${name}"
iptables -A "i${initial}r_${name}" -m limit --limit 1/sec --limit-burst
5 -j LOG --log-level 4 --log-prefix "TARPIT ${name}: "
iptables -A "i${initial}r_${name}" -m tcp -p tcp -j TARPIT
iptables -A "input_${src}_rule" -m set --match-set "tarpit_${name}" dst
-m tcp -p tcp -j "i${initial}r_${name}"
return 0
}
. /lib/functions/network.sh
config_load firewall
config_foreach tarpit_add tarpit "$@“
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] dnsmasq stops receiving packets after network restart
Hi, On Tue, Sep 25, 2018 at 11:23 AM Jo-Philipp Wich wrote: > Maybe netlink congestion or something related to privilege dropping? Can > you manage to capture an strace log of the running dnsmasq instance > while the network is getting restarted? After some discussion on the dnsmasq mailing list, the cause has been found and your theory about "resubscribe" is correct. When dnsmasq is configured to listened to one particular interface, dnsmasq binds (SO_BINDTODEVICE) to this interface during startup if the interface is available. On my devices, I had configured dnsmasq to only listen to br-lan. When I restart networking, br-lan is re-created. This event is not detected by dnsmasq and the socket will silently fail. If I configure dnsmasq to listen to two interfaces, SO_BINDTODEVICE is never used and the error disappears. Why this error has appeared now is still unknown, but it could be because no one has gone looking for it. My current work-around, base on the advice of Simon Kelley, is to have the function which looks up the interface to bind to (whichdevice()) return NULL. Filtering of received packets is anyway done not dependent on the bound socket. BR, Kristian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt 19.01 plans
On 09/26/2018 09:38 AM, Koen Vandeputte wrote: > > > On 2018-09-23 00:42, Hauke Mehrtens wrote: >> Hi, >> >> We talked about plans for the next OpenWrt releases in this mail thread: >> http://lists.infradead.org/pipermail/openwrt-adm/2018-July/000849.html >> This mail is more or less a summary of the conclusions, this is still >> open for change especially the dates as this depends on people having >> time to do the work. >> >> The next release, lets call it OpenWrt 19.01, should happen in January >> 2019, we would branch off from master in December 2018. This is the >> current plan, but based on past experience it could also happen later. >> >> OpenWrt 19.01 will ship with kernel 4.14 only, we encourage everyone to >> update the targets to kernel 4.14, support for kernel 4.19 will probably >> be added to OpenWrt master soon, but we will not select it as the >> default kernel for any target till OpenWrt 19.01 is branched off, to get >> more testing on 4.14. The release after 19.01, which should happen in >> late summer 2019, should then use kernel 4.19 only. >> >> For OpenWrt 19.01 GCC will stay on the 7.X branch, binutils and musl >> already got some upgrades after the 18.06 release and could get some >> more updates. >> >> We are currently working on updating the wireless drivers and getting >> them closer to upstream. The wireless driver in OpenWrt 19.01 will be >> taken from kernel 4.19 or later and we want to update them more >> frequently in master. >> >> Otherwise we will have the normal changes in all places like with every >> release. >> >> LEDE 17.01 will get security updates and occasional bug fixes till >> OpenWrt 19.01 was released, but we encourage everyone to upgrade to >> 18.06 to get full security support already now, as especially some of >> the packages are not well maintained any more. >> >> Hauke >> >> >> >> ___ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel > Hi Hauke, > Hi All, > > Some targets are still on (EOL) kernel 3.18 today. > This kernel also still exists by the grace of Greg K-H but could be > dropped any moment. > > I've bumped it a few times (untested) just for the sake of security > updates. > But afaict, nobody attempted/requested to update these to a newer kernel > version. > > These targets were also dropped in 18.06 branch. > Maybe we should also consider dropping support for these targets in master? > > > adm5120 > xburst > mcs814x > au1000 > ppc40x > adm8668 > ppc44x I vote for removing them if on one wants to take care of these targets. If something breaks kernel < 4.9 I anyway do not care any more. Hauke signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Cannot build python3
Hi, I cannot build the host python3 _ctypes module. Some more info on https://forum.openwrt.org/t/error-building-python3-on-opensuse/21764 . I'm building OpenWRT 18.06.1 on openSUSE LEAP 15.0. The _ctypes module is linked against staging_dir/hostpkg/lib/libffi.so.6, but when doing the import test, it searches /usr/lib64. And it has libffi.so.7, so the test fails. Building on ubuntu works, it probably finds /usr/lib/x86_64-linux-gnu/libffi.so.6. Don't know how to fix this. //Jan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
