Re: IPv6: how to trigger script when address prefix changes?

[Daniel Jakots]

On Thu, 7 Oct 2021 02:52:13 +0200, Mike Fischer
 wrote:

> Would a IPv6 address prefix change be something the hotplug(4) /
> hotplugd(8) mechanism would see?

It would rather be ifstated(8), but I don't think so. I've never looked
into this, but if I were, I would check the route(8) monitor command:
https://man.openbsd.org/route#monitor

IPv6: how to trigger script when address prefix changes?

[Mike Fischer]

Hi!

I have a need to update DNS  records, and potentially pf(4) rules or tables 
when a public routable IPv6 address of my host changes.

Such a change is expected whenever slaacd receives a change in the advertised 
IPv6 address prefix(es) from the router(s).


Other than regularly polling the interface for its IPv6 addresses and comparing 
to a previously saved state, is there some way to get notified actively when 
such a change happens? (I am not a friend of polling as it wastes cpu cycles 
and on average comes with a delay of half the polling interval. slaacd already 
knows that a change is happening so why not let it tell my script?)

Note that I am not concerned about the temporary IPv6 addresses generated by 
RFC 8981 privacy settings. Just any addresses using a fixed/static Interface 
Identifier (IID), either manually configured, EUI-64 or randomly generated. In 
other words this is about incoming traffic from the Internet to services 
running on my host, not host initiated outgoing traffic. If changes to 
temporary addresses also trigger my script, I could live with that but I don’t 
need this information.


>From reading the documentation, scripts configured in hostname.if(5) using the 
>! syntax do not seem to work for this, as they seem to be triggered 
>only when /etc/netstart is executed? (This is not documented anywhere I could 
>find.)

Would a IPv6 address prefix change be something the hotplug(4) / hotplugd(8) 
mechanism would see?

Can someone enlighten me please?


Thanks!
Mike

Re: Spleen with russian (maybe more) cyrillic symbols

[ropers]

Sorry for the repeated noise, but there's one more thing I stupidly forgot:

Whatever subset of legal Unicode characters might be chosen for
inclusion in minimalistic UTF-8 support, it would be VERY important
for the U+FFFD � REPLACEMENT CHARACTER to be included, because that's
Unicode's way of throwing up its hands and saying "I can't even, like,
deal with you anymore."



NB: What Wikipedia says about "[a] poorly implemented text editor"
here also applies --mutatis mutandis-- to the console:
Only substitute U+FFFD replacement characters at the point of actual
console output, i.e. when *displaying* text containing characters not
included in the tiny supported Unicode subset.  Don't actually save
the U+FFFD-substituted text, because that would corrupt otherwise good
data.

(Obviously it would be impossible to use .notdef characters, because
those would not save any glyphs at all but require 1,112,064
additional ones.  If those .notdef "tofu blocks" could be dynamically
generated, things might be different, but compatibility-wise that all
seems very dubious.)

Speaking of compatibility, it's a valid question to ask what should
happen when characters are not necessarily redefinable, e.g. on a
serial console.  I wonder if it might be an option to produce an
inverted "?" as a printable ASCII-safe fallback wherever U+FFFD is
needed.  The VT100 has \33[7m and \33[0m to invert and revert video
for text characters
, but I'm not sure
how consistently those ESCape codes would work everywhere.
If an ESC sequence is not understood, is it just ignored?  If yes,
then that would make "\33[7m?\33[0m" neatly fall back to "?", which
might be a substitute of last resort for U+FFFD.


On 05/10/2021, ropers  wrote:
> On 05/10/2021, ropers  wrote:
>> This does relate to a question I've been thinking about for a while,
>> so even if actually offering diffs for that is still way above my pay
>> grade, I will offer these thoughts:
>>
>> * Of ASCII's 128 characters, only 95 are actually printable (ASCII
>> sticks 2 thru 7 minus 0x7F DEL).[0]
>> * In principle, the console is capable of supporting 256 glyphs.
>> * With traditional Extended ASCII (EASCII) character sets, more than
>> 95 characters were (still are) printable, but code assuming the use of
>> ISO 8859-1 is deprecated and no longer portable in this age of UTF-8,
>> and for EASCII sticks 8 thru F, there no longer is a direct
>> correspondence between code points and code units at all.
>> * Even if framebuffer console drivers could hypothetically be altered
>> to allow the use of more than 256 glyphs, I completely agree with Ingo
>> that that would be a fairly terrible idea for various reasons.  While
>> the 256-glyphs limitation does stem from VGA console drivers
>> permitting no more than 256 text mode glyphs (or 512 with hacks), it
>> would be best to not totally break framebuffer and vga console
>> compatibility, but to stay within those limits.
>> * With "extremely minimalistic UTF-8 support", up to 161 "spots" might
>> be available.
>> * There are 1,112,064 legal Unicode character code points (0x11 *
>> 0x1 - 0x800, i.e. seventeen 65,536-character planes minus the
>> 2,048 code points from U+D800 thru U+DFFF that are reserved for UTF-16
>> surrogates).  Of those, 137,468 are private use, and 66 are
>> non-characters.  If we also subtract the 95 printable ASCII
>> characters, that leaves 974,435 characters that might compete for
>> those 161 spots.
>> * There is an extremely strong argument for accommodating all
>> characters from ISO 8859-1 in any future minimalistic UTF-8 console
>> support.  The non-breaking space and soft hyphen could use the same
>> glyphs as space and hyphen-minus, respectively.  This means that to
>> maintain maximum backwards compatibility and UTF-8
>> forward-portability, 94 of those 161 spots would have to be taken,
>> leaving 67.
>> * There might also be a strong argument for accommodating all the
>> characters from ISO 8859-15 (so an additional 8) and Windows-1252,[1]
>> which despite no Unix pedigree is a common superset of ISO 8859-1,
>> with EASCII sticks A thru F being identical to ISO 8859-1.  ISO
>> 8859-15 differs from ISO 8859-1 in that it includes 8 characters in
>> sticks A/B that Windows-1252 encodes in sticks 8/9.  However, with
>> UTF-8, code units and code points no longer match outside of sticks
>> 0-7, so UTF-8 implementers of ISO 8859-1 and Windows-1252 backwards
>> compatibility get ISO 8859-15 support for free.  Besides those 8,
>> Windows-1252 support would consume an additional 19 characters, so
>> we'd have to subtract 27 from those 27 remaining spots, leaving 40.
>
> s/27 remaining/67 remaining
>
>> * 32 of those spots are from the C0 control codes from ASCII sticks
>> 0/1.  While Bemer et al. did originally propose alternatively
>> printable glyphs for those normally unprintable characters, their
>> 

USB devices power control

[jeanfrancois]

Hello,

I'm looking for a way to turn on/off the usb power, does one know which 
command helps with

this ?

Regards,

Jean-Frnaçois

drmfreeze

[Avon Robertson]

Hello misc@,

Earlier today an AMD host I have froze again. I ssh'd into the host
and retrieved the output from dmesg, /var/log/messages, and
/var/run/dmesg.boot.

I found nothing of note in $HOME/.local/share/xorg/Xorg.0.log.

At the time of the freeze the ksh script I use to update my local /cvs
repository was the only programme executing inside the rightmost pane
of a 3 pane tmux session. I have a log of the output produced by this
script which is probably of no use to those who have been trying to
isolate and fix this bug for many months.

Please advise if any of the above is of use or interest to anyone, and
if so to which list should I post it.

aer
--