Entries by Raymond P. Burkholder

From Using a "proper" camera as a webcam there were some references to some interesting inexpensive high resolutions cameras and lenses. I can't vouch for quality, but I intend to give them a try.

• C920/C922/C930 enclosure kit for CS-type lens mk2 - with some references to lenses and IR-cut filters
• IMX477 Full Report – Datasheet, Specs, Technologies and Camera Modules - f you are considering the Sony IMX477 or IMX477R, then this is for you. datasheets, specs, and related informaiton
• ArduCam embedded camera solutions on Amazon

There are suggestions for teleprompters in there as well.

Interesting portions of the query:

# decode-dimms 
# decode-dimms version 4.3

Memory Serial Presence Detect Decoder
By Philip Edelbrock, Christian Zuckschwerdt, Burkart Lingner,
Jean Delvare, Trent Piepho and others


Decoding EEPROM: /sys/bus/i2c/drivers/ee1004/3-0050
Guessing DIMM is in                              bank 1
Kernel driver used                               ee1004

---=== SPD EEPROM Information ===---
EEPROM CRC of bytes 0-125                        OK (0xB200)
# of bytes written to SDRAM EEPROM               384
Total number of bytes in EEPROM                  512
Fundamental Memory type                          DDR4 SDRAM
SPD Revision                                     1.1
Module Type                                      SO-DIMM
EEPROM CRC of bytes 128-253                      OK (0x2A87)

---=== Memory Characteristics ===---
Maximum module speed                             2400 MT/s (PC4-19200)
Size                                             16384 MB
Banks x Rows x Columns x Bits                    16 x 16 x 10 x 64
SDRAM Device Width                               8 bits
Ranks                                            2
Rank Mix                                         Symmetrical
Primary Bus Width                                64 bits
AA-RCD-RP-RAS (cycles)                           14-14-14-35
Supported CAS Latencies                          16T, 15T, 14T, 13T, 12T, 11T, 9T

---=== Manufacturer Data ===---
Module Manufacturer                              Kingston
DRAM Manufacturer                                SK Hynix (former Hyundai Electronics)
Manufacturing Location Code                      0x01
Manufacturing Date                               2018-W21
Assembly Serial Number                           0xC22D6945
Part Number                                      KHX2400C14S4/16G


Number of SDRAM DIMMs detected and decoded: 1
                           

IATA airport codes to LOC:

$ dig +short YYC.air.jpmens.net LOC
51 6 50.037 N 114 1 11.988 W 1084.00m 1m 10000m 10m

and more fun with an associated TXT:

$ dig +short YYC.air.jpmens.net TXT
"cc:CA; m:Calgary; t:large, n:Calgary International Airport"

with more at Airports of the world, and other data in DNS

Another from the email list (2022/04/22):

systemd-resolved is broken in many ways. I doubt it can forward correctly TSIG or SIG(0). If you have a proper DNS server running on your machine, there is not many reasons to run also systemd-resolved. If you need it, I suggest to write fixed /etc/resolv.conf pointing to 127.0.0.1 or ::1. Consider chattr +i /etc/resolv.conf afterwards. Do not use stub resolver provided by systemd if you have better caching server running on the same machine. I would even recommend to uninstall it on Fedora, where it is possible. Unless you use mdns on selected networks only, I don't think systemd-resolved provides you any benefit.

systemd-resolved strips in default configuration even DNSSEC signatures. I would doubt it can handle key signatures or even updates.

A solution:

    sudo systemctl disable systemd-resolved.service
    sudo service systemd-resolved stop

And then mask: systemd masking

From an email list 2022/04/21:

Geofeed is specified in RFC 8805. Finding and using Geofeed data is described in RFC 9092.

Example in the wild:

    $ whois -h whois.ripe.net 146.75.0.0 | fgrep geofeed:
    geofeed:        https://ip-geolocation.fastly.com/

Another example below, in this instance the geofeed information is stored in a 'remarks:' attribute. Unfortunately this particular RIR does not (yet?) properly support the native RPSL geofeed attribute for IPv6 /48 PI blocks.

    $ whois -h whois.ripe.net 2001:67c:208c::/48 | grep geofeed
    remarks:        Geofeed https://sobornost.net/geofeed.csv

Both approaches work.

----

Besides geofeed, there are also geoidx records in IRRs but whether geolocation services actually use geofeed or geoidx remains to be seen. You can see some geoidx: at this IRR entry in TC: bgp.net example

----

A helpful resource: Geo & VPN Services - the RFC only works if they're pulling your feed and they'd only know that if you contact them in the first place.

----

• RFC 3693: Geopriv Requirements
• RFC 5870: A Uniform Resource Identifier for Geographic Locations
• RFC 6288: URN Namespace for the Defence Geospatial Information Working Group (DGIWG)
• RFC 6397: Multi-Threaded Routing Toolkit (MRT) BGP Routing Information Export Format with Geo-Location Extensions
• RFC 6772: Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information
• RFC 7942: The GeoJSON Format
• RFC 8142: GeoJSON Text Sequences
• RFC 8805: A Format for Self-Published IP Geolocation Feeds
• RFC 9092: Finding and Using Geofeed Data

Heard on an email list:

There are public and commercial offerings for "DNS based protection".

e.g. 9.9.9.9 automatically generates NXDomains for suspected malicious DNS Names even in their free service.

They have a page where you can check if you have been blacklisted (see Threat blocking).

From an email list, the definition of email list-washing:

Trying to identify the addresses in a spam list that will get you in trouble, e.g., spam traps and people with a history of complaining, so that you can mail to what's left. And also, by implication, dealing with complaints by saying "we took you off the list" without looking at the overall list quality.

The technical methods for removing stale bouncing addresses from a legitimate list are somewhat similar but the motivation is not.

• IP -> PTR lookup -> that hostname lookup, and match to IP again
• SPF
• DKIM - one possible implementation: OpenDKIM - opendkim is an excellent tool, which helped find the real problem with a simple "Diagnostics yes" in the config file.
• DMARC
• ARC (for mailinglists)
• SRS (When forwarding, rewrite the From and resign DKIM, and then ARC-sign that)
• Decent TLS
• MTA-STS
• DANE

Use a site like internet.nl for testing mail server configuration and capabilities

Follow up comment: Google at least adds ARC headers in Gmail, and did the editing of RFC8617. ARC – Authenticated Received Chain

Follow up comment: Bimi Group - is snakeoil, or well, a scam is more like it: if you can pay and they like you, you get a logo, anybody else is out... marketing companies of the world (and the once earning money for bits ala domains and worse EV SSL certs... rejoice)

Follow up link: mailing lists are the ugly stepchild

Settings for mailing list:

We have SPF, DKIM signing, and a DMARC policy that sets p=none.

We're not setting p=reject, considering the number of mailing lists our users are on that are outdated or based on EOL software (including this one which depends on python 2.7, and including our own which have the same problem). It's impossible to know, from the outside, how mailing lists are configured. Mailman3 is...special. That's a rant for another time.

We get about an email a week from someone emailing security-officer@ trying to get a bug bounty telling us we should set p=reject. There's an ecosystem for this stuff.

Note: Yup. Gmail has made it quite clear that they will not accept v6 mail that isn't SPF or DKIM authenticated. DKIM is more work but works more reliably.

ARC: It's certainly not a magic ticket into an inbox but it is slowly helping undo DMARC mailing list damage. It's not important unless you forward mail like a mailing list does.

What ARC does:

ARC addreses the problem that mailing lists do a lousy job of spam filtering, A list that usually sends lovely clean mail sometimes doesn't, since a typical list forwards anything with a subscriber's address on the From line including spam from cleverish spammers who take pairs of from/to addresses from stolen mailboxes.

ARC lets the recipient system look back and do what we might call retroactive filtering, using info about messages as they arrived at the previous forwarder. While it would be nice if lists did a better job of spam filtering, they don't, and ARC is a reasonable remedy for that.

Additional protection settings:

I run my own mail server and have no trouble at all delivering mail to Gmail over IPv6. I do have SPF, DKIM, DNSSEC and DANE on my mail servers. My DMARC policy is p=none. If it matters, the MTA is a heavily hacked version of qmail.

Someone mentioned nullmailer as a small mail program that allows you (or your system) to send mails through an existing email account (using an SMTP server).

In response to "Clearly, someone used the reputation of ImprovMX.com to deliver emails by forging them before delivery., "DKIM replay attacks preventative measures

2022/04/24 added - DMARC Domain Checker

From the P4-dev mailing list, an interesting tool which deep dives wifi, P4, the kernel, ...

you may want to look at the BATMAN and P4 examples in Mininet-WiFi: Manet Routing Protocols or P4 Programming Protocol-Independent Packet Processors .

BTW, we recently fully open-sourced here: mn-wifi-ebook.

The English version of the Mininet-WiFi book: The Mininet-WiFi Book

look at Hetrixtools - It's not IP Reputation Service, but this tool can you can an idea with RBL Blacklist monitor maybe ?

There are only two IP-based reputation services that are truly widely used, world-wide, ours and Validity's (nee ReturnPath).

IADB (ISIPP Accreditation Database, now known to consumers as the Good Senders List, or GSL) - Ours have *always* been free for receivers to query, and always will be, as our primary reason for having been in business for going on 20 years is to provide a way for *receivers* to determine the ham from the spam (making it easier for them to reject spam). I'm surprised to hear that *any* of the others are charging for access for querying - shocked in fact. More general information about the IADB is here: for ISPs

FWIW - spamassassin checks the ISIPP by default since 3.10 and reduces the score if your address is found there.

2022/04/09 - E-Mail Reputation – Protect against false positives - reputation data services - has a link to applications using the data, one of which being rspamd -- but note: "gmail's lack of cooperation with the dns good list means inbound from them gets dropped when one of their outbound smtp senders gets badlisted, which they often do. " -- followed up by: [How about using their SPF records as automation input? Their MXes are inside those blocks right now at least.]

2022/04/09 - HetrixTools - Uptime Monitor & Blacklist Monitor

• download kernel 5.17 source tar.gz file from kernel.org
• Unpack the source and apply the patch with cd linux; patch -p1 < patch_file
• Run "make localmodconfig"
• Compile (run "make")
• Install: sudo make modules_install install
• reboot and choose the new kernel in grub

Seen on a mailing list, some comments regarding local preference vs MED.

Unfortunately, the reason crazy-long prepends actually propagate so widely in the internet core is because most of those decisions to prefer your peer's customers are done using a relatively big and heavy hammer.

> IOW if your peer or customer has prepended 5 times or more, dont LOCAL_PREF or maybe even de-LOCAL_PREF it

LOCAL_PREF is, in my opinion, the wrong tool to use, but it's what most of the networks out there seem to have settled on, to the point of having published BGP communities to use for controlling the LOCAL_PREF setting on received routes: https://onestep.net/communities/

I've long practiced, and advocated for, the use of MEDs or tweaking origin codes as a better way to nudge traffic towards customers, peers, customers of peers, etc., because it still allows as-path to be a factor in nudging traffic away. Prepend inbound 3 times on routes learned from your transit provider, but not on your peers, listen to MEDs from your peers, and enable always-compare-med and deterministic-med to allow values to be compared across different pathways.

That way, someone trying to say "don't use this path" can do a simple triple-prepend, and see their traffic shift. In our current world of using LOCAL_PREF, however, the poor customer keeps prepending more and more, and never sees their traffic shift. In desperation, they prepend the maximum number of times allowed, hoping that maybe this will somehow do the trick...not understanding that no matter what they do in the prepend realm, so long as their upstreams are using the LOCAL_PREF hammer, their prepends will fall on deaf ears.

For the most part--if you think LOCAL_PREF is the right knob to use for moving traffic, it probably means you need to go back and rethink your traffic engineering approach.

Just to show how wide-ranging the DNS ecosystem is, some DNS RFC Collections:

• ttkzw's DNS RFCs - pictographs of a DNS RFC timeline and relationships
• DNS Camel Viewer - a list of 297 RFCs relevant to DNS which can be filtered in various ways - use the 'BEST_CURRENT_PRACTICE' selection with 'INTERNET STANDARD' to see Domain Names, IPv6, DNSSEC, DKIM, and EDNS. Camel is O'Reilly's animal on their DNS handbooks.
• DNS RFCs - a curated list of DNS RFC's, as a subset of a much larger collection of Internet Technical Documents

In looking at the output of 'lsof' for a process, I saw a couple of attached /proc entries. Looking at each, provides an interesting view into the process.

$ cat /proc/<pid>/statm
10593951 17514 5924 24288 0 82658 0
$ cat /proc/<pid>/status
Name:   code
Umask:  0022
State:  S (sleeping)
Tgid:   227783
Ngid:   0
Pid:    227783
PPid:   227577
TracerPid:      0
Uid:    1000    1000    1000    1000
Gid:    1000    1000    1000    1000
... more stuff ...

When using Cern's ROOT Data Analysis Framework, there are notes about possible compile time enhancements. It is best to take a look on which cpu variant the compiler will generate code, and for which target cpu the code will run. They need to be compatible.

AVX-512 is an interesting Wikipedia page describing the various cpu variant incarnations and their specialized instruction subsets.

Here are a few command line examples for examining what the gcc compiler sees as being available.

$ gcc -march=native -Q --help=target | grep march
  -march=                               skylake
  Known valid arguments for -march= option:

$ echo | gcc -dM -E - -march=native
  ... large quantity of flags ...

gcc x86 cpu options cmake command:

add_definitions(-march=native)

Even though this optimizes instruction use, it has to be used carefully. It will probably cause side effects with compiling code on one version of cpu and when copying the executables to a different machine, with possibly a different cpu variant.

Reference: How to see which flags -march=native will activate?