From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.haj.ipfire.org (localhost [IPv6:::1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4fzkMw4ZJKz2yDM for ; Mon, 20 Apr 2026 11:51:08 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (secp384r1 raw public key) server-digest SHA384 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail01.haj.ipfire.org", Issuer "R12" (not verified)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4fzkMs22J7z2xKC for ; Mon, 20 Apr 2026 11:51:05 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4fzkMq6xMyz32r; Mon, 20 Apr 2026 11:51:03 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1776685864; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=AqUzEj+hYDYDu2lNj4yV4tL0LGX3zyXTI3uarjRONvU=; b=HNdUIMTTaGRY7iaCB401/kaOHGI7ViyyEIWvQfEvTv7CIxcncohTPUkfWmuxsOKatq4ZLt JYH6oCrHL807ozCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1776685864; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=AqUzEj+hYDYDu2lNj4yV4tL0LGX3zyXTI3uarjRONvU=; b=G4cNYHM5duE6/TTAxL6fULt7EvmvAaKZzbNURiSQ5r19tF6YsyJYk9f9SJcJa7PqqARjuV jN7UiNu7PAY1Ywo6Tiu+hvtYEazmmcnpHPOMK+Jf2OzcnnnAkSjPqNWh6beN/+EjsrEJJo yocdXSY3hAfl+kj+pdZBOPgbUBRsskN80zXDTQ57uoHatXXKq1WP8xfPhLVEqglmQ1/jyI bb/u+uQrAXCC8X28nJMTOrFHlFTrzlC9kBlHASb6WE343HqfUnCRDWyun/cXohN7mk/Ru/ s+3a96V9rduzsyCou3nR0wl+Kl6f6ad8GUIXAJ04zswF+qaTR+Qqa3PoPMlx4A== Content-Type: text/plain; charset=utf-8 Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: Mime-Version: 1.0 Subject: Re: Feedback on issues with DNSFW in CU201 Testing From: Michael Tremer In-Reply-To: <529b26c9-7d9d-450c-ba14-2e26854f9909@Canary> Date: Mon, 20 Apr 2026 12:51:03 +0100 Cc: "IPFire: Development-List" , Adolf Belka Content-Transfer-Encoding: quoted-printable Message-Id: References: <9786EB04-D529-48D2-9BB6-AEF37B246714@ipfire.org> <99E8DC3B-30D7-43D5-AEBE-34B01E2953A0@ipfire.org> <12445407-95ac-457d-b0fe-0f74a3d2eb21@ipfire.org> <8A994F8C-FB85-487E-9799-98CED1881E1F@ipfire.org> <14f1205d-60c6-4e4a-b986-7ed6178c9033@ipfire.org> <3b3a3c0a-bdb7-4522-b949-4ca9fda8e75f@ipfire.org> <71ac9fa2-1ba1-4d4f-8e10-533c61e02831@ipfire.org> <806B9D88-FFC4-4BD8-A976-49CB43249E66@ipfire.org> <529b26c9-7d9d-450c-ba14-2e26854f9909@Canary> To: Jon Murphy Hello Jon, I pushed a fix for this problem: = https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommitdiff;h=3Da7f578e949a3= 85e79f1b39f5ac19d7fea32f4bed The fix however is to check if a user has entered a valid domain name. = =E2=80=9C*.domain.tld=E2=80=9D is not a valid FQDN and therefore won=E2=80= =99t be saveable. This has been ported to Core Update 201 and I hope that we can finally = bring the testing stage of this release to an end. -Michael > On 15 Apr 2026, at 22:24, Jon Murphy wrote: >=20 > One more new issue: >=20 > If a domain is added to a custom block similar to `*.apple.com` then = an additional `*.` is added. So this: >=20 > *.news-events.apple.com > news-events.apple.com > *.zip >=20 > becomes this in the custom.zone file: >=20 > $ORIGIN _custom.rpz.local. > news-events.apple.com CNAME . > *.news-events.apple.com CNAME . > *.news-events.apple.com CNAME . > *.*.news-events.apple.com CNAME . > *.zip CNAME . > *.*.zip CNAME . >=20 > So there should be a check for a beginning `*.` and then not add an = additional asterisks. >=20 >=20 > =E2=80=94 > Jon >=20 >=20 > On Friday, Apr 10, 2026 at 11:46 AM, Jon Murphy = wrote: > The recent update allows more than one category and seems to work OK = (still testing). >=20 > Found a new issue; In the Firewall DNS > Access Control area > Custom = Source a CIDR notation of 192.168.74.0/24 works OK, but the subnet mask = notation of 192.168.74.0/255.255.255.0 throws this error: >=20 > Apr 10 11:25:45 ipfireAPU2 unbound: [1694:6] error: netblock too = large: 192.168.74.0/255.255.255.0 > Apr 10 11:25:45 ipfireAPU2 unbound: [1694:6] error: cannot parse = netblock: 192.168.74.0/255.255.255.0 > Apr 10 11:26:48 ipfireAPU2 dhcpd: execute_statement argv[0] =3D = /usr/sbin/unbound-dhcp-leases-client >=20 >=20 >=20 >> On Apr 10, 2026, at 5:09=E2=80=AFAM, Adolf Belka = wrote: >>=20 >> Hi Michael, >>=20 >> On 10/04/2026 11:33, Adolf Belka wrote: >>> Hi Michael, >>> On 09/04/2026 12:20, Michael Tremer wrote: >>>> Hello Adolf, >>>>=20 >>>> Could you please let me know is this fixes the problem? >>> It has solved the problem when the browser is set up to use No Proxy = or System Proxy and the PC has no proxy set up. >>> I was able to select Advertising, Dating, Gambling, Pornography, = Shopping and Streaming at the same time and trying to access URL's from = the lists of those zones caused the access to be blocked. Yaaah. Entries = for all these categories found in the unbound log. >>> Unfortunately when I changed the browser to use IPFire as the web = proxy (Conventional mode) by selecting Manual proxy configuration in the = browser and specifying the IPFire IP all accesses to the selected = categories listed above were allowed to be accessed except for the url = for the shopping site. That was still blocked and in the unbound log = there was an entry for the shopping site but no entries for any of the = other category url's I had just accessed and that were allowed. >>> So problem is fixed for when the IPFire web proxy is not used by the = browser but there is still an issue when working via the proxy. >>> I will check some more shopping site url's to see if the shopping = site issue is consistent for multiple url's or only that one. I thought = it might be that the url no longer exists but it is in the unbound logs = getting blocked by the DNSFW. So the question would be why that url gets = blocked by the DNSFW via the web proxy when the other Category url's are = not shown in the unbound log at all. >>=20 >> Further follow-up. After the test above with the web proxy being used = where the web sites were allowed to be accessed, I left the browser open = with the opened tabs. >>=20 >> Although the sites were not blocked by DNSFW via the web proxy, = except for the shopping url, DNSFW did then stop some Mozilla telemetry = accesses via the ads zone. >>=20 >> 11:22:13 unbound: [1741:0] info: rpz: applied = [shopping.rpz.ipfire.org] 1000islandsphotoart.com. rpz-nxdomain = 127.0.0.1@42131 1000islandsphotoart.com. A IN >> 11:38:12 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org] = *.telemetry.mozilla.org. rpz-nxdomain 192.168.200.10@45618 = incoming.telemetry.mozilla.org. A IN >> 11:40:12 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org] = *.telemetry.mozilla.org. rpz-nxdomain 192.168.200.10@47126 = incoming.telemetry.mozilla.org. A IN >> 11:42:20 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org] = *.telemetry.mozilla.org. rpz-nxdomain 192.168.200.10@50709 = incoming.telemetry.mozilla.org. A IN >> 11:46:20 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org] = *.telemetry.mozilla.org. rpz-nxdomain 192.168.200.10@46388 = incoming.telemetry.mozilla.org. A IN >> 11:54:20 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org] = *.telemetry.mozilla.org. rpz-nxdomain 192.168.200.10@53250 = incoming.telemetry.mozilla.org. A IN >> 11:55:25 unbound: [1741:0] info: rpz: applied = [shopping.rpz.ipfire.org] 1000islandsphotoart.com. rpz-nxdomain = 127.0.0.1@42131 1000islandsphotoart.com. A IN >> 11:55:31 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org] = ads.mozilla.org. rpz-nxdomain 192.168.200.10@43432 ads.mozilla.org. A IN >> 11:55:31 unbound: [1741:0] info: rpz: applied [ads.rpz.ipfire.org] = *.telemetry.mozilla.org. rpz-nxdomain 192.168.200.10@48485 = incoming.telemetry.mozilla.org. A IN >>=20 >> The first line was the blocked shopping url after changing the = browser to use the IPFire web proxy. >> The second shopping block was when I cam back and tried the shopping = url again to see if it was still blocked. >> All the other mozilla related blocks must be the Firefox browser = trying to open some things on the web pages that had previously been = opened. >>=20 >> Regards, >>=20 >> Adolf. >>=20 >>=20 >>> Regards, >>> Adolf. >>>>=20 >>>> = https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommitdiff;h=3De3c11ae3436b= 578432df0058eee229f262791254 >>>>=20 >>>> Best, >>>> -Michael >>>>=20 >>>>> On 25 Mar 2026, at 13:43, Adolf Belka = wrote: >>>>>=20 >>>>> Hi Michael & Jon, >>>>>=20 >>>>> On 25/03/2026 12:58, Adolf Belka wrote: >>>>>> Hi Michael and Jon, >>>>>> On 25/03/2026 10:30, Michael Tremer wrote: >>>>>>> Hello Jon, >>>>>>>=20 >>>>>>> Why would it be necessary to manually change the configuration? >>>>>>>=20 >>>>>>> Can you explain to us what you are thinking? >>>>>> I think the argument is that the define-tag and = access-control-tag options should not be multiple entries but single = entries with multiple tags space separated in the "" section. >>>>>=20 >>>>> At least the access-control-tag option has to be able to be used = multiple times. If you have three categories defined, one with green = selected another with blue and the last with orange then there has to be = at least three access-control-tags because each of the subnets has a = different category assigned to it. >>>>>=20 >>>>> I also found a similar situation outlined in the unbound = documentation where they have four access-control-tags defined. >>>>>=20 >>>>> = https://unbound.docs.nlnetlabs.nl/en/latest/topics/filtering/tags-views.ht= ml#tags >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Adolf. >>>>>=20 >>>>>>>=20 >>>>>>>> On 24 Mar 2026, at 21:03, Jon Murphy = wrote: >>>>>>>>=20 >>>>>>>> Try this in the dnsbl.conf file. >>>>>>>>=20 >>>>>>>> server: >>>>>>>> define-tag: "ads.rpz.ipfire.org dating.rpz.ipfire.org" >>>>>>>>=20 >>>>>>>> server: >>>>>>>> access-control-tag: 192.168.74.0/24 "ads.rpz.ipfire.org = dating.rpz.ipfire.org" >>>>>> Tried this but it made no difference. I suspect this might be = that unbound needs to reload the config file if it has been changed and = running unbound reload results in the dnsbl.conf file being updated with = what is on the WUI page, so it goes back to the version before it was = manually edited. >>>>>> However this made me wonder what would happen if I only had the = porn entry selected and not both the porn and gambling. >>>>>> The result, with the browser network option set to No Proxy was = that all porn sites were now blocked. >>>>>> I then wondered what would happen if I chose two different = categories where the working gambling one was after another category. So = I tested out Dating and Gambling. >>>>>> First tested out Dating on its own. >>>>>> It blocked for academysingles.com and loopylove.com >>>>>> Then I enabled both Dating and Gambling. In this case the two = dating urls were still blocked but now all the urls that I had = previously used, when testing out Gambling and Porn categories together, = were no longer blocked. >>>>>> If I disabled the Dating category then the Gambling sites were = blocked again. >>>>>> This was also found in the DNS: Unbound logs. >>>>>> So it looks like if there are multiple categories selected then = only the urls from the first category get blocked. >>>>>> Regards, >>>>>> Adolf. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Separate "access-control-tag" don=E2=80=99t seem to work. >>>>>>>=20 >>>>>>> What is this supposed to mean? >>>>>>>=20 >>>>>>> -Michael >>>>>>>=20 >>>>>>>>=20 >>>>>>>> The above changes allows RPZ to work as expected. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> ------ Original Message ------ >>>>>>>> =46rom "Michael Tremer" >>>>>>>> To "Adolf Belka" >>>>>>>> Cc development@lists.ipfire.org; dbl@lists.ipfire.org >>>>>>>> Date 3/23/2026 9:41:07=E2=80=AFAM >>>>>>>> Subject Re: Feedback on issues with DNSFW in CU201 Testing >>>>>>>>=20 >>>>>>>>> Hello, >>>>>>>>>=20 >>>>>>>>> So this looks good. The list has been properly loaded into = Unbound. >>>>>>>>>=20 >>>>>>>>> I don=E2=80=99t quite know what could be going wrong now. >>>>>>>>>=20 >>>>>>>>> -Michael >>>>>>>>>=20 >>>>>>>>>> On 23 Mar 2026, at 12:22, Adolf Belka = wrote: >>>>>>>>>>=20 >>>>>>>>>> Hi Michael, >>>>>>>>>>=20 >>>>>>>>>> On 23/03/2026 12:10, Michael Tremer wrote: >>>>>>>>>>> Hello Adolf, >>>>>>>>>>> What is the output of unbound-control list_auth_zones? >>>>>>>>>>=20 >>>>>>>>>> porn.rpz.ipfire.org. serial 1773964805 since = 1774267487 2026-03-23T13:04:47 >>>>>>>>>> gambling.rpz.ipfire.org serial 1773997205 since = 1774267487 2026-03-23T13:04:47 >>>>>>>>>>=20 >>>>>>>>>> Regards, >>>>>>>>>>=20 >>>>>>>>>> Adolf. >>>>>>>>>>=20 >>>>>>>>>>> -Michael >>>>>>>>>>>> On 20 Mar 2026, at 16:59, Adolf Belka = wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> Hi Michael, >>>>>>>>>>>>=20 >>>>>>>>>>>> On 20/03/2026 16:56, Michael Tremer wrote: >>>>>>>>>>>>> Hello Adolf, >>>>>>>>>>>>> I am copying the DBL list, too. >>>>>>>>>>>>=20 >>>>>>>>>>>> Good idea. I was just thinking of it being related to = Testing issue. >>>>>>>>>>>>> So this is obviously not normal, but we can debug this = step by step: >>>>>>>>>>>>> First of all, we should check if Unbound was able to = successfully fetch the DNS zones. Gambling has clearly been downloaded, = but it seems that the Porn list might not. You can check in = /var/cache/unbound if there is the zone file. If yes, then you can try = to resolve a couple of things on the console and check if they are being = blocked: >>>>>>>>>>>>=20 >>>>>>>>>>>> I should have already mentioned this but forgot. It was one = of the first things I checked and I have just re-confirmed now. The porn = zone file is present. It was updated at 11:40 CET and the Gambling zone = was updated at 12:53 CET. >>>>>>>>>>>>=20 >>>>>>>>>>>> I also checked that the zone file contained the url's being = used and it did and does. >>>>>>>>>>>>=20 >>>>>>>>>>>>> # dig @localhost some.porn.website.com = >>>>>>>>>>>>> You should see NXDOMAIN if the domain exists and has been = blocked and you should see the log entries just like gambling. >>>>>>>>>>>>=20 >>>>>>>>>>>> Got >>>>>>>>>>>>=20 >>>>>>>>>>>> ;; Got answer: >>>>>>>>>>>> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 54293 >>>>>>>>>>>> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, = ADDITIONAL: 1 >>>>>>>>>>>>=20 >>>>>>>>>>>> So NXDOMAIN is in the answer but there was nothing = additional in the unbound log. The last entry in it was from 12:58:50 = when I did the tests with the gambling sites and if there was an entry = it should have a timestamp for around 17:45 >>>>>>>>>>>>=20 >>>>>>>>>>>>> This rules out anything that is going wrong between the = browser and Unbound. >>>>>>>>>>>>> In case of the URL filter, it simply seems that squidguard = is not seeing the requests. You might as well try something like: >>>>>>>>>>>>=20 >>>>>>>>>>>> With the URL Filter enabled and DNSFW disabled then the URL = Filter blocks and logs both the Gambling and Porn site accesses. Sorry = if that came across as differently in my mail. The URL Filter works fine = for me with both CU200 and CU201 Testing. >>>>>>>>>>>>=20 >>>>>>>>>>>>> # http_proxy=3Dhttp://1.2.3.4:800 = https_proxy=3Dhttp://1.2.3.4:800 wget -d = http://some.porn.website.com >>>>>>>>>>>>> The squidguard.log should also contain some interesting = information if something didn=E2=80=99t go as planned. >>>>>>>>>>>>> -Michael >>>>>>>>>>>>>> On 20 Mar 2026, at 12:30, Adolf Belka = wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I am having issues with getting DNSFW to work properly, = it fails in many conditions to block things from the list. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The dbl list works fine for me in the URL Filter for both = CU200 and CU201 Testing. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> For my testing I created a new install of CU201 Testing = and just went straight to DNSFW and enabled the Gambling and Pornography = categories and Saved. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Then selected the Green network for both categories using = the pencil edit option. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> In this setup I had no Web Proxy enabled. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I then cleared the browser cache and set the Browser to = No Proxy. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I then tested out nl.onecasino.com and www.xnxx.com in = Firefox and in Netsurf >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The gambling site was blocked and gave the message >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Unable to connect >>>>>>>>>>>>>> Firefox can=E2=80=99t establish a connection to the = server at nl.onecasino.com. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> For the porn site it was not blocked but opened up. >>>>>>>>>>>>>> I tried with two other gambling and porn sites. All three = gambling sites were blocked. All three porn sites were allowed through. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> In the DND: Unbound System Logs I found >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> 12:52:26 unbound: [1820:0] info: rpz: applied = [gambling.rpz.ipfire.org] *.postcodeloterij.nl. rpz-nxdomain = 192.168.200.11@44247 www.postcodeloterij.nl. A IN >>>>>>>>>>>>>> 12:52:26 unbound: [1820:0] info: rpz: applied = [gambling.rpz.ipfire.org] *.postcodeloterij.nl. rpz-nxdomain = 192.168.200.11@44356 www.postcodeloterij.nl. HTTPS IN >>>>>>>>>>>>>> 12:51:32 unbound: [1820:0] info: rpz: applied = [gambling.rpz.ipfire.org] *.onecasino.com. rpz-nxdomain = 192.168.200.11@55955 nl.onecasino.com. A IN >>>>>>>>>>>>>> 12:51:32 unbound: [1820:0] info: rpz: applied = [gambling.rpz.ipfire.org] *.onecasino.com. rpz-nxdomain = 192.168.200.11@49136 nl.onecasino.com. HTTPS IN >>>>>>>>>>>>>> 12:50:41 unbound: [1820:0] info: rpz: applied = [gambling.rpz.ipfire.org] *.hollandcasino.nl. rpz-nxdomain = 192.168.200.11@47229 welkom.hollandcasino.nl. A IN >>>>>>>>>>>>>> 12:50:41 unbound: [1820:0] info: rpz: applied = [gambling.rpz.ipfire.org] *.hollandcasino.nl. rpz-nxdomain = 192.168.200.11@43346 welkom.hollandcasino.nl. HTTPS IN >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> So the blocked gambling sites were in the logs but not = any of the pornography sites had tested. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Then tried the browser with the Network Settings set to = Use system proxy settings and the same result occurred. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I then turned on the Web Proxy with conventional = connection on port 800. Saved and restarted and then Cleared the web = proxy cache. >>>>>>>>>>>>>> Then I cleared the browser cache and set the Network = Settings to Manual proxy configuration with the IP of my IPFire system = being tested. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I then tested the same three gambling URL's and Porn = URL's. >>>>>>>>>>>>>> All of the sites were opened up. >>>>>>>>>>>>>> In the DNS: Unbound system log there were no new entries. >>>>>>>>>>>>>> In the Proxy Logs there were entries for the gambling and = porn sites. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I have also tested the browser out using the web proxy = with the Automatic proxy configuration URL accessing the wpad file via = dhcp and that also had the same results as using the Manual proxy = configuration option. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I have repeated a lot of my tests multiple times, also = with repeated new installs and for me, as long as I ensured I had = cleared the web proxy and browser caches, always came up with the same = results as I have described above. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> It would be good to know if any of you also experience = the same effect or if it works without problems for yourselves. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Adolf. >=20 >=20 > Jon >=20 >=20 > --=20 > Jon Murphy > murphy.jon@me.com > 847-774-3550 (cell) > --=20 >=20 >=20 >=20 >=20 >=20