Flyspray:: Mon, 25 Mar 2019 13:11:57 +0000 Flyspray::OpenWrt/LEDE Project: Recently edited tasks https://bugs.openwrt.org/ FS#2204: odhcpd: dhcpv6 preffered lifetime halved on renew of static lease rogerjames99 Mon, 25 Mar 2019 11:20:28 +0000 Model Linksys WRT1900ACS
Architecture ARMv7 Processor rev 1 (v7l)
Firmware Version Lede SNAPSHOT r9506-42f2e07ba0 / LuCI Master (git-19.061.64392-718fb97)
Kernel Version 4.14.103
odhcpd 2019-02-27-16c5b6c9-3

When using systemd-networkd to request a static ipv6 address from from an openwrt router. I run into the problem illustrated by the following trace. The address to follow is IA_ADDR 2001:8b0:1418:4c2f::9 pltime:2372 vltime:2372

34 dhcp6 renew (xid=1c3ff1 (server-ID hwaddr type 1 c25627d4a752) (IA_NA IAID:9 T1:1186 T2:1897 (IA_ADDR fda0:4d7f:afbb:4c2f::9 pltime:4294967295 vltime:4294967295) (IA_ADDR 2001:8b0:1418:4c2f::9 pltime:2372 vltime:2372)) (option-request DNS-server DNS-search-list NTP-server SNTP-servers) (client-ID hwaddr/time type 1 time 558114890 b827eb719903) (elapsed-time 0))
35 dhcp6 reply (xid=1c3ff1 (server-ID hwaddr type 1 c25627d4a752) (client-ID hwaddr/time type 1 time 558114890 b827eb719903) (opt_82) (DNS-server fda0:4d7f:afbb:4c2f::1) (IA_NA IAID:9 T1:580 T2:928 (IA_ADDR 2001:8b0:1418:4c2f::9 pltime:1161 vltime:1161) (IA_ADDR fda0:4d7f:afbb:4c2f::9 pltime:4294967295 vltime:4294967295)))

Note that the pltime has been halved in the routers reply!

42 dhcp6 renew (xid=973c61 (server-ID hwaddr type 1 c25627d4a752) (IA_NA IAID:9 T1:580 T2:928 (IA_ADDR fda0:4d7f:afbb:4c2f::9 pltime:4294967295 vltime:4294967295) (IA_ADDR 2001:8b0:1418:4c2f::9 pltime:1161 vltime:1161)) (option-request DNS-server DNS-search-list NTP-server SNTP-servers) (client-ID hwaddr/time type 1 time 558114890 b827eb719903) (elapsed-time 0))
43 dhcp6 reply (xid=973c61 (server-ID hwaddr type 1 c25627d4a752) (client-ID hwaddr/time type 1 time 558114890 b827eb719903) (opt_82) (DNS-server fda0:4d7f:afbb:4c2f::1) (IA_NA IAID:9 T1:285 T2:456 (IA_ADDR 2001:8b0:1418:4c2f::9 pltime:571 vltime:571) (IA_ADDR fda0:4d7f:afbb:4c2f::9 pltime:4294967295 vltime:4294967295)))

52 dhcp6 renew (xid=4f072e (server-ID hwaddr type 1 c25627d4a752) (IA_NA IAID:9 T1:285 T2:456 (IA_ADDR fda0:4d7f:afbb:4c2f::9 pltime:4294967295 vltime:4294967295) (IA_ADDR 2001:8b0:1418:4c2f::9 pltime:571 vltime:571)) (option-request DNS-server DNS-search-list NTP-server SNTP-servers) (client-ID hwaddr/time type 1 time 558114890 b827eb719903) (elapsed-time 0))
53 dhcp6 reply (xid=4f072e (server-ID hwaddr type 1 c25627d4a752) (client-ID hwaddr/time type 1 time 558114890 b827eb719903) (opt_82) (DNS-server fda0:4d7f:afbb:4c2f::1) (IA_NA IAID:9 T1:130 T2:208 (IA_ADDR 2001:8b0:1418:4c2f::9 pltime:261 vltime:261) (IA_ADDR fda0:4d7f:afbb:4c2f::9 pltime:4294967295 vltime:4294967295)))

and so on until

274: 106 01:45:01.745699 c2:56:27:d4:a7:52 > b8:27:eb:d4:eb:54, ethertype IPv6 (0x86dd), length 198: (flowlabel 0xc541e, hlim 64, next-header UDP (17) payload length: 144) fe80::c056:27ff:fed4:a752.547 > fe80::ba27:ebff:fed4:eb54.546: [udp sum ok] dhcp6 reply (xid=3eeea5 (server-ID hwaddr type 1 c25627d4a752) (client-ID hwaddr/time type 1 time 558114890 b827eb719903) (opt_82) (DNS-server fda0:4d7f:afbb:4c2f::1) (IA_NA IAID:9 T1:4294967295 T2:4294967295 (IA_ADDR fda0:4d7f:afbb:4c2f::9 pltime:4294967295 vltime:4294967295) (IA_ADDR 2001:8b0:1418:4c2f::9 pltime:0 vltime:0)

At which point the client gives up and removes the address from the interface and does not attempt to reaccquire it.

I can get round this by having the client request an infinite lease. But I would prefer not to.

This does not look like the correct behaviour to me. Leasetime half life is a matter for the client not the server.

Steps to reproduce

1. Configure a network to request a static ipv6 lease.

:/etc/systemd/network $ cat 10-peglegpete.network
[Match]
Name=peglegpete

[Network]
DHCP=yes
IPv6AcceptRA=yes

[Address]
Address=2001:1111:2222:3333::9/64

[DHCP]
DUIDType=link-layer-time
DUIDRawData=00:01:21:44:28:4a:b8:27:eb:71:99:03
IAID=9

2. Set up a static lease in odhcpd using matching DUID and IAID data. Remember to prefix the DUID with the DUID-LLT type code 0001.

]]>
https://bugs.openwrt.org/index.php?do=details&task_id=2204 https://bugs.openwrt.org/index.php?do=details&task_id=2204
FS#2203: mtk_eth_soc: cannot build without nf_conntrack LGA1150 Mon, 25 Mar 2019 09:53:19 +0000 CC drivers/net/ethernet/mediatek/mtk_eth_soc.o In file included from drivers/net/ethernet/mediatek/mtk_eth_soc.c:34:0: ./include/net/netfilter/nf_flow_table.h:19:2: error: unknown type name 'nf_hookfn' nf_hookfn *hook; ^~~~~~~~~ ./include/net/netfilter/nf_flow_table.h:149:23: warning: 'struct nf_hook_state' declared inside parameter list will not be visible outside of this definition or declaration const struct nf_hook_state *state); ^~~~~~~~~~~~~ ./include/net/netfilter/nf_flow_table.h:151:25: warning: 'struct nf_hook_state' declared inside parameter list will not be visible outside of this definition or declaration const struct nf_hook_state *state); ^~~~~~~~~~~~~ scripts/Makefile.build:326: recipe for target 'drivers/net/ethernet/mediatek/mtk_eth_soc.o' failed ]]> https://bugs.openwrt.org/index.php?do=details&task_id=2203 https://bugs.openwrt.org/index.php?do=details&task_id=2203 FS#1763: 18.06 doesn't obtain IPv6 address on mt76 Henry Gebhardt Fri, 10 Aug 2018 13:41:33 +0000 OpenWRT-18.06 doesn’t obtain an IPv6 address on the wan6 interface since commit 424a9ae128bd2045cd4bfd6e3229f2529d150a25. IPv6 works before that commit. The git bisect output is

$ git bisect good
There are only 'skip'ped commits left to test.
The first bad commit could be any of:
424a9ae128bd2045cd4bfd6e3229f2529d150a25
bfed38254076d576914251689a2e1f85d514783d
We cannot bisect more!

The WAN6 interface status when not working is

root@OpenWrt:~# ifstatus wan6
{
	"up": false,
	"pending": true,
	"available": true,
	"autostart": true,
	"dynamic": false,
	"proto": "dhcpv6",
	"device": "eth0.2",
	"data": {		
	}
}

The device is a Netgear R6220, and my ISP is Comcast in Pennsylvania.

I attach dmesg when running the last working commit.

Other users also have this problem, see this forum thread. (I’m the OP of that thread.)

Would be great to have IPv6 working again. Thank you!

Steps to reproduce:
0. Delete .config file, in “make menuconfig” select appropriate target (MediaTek Ralink MIPS), subtarget (MT7621), and target profile (Netgear R6220).
1a. Compile image prior to above commits, upload to router
1b. Run “sysupgrade -v -n /tmp/*.tar” 1c. Confirm that IPv6 is working, e.g. by pointing browser to ipv6-test.com, or “ifstatus wan6” on the router
2a. Compile image from source after above mentioned commits, e.g. tag “v18.06.0”, upload to router
2b. Run “sysupgrade -v -n /tmp/*.tar” 2c. Confirm that IPv6 is not working

]]>
https://bugs.openwrt.org/index.php?do=details&task_id=1763 https://bugs.openwrt.org/index.php?do=details&task_id=1763
FS#1978: syscall getrandom() hangs on Turris Omnia Andrew McConachie Fri, 30 Nov 2018 14:54:54 +0000 Supply the following if possible:
- Device problem occurs on
- Software versions of OpenWrt/LEDE release, packages, etc.
- Steps to reproduce

root@OpenWrt:/~# uname -a
Linux OpenWrt 4.14.63 #0 SMP Wed Aug 15 20:42:39 2018 armv7l GNU/Linux

root@OpenWrt:~# cat /proc/version
Linux version 4.14.63 (buildbot@builds-03.infra.lede-project.org) (gcc version 7.3.0 (OpenWrt GCC 7.3.0 r7101-a63e38b)) #0 SMP Wed Aug 15 20:42:39 2018

root@OpenWrt:~# uptime
14:40:46 up 1:14, load average: 0.00, 0.00, 0.00

root@OpenWrt:~# cat /proc/device-tree/model
Turris Omniaroot@OpenWrt:~#

root@OpenWrt:~# ps |grep rand
2228 root 1128 S /bin/sh /sbin/urandom_seed
2247 root 748 S getrandom 512
3114 root 1056 R grep rand

root@OpenWrt:~# cat /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 1 (v7l)
BogoMIPS : 1600.00
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
CPU implementer : 0×41 CPU architecture: 7
CPU variant : 0×4 CPU part : 0xc09
CPU revision : 1

processor : 1
model name : ARMv7 Processor rev 1 (v7l)
BogoMIPS : 1600.00
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
CPU implementer : 0×41 CPU architecture: 7
CPU variant : 0×4 CPU part : 0xc09
CPU revision : 1

Hardware : Marvell Armada 380/385 (Device Tree)
Revision : 0000
Serial : 0000000000000000

root@OpenWrt:~# cat /proc/devices
Character devices:

1 mem
4 ttyS
5 /dev/tty
5 /dev/console
5 /dev/ptmx

10 misc
89 i2c
90 mtd
108 ppp
128 ptm
136 pts
180 usb
189 usb_device
251 watchdog
252 rtc
253 ttyMV
254 gpiochip

Block devices:

7 loop
8 sd

31 mtdblock
65 sd
66 sd
67 sd
68 sd
69 sd
70 sd
71 sd
128 sd
129 sd
130 sd
131 sd
132 sd
133 sd
134 sd
135 sd
179 mmc
254 ubiblock
259 blkext

root@OpenWrt:~# ls -l /dev/|grep rand
crw-rw-rw- 1 root root 1, 8 Nov 30 13:26 random
crw-rw-rw- 1 root root 1, 9 Nov 30 13:26 urandom

 

I am using the stock images from here:
https://downloads.openwrt.org/releases/18.06.1/targets/mvebu/cortexa9/openwrt-18.06.1-mvebu-cortexa9-turris-omnia-initramfs-kernel.bin https://downloads.openwrt.org/releases/18.06.1/targets/mvebu/cortexa9/openwrt-18.06.1-mvebu-cortexa9-turris-omnia-kernel.bin https://downloads.openwrt.org/releases/18.06.1/targets/mvebu/cortexa9/openwrt-18.06.1-mvebu-cortexa9-turris-omnia-sysupgrade.img.gz

I discovered this when troubleshooting why unbound would not start. I could see with strace that unbound was getting stuck at the getrandom() syscall, and at first I thought it was a problem with unbound. But then I saw that /usr/bin/getrandom 512 had been stuck since boot. The syscall just blocks forever.

root@OpenWrt:~# which getrandom
/usr/bin/getrandom
root@OpenWrt:~# strace /usr/bin/getrandom 512 >/tmp/derp.txt
execve(”/usr/bin/getrandom”, [”/usr/bin/getrandom”, “512”], 0xbead7df4 /* 13 vars */) = 0
set_tls(0xb6f31544, 0xbe8aec28, 0x490ceab4, 0, 0xb6f314a0) = 0
set_tid_address(0xb6f314bc) = 3132
open(”/etc/ld-musl-armhf.path”, O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open(”/lib/libgcc_s.so.1”, O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=41251, ...}) = 0
read(3, “\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\20<\0\0004\0\0\0”..., 936) = 936
mmap2(NULL, 110592, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xb6ea0000
mmap2(0xb6eb9000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0×9000) = 0xb6eb9000
close(3) = 0
mprotect(0xb6eb9000, 4096, PROT_READ) = 0
mprotect(0×20000, 4096, PROT_READ) = 0
ioctl(1, TIOCGWINSZ, 0xbe8aec80) = -1 ENOTTY (Not a tty)
getrandom(


‘/usr/bin/head /dev/urandom’ returns random data like you expect.
‘/usr/bin/head /dev/random’ just hangs.

]]>
https://bugs.openwrt.org/index.php?do=details&task_id=1978 https://bugs.openwrt.org/index.php?do=details&task_id=1978
FS#2202: brcm63xx: Hg556a: kernel boot stuck at "random: crng init done" Israel Sat, 23 Mar 2019 10:51:00 +0000 The kernel 4.14.107 is unable to boot on the Hg556a (BCM6358).

Steps to reproduce:

  Intall the latest trunk version kernel 4.14.107

Sympthoms:

  No Boot
  It stucks at “random: fast init done”, and apparently no more kernel messages
  But after a minute it spits the last message random: crng init done

Boot Log:

*** Press any key to stop auto run (1 seconds) ***
Auto run second count down: 0
boot kernel from be020100
Code Address: 0x80A00000, Entry Address: 0x80a00000
Decompression OK!
Entry at 0x80a00000
Closing network.
Starting program at 0x80a00000
[    0.000000] Linux version 4.14.107 (hg556a@localhost.localdomain) (gcc version 7.4.0 (OpenWrt GCC 7.4.0 r9015-34696ce25e)) #0 Thu Mar 10 15:47:43 2019
[    0.000000] Detected Broadcom 0x6358 CPU revision a1
[    0.000000] CPU frequency is 300 MHz
[    0.000000] 64MB of RAM installed
[    0.000000] board_bcm963xx: Boot address 0xbe000000
[    0.000000] board_bcm963xx: CFE version: d081.5003
[    0.000000] bcm63xx_nvram: nvram checksum failed, contents may be invalid (expected 33313330, got 3c502ae7)
[    0.000000] bootconsole [early0] enabled
[    0.000000] CPU0 revision is: 0002a010 (Broadcom BMIPS4350)
[    0.000000] board: board name: HW556_B
[    0.000000] MIPS: machine is Huawei EchoLife HG556a (version B)
[    0.000000] Determined physical RAM map:
[    0.000000]  memory: 04000000 @ 00000000 (usable)
[    0.000000] Initrd not found or empty - disabling initrd
[    0.000000] Primary instruction cache 16kB, VIPT, 2-way, linesize 16 bytes.
[    0.000000] Primary data cache 16kB, 2-way, VIPT, cache aliases, linesize 16 bytes
[    0.000000] Zone ranges:
[    0.000000]   Normal   [mem 0x0000000000000000-0x0000000003ffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000000000-0x0000000003ffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x0000000003ffffff]
[    0.000000] random: get_random_bytes called from start_kernel+0x80/0x488 with crng_init=0
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 16256
[    0.000000] Kernel command line: rootfstype=squashfs,jffs2 noinitrd console=ttyS0,115200
[    0.000000] PID hash table entries: 256 (order: -2, 1024 bytes)
[    0.000000] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[    0.000000] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Memory: 54392K/65536K available (6369K kernel code, 343K rwdata, 2132K rodata, 1324K init, 256K bss, 11144K reserved, 0K cma-reserved)
[    0.000000] SLUB: HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] NR_IRQS: 256
[    0.000000] clocksource: MIPS: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 12741736309 ns
[    0.000026] sched_clock: 32 bits at 150MHz, resolution 6ns, wraps every 14316557820ns
[    1.034043] random: fast init done
[   53.820705] random: crng init done


]]>
https://bugs.openwrt.org/index.php?do=details&task_id=2202 https://bugs.openwrt.org/index.php?do=details&task_id=2202
FS#2201: kernel error: do_page_fault(): sending SIGSEGV to reader#1 for invalid read access from 77a87d90 camel Fri, 22 Mar 2019 21:05:36 +0000 current trunk from 22.3.2019
git-19.079.18950-11e64f8) / OpenWrt SNAPSHOT r9672-d78e229903

i see in the logs that having more often kernel error:

Fri Mar 22 15:14:27 2019 kern.info kernel: [11750.766284] do_page_fault(): sending SIGSEGV to reader#1 for invalid read access from 77a87d90
Fri Mar 22 15:14:27 2019 kern.info kernel: [11750.774984] epc = 77f55944 in libc.so[77edb000+94000]
Fri Mar 22 15:14:27 2019 kern.info kernel: [11750.780320] ra = 77f558e0 in libc.so[77edb000+94000]

any idea about what can be the reason for it ? or how i can give you more infos ?

]]>
https://bugs.openwrt.org/index.php?do=details&task_id=2201 https://bugs.openwrt.org/index.php?do=details&task_id=2201
FS#2200: Luci doesn't accept multiple IPv6 prefixes Trey Sis Fri, 22 Mar 2019 14:25:45 +0000 Under Luci → Network → Interfaces → interface-id you can define the routed IPv6 prefixes on an interface, but Luci only accepts one prefix in the “IPv6 routed prefix” field. This field should accept a space-separated list.

You can still define multiple prefixes directly in the configuration at /etc/config/network, e.g.:
option ip6prefix ‘prefix1::/64 prefix2::/64’ Doing that will lead to Luci showing both prefixes on the configuration page, but deny changes due to the wrong format of this field.

]]>
https://bugs.openwrt.org/index.php?do=details&task_id=2200 https://bugs.openwrt.org/index.php?do=details&task_id=2200
FS#2199: Bananapi R2, Kernel command line problem Ivan Fri, 22 Mar 2019 08:07:23 +0000 Can not configure root variable in kernel command line with U-Boot. Please clean
CONFIG_CMDLINE for linux kernel.

thanks.

 


]]>
https://bugs.openwrt.org/index.php?do=details&task_id=2199 https://bugs.openwrt.org/index.php?do=details&task_id=2199
FS#2198: Tow entangled problems involving boost and package integration. reallyohwell Thu, 21 Mar 2019 23:03:14 +0000 This involves an x86 generic full build of 18.02.
This seems less to be a problem directly involving packages, and more a
problem involving the integration of packages.

The builds were finishing up to this point.
In make menuconfig, I added in a few packages to replace the weaker
binutils version of these utilities, e.g., the less package, because I
wanted the search capability.
Apparently these additions got tangled up with boost, which was not at
this point selected:

cp -fpR -v /home/stuff/code/openwrt/repo/build_dir/target-i386_pentium4_musl/boost_1_68_0/ipkg-install/lib/*.{a,so*} /home/stuff/code/openwrt/repo/tmp/stage-boost/usr/lib/
‘/home/stuff/code/openwrt/repo/build_dir/target-i386_pentium4_musl/boost_1_68_0/ipkg-install/lib/libboost_exception.a’ → ‘/home/stuff/code/openwrt/repo/tmp/stage-boost/usr/lib/libboost_exception.a’ cp: cannot stat ‘/home/stuff/code/openwrt/repo/build_dir/target-i386_pentium4_musl/boost_1_68_0/ipkg-install/lib/*.so*’: No such file or directory

I searched for the unusual string {a,so*} and found it in feeds/packages/libs/boost/Makefile
line 473.
Apparently boost was being pulled in, but not creating any .so* files, even though boost was not yet selected.

So I went into make menuconfig and selected boost. Same problem.

Then I split line 473 to this form:

$(CP) -v $(PKG_INSTALL_DIR)/lib/*.a $(1)/usr/lib/
-$(CP) -v $(PKG_INSTALL_DIR)/lib/*.so* $(1)/usr/lib/

(It had been {a,so*}).
This (I think) will execute the same if boost is creating any .so files,
but will otherwise get past this step if no .so files are being created.

It seemed to work at first. But then (using make -j1) I started getting
complaints about the newly selected packages overwriting busybox versions of
files.
If you look more closely you will see that these errors wrote in the middle
of the string “Configuring boost.”
CoCollected errors:
* check_data_file_clashes: Package logger wants to install file /home/stuff/code/openwrt/repo/build_dir/target-i386_pentium4_musl/root-x86/usr/bin/logger

      But that file is already provided by package  * busybox

* opkg_install_cmd: Cannot install package logger.
* check_data_file_clashes: Package findutils-find wants to install file /home/stuff/code/openwrt/repo/build_dir/target-i386_pentium4_musl/root-x86/usr/bin/find

      But that file is already provided by package  * busybox

* opkg_install_cmd: Cannot install package findutils-find.
* check_data_file_clashes: Package findutils-xargs wants to install file /home/stuff/code/openwrt/repo/build_dir/target-i386_pentium4_musl/root-x86/usr/bin/xargs

      But that file is already provided by package  * busybox

* opkg_install_cmd: Cannot install package findutils-xargs.
* check_data_file_clashes: Package less-wide wants to install file /home/stuff/code/openwrt/repo/build_dir/target-i386_pentium4_musl/root-x86/bin/less

      But that file is already provided by package  * less

* opkg_install_cmd: Cannot install package less-wide.
nfiguring boost.

Note that busybox doesn’t like having logger, find, and xargs overwritten,
but I also selected find and less, which should have overwritten busybox
versions of the files. But that didn’t generate any complaints.

Here is where my memory gets a little hazy... I found out about this time that
menuconfig/boost was set to not install any libraries, so I selected ‘all
libraries’, and that may have gotten rid of the boost .so problem, because the
boost build was now creating .so files.

But I was still getting the file overwrite problem, so I yanked out the
offending package selections. At that point the make process completed.

Anyway, that’s what happened.

 


]]>
https://bugs.openwrt.org/index.php?do=details&task_id=2198 https://bugs.openwrt.org/index.php?do=details&task_id=2198
FS#2170: WNDR3400 v2 needs gpio pin 21 high to enable USB Eric Bohlman Thu, 07 Mar 2019 02:45:23 +0000 The Netgear WNDR3400 v2, just like the v3, requires GPIO pin 21 to be set to high for the USB port to work, but the current software version doesn’t do it.

Upon powerup, USB devices are not recognized. After executing

echo "21" > /sys/class/gpio/export
echo "out" > /sys/class/gpio/gpio21/direction
echo "1" > /sys/class/gpio/gpio21/value

they are recognized. Because this comes after files have been mounted, it’s necessary to reboot to access, say, an extroot.

]]>
https://bugs.openwrt.org/index.php?do=details&task_id=2170 https://bugs.openwrt.org/index.php?do=details&task_id=2170