-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2023-04-25 at 23:22 +0200, Bengt Gördén wrote:

On 2023-04-25 22:58, Carlos E. R. wrote:

...

rule family="ipv6" source address="fc00::/64" port port="5353" protocol="udp" accept rule family="ipv6" source address="fe80::/64" port port="5353" protocol="udp" accept

I have this comment on my "/etc/sysconfig/SuSEfirewall2" file, from which they werre translated to the above two lines: # fe80::/64,udp,5353 - autoconf broadcast from printer #fc00 # Posible entrada desde internet al ssh FW_SERVICES_ACCEPT_EXT="192.168.1.14/24,_rpc_,nfs 192.168.1.15/24,_rpc_,nfs 192.168.1.129/24,_rpc_,nfs \ fe80::/64,udp,5353 fc00::/64,udp,5353 \ 192.168.1.0/24,tcp,80 192.168.1.0/24,tcp,22 \ 0/0,tcp,22,,hitcount=3,blockseconds=100,recentname=ssh" Ie, I wrote that probably to silence noise in the log from a printer broadcast, or to have some autoconf feature from the printer working.

Whats the output of ip6tables-save

Isengard:/etc/firewalld/zones # ip6tables-save # Generated by ip6tables-save v1.8.7 on Wed Apr 26 02:17:33 2023 *raw :PREROUTING ACCEPT [14175:19377794] :OUTPUT ACCEPT [9470:17375360] COMMIT # Completed on Wed Apr 26 02:17:33 2023 # Generated by ip6tables-save v1.8.7 on Wed Apr 26 02:17:33 2023 *security :INPUT ACCEPT [12058:19236084] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [9470:17375360] COMMIT # Completed on Wed Apr 26 02:17:33 2023 # Generated by ip6tables-save v1.8.7 on Wed Apr 26 02:17:33 2023 *nat :PREROUTING ACCEPT [2050:136843] :INPUT ACCEPT [18:1343] :OUTPUT ACCEPT [37:4315] :POSTROUTING ACCEPT [37:4315] COMMIT # Completed on Wed Apr 26 02:17:33 2023 # Generated by ip6tables-save v1.8.7 on Wed Apr 26 02:17:33 2023 *mangle :PREROUTING ACCEPT [14175:19377794] :INPUT ACCEPT [14089:19371371] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [9470:17375360] :POSTROUTING ACCEPT [9475:17375810] COMMIT # Completed on Wed Apr 26 02:17:33 2023 # Generated by ip6tables-save v1.8.7 on Wed Apr 26 02:17:33 2023 *filter :INPUT ACCEPT [14033:19362332] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [9470:17375360] - -A INPUT -p udp -m udp --dport 546 -j ACCEPT - -A INPUT -p udp -m udp --dport 5353 -m pkttype --pkt-type multicast -j ACCEPT COMMIT # Completed on Wed Apr 26 02:17:33 2023 Isengard:/etc/firewalld/zones # - -- Cheers, Carlos E. R. (from openSUSE 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZEhwKhwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfViOoAn3xz/8HFm65pDigqM8uu VsDrKLDIAJ0fTXHqWYtddI+Gkgl17nz4yrBoTw== =r3T6 -----END PGP SIGNATURE-----

On Wed, Apr 26, 2023 at 10:59 AM Bengt Gördén wrote:

Now I don't know firewalld but from ip6tables-save I don't see that you reject or drop anything.

Google for "nftables"

Andrei Borzenkov wrote:

...

...

(Can I write comments in xml file /etc/firewalld/zones/external.xml?)

Yes, use "<!-- comment -->". Can span multiple lines.

These files are modified by GUI and CLI so I am not sure these comments will be preserved.

That is a good point. The XML file is presumbly not intended as a user interface, so why keep comments. Unless the GUI/CLI permits adding comments, somehow. -- Per Jessen, Zürich (14.2°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes

Carlos E. R. wrote:

On 2023-04-26 12:44, Per Jessen wrote:

...

Andrei Borzenkov wrote:

...

...

...

(Can I write comments in xml file /etc/firewalld/zones/external.xml?)

Yes, use "<!-- comment -->". Can span multiple lines.

These files are modified by GUI and CLI so I am not sure these comments will be preserved.

That is a good point. The XML file is presumbly not intended as a user interface, so why keep comments. Unless the GUI/CLI permits adding comments, somehow.

I see easier to edit the file by hand to purge the excess of rules, but I need comments to know what is the purpose of this or that.

Yeah I would too, but the whole idea of tools such as firewalld is to make manual editing superfluous. Wrap everything in a nice GUI abstracting from the tedious technical detail.

SuSEfirewall2 accepted comments.

So does my bash script :-) If you google it, e.g. "adding comments in firewalld", there are interesting hits. https://serverfault.com/questions/893112/migrating-from-iptables-to-firewall... How can we comment each firewalld rules for description? https://access.redhat.com/solutions/6822451 https://www.golinuxcloud.com/firewalld-cheat-sheet/#1_Add_comment_to_firewal... -- Per Jessen, Zürich (13.9°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes

Andrei Borzenkov wrote:

On Wed, Apr 26, 2023 at 2:31 PM Per Jessen wrote:

...

How can we comment each firewalld rules for description? https://access.redhat.com/solutions/6822451

Can you access it?

No ..... I realised too late, sorry. -- Per Jessen, Zürich (14.4°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes

On Wed, Apr 26, 2023 at 2:43 PM Per Jessen wrote:

The mention of adding '-m comment --comment "" ' to rules suggests there is an XML element for such comments

This works only in direct rules where "XML element" is simply full iptables invocation.

Carlos E. R. wrote:

On 2023-04-26 13:42, Per Jessen wrote:

...

Per Jessen wrote:

...

Andrei Borzenkov wrote:

...

On Wed, Apr 26, 2023 at 2:31 PM Per Jessen <> wrote:

...

The mention of adding '-m comment --comment "" ' to rules suggests there is an XML element for such comments - might be worth looking into, to maybe add comments manually.

/etc/firewalld/direct.xml:

...

<?xml version="1.0" encoding="utf-8"?> <direct> <rule ipv="ipv4" table="filter" chain="INPUT" priority="0">-p tcp -m tcp -s 10.10.10.60 --dport=80 -j ACCEPT -m comment --comment

Yeah, Andrei already said so. -- Per Jessen, Zürich (15.9°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes

On 2023-04-26 08:45, Per Jessen wrote:

Carlos E. R. wrote:

...

(This is a thinking aloud post, so of course there is conflict in what I say)

I didn't see any conflicts, maybe I need to look again :-)

...

Isengard:/etc/firewalld/zones # firewall-cmd --list-all [snip - 80 rich rules] rule family="ipv6" source address="fe80::/64" port port="5353" protocol="udp" accept rule family="ipv6" source address="fc00::/64" port port="5353" protocol="udp" accept

1) isn't that the kind of rule - family="ipv6" - that made your firewalld explode yesterday?

Yes, but a different rule. family="ipv6" source mac="MAC..." reject

2) 5353 is for mdns - you won't see any of that on fe80::. Are you actually using fc00:: ?

You ask details I don't remember :-D My notes in "/etc/sysconfig/SuSEfirewall2" say: # fe80::/64,udp,5353 - autoconf broadcast from printer

3) Personally, I would be unhappy with such a setup, 86 rich rules.

Me too.

I appreciate it is due to the conversion script, but a pile of "rich rules" is not much better than my old well-structured iptables script, with comments. Anyway, just an observation.

Yes, I intend to clear them, but time is limited and I have to decide how. If rich rules accepted multiple IPs or multiple ports, it would be easier. Maybe I have to apply them to the entire LAN range.

...

carlos@Friend:~ $curl http://[Ipv6_ADDR] <html><body> <h1>Welcome to Isengard</a></h1> <h3>Letras: \ | @ # € </h3> [snip]

Now, this is not correct, it is the response expected INSIDE the LAN. That means a problem in the Apache configuration for virtual hosts, but also that port 80 is not closed on IPv6.

You were presumably expecting the last rich rule

rule priority="10" source mac="ROUTER_MAC" reject

to cause that to be blocked.

Yep.

...

Obviously, computers have their own mind, but I'm not familiar with the firewalld "mind".

My computers do _exactly_ what they are told :-)

Mine too, but what they are actually told is not exactly what I meant to tell them :-p Do wwat I mean, not what I say DWIMNWIS Turn left! No, the other left! :-)

...

It seems that:

services: dns http https mountd nfs nfs3 ntp rpc-bind ssh

takes precedence over the rich rule denying packets via router.

Aha, okay. (I didn't know the meaning of that line).

...

(Can I write comments in xml file /etc/firewalld/zones/external.xml?)

Yes, use "<!-- comment -->". Can span multiple lines.

Ah. Thanks. Ah, Andrei notes that perhaps they will not be preserved. Ok, I can only try. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)

On 2023-04-26 12:47, Per Jessen wrote:

Carlos E. R. wrote:

...

On 2023-04-26 08:45, Per Jessen wrote:

...

Carlos E. R. wrote:

...

(Can I write comments in xml file /etc/firewalld/zones/external.xml?)

Yes, use "<!-- comment -->". Can span multiple lines.

Ah. Thanks.

Ah, Andrei notes that perhaps they will not be preserved. Ok, I can only try.

It depends on how that file is being managed - if individual elements are being added/removed, your comments might well be kept - but if the XML format is only used as storage, your comments most probably won't be kept.

Then the file should have a machine written comment at the top: do not edit, automatically generated file. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)

On 2023-04-26 13:18, Per Jessen wrote:

Carlos E. R. wrote:

...

On 2023-04-26 12:47, Per Jessen wrote:

...

Carlos E. R. wrote:

...

On 2023-04-26 08:45, Per Jessen wrote:

...

Carlos E. R. wrote:

...

(Can I write comments in xml file /etc/firewalld/zones/external.xml?)

Yes, use "<!-- comment -->". Can span multiple lines.

Ah. Thanks.

Ah, Andrei notes that perhaps they will not be preserved. Ok, I can only try.

It depends on how that file is being managed - if individual elements are being added/removed, your comments might well be kept - but if the XML format is only used as storage, your comments most probably won't be kept.

Then the file should have a machine written comment at the top: do not edit, automatically generated file.

Frankly, no. XML is easily formatted to be human readable, but it is most often not intended as such. If you are editing XML, unless it is e.g. an XSLT stylesheet or an HTML page, you should assume it was produced by some code. IMHO.

Other software produce precisely that line. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)

On 2023-04-26 15:39, Per Jessen wrote:

Carlos E. R. wrote:

...

On 2023-04-26 13:18, Per Jessen wrote:

...

Carlos E. R. wrote:

...

On 2023-04-26 12:47, Per Jessen wrote:

...

Carlos E. R. wrote:

...

On 2023-04-26 08:45, Per Jessen wrote: > Carlos E. R. wrote: >> (Can I write comments in xml file >> /etc/firewalld/zones/external.xml?) > > Yes, use "<!-- comment -->". Can span multiple lines.

Ah. Thanks.

Ah, Andrei notes that perhaps they will not be preserved. Ok, I can only try.

It depends on how that file is being managed - if individual elements are being added/removed, your comments might well be kept - but if the XML format is only used as storage, your comments most probably won't be kept.

Then the file should have a machine written comment at the top: do not edit, automatically generated file.

Frankly, no. XML is easily formatted to be human readable, but it is most often not intended as such. If you are editing XML, unless it is e.g. an XSLT stylesheet or an HTML page, you should assume it was produced by some code. IMHO.

Other software produce precisely that line.

In XML ?

I don't remember all the file types where I saw this. /usr/share/mobile-broadband-provider-info/apns-conf.xml <?xml version="1.0"?> <!-- Automatically generated from serviceproviders.xml --> /usr/share/flightgear/Aircraft/Instruments-3d/mk-viii/caution0.xml <?xml version="1.0"?> <!--automatically generated, do not edit--> :-) (I found them using 'mc' ;-) ) -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)

On 2023-04-26 18:23, Per Jessen wrote:

Carlos E. R. wrote:

...

On 2023-04-26 15:39, Per Jessen wrote:

...

...

...

Frankly, no. XML is easily formatted to be human readable, but it is most often not intended as such. If you are editing XML, unless it is e.g. an XSLT stylesheet or an HTML page, you should assume it was produced by some code. IMHO.

Other software produce precisely that line.

In XML ?

I don't remember all the file types where I saw this.

Thank goodness we are only discussing XML.

...

/usr/share/mobile-broadband-provider-info/apns-conf.xml

<?xml version="1.0"?> <!-- Automatically generated from serviceproviders.xml -->

/usr/share/flightgear/Aircraft/Instruments-3d/mk-viii/caution0.xml

<?xml version="1.0"?> <!--automatically generated, do not edit-->

Gee, thanks for that - one(!) exception to prove the rule.

Actually, it is many files in flightgear, I just copied one :-p

I took a quick look on my home drive - some 3700 LibreOffice files (text or spreadsheet) - each one is made up of 6 XML files. None of them contain any such comment.

Maybe they should, if they can not be edited ;-) -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)

Carlos E. R. wrote:

Found another.

/home/cer/tmp/initrd/etc/splashy/config.xml

<!-- Automatically generated by splashy_config. Do not edit -->

I think it is inside the initrd archive.

See what Dave Howorth said about that situation :-)

And this reference:

/home/cer/bin/lazarus/lazarus_usrlib/docs/xml/lcl/lresources.xml

Oh no, the evidence is growing :-) -- Per Jessen, Zürich (18.9°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes

On Wed, 26 Apr 2023 18:23:58 +0200 Per Jessen wrote:

I took a quick look on my home drive - some 3700 LibreOffice files (text or spreadsheet) - each one is made up of 6 XML files. None of them contain any such comment.

Eh, an LO document should just be a single file (.ods, .odt etc) surely? Anything else would be a nightmare to copy etc.

On 2023-04-27 08:58, Per Jessen wrote:

Dave Howorth wrote:

...

On Wed, 26 Apr 2023 18:23:58 +0200 Per Jessen wrote:

...

I took a quick look on my home drive - some 3700 LibreOffice files (text or spreadsheet) - each one is made up of 6 XML files. None of them contain any such comment.

Eh, an LO document should just be a single file (.ods, .odt etc) surely? Anything else would be a nightmare to copy etc.

Yes, to the casual observer, an LO document certainly appears to be a single file. An LO document is a zip file, in a style similar to a jar file:

An archive. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)

Dave Howorth wrote:

On Thu, 27 Apr 2023 08:58:44 +0200 Per Jessen wrote:

...

per@office64:~> unzip -l Documents/surbl-stats.ods Archive: Documents/surbl-stats.ods Length Date Time Name -------- ---- ---- ---- 46 07-24-09 06:44 mimetype 423142 07-24-09 06:44 content.xml 6168 07-24-09 06:44 styles.xml 914 07-24-09 06:44 meta.xml 9768 07-24-09 06:44 Thumbnails/thumbnail.png [snip] 9069 07-24-09 06:44 settings.xml 1873 07-24-09 06:44 META-INF/manifest.xml -------- ------- 450980 15 files

Right, but there are no XML files there that could be accidently edited, so no need for any warnings about editing them :) So a poor choice of counterexample?

Yeah I admit it, it was a slightly poor example :-) Still, the key message remains the same - excluding certain common examples, XML files are not for human processing, accidentally or otherwise. When they are made human-readable with newlines and indentation, it is for debugging purposes. Maybe these are better examples ? /var/lib/wicked/ (three XML files) all openSUSE repodata (1270 files on my mirror) -- Per Jessen, Zürich (18.4°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2023-04-27 at 14:15 +0200, Carlos E. R. wrote:

On 2023-04-27 13:12, Per Jessen wrote:

...

Dave Howorth wrote:

...

Yeah I admit it, it was a slightly poor example :-) Still, the key message remains the same - excluding certain common examples, XML files are not for human processing, accidentally or otherwise. When they are made human-readable with newlines and indentation, it is for debugging purposes.

I'm right now editing the Isengard:/etc/firewalld/zones/external.xml, to reduce the number of rules, and it is right tedious. With commands it would be unthinkable.

Looking at the official documentation:

https://firewalld.org/documentation/zone/examples.html

it is all XML, not commands, so they do intend people to edit them directly.

By the way, looking at that site, I do not see a documentation section on "rules" :-?

https://firewalld.org/documentation/zone/options.html https://firewalld.org/documentation/man-pages/firewalld.richlanguage I got the modified file working with just one error :-) Isengard:/etc/firewalld # firewall-cmd --reload success But: Isengard:/etc/firewalld/zones # firewall-cmd --list-all external (active) target: default icmp-block-inversion: no interfaces: eth0 wlan0 sources: services: ssh ports: protocols: forward: no masquerade: yes forward-ports: source-ports: icmp-blocks: rich rules: Isengard:/etc/firewalld/zones # it had actually failed. One has to do this: Isengard:/etc/firewalld/zones # firewall-cmd --check-config Error: INVALID_ZONE: 'external.xml': not a valid zone file: not well-formed (invalid token): line 59, column 18 Isengard:/etc/firewalld/zones # mcedit external.xml It did not like this: <rule family="ipv4"> <source address="192.168.0.0/16"/> <service name="ssh"/> <accept limit value="3/m" /> </rule> I had to change it to: <rule family="ipv4"> <source address="192.168.0.0/16"/> <service name="ssh"/> <accept> <limit value="3/m"/> </accept> </rule> Isengard:/etc/firewalld/zones # firewall-cmd --list-all external (active) target: default icmp-block-inversion: no interfaces: eth0 wlan0 sources: services: ports: 12854/tcp 53792/tcp 12858/udp 47981/udp 38059/tcp 56517/udp 40399/tcp protocols: forward: no masquerade: no forward-ports: source-ports: icmp-blocks: address-unreachable bad-header beyond-scope communication-prohibited destination-unreachable echo-reply failed-policy fragmentation-needed host-precedence-violation host-prohibited host-redirect host-unknown host-unreachable ip-header-bad network-prohibited network-redirect network-unknown network-unreachable no-route packet-too-big parameter-problem port-unreachable precedence-cutoff protocol-unreachable reject-route required-option-missing source-route-failed time-exceeded timestamp-reply timestamp-request tos-host-redirect tos-host-unreachable tos-network-redirect tos-network-unreachable ttl-zero-during-reassembly ttl-zero-during-transit unknown-header-type unknown-option rich rules: rule family="ipv4" source address="192.168.0.0/16" service name="https" accept rule family="ipv4" source address="192.168.1.128/32" port port="2908" protocol="udp" accept rule family="ipv4" source address="192.168.1.57/32" accept rule family="ipv4" source address="192.168.1.54/32" accept rule family="ipv4" source address="192.168.1.5/32" protocol value="icmp" accept rule family="ipv4" source address="192.168.0.0/16" service name="http" accept rule family="ipv4" source address="192.168.0.0/16" service name="nfs" accept rule family="ipv4" source address="192.168.0.0/16" service name="dns" accept rule family="ipv4" source address="192.168.1.129/32" port port="9090" protocol="tcp" accept rule family="ipv4" source address="192.168.0.0/16" port port="8080" protocol="tcp" accept rule family="ipv4" source address="172.26.0.0/16" protocol value="udp" accept rule family="ipv4" source address="192.168.1.128/32" port port="1252" protocol="tcp" accept rule family="ipv4" source address="192.168.0.0/16" port port="5556" protocol="tcp" accept rule family="ipv4" source address="192.168.1.129/32" port port="4000" protocol="tcp" accept rule family="ipv4" source address="192.168.0.0/16" port port="137-139" protocol="udp" accept rule family="ipv4" source address="192.168.1.14/32" port port="8000" protocol="tcp" accept rule family="ipv4" source address="192.168.0.0/16" port port="514" protocol="udp" accept rule family="ipv4" source address="192.168.0.0/16" port port="22" protocol="tcp" accept rule family="ipv4" source address="192.168.1.7/32" protocol value="udp" accept rule family="ipv4" source address="192.168.1.14/32" protocol value="icmp" accept rule family="ipv4" source address="192.168.0.0/16" port port="873" protocol="tcp" accept rule family="ipv4" source address="192.168.1.55/32" accept rule family="ipv4" source address="192.168.1.128/32" port port="4754" protocol="udp" accept rule family="ipv4" source address="192.168.0.0/16" port port="4080" protocol="tcp" accept rule family="ipv4" source address="192.168.0.0/16" service name="ssh" accept limit value="3/m" rule family="ipv4" source address="192.168.1.129/32" port port="5000" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" port port="4001" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" port port="25" protocol="tcp" accept rule family="ipv4" source address="192.168.1.1/32" port port="53792" protocol="tcp" accept rule family="ipv4" source address="192.168.0.0/16" service name="mountd" accept rule family="ipv4" source address="192.168.0.0/16" port port="53" protocol="udp" accept rule family="ipv4" source address="192.168.0.0/16" port port="80" protocol="tcp" accept rule family="ipv4" source address="192.168.0.0/16" port port="5353" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" port port="4000" protocol="tcp" accept rule family="ipv4" source address="192.168.0.0/16" port port="137-139" protocol="tcp" accept rule family="ipv4" source address="192.168.1.1/32" protocol value="udp" accept rule family="ipv4" source address="192.168.1.129/32" port port="4001" protocol="tcp" accept rule family="ipv4" source address="192.168.0.0/16" port port="2049" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" port port="6666" protocol="udp" accept rule family="ipv4" source address="192.168.0.0/16" port port="5558" protocol="tcp" accept rule family="ipv4" source address="192.168.1.128/32" port port="4120" protocol="udp" accept rule family="ipv6" source address="fe80::/64" port port="5353" protocol="udp" accept rule family="ipv4" source address="192.168.0.0/16" port port="111" protocol="udp" accept rule family="ipv4" source address="192.168.0.0/16" port port="4243" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" port port="4242" protocol="tcp" accept rule family="ipv4" source address="192.168.0.0/16" port port="445" protocol="tcp" accept rule family="ipv4" source address="192.168.0.0/16" port port="162" protocol="udp" accept rule family="ipv4" source address="192.168.0.0/16" port port="4243" protocol="udp" accept rule family="ipv4" source address="192.168.0.0/16" service name="nfs3" accept rule family="ipv4" source address="192.168.0.0/16" service name="rpc-bind" accept rule family="ipv4" source address="192.168.1.7/32" port port="3553" protocol="udp" accept rule family="ipv4" source address="192.168.1.1/32" protocol value="icmp" accept rule family="ipv4" source address="192.168.1.7/32" port port="515" protocol="tcp" accept rule family="ipv4" source address="192.168.0.0/16" port port="53" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" port port="8081" protocol="tcp" accept rule family="ipv4" source address="192.168.1.14/32" port port="9090" protocol="tcp" accept rule family="ipv4" source address="192.168.1.56/32" accept rule family="ipv4" source address="192.168.0.0/16" port port="111" protocol="tcp" accept rule family="ipv6" source address="fc00::/64" port port="5353" protocol="udp" accept rule family="ipv4" source address="192.168.1.129/32" port port="8081" protocol="tcp" accept rule family="ipv4" source address="192.168.1.128/32" port port="1625" protocol="tcp" accept rule priority="10" source mac="CC:..." reject Isengard:/etc/firewalld/zones # I have not dared to write comments, though. I want to change as many port numbers to services when I can. It is tyring. I had to change the initial block: <service name="ssh"/> <service name="dns"/> <service name="http"/> <service name="https"/> <service name="mountd"/> <service name="nfs"/> <service name="nfs3"/> <service name="rpc-bind"/> <service name="ntp"/> to rules instead, in order to accept them only for IPv4. <?xml version="1.0" encoding="utf-8"?> <zone> <short>External</short> <description>For use on external networks. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description> <port port="12854" protocol="tcp"/> <port port="53792" protocol="tcp"/> <port port="12858" protocol="udp"/> <port port="47981" protocol="udp"/> <port port="38059" protocol="tcp"/> <port port="56517" protocol="udp"/> <port port="40399" protocol="tcp"/> I don't understand what the next block is. Do I really need it? <icmp-block name="address-unreachable"/> <icmp-block name="bad-header"/> <icmp-block name="beyond-scope"/> <icmp-block name="communication-prohibited"/> <icmp-block name="destination-unreachable"/> <icmp-block name="echo-reply"/> <icmp-block name="failed-policy"/> <icmp-block name="fragmentation-needed"/> <icmp-block name="host-precedence-violation"/> <icmp-block name="host-prohibited"/> <icmp-block name="host-redirect"/> <icmp-block name="host-unknown"/> <icmp-block name="host-unreachable"/> <icmp-block name="ip-header-bad"/> <icmp-block name="network-prohibited"/> <icmp-block name="network-redirect"/> <icmp-block name="network-unknown"/> <icmp-block name="network-unreachable"/> <icmp-block name="no-route"/> <icmp-block name="packet-too-big"/> <icmp-block name="parameter-problem"/> <icmp-block name="port-unreachable"/> <icmp-block name="precedence-cutoff"/> <icmp-block name="protocol-unreachable"/> <icmp-block name="reject-route"/> <icmp-block name="required-option-missing"/> <icmp-block name="source-route-failed"/> <icmp-block name="time-exceeded"/> <icmp-block name="timestamp-reply"/> <icmp-block name="timestamp-request"/> <icmp-block name="tos-host-redirect"/> <icmp-block name="tos-host-unreachable"/> <icmp-block name="tos-network-redirect"/> <icmp-block name="tos-network-unreachable"/> <icmp-block name="ttl-zero-during-reassembly"/> <icmp-block name="ttl-zero-during-transit"/> <icmp-block name="unknown-header-type"/> <icmp-block name="unknown-option"/> <rule priority="10"> <source mac="CC:..."/> <reject/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <service name="ssh"/> <accept> <limit value="3/m"/> </accept> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <service name="dns"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <service name="http"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <service name="https"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <service name="mountd"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <service name="nfs"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <service name="nfs3"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <service name="rpc-bind"/> <accept/> </rule> <rule family="ipv4"> <source address="172.26.0.0/16"/> <protocol value="udp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="22" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="53" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="53" protocol="udp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="80" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="111" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="111" protocol="udp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="137-139" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="137-139" protocol="udp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="162" protocol="udp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="445" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="514" protocol="udp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="873" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="2049" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="4080" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="4243" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="4243" protocol="udp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="5353" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="5556" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="5558" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="8080" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.128/32"/> <port port="2908" protocol="udp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.5/32"/> <protocol value="icmp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.7/32"/> <protocol value="udp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.54/32"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.55/32"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.57/32"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.1/32"/> <protocol value="udp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.1/32"/> <protocol value="icmp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.1/32"/> <port port="53792" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.7/32"/> <port port="515" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.7/32"/> <port port="3553" protocol="udp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.14/32"/> <protocol value="icmp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.14/32"/> <port port="25" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.14/32"/> <port port="4000" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.14/32"/> <port port="4001" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.14/32"/> <port port="4242" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.14/32"/> <port port="6666" protocol="udp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.14/32"/> <port port="8000" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.14/32"/> <port port="8081" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.14/32"/> <port port="9090" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.128/32"/> <port port="4120" protocol="udp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.128/32"/> <port port="1252" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.128/32"/> <port port="1625" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.129/32"/> <port port="4000" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.129/32"/> <port port="5000" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.129/32"/> <port port="9090" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.129/32"/> <port port="8081" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.128/32"/> <port port="4754" protocol="udp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.129/32"/> <port port="4001" protocol="tcp"/> <accept/> </rule> <rule family="ipv4"> <source address="192.168.1.56/32"/> <accept/> </rule> <rule family="ipv6"> <source address="fe80::/64"/> <port port="5353" protocol="udp"/> <accept/> </rule> <rule family="ipv6"> <source address="fc00::/64"/> <port port="5353" protocol="udp"/> <accept/> </rule> <interface name="eth0"/> <interface name="wlan0"/> </zone> And now I have a headache. - -- Cheers, Carlos E. R. (from openSUSE 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZEr6Ghwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVeNsAnisz2fc+U2vKXziUbqQs mnA1l2AFAJ4zbtZGvL7JGVytI1MFJ5CBP/vUeg== =14sB -----END PGP SIGNATURE-----

On 2023-04-28 09:04, Per Jessen wrote:

Carlos E. R. wrote:

...

It did not like this:

<rule family="ipv4"> <source address="192.168.0.0/16"/> <service name="ssh"/> <accept limit value="3/m" /> </rule>

Obviously - an experienced XML editor will spot that immediately :-)

Well, the manual wasn't clear for a non experienced editor. Still, that was the single error, and I reduced the file from 12812 to 9609 bytes :-)

...

rich rules: rule family="ipv4" source address="192.168.0.0/16" service name="https" accept rule family="ipv4" source address="192.168.1.128/32" port port="2908" protocol="udp" accept rule family="ipv4" source address="192.168.1.57/32" accept rule family="ipv4" source address="192.168.1.54/32" accept [snip 50 rules]

I have to admit, for a local network it certainly seems overly complex. You should be happy you only have a few machines ....

A local network with a non working external firewall protecting it. I initially did it, long ago, for learning and because I did not trust the Telefónica firewall. I was right, old routers did not enable the firewall by default, they relied on NAT. Before them, modems did not have a firewall, but there was no LAN either.

...

I have not dared to write comments, though.

As long as they were syntactically correct, they would have been fine, even if short-lived.

I may write them; I can use the software to create some new rule, see what change they wrote to the file, then enact the old file with edited new rules instead. Some of the comments may come from the old SuSEfirewall2 file.

...

I want to change as many port numbers to services when I can. It is tyring.

I had to change the initial block to rules instead, in order to accept them only for IPv4:

<service name="ssh"/> <service name="dns"/> <service name="http"/> <service name="https"/> <service name="mountd"/> <service name="nfs"/> <service name="nfs3"/> <service name="rpc-bind"/> <service name="ntp"/>

This is based on

a) the ipv6 firewall in your router not working, hence b) you need to block things on the local machines ?

Right.

Why do you want to block ssh, dns, http/s and ntp? As for nfs, that also seems somewhat unnecessary when your nfs server presumably only exports to known ipv4 hosts.

I want to block them only on IPv6. For example, http access the wrong apache virtual host, the internal one, from outside. For now, it is easier to block it rather than find out why. For ssh, well, the intranet is on password, not keys. nfs, yes, right, only exports to some hosts. The others, I simply have not checked. Easier to block rather than check. The external nmap revealed opened ports. Later, I can open to IPv6 things that I know I need/want I'm still debating myself whether I want: rule priority="10" source mac="CC:..." reject with or without priority.

...

I don't understand what the next block is. Do I really need it?

<icmp-block name="this-and-that"/>

I presume it was migrated from your SFW2 setup, so I guess you needed it previously.

I never wrote those. They must be default rules.

I have nothing like it - I don't know why you would need to block all of those, individually. If (!) there are some unwanted ICMPs, block those, then allow the rest.

Me neither.

[snip 366 lines that might have been better put on paste.o.o]

Oops. That many? Well, only 26 Kb total. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)

On 2023-04-28 13:13, Andrei Borzenkov wrote:

On Fri, Apr 28, 2023 at 1:12 PM Carlos E. R. wrote:

...

I want to block them only on IPv6.

If you are not going to use IPv6 internally, having source zone for 192.168.1.0/24 (or whatever your internal addresses are) and fallback zone for external traffic would be much more clean.

I expect^H^H^H^H^H^Hhope to have proper IPv6 one day... -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)

On Fri, Apr 28, 2023 at 3:21 PM Freek de Kruijf wrote:

Op vrijdag 28 april 2023 13:18:47 CEST schreef Carlos E. R.:

...

On 2023-04-28 13:13, Andrei Borzenkov wrote:

...

On Fri, Apr 28, 2023 at 1:12 PM Carlos E. R. wrote:

...

I want to block them only on IPv6.

If you are not going to use IPv6 internally, having source zone for 192.168.1.0/24 (or whatever your internal addresses are) and fallback zone for external traffic would be much more clean.

I expect^H^H^H^H^H^Hhope to have proper IPv6 one day...

-- Cheers / Saludos,

Carlos E. R. (from 15.4 x86_64 at Telcontar)

All global IPv6 addresses are 2000::/3 so you might block/drop all these addresses by using "firewall-cmd --zone=block --add-source=2000::/3" or "firewall-cmd --zone=drop --add-source=2000::/3", depending on if you want to reject (with an ICMP message) or drop the incoming IPv6 package from a global IPv6 address. You still can use private IPv6 addresses (link local or unique local addresses).

This will block both external and internal IPv6, so will have more or less the same effect as "not using IPv6 internally". LL and ULA have been beaten to death previously.

On Fri, Apr 28, 2023 at 3:33 PM Carlos E. R. wrote:

Well, currently I have:

rule priority="10" source mac="CC:..." reject

which rejects packets coming through the router, except those that have an explicit "accept".

This rule is completely useless because those packages would have been rejected by default anyway. I know that I mentioned it, in my defense I corrected myself.

On 2023-04-28 17:06, Lew Wolfgang wrote:

On 4/28/23 04:18, Carlos E. R. wrote:

...

...

If you are not going to use IPv6 internally, having source zone for 192.168.1.0/24 (or whatever your internal addresses are) and fallback zone for external traffic would be much more clean.

I expect^H^H^H^H^H^Hhope to have proper IPv6 one day...

What will IPv6 actually do for you?  It's a serious question, what will it give you that you don't already have with IPv4 and NAT?

From my experience at work it's nothing but a PITA that reduces reliability. Well, it allows direct connection from outside to an internal computer, if wanted, without tricks.

This is interesting to gamers, for instance, or for direct VoIP. Or remote working. If a coworker needs files you have, you can just share them from your computer, no intermediate server needed. As it is, there are providers in Spain that do not give you a public IPv4 address, but one in the 10.*.*.* network. This directly blocks those people from accessing home from outside. All this are uses that were originally designed for Internet, but rendered impossible when NAT was implemented, because there were not enough addresses for everybody. This doesn't affect USAians as much as others. Nor Spaniards as much as Indians, for instance. Then came Telefónica with their stupidity of not issuing static addresses by default and against quelled the dreams. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)

Carlos E. R. wrote:

On 2023-04-28 09:04, Per Jessen wrote:

...

Carlos E. R. wrote:

...

It did not like this:

<rule family="ipv4"> <source address="192.168.0.0/16"/> <service name="ssh"/> <accept limit value="3/m" /> </rule>

Obviously - an experienced XML editor will spot that immediately :-)

Well, the manual wasn't clear for a non experienced editor.

Maybe recall a recent thread about the manual editing ... oh never mind :-)

...

I have to admit, for a local network it certainly seems overly complex. You should be happy you only have a few machines ....

A local network with a non working external firewall protecting it.

The latter should not affect the complexity, I would say. Most of your rich rules are unrelated to that. Afaict, you are restricting access internally?

I was right, old routers did not enable the firewall by default, they relied on NAT. Before them, modems did not have a firewall, but there was no LAN either.

We are talking quite a while back, late 1800s?

...

Why do you want to block ssh, dns, http/s and ntp? As for nfs, that also seems somewhat unnecessary when your nfs server presumably only exports to known ipv4 hosts.

I want to block them only on IPv6.

For example, http access the wrong apache virtual host, the internal one, from outside. For now, it is easier to block it rather than find out why. For ssh, well, the intranet is on password, not keys.

Oh I see.

...

...

I don't understand what the next block is. Do I really need it?

<icmp-block name="this-and-that"/>

I presume it was migrated from your SFW2 setup, so I guess you needed it previously.

I never wrote those. They must be default rules.

Maybe check one of your other machines still using SFW2. You ought to see a long list of rules targeting those icmps. -- Per Jessen, Zürich (16.5°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes

Carlos E. R. wrote:

...

...

...

...

I don't understand what the next block is. Do I really need it?

<icmp-block name="this-and-that"/>

I presume it was migrated from your SFW2 setup, so I guess you needed it previously.

I never wrote those. They must be default rules.

Maybe check one of your other machines still using SFW2. You ought to see a long list of rules targeting those icmps.

Oh, I have the file of this machine intact.

Isengard:/etc/firewalld/zones # grep -i address-unreachable /etc/sysconfig/SuSEfirewall2 Isengard:/etc/firewalld/zones #

The reference is not there, it has to be some default.

That is not a safe way to determine it. The issue is - if it is a default, it is in the migration script and that would be weird. Try running "iptables --list -n" and maybe grep for 'icmp' For comparison, from my opensuse mirror: jensen:~ # iptables --list -n| grep icmp ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 8 limit: avg 2/sec burst 5 DROP icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 8 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 -- Per Jessen, Zürich (15.9°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes

Carlos E. R. wrote:

...

The issue is - if it is a default, it is in the migration script and that would be weird.

Try running "iptables --list -n" and maybe grep for 'icmp'

Telcontar:~ # iptables --list -n | grep -i icmp ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED REJECT all -- 0.0.0.0/0 0.0.0.0/0 owner GID match 1011 reject-with icmp-port-unreachable

That is an odd one, I don't think I have ever seen anything like that.

ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 4 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 8 ACCEPT icmp -- 192.168.1.1 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED ACCEPT icmp -- 192.168.1.5 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED ACCEPT icmp -- 192.168.1.6 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED ACCEPT icmp -- 192.168.1.29 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED ACCEPT icmp -- 192.168.1.15 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED ACCEPT icmp -- 192.168.1.16 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED

Those were clearly added by yourself. I am a bit puzzled regarding 'ctstate' for ICMP traffic, but that is likely a personal shortcoming :-)

ACCEPT icmp -- 192.168.1.1 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED ACCEPT icmp -- 192.168.1.5 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED ACCEPT icmp -- 192.168.1.6 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED ACCEPT icmp -- 192.168.1.29 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED ACCEPT icmp -- 192.168.1.15 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED ACCEPT icmp -- 192.168.1.16 0.0.0.0/0 ctstate NEW,RELATED,ESTABLISHED

That is more stuff that you have added. It looks to me as if you accept type 4 (weird, "source quench?" ) type 8 (ping request) I expect you didn't actually add those ICMP rules yourself, but the host addresses must have come from you. -- Per Jessen, Zürich (14.5°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes

Andrei Borzenkov wrote:

On 28.04.2023 20:19, Per Jessen wrote:

...

Those were clearly added by yourself. I am a bit puzzled regarding 'ctstate' for ICMP traffic, but that is likely a personal shortcoming :-)

Host/port unreachable in response to TCP SYN packet is "related".

Right, that one I knew.

Echo request from outside is not but echo reply is.

Ah, okay, I had never thought of that. -- Per Jessen, Zürich (14.7°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes

Carlos E. R. wrote:

On 2023-04-28 19:19, Per Jessen wrote:

...

Carlos E. R. wrote:

...

...

The issue is - if it is a default, it is in the migration script and that would be weird.

Try running "iptables --list -n" and maybe grep for 'icmp'

I see I forgot to mention that I run the query in a computer that is still running SuSEfirewall2.

I did expect that, otherwise it would have been useless :-)

...

...

Telcontar:~ # iptables --list -n | grep -i icmp ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED REJECT all -- 0.0.0.0/0 0.0.0.0/0 owner GID match 1011 reject-with icmp-port-unreachable

That is an odd one, I don't think I have ever seen anything like that.

I think I remember where that one may come from, but I do not remember it was icmp.

No, it's for all protocols, the grep hits on on the reject-with reason.

This was used on acroread. That program run with that GID, and thus had it network connections denied. No talking back home.

Weird sh**t .... :-) [snip]

.5 was oldrouter.valinor .6 is one of the switches, don't know which. .29 I don't remember, it is not in the DNS, but seeing the syslog reference it had to be a router or access point. Not active anymore.

It is beginning to sound like you have a lot of old baggage to get rid of.

...

That is more stuff that you have added. It looks to me as if you accept type 4 (weird, "source quench?" ) type 8 (ping request)

See above. I just wrote a plain normal SuSEfirewall option.

Oh sure, I understand that, but it is nonetheless why you have ended up with something utterly unmaintainable. In my opinion, of course. -- Per Jessen, Zürich (13.2°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes

Carlos E. R. wrote:

Ah, found where I got the trick for acrobat:

] Date: Sun, 17 Apr 2005 18:52:27 +0200 ] From: nordi ] To: suse-security@ ] Subject: Re: [suse-security] How to block Acroread 7 with SuSE FW2? ] ] In order to block that traffic you could make the acroread executable ] SGID 'acro' and then block all traffic coming from group 'acro'. ] Iptables has an option for doing this by using the --gid-owner option. ] Of course that works only with a local firewall.

Interesting. Well, thanks for the explanation, at least you can get rid of that now.

...

Oh sure, I understand that, but it is nonetheless why you have ended up with something utterly unmaintainable. In my opinion, of course.

Look at it this way.

I just wanted to trust machine at 192.168.1.5 for syslog and icmp. I simply told the firewall script in the approved manner to do it. How it did do it, is not my business.

Of course - the question is _why_ you chose to be so restrictive with traffic between your _own_ machines. I too restrict certain (groups of) machines, e.g. unknown wifi devices, but I would never go to the level of restricting individual intrnal machines.

And why icmp? because it was probably spamming the log, and probably some feature of the router or switch or whatever it was did not work unless I allowed that packet to pass.

I think I would have chose a different method to stop something spamming a logfile, but never mind - the issue is that your solution from 1725 has been turned into a jungle of rules in 2023. Time to reassess. I suggest you just accept all icmp, for ipv4 you can even skip the ping-flood protection. After 24 hours, check your logs to see if any have been filled up. -- Per Jessen, Zürich (16.4°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes

Carlos E. R. wrote:

On 2023-04-29 08:54, Per Jessen wrote:

...

Carlos E. R. wrote:

...

Ah, found where I got the trick for acrobat:

] Date: Sun, 17 Apr 2005 18:52:27 +0200 ] From: nordi ] To: suse-security@ ] Subject: Re: [suse-security] How to block Acroread 7 with SuSE FW2? ] ] In order to block that traffic you could make the acroread executable ] SGID 'acro' and then block all traffic coming from group 'acro'. ] Iptables has an option for doing this by using the --gid-owner option. ] Of course that works only with a local firewall.

Interesting. Well, thanks for the explanation, at least you can get rid of that now.

Yep. I had forgotten about it. Still, we can find out how it is translated to firewalld.

Might be good for laugh, I suppose. No doubt a rich rule.

...

Of course - the question is _why_ you chose to be so restrictive with traffic between your _own_ machines. I too restrict certain (groups of) machines, e.g. unknown wifi devices, but I would never go to the level of restricting individual intrnal machines.

Oh, I said that before: because I did not trust Telefónica router.

It sounds much more like you didn't trust your own machines.

They considered NAT to be all that was needed.

Which it almost certainly was. Did you have any traffic penetrate that NAT-wall ? -- Per Jessen, Zürich (18.9°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes

Carlos E. R. wrote:

On 2023-04-29 14:07, Per Jessen wrote:

...

Carlos E. R. wrote:

...

...

Of course - the question is _why_ you chose to be so restrictive with traffic between your _own_ machines. I too restrict certain (groups of) machines, e.g. unknown wifi devices, but I would never go to the level of restricting individual intrnal machines.

Oh, I said that before: because I did not trust Telefónica router.

It sounds much more like you didn't trust your own machines.

I trusted existing machines, but not guest machines. I don't have a separate LAN for them. Even a machine on my Guest Wifi gets given an IP in the same LAN as every other machine. No way to separate them with my existing hardware.

I thought you had a reserved range that you could allocate as fixed addresses. Something about 20 addresses?

The only thing the guest wifi has is a different ssid and password, so you do not have to give the main one. And that guest password can be cycled.

Our wifi password is just "password" and I give it to anyone who wants it.

Do you know that all Telefónica routers use the same user, ie "1234" and is hardcoded? And back then, not 1754 but 2010 or thereabouts, used the same password?

Well, that isn't too unlike Netgear and Tp-Link and D-link etc. By default they also all comes with the same admin userid and password. I was not aware that it was hardcoded in Telefonica equipment, but nothing surprises me about Telefonica any more. I think everyone is just amazed that you keep using them. -- Per Jessen, Zürich (20.1°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes

Carlos E. R. wrote:

On Saturday, 2023-04-29 at 18:21 +0200, Per Jessen wrote:

...

Carlos E. R. wrote:

...

On 2023-04-29 14:07, Per Jessen wrote:

...

Carlos E. R. wrote:

...

...

Of course - the question is _why_ you chose to be so restrictive with traffic between your _own_ machines. I too restrict certain (groups of) machines, e.g. unknown wifi devices, but I would never go to the level of restricting individual intrnal machines.

Oh, I said that before: because I did not trust Telefónica router.

It sounds much more like you didn't trust your own machines.

I trusted existing machines, but not guest machines. I don't have a separate LAN for them. Even a machine on my Guest Wifi gets given an IP in the same LAN as every other machine. No way to separate them with my existing hardware.

I thought you had a reserved range that you could allocate as fixed addresses. Something about 20 addresses?

AFAIR, no, it is just the global DHCP (or whatever method) pool.

So ... I'm curious, how do you guarantee fixed, known addresses for your machines? I tried searching, but google is not up-to-date with our archives. I feel so sure you mentioned something about a reserved range not used for dhcp.

The wifi configuration of my current router page says, that it allows 64 guest clients. Says nothing about an VLAN for them.

Any VLAN would be assigned to the SSID, not the clients.

...

Well, that isn't too unlike Netgear and Tp-Link and D-link etc. By default they also all comes with the same admin userid and password. I was not aware that it was hardcoded in Telefonica equipment, but nothing surprises me about Telefonica any more. I think everyone is just amazed that you keep using them.

Oh, they learn. The fibre routers I have seen all had a custom password written in the label or sticker all routers have. Same as commercial (home grade) we can buy. Still, the user is 1234 and can not be changed.

As to why we use them, I feel in the family, million of us do use them.

Yep. Millions of flies can't be wrong. -- Per Jessen, Zürich (18.9°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes

Carlos E. R. wrote:

On 2023-04-29 20:15, Per Jessen wrote:

...

Carlos E. R. wrote:

So ... I'm curious, how do you guarantee fixed, known addresses for your machines? I tried searching, but google is not up-to-date with our archives. I feel so sure you mentioned something about a reserved range not used for dhcp.

I can use static leases defined in the router (there is a limited number of them, maybe 30),

Ah, maybe that is I'm thinking of.

or I configure a static address in the computer.

It won't help if dhcp has dished out a fixed address to somebody else.

Ah, that's something not feasible with my IPv6 (aside from ULA).

Well, your router seems to leave a lot to be desired.

But I think I was saying that I can not give guest machines IPs in a different LAN or VLAN. Not supported by my current hardware, AFAICS.

It doesn't have to be. You could simply keep your machines in a defined range that is never dished out by dhcp.

...

...

The wifi configuration of my current router page says, that it allows 64 guest clients. Says nothing about an VLAN for them.

Any VLAN would be assigned to the SSID, not the clients.

Ok, but no such a thing, AFAIK.

There is VLAN support, but can not assign an VLAN to the guest wifi config.

It is a pretty unusual thing to find in a consumer network. For one thing, you need managed switches which are also quite rare in a consumer network. -- Per Jessen, Zürich (15.6°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes

Carlos E. R. wrote:

On 2023-04-29 21:07, Per Jessen wrote:

...

...

But I think I was saying that I can not give guest machines IPs in a different LAN or VLAN. Not supported by my current hardware, AFAICS.

It doesn't have to be. You could simply keep your machines in a defined range that is never dished out by dhcp.

I do that. But there is nothing that impedes a guest machine from reading a share in any other machine. It is all a single /16.

Ever heard of firewalls? When you know "all known machines" are in 192.168.34.0/24 and "everything else" is in 192.168.101.0/24, it is easy to permit everything between "all known machines" and isolate them from "everything else". That is what I do with my home "subnet" ranges I posted at some point. They are all in a single /64. Disclaimer: not a ready-to-go solution, just for inspiration. The rest is up to the reader. Maybe require some reading. -- Per Jessen, Zürich (13.6°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes

Carlos E. R. wrote:

On 2023-04-30 08:59, Per Jessen wrote:

...

Carlos E. R. wrote:

...

On 2023-04-29 21:07, Per Jessen wrote:

...

...

But I think I was saying that I can not give guest machines IPs in a different LAN or VLAN. Not supported by my current hardware, AFAICS.

It doesn't have to be. You could simply keep your machines in a defined range that is never dished out by dhcp.

I do that. But there is nothing that impedes a guest machine from reading a share in any other machine. It is all a single /16.

Ever heard of firewalls?

I did say "with my existing hardware" :-) If not in this post, in another.

Maybe you did, but what is the significance? you don't need extra hardware to set up a firewall.

Certainly. But with my existing hardware, I can not put guests in another LAN.

I never suggested you should. It might provide extra separation and better options for performance, but in a household context, those are not particularly relevant. On a known machine : iptables -I INPUT -p all -s 192.168.34.0/24 -j ACCEPT iptables -I INPUT -p all -s 192.168.101.0/24 -j DROP Disclaimer:  not a ready-to-go solution, just for inspiration.  The rest is up to the reader.  Might require some reading. -- Per Jessen, Zürich (15.6°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes

Carlos E. R. wrote:

...

On a known machine : iptables -I INPUT -p all -s 192.168.34.0/24 -j ACCEPT iptables -I INPUT -p all -s 192.168.101.0/24 -j DROP

All that is very nice, but I do need new hardware to assign 192.168.101.0/24 to guests. Currently I have no way to do that.

I thought you said your router supported allocating fixed addresses, up to 30 ?

For most common home routers I have seen, the guest configuration is only about giving guests a different SSID and password than the main one. They get IPs from the same pool as the household.

That is fine - assign fixed addresses to the household machines. Disclaimer:  not a ready-to-go solution, just for inspiration.  The rest is up to the reader.  Might require some reading. -- Per Jessen, Zürich (16.1°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes

Carlos E. R. wrote:

On 2023-04-30 12:34, Per Jessen wrote:

...

Carlos E. R. wrote:

...

...

On a known machine : iptables -I INPUT -p all -s 192.168.34.0/24 -j ACCEPT iptables -I INPUT -p all -s 192.168.101.0/24 -j DROP

All that is very nice, but I do need new hardware to assign 192.168.101.0/24 to guests. Currently I have no way to do that.

I thought you said your router supported allocating fixed addresses, up to 30 ?

Ok, yes, but I'm not going to bother to use those for guests. Too much work.

I didn't suggest that.

...

...

For most common home routers I have seen, the guest configuration is only about giving guests a different SSID and password than the main one. They get IPs from the same pool as the household.

That is fine - assign fixed addresses to the household machines.

Bufff. I did, most of them... then replaced the router and config destroyed. I'm too lazy,

Actually, you are not lazy enough or you have too much time an your hands. You spend days fiddling with a tedious firewall setup, dragging around age old stuff that you have long forgotten the purpose of, trying to figure out if a dhcp client request should be allowed or not. I am lazy or I don't have enough time - I can't be bothered with all that tedium. Split the machines into trusted and untrusted (simplified) and set up rules for trusted and unstrusted. Essentially two rules, all done. -- Per Jessen, Zürich (15.7°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes

On 4/30/23 03:09, Carlos E. R. wrote:

And before you ask, no, I can not put DHCP on a different machine without breaking TV and who knows what.

Do you have a separate modem or something for the TV?  How does all that work?  Do you feed the TV(s) from a coax cable? Where does the phone connect? It's a serious question, we've got only a coax feed from the ISP that handles VOIP, IP, and TV.  I wish we could get a direct fiber connection, but it's not available.  Fiber runs down the street here, but it daisy-chains utility boxes in the street that in turn feed RG-6 coax that leads to the houses.  One box feeds about eight houses.  It's all underground. Inside the house the single coax is split into three with a regular passive splitter which in turn feeds a VOIP modem, my DOCSIS 3.1 cable modem, and a Tivo Romaio DVR.  The Romaio is the master of the Tivo network which in turn feeds four Tivo "Mini" interfaces via TCP-IP over wired Ethernet.  The Minis are next to the TV's and feed them via HDMI cables.  The master has six tuners, so it can handle four Minis and also record two channels for later viewing.  It can record six channels if none of the Minis are active.  Three TV's lack a Mini, they get their content via IP over WiFi.  Tivo is great, it allows us to skip over advertisements! Before you comment on the absurd number of TV's, realize that we have lots of family living here with us.  Not that we want them here, but the declining standard of living that we're experiencing here in California limits their options to live on their own, and I don't want to see them living on the streets.

For most common home routers I have seen, the guest configuration is only about giving guests a different SSID and password than the main one. They get IPs from the same pool as the household.

I've got an Asus RT-AC68U that provides an isolated guest network on both 2.4 and 5 GHz.  I go further and have that router on it's own isolated subnet on my Zyxel router. Of course I've got IPv6 disabled here as well as on my main router.  NAT keeps me as snug as a bug in a rug without complicating my life, it's bad enough as it is. Regards, Lew

On Sun, 30 Apr 2023 19:21:12 +0200 "Carlos E. R." wrote:

The "old" setup:

--fibre---ONT---ROUTER----TV_DECO \ \----computers phones

ONT → https://en.wikipedia.org/wiki/Network_interface_device#Optical_network_termi...

Only that it is not external, but internal, in the wall of the sitting room TV cabinet.

Then, recently they removed the ONT, replaced the router and DECO:

What is a 'DECO'?

Carlos E. R. wrote:

On 2023-05-01 11:36, Dave Howorth wrote:

...

What is a 'DECO'?

TV decoder. I don't know exactly how it is called in English.

In the old days, it was a "set top box". I don't know if people have those anymore - my TV has built-in card readers. -- Per Jessen, Zürich (16.4°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes

On 5/1/23 08:57, Carlos E.R. wrote:

This box works on demand, only one video stream is received at a time. The user selects what to see with the IR remote control, the box sends the appropriate command to the server cloud, then the server cloud sends back the stream direct to the client. Each client a different stream.

Uhm..................Not sure that is correct. Spain being in a parallel universe may work that way but I doubt it. All the signals are present all the time. Each is on it's own frequency [ channel ]. The decoder box just tunes in the appropriate frequency that you want. Over the air, cable, satellite all work this way. -- In times of Tyranny and injustice when law oppresses the people, the outlaw takes his place in history. ~ · Robin Hood · 2010 · Screen Title

On 2023-05-01 17:49, Dave Howorth wrote:

On Mon, 1 May 2023 09:54:29 -0500 Bill Walsh wrote:

...

On 5/1/23 08:57, Carlos E.R. wrote:

...

This box works on demand, only one video stream is received at a time. The user selects what to see with the IR remote control, the box sends the appropriate command to the server cloud, then the server cloud sends back the stream direct to the client. Each client a different stream.

Uhm..................Not sure that is correct. Spain being in a parallel universe may work that way but I doubt it. All the signals are present all the time. Each is on it's own frequency [ channel ]. The decoder box just tunes in the appropriate frequency that you want. Over the air, cable, satellite all work this way.

I think you'll find that digital on-demand systems don't work like that at all. They work as Carlos described. The user initiates a stream at a time of their choosing for the programme of their choosing, and it is sent to them specifically. I suspect the service Carlos is describing is Movistar+

Yes, aka Movistar Fusion. To watch on the computer, this web: https://ver.movistarplus.es/ No credentials needed if used inside the LAN that has a contract. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)

Carlos E.R. wrote:

On 2023-05-01 15:51, Per Jessen wrote:

...

Carlos E. R. wrote:

...

On 2023-05-01 11:36, Dave Howorth wrote:

...

What is a 'DECO'?

TV decoder. I don't know exactly how it is called in English.

In the old days, it was a "set top box". I don't know if people have those anymore - my TV has built-in card readers.

This one is quite different.

With cable TV, all channels are sent simultaneously to every home. The box simply tunes one.

This box works on demand, only one video stream is received at a time. The user selects what to see with the IR remote control, the box sends the appropriate command to the server cloud, then the server cloud sends back the stream direct to the client. Each client a different stream.

Like Bill said, "ummm ...." - doesn't sound right to me either.

If the client wants several TV sets, he has to hire one decoder for each.

Here, there are no "decoders" . It would be bonkers - change "decoder" just because you change provider?? Besides the excellent ervices of my local streaming service "MythTV", my TV offers a menu of 9-10 different - Samsung TV, Rakuten TV, Amazon Prime, Netflux, Sky, 20minutes and more.

Or, you can watch a stream on the computer, gratis, if the computer is in the LAN

I'm curious, how does your VLC client tell the "cloud" what it wants to watch? -- Per Jessen, Zürich (16.8°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes

On 5/1/23 08:42, Per Jessen wrote:

Per Jessen wrote:

...

Here, there are no "decoders" . It would be bonkers - change "decoder" just because you change provider?? Hmm, correction - the big providers (at least one) do offer their own hardware, but the smaller providers rely on consumer hardware - Fritz!Box, Apple TVbox and AndroidTV (built-in) - or indeed your own PC. My provcider recommends Fritz!Box.

Do you have paid subscription channels, Per?  How is that done? You mentioned that your TV's have card readers, are these cards used as decryption tokens for paid channel subscriptions?  Over here they've used things called CableCards that handle the decryption tasks.  We've got one in our master Tivo box that can decrypt six channels simultaneously.  There used to be a federal requirement that all cable TV companies support CableCards, but that requirement was dropped a few years ago.  Now they're supported as a courtesy, and many companies don't support them at all.  They expect you to rent their own proprietary decoders.  If our ISP ever drops CableCard support we'll just drop cable TV altogether and go TV via IP. There are still digital over-the-air channels here but we can't receive most of them due local geography.  Wolfgang Manor doesn't have line-of-sight to the transmitter sites. Regards, Lew

On 5/1/23 10:11, Per Jessen wrote:

...

them at all.  They expect you to rent their own proprietary decoders.  If our ISP ever drops CableCard support we'll just drop cable TV altogether and go TV via IP. Apart from old fuddy-duddies like myself, everyone here (Switzerland) has gone IPTV long ago. Aerial TV distribution ceased in 2018. What remains is DVB-C, DVB-S and IPTV.

I expect that over-the-air TV is on the way out over here too, perhaps Bill knows more?  I remember hearing about plans for re-using the spectrum.  Anything that we currently watch on the telly isn't available OTA anyway. Regards, Lew

On 5/1/23 10:55, Bill Walsh wrote:

On 5/1/23 12:24, Lew Wolfgang wrote:

...

On 5/1/23 10:11, Per Jessen wrote:

...

...

them at all.  They expect you to rent their own proprietary decoders.  If our ISP ever drops CableCard support we'll just drop cable TV altogether and go TV via IP. Apart from old fuddy-duddies like myself, everyone here (Switzerland) has gone IPTV long ago. Aerial TV distribution ceased in 2018. What remains is DVB-C, DVB-S and IPTV.

I expect that over-the-air TV is on the way out over here too, perhaps Bill knows more?  I remember hearing about plans for re-using the spectrum.  Anything that we currently watch on the telly isn't available OTA anyway.

Cable and satellite were behind the push to digital TV. They thought it would kill OTA. No more "fringe" reception so smaller viewer numbers. It backfired big time. Our station has ten channels on the air. Before digital we could only do one. Most any city with local OTA's will find something on the order of 40 or 50 channels available. We share programming with a friend out in western Kansas. He has multiple stations with multiple channels on each. Major network stations put in repeaters around the state to increase broadcast area. You can now find WAY more TV than you could before digital.

Lew, unless your WAY out in the boonies, which I know your not, or down in a deep hole, which I doubt, OR you local TV stations are all stupid and placed their transmitters in the worst possible location(s), I see no reason you should have an issue with OTA. You might need to put up an outdoor antenna. I see twenty channels plus subchannels.

https://www.channelmaster.com/pages/tv-antenna-map-san-diego-ca-92129

One transmitter site is located on Mount Soledad 22-miles north of us, a second is on Otay Mountain, about 11-miles NE of us.  The problem is we're in a bit of a valley.  The neighborhood was originally built with 40-foot TV masts on each house, then in the mid 1980's the area was wired for CATV.  The antennas then started to disappear.  Ours actually fell over of it's own accord around 1989.  So going back to OTA would require a significant mast on our roof.  Also, note that many of those listed stations are located in Tijuana and are only Spanish speaking. Regards, Lew

On 5/1/23 12:51, Carlos E. R. wrote:

...

One transmitter site is located on Mount Soledad 22-miles north of us, a second is on Otay Mountain, about 11-miles NE of us.  The problem is we're in a bit of a valley.  The neighborhood was originally built with

40-foot TV masts on each house, then in the mid 1980's the area was wired for CATV.  The antennas then started to disappear.  Ours actually fell over of it's own accord around 1989.  So going back to OTA would require a significant mast on our roof.  Also, note that many of those listed stations are located in Tijuana and are only Spanish speaking.

Just have the community put a digital transmitter in the centre of the valley. 20 channels at least.

Easier said than done.  Leasing tower space, obtaining right-of-entry, FCC licensing and permits, etc.  Studies would have to be done to identify interference problems, jurisdictional overlaps, threats to endangered species, effects on carbon footprints, and such.  It would be a nightmare. You might recall that a couple of months ago I was looking into Internet access via microwave link?  The company came out and determined that we were dark for their service.  There's a good antenna farm not too far away and the guy said they've tried to install their repeater there, but they just couldn't get things lined up.  Remember, this is California, the home of Big Government and the Regulation State. Regards, Lew

On 5/1/23 15:18, Carlos E. R. wrote:

On 2023-05-01 22:11, Lew Wolfgang wrote:

...

On 5/1/23 12:51, Carlos E. R. wrote:

...

...

One transmitter site is located on Mount Soledad 22-miles north of us, a second is on Otay Mountain, about 11-miles NE of us.  The problem is we're in a bit of a valley.  The neighborhood was originally built with

40-foot TV masts on each house, then in the mid 1980's the area was wired for CATV.  The antennas then started to disappear.  Ours actually

fell over of it's own accord around 1989.  So going back to OTA would require a significant mast on our roof.  Also, note that many of those listed stations are located in Tijuana and are only Spanish speaking.

Just have the community put a digital transmitter in the centre of the valley. 20 channels at least.

Easier said than done.  Leasing tower space, obtaining right-of-entry, FCC licensing and permits, etc.  Studies would have to be done to identify interference problems, jurisdictional overlaps, threats to endangered species, effects on carbon footprints, and such.  It would be a nightmare.

Same as in any modern country. Yet we do it.

...

You might recall that a couple of months ago I was looking into Internet access via microwave link?  The company came out and determined that we were dark for their service.  There's a good antenna farm not too far away and the guy said they've tried to install their repeater there, but they just couldn't get things lined up.  Remember, this is California, the home of Big Government and the Regulation State.

Just come over here and compare. Yet we do it.

Or come to the land of freedom. I have a 65 foot tower on the north end of the house and a 75 foot tower on the south. No regulations. No environmental impacts. Put them up myself just because I wanted them. -- In times of Tyranny and injustice when law oppresses the people, the outlaw takes his place in history. ~ · Robin Hood · 2010 · Screen Title

On 2023-05-02 02:09, Lew Wolfgang wrote:

On 5/1/23 13:18, Carlos E. R. wrote:

...

On 2023-05-01 22:11, Lew Wolfgang wrote:

...

On 5/1/23 12:51, Carlos E. R. wrote:

...

Just have the community put a digital transmitter in the centre of the valley. 20 channels at least.

Easier said than done.  Leasing tower space, obtaining right-of-entry, FCC licensing and permits, etc.  Studies would have to be done to identify interference problems, jurisdictional overlaps, threats to endangered species, effects on carbon footprints, and such.  It would be a nightmare.

Same as in any modern country. Yet we do it.

Your country allows television stations to be created and operated without any governmental oversight?  What if your frequencies interfere with other areas?  Can you, as a amateur radio operator, operate at any frequency and power?

Of course not. I'm saying the reverse: we have more strict requirements and red tape than you do, yet we don't complain and get things done. No rogue TV. Just comply and hard work. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)

On 5/1/23 12:49, Carlos E. R. wrote:

...

I expect that over-the-air TV is on the way out over here too, perhaps Bill knows more?  I remember hearing about plans for re-using the spectrum.  Anything that we currently watch on the telly isn't available OTA anyway.

Not here at all. Over the air TV is just fine and strong. Digital Terrestrial Television, aka TDT

I guess I'm mistaken about OTA TV going away.  Indeed, there's now a spec called ATSC 3.0 that allows 4K and things like Dolby Atmos.  We haven't watched OTA for more than 30-years. Regards, Lew

On 2023-05-01 17:31, Per Jessen wrote:

Carlos E.R. wrote:

...

On 2023-05-01 15:51, Per Jessen wrote:

...

Carlos E. R. wrote:

...

On 2023-05-01 11:36, Dave Howorth wrote:

...

What is a 'DECO'?

TV decoder. I don't know exactly how it is called in English.

In the old days, it was a "set top box". I don't know if people have those anymore - my TV has built-in card readers.

This one is quite different.

With cable TV, all channels are sent simultaneously to every home. The box simply tunes one.

This box works on demand, only one video stream is received at a time. The user selects what to see with the IR remote control, the box sends the appropriate command to the server cloud, then the server cloud sends back the stream direct to the client. Each client a different stream.

Like Bill said, "ummm ...." - doesn't sound right to me either.

...

If the client wants several TV sets, he has to hire one decoder for each.

Here, there are no "decoders" . It would be bonkers - change "decoder" just because you change provider??

Absolutely. And pay the rent, the decoder is rented, not sold.

Besides the excellent ervices of my local streaming service "MythTV", my TV offers a menu of 9-10 different - Samsung TV, Rakuten TV, Amazon Prime, Netflux, Sky, 20minutes and more.

...

Or, you can watch a stream on the computer, gratis, if the computer is in the LAN

I'm curious, how does your VLC client tell the "cloud" what it wants to watch?

No VLC. Chrome or Firefox. VLC was reverse engineered, there was a list of URLS: #EXTINF:-1,[000] Movistar+ HD rtp://@239.0.5.185:8208 #EXTINF:-1,[001] La 1 HD rtp://@239.0.0.185:8208 #EXTINF:-1,[002] La 2 HD rtp://@239.0.0.183:8208 #EXTINF:-1,[003] Antena 3 HD rtp://@239.0.0.186:8208 #EXTINF:-1,[004] Cuatro HD rtp://@239.0.0.177:8208 #EXTINF:-1,[005] Tele 5 HD rtp://@239.0.0.176:8208 #EXTINF:-1,[006] La Sexta HD rtp://@239.0.0.187:8208 ... https://www.web-futbol.com/lista-actualizada-de-canales-para-vlc-2020/ Section "Fibra (FTTH) – Canales HD" I just tried the last one, it works. An updated list, but might not be the same thing, might be IPTV instead: https://www.audiencesusa.com/listas-de-canales-iptv/vlc-player/ -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)

On Mon, 01 May 2023 15:51:23 +0200 Per Jessen wrote:

Carlos E. R. wrote:

...

On 2023-05-01 11:36, Dave Howorth wrote:

...

What is a 'DECO'?

TV decoder. I don't know exactly how it is called in English.

In the old days, it was a "set top box". I don't know if people have those anymore - my TV has built-in card readers.

Thanks, I've heard of set top boxes but think of them as an American thing. Wikipedia has more explanation of the possibilities than anybody could want: https://en.wikipedia.org/wiki/Set-top_box But I understand the general idea now, thanks Per & Carlos. For me TV still comes over the air and requires a tuner, nowadays followed by a demultiplexor, before there's a stream that can be interpreted by a display processor. I believe in a year or two my landline will stop working and I will need to have new equipment that requires the power to be on in order to report a power failure :( Progress!

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2023-04-29 at 10:22 -0700, Lew Wolfgang wrote:

On 4/29/23 05:34, Carlos E. R. wrote: It sounds much more like you didn't trust your own machines.

I trusted existing machines, but not guest machines. I don't have a separate LAN for them. Even a machine on my Guest Wifi gets given an IP in the same LAN as every other machine. No way to separate them with my existing hardware.

Oh, both my switches have VLAN capability. But not my WiFi points. I could, of course, buy a new wifi router and just assign it a new range. But I'm not going to do that expense. - -- Cheers. -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZE1WYhwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVYWIAn1iswQv8eZ6kSboiS8if uyZ8i985AJ4sPGAmPBu1aj5FxI9+Lm+NoC7FFw== =130t -----END PGP SIGNATURE-----

On 2023-04-26 08:45, Per Jessen wrote:

Carlos E. R. wrote:

...

(Can I write comments in xml file /etc/firewalld/zones/external.xml?)

Yes, use "<!-- comment -->". Can span multiple lines.

We went over this, but it is even worse: Telcontar:/etc/firewalld # firewall-cmd --check-config Error: INVALID_ZONE: 'external.xml': not a valid zone file: mismatched tag: line 176, column 4 Telcontar:/etc/firewalld # <rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="20" protocol="tcp"/> <accept/> </rule> <!-- comment --> <rule family="ipv4"> <source address="192.168.1.57/32"/> <port port="53633" protocol="tcp"/> <accept/> </rule> Can't write comments in the file at all, even renouncing to using the commands. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)

On 2023-05-01 15:30, Per Jessen wrote:

Carlos E. R. wrote:

...

On 2023-04-26 08:45, Per Jessen wrote:

...

Carlos E. R. wrote:

...

...

(Can I write comments in xml file /etc/firewalld/zones/external.xml?)

Yes, use "<!-- comment -->". Can span multiple lines.

We went over this, but it is even worse:

Telcontar:/etc/firewalld # firewall-cmd --check-config Error: INVALID_ZONE: 'external.xml': not a valid zone file: mismatched tag: line 176, column 4

At first glance, that seems to be a bug - even if that config file is not intended as a user interface. Adding a comment is perfectly valid XML.

Second glance - with the virtually empty config, I added a comment and "--check-config" reported "success".

You could try feeding the XML to a validator - or use "xmllint" if you have that installed.

https://www.w3schools.com/xml/xml_validator.asp

xmllint your.xml.file

It just prints my file back. Oh, now the comment works. Go figure. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)

On 2023-05-02 08:22, Per Jessen wrote:

Carlos E. R. wrote:

...

On 2023-05-01 15:30, Per Jessen wrote:

...

xmllint your.xml.file

It just prints my file back.

Good. That means it found no problem in that file.

What does it do when there is a problem? -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)

On 2023-05-02 13:07, Per Jessen wrote:

Carlos E. R. wrote:

...

On 2023-05-02 08:22, Per Jessen wrote:

...

Carlos E. R. wrote:

...

On 2023-05-01 15:30, Per Jessen wrote:

...

xmllint your.xml.file

It just prints my file back.

Good. That means it found no problem in that file.

What does it do when there is a problem?

If you had introduced an error and tried it, you would have had an answer in seconds :-)

The answer is - it complains.

I mean, is it obvious to see? Don't I have to go up a kilometre of print to see it up there, out of sight? I would expect to see just a message like "good" or "bad", a single line. With all that print, I can not put it in my CLI:

Telcontar:/etc/firewalld # firewall-cmd --check-config && firewall-offline-cmd --check-config && firewall-cmd --reload && tail -n 100 /var/log/firewalld | grep `date -u +"%Y-%m-%d-%H"` success WARNING: 'NoneType' object has no attribute 'check': None WARNING: 'NoneType' object has no attribute 'check': None success Telcontar:/etc/firewalld #

# xmllint zones/external.xml just prints the file and I can't know where is the line that produces that warning. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)

On 2023-05-02 13:50, Per Jessen wrote:

Carlos E. R. wrote:

...

On 2023-05-02 13:07, Per Jessen wrote:

...

Carlos E. R. wrote:

...

On 2023-05-02 08:22, Per Jessen wrote:

...

Carlos E. R. wrote:

...

On 2023-05-01 15:30, Per Jessen wrote: > > xmllint your.xml.file

It just prints my file back.

Good. That means it found no problem in that file.

What does it do when there is a problem?

If you had introduced an error and tried it, you would have had an answer in seconds :-)

The answer is - it complains.

I mean, is it obvious to see? Don't I have to go up a kilometre of print to see it up there, out of sight?

Again, if you had tried it, you would have had an answer in seconds :-)

Yeah, I produced an error and saw it, after posting.

...

I would expect to see just a message like "good" or "bad", a single line.

Well. Other people might expect a return code indicating failure or success. By default, xmllint prints the parsed tree. Add argument '--noout' if you don't want that.

Ah, thanks.

...

With all that print, I can not put it in my CLI:

...

Telcontar:/etc/firewalld # firewall-cmd --check-config && firewall-offline-cmd --check-config && firewall-cmd --reload && tail -n 100 /var/log/firewalld | grep `date -u +"%Y-%m-%d-%H"` success WARNING: 'NoneType' object has no attribute 'check': None WARNING: 'NoneType' object has no attribute 'check': None success Telcontar:/etc/firewalld #

The above has got nothing to do with xmllint, but it sounds like it checks against an xml schema and finds an unwanted/undefined attribute. Hmm, maybe not - there is no schema specified in that file.

The thing is, as it does not say what line is bad, I can not find it. Telcontar:/etc/firewalld # grep -ri NoneType * Telcontar:/etc/firewalld #

Telcontar:/etc/firewalld # grep -ri check * SuSEfirewall2-to-firewalld.txt:INFO: The dry-run has been completed. Please check the above output to ensure SuSEfirewall2-to-firewalld.txt:INFO: The dry-run has been completed. Please check the above output to ensure susefirewall2-to-firewalld_11.txt:INFO: The dry-run has been completed. Please check the above output to ensure Telcontar:/etc/firewalld #

...

# xmllint zones/external.xml

just prints the file and I can't know where is the line that produces that warning.

xmllint in the basic invocation only checks for the XML being well-formed, i.e. syntactically correct.

I guessed. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)

On 5/2/23 13:50, Per Jessen wrote:

Carlos E. R. wrote:

...

On 2023-05-02 13:07, Per Jessen wrote:

...

Carlos E. R. wrote:

...

On 2023-05-02 08:22, Per Jessen wrote:

...

Carlos E. R. wrote:

...

On 2023-05-01 15:30, Per Jessen wrote: The above has got nothing to do with xmllint, but it sounds like it checks against an xml schema and finds an unwanted/undefined attribute. Hmm, maybe not - there is no schema specified in that file.

It seems there is no XML schema for firewalld (there are some GitHub issues open about it), most one can do besides checking the overall XML validity using xmllint is using `firewall-cmd --check-config` (or `firewall-offline-cmd --check-config`, respectively).

...

# xmllint zones/external.xml

just prints the file and I can't know where is the line that produces that warning.

xmllint in the basic invocation only checks for the XML being well-formed, i.e. syntactically correct.

On 2023-05-02 11:53, Per Jessen wrote:

Per Jessen wrote:

...

Second glance - with the virtually empty config, I added a comment and "--check-config" reported "success".

I have now tried adding comments all over the place, unfolding lines etc - doing a "--check-config" reports no problems, a "--reload" works too and xmllint is happy.

I even tried adding this:

<rule family="ipv4"> <source address="192.168.0.0/16"/> <port port="20" protocol="tcp"/> <accept/> </rule>

<!-- comment -->

The above wasn't in my converted config, but it also caused no problems or complaints when I added it. I also tried adding blanks where blanks aren't always expected - again, no problems or complaints.

Yes, I wrote yesterday several comments and they all worked fine. I don't understand why it complained before. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)

Carlos E. R. wrote:

I don't like this firewalld...

Maybe if you used it the way it was intended, via the GUI. -- Per Jessen, Zürich (20.1°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2023-04-29 at 11:57 +0200, Carlos E. R. wrote: Thinking aloud again, maybe I find what is going on while I write. I see this entry in my firewall log, repeatedly: <0.4> 2023-04-29T12:07:15.296265+02:00 Isengard kernel - - - [1253972.924118][ C3] FINAL_REJECT: IN=eth0 OUT= MAC=...:49:01:86:dd SRC=fd81:...:4901 DST=ff02:0000:0000:0000:0000:0000:0000:00fb LEN=155 TC=0 HOPLIMIT=255 FLOWLBL=503569 PROTO=UDP SPT=5353 DPT=5353 LEN=115 <0.4> 2023-04-29T11:40:31.021724+02:00 Isengard kernel - - - [1252368.627743][ C3] FINAL_REJECT: IN=eth0 OUT= MAC=33:...:5a:bd:86:dd SRC=2a02:...:5abd DST=ff02:...:00fb LEN=105 TC=0 HOPLIMIT=255 FLOWLBL=44733 PROTO=UDP SPT=5353 DPT=5353 LEN=65 that is mdns, aka Multicast DNS (mDNS). It is open in the intranet for IPv4, but seems some machine prefers IPv6. One comes from 2a02:..., which is my prefix. The one that changes, so I can not write that in the firewall rules. cer@Isengard:~/Pictures> ip neigh 192.168.1.129 dev eth0 lladdr ...:5f STALE 192.168.2.18 dev eth0 lladdr ...:01 STALE 192.168.1.14 dev eth0 lladdr ...:bd REACHABLE 192.168.1.1 dev eth0 lladdr ...:d4 REACHABLE 192.168.1.7 dev eth0 lladdr ...:3c STALE fe80::...:5abd dev eth0 lladdr ...5a:bd STALE fe80::...:80d4 dev eth0 lladdr ...:d4 router STALE fe80::...:ced2 dev eth0 lladdr ...:49 STALE 2a02:...:298b dev eth0 lladdr ...:49 STALE 2a02:...:5abd dev eth0 lladdr ...:5a:bd STALE <=== The 5abd part matches the src. It is Telcontar, this desktop machine. Compare the long string... Yes, it is this one: inet6 2a02:...:5abd/64 scope global dynamic mngtmpaddr On the second firewall entry pasted above. The MAC matches partially the "link/ether" string as printed by "ip addr": MAC=...:a1:5a:bd:86:dd link/ether ...:a1:5a:bd brd ff:ff:ff:ff:ff:ff The other log entry <0.4> 2023-04-29T12:07:15.296265+02:00 Isengard kernel - - - [1253972.924118][ C3] FINAL_REJECT: IN=eth0 OUT= MAC=...:49:01:86:dd SRC=fd81:...:4901 DST=ff02:0000:0000:0000:0000:0000:0000:00fb LEN=155 TC=0 HOPLIMIT=255 FLOWLBL=503569 PROTO=UDP SPT=5353 DPT=5353 LEN=115 That's Beta laptop. Beta:~ # ip addr | grep fd81 | grep 4901 inet6 fd81:...:4901/64 scope global mngtmpaddr noprefixroute Beta:~ # Well, it is a nighmare to find out what machine in the network has a certain IPv6 address. Because it is not only one, it is a bunch of them! And they change! In my case, both the prefix and the suffix. I do not see how to allow them in the firewall. Or silence them (just them). Would it bad, in my case, to open "mDNS" both for IPv4 and IPv6, considering the router firewall doesn't work? - -- Cheers, Carlos E. R. (from openSUSE 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZEz47xwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfV9p8Anj02TENJmh+NHxJHLScr RY0WNTyLAJ9gyiHpAlr/6JwEPIgSQfRTM3Cuvw== =688F -----END PGP SIGNATURE-----

On 29.04.2023 15:00, Per Jessen wrote:

- monitor the ipv6 lease file, in /var/lib/NetworkManager

Prefix comes from RA, not from DHCP bor@bor-Latitude-E5450:~$ sudo cat /var/lib/NetworkManager/internal-7fdc67fc-d846-4fed-a6f5-2460f96a1708-wlp2s0.lease # This is private data. Do not parse. ADDRESS=192.168.1.6 bor@bor-Latitude-E5450:~$

On 29.04.2023 15:48, Per Jessen wrote:

Andrei Borzenkov wrote:

...

On 29.04.2023 15:00, Per Jessen wrote:

...

- monitor the ipv6 lease file, in /var/lib/NetworkManager

Prefix comes from RA, not from DHCP

Yes, but the prefix will still be written into the lease file,

As my example that you gratuitously trimmed shows - it does not. e.g.

office68:~ # cat /var/lib/NetworkManager/dhclient6-987c4a73-1fb9-3528-9145-9b04bc192c30-eth0.lease default-duid "\000\004\330\216\262\302\224f\300\254\032\354G\260\207p\207S"; lease6 { interface "eth0"; ia-na 76:17:e1:1b {

You requested IA NA from DHCPv6, of course you got back full address with prefix. But that requires using DHCPv6 for address configuration in the first place. And even if you *are* using DHCPv6 the content of lease file depends on which DHCP implementation NM is using. Which changes over time and currently preferred is internal client which does not write anything related to DHCPv6 (even though it does use it to obtain address).

starts 1682405437; renew 3600; rebind 7200; iaaddr 2a03:7520:4c68:1:ff99:ffff:0:c8f7 { starts 1682405437; preferred-life 43200; max-life 86400; } } option dhcp6.client-id 0:4:d8:8e:b2:c2:94:66:c0:ac:1a:ec:47:b0:87:70:87:53; option dhcp6.server-id 0:1:0:1:28:3e:35:d2:0:15:60:57:7:f1; option dhcp6.name-servers 2a03:7520:4c68:1::1000; }

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2023-04-29 at 16:42 +0200, Per Jessen wrote:

Andrei Borzenkov wrote:

...

On 29.04.2023 15:48, Per Jessen wrote:

...

Andrei Borzenkov wrote:

...

On 29.04.2023 15:00, Per Jessen wrote:

...

- monitor the ipv6 lease file, in /var/lib/NetworkManager

Prefix comes from RA, not from DHCP

Yes, but the prefix will still be written into the lease file,

As my example that you gratuitously trimmed shows - it does not.

Your example did not appear to be applicable to the situation at hand.

...

...

office68:~ # cat /var/lib/NetworkManager/dhclient6-987c4a73-1fb9-3528-9145-9b04bc192c30-eth0.lease default-duid "\000\004\330\216\262\302\224f\300\254\032\354G\260\207p\207S"; lease6 { interface "eth0"; ia-na 76:17:e1:1b {

You requested IA NA from DHCPv6, of course you got back full address with prefix. But that requires using DHCPv6 for address configuration in the first place.

Which ISTR was necessary anyway? for DNS config? - I think Carlos may also have mentioned it being used/available in the Mitrastar router.

I could try stopping our dhcpv6 and see what happens.

...

And even if you *are* using DHCPv6 the content of lease file depends on which DHCP implementation NM is using. Which changes over time and currently preferred is internal client which does not write anything related to DHCPv6 (even though it does use it to obtain address).

Okay - if the lease file cannot be depended on, maybe it can just be used to detect the change and the actual address determined with "ip -6 -o addr show".

If that doesn't work either, I would write an iptables rule to catch the RA and log a message.

This is the file I have, with some editing for privacy. It corresponds fully with the address I get on the "ip addr" command, as "scope global dynamic mngtmpaddr" <lease> <family>ipv6</family> <type>auto</type> <uuid>73ca3964-...</uuid> <state>granted</state> <acquired>1682786208</acquired> <update>0x00000004</update> ipv6:auto <addresses> <address> <local>2a02:9140:...:50a1/64</local> <cache-info> <preferred-lifetime>86400</preferred-lifetime> <valid-lifetime>86400</valid-lifetime> </cache-info> </address> <address> <local>fd81:8fe5:...:50a1/64</local> </address> </addresses> <dns> <server>2a02:9000::aaaa</server> <server>2a02:9000::bbbb</server> </dns> </lease> Isengard:/var/lib/named # There is a duid file, but it is dated yr 2018. There is also a /var/lib/wicked/lease-wlan0-dhcp-ipv6.xml, quite different. It does not contain the same prefix at all. Nor any "<address>" field. Isengard:/var/lib/named # cat /var/lib/wicked/lease-wlan0-dhcp-ipv6.xml <lease> <family>ipv6</family> <type>dhcp</type> <uuid>73ca3964-...</uuid> <state>granted</state> <acquired>1681729921</acquired> <update>0x0000341e</update> ipv6:dhcp <client-id>00:01:...:50:a1</client-id> <server-id>00:03:...:80:d4</server-id> <server-address>fe80::...:b34c</server-address> <server-preference>0</server-preference> <dns> <server>2a02:9000::aaaa</server> <server>2a02:9000::bbbb</server> </dns> <options> <unknown-16> <code>16</code> <data>00:00:0d:...:6f:72:67</data> </unknown-16> </options> </lease> Isengard:/var/lib/named # Maybe because I tell wifi to switch off. # ip addr ... 3: wlan0: mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether a0:d3:...:ff:ff altname wlp1s0 Isengard:/var/lib/named # Well, the best thing would be find out if wicked has hook scripts. There is a directory, "/etc/wicked/scripts". /etc/wicked/scripts /etc/wicked/scripts/redfish-update /usr/share/doc/packages/wicked/samples/scripts /usr/share/doc/packages/wicked/samples/scripts/config /usr/share/doc/packages/wicked/samples/scripts/config/dummy0.xml /usr/share/doc/packages/wicked/samples/scripts/config/ifcfg-dummy1 /usr/share/doc/packages/wicked/samples/scripts/systemd /usr/share/doc/packages/wicked/samples/scripts/systemd/test-post@.service I had a quick look at them (3 scripts). Can't make sense of them. - -- Cheers, Carlos E. R. (from openSUSE 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZE1MXBwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVSukAn2Txw7VvwQuy8i9yMSJW YhKXCvU7AJwKI6n2tvZm7ViF7njHB591GKOCtA== =pLYr -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2023-04-29 at 19:07 +0200, Per Jessen wrote:

Carlos E. R. wrote:

...

This is the file I have, with some editing for privacy. It corresponds fully with the address I get on the "ip addr" command, as "scope global dynamic mngtmpaddr"

<lease> <family>ipv6</family>

I guess that is what Andrei meant - the format changes. My NM lease files are not XML.

...

ipv6:auto <addresses> <address> <local>2a02:9140:...:50a1/64</local> <cache-info> <preferred-lifetime>86400</preferred-lifetime> <valid-lifetime>86400</valid-lifetime> </cache-info> </address> <address> <local>fd81:8fe5:...:50a1/64</local>

fd81 ? I wonder what that is.

The ULA.

...

There is a duid file, but it is dated yr 2018.

That is normal, it is generated at installation time.

Ah.

...

There is also a /var/lib/wicked/lease-wlan0-dhcp-ipv6.xml, quite different.

Ummm, it looks very similar to what you posted above.

No address. I realized I have wifi disabled later. - -- Cheers, Carlos E. R. (from openSUSE 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZE1YRBwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVkE4An3PTqKSAOpqSeXrGjJFI PgywEe3mAJ4+EzYTXf8rEvrE364+O7E4U62VVA== =uXZm -----END PGP SIGNATURE-----

Andrei Borzenkov wrote:

On 29.04.2023 17:42, Per Jessen wrote:

...

Andrei Borzenkov wrote:

...

On 29.04.2023 15:48, Per Jessen wrote:

...

Andrei Borzenkov wrote:

...

On 29.04.2023 15:00, Per Jessen wrote:

...

- monitor the ipv6 lease file, in /var/lib/NetworkManager

Prefix comes from RA, not from DHCP

Yes, but the prefix will still be written into the lease file,

As my example that you gratuitously trimmed shows - it does not.

Your example did not appear to be applicable to the situation at hand.

...

...

office68:~ # cat /var/lib/NetworkManager/dhclient6-987c4a73-1fb9-3528-9145-9b04bc192c30-eth0.lease default-duid "\000\004\330\216\262\302\224f\300\254\032\354G\260\207p\207S"; lease6 { interface "eth0"; ia-na 76:17:e1:1b {

You requested IA NA from DHCPv6, of course you got back full address with prefix. But that requires using DHCPv6 for address configuration in the first place.

Which ISTR was necessary anyway? for DNS config?

DNS_SERVERS is just another DHCPv6 option like IA_NA, IA_TA or IA_PD. If clients asked for DNS_SERVERS, why should it get back IA_NA?

I have no idea what a default openSUSE setup / client might ask for. Eleven years ago when I set it up, there was a reason for having DHCPv6, e.g. for dynamic DNS updates and something about the DNS config too. It is entirely possible things have improved since then, I simply don't know. Do you know? -- Per Jessen, Zürich (19.3°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes