Posted by jpluimers on 2023/04/19
Having my background before the web-development era, and having lived mostly in back-ends or client-server front-ends, I sometimes need to really dig into things in order to understand them better.
CORS is such a thing, so below are some links to get started. My main interest is CORS proxies as they will force me do go deep and really get what is going on below the surface.
Defunct CORS proxy sites:
Used searches:
–jeroen
Posted in Communications Development, Development, HTTP, Internet protocol suite, REST, Software Development, TCP, Web Development | Leave a Comment »
Posted by jpluimers on 2023/04/18
Cool one-liner program via [Archive] Jilles🏳️🌈 (@jilles_com) / Twitter:
for s in 0123456789ABCDEF 172.16.0.254 Passwd:admin;do echo -en "Big Endian: $s\nMiddle Endian: ";echo -n $s|xxd -e -g 4 | xxd -r;echo -en "\nLittle Endian: ";echo -n $s|xxd -e -g 2 | xxd -r;echo -en "\nReversed : ";echo -n $s|xxd -p -c1 | tac | xxd -p -r;echo -e "\n";done
Note that the hex are bytes, not nibbles, so the endianness is OK:
Big Endian: 0123456789ABCDEF
Middle Endian: 32107654BA98FEDC
Little Endian: 1032547698BADCFE
Reversed : FEDCBA9876543210
Big Endian: 172.16.0.254
Middle Endian: .2710.61452.
Little Endian: 71.2610.2.45
Reversed : 452.0.61.271
Big Endian: Passwd:admin
Middle Endian: ssaPa:dwnimd
Little Endian: aPssdwa:mdni
Reversed : nimda:dwssaP
That nibble/byte thing confused me at first (as I associate hexadecimal output with hex dumps, where each hexadecimal character represents a nibble)) so here are some interesting messages from the thread that Jilles_com started:
Some related man pages:
–jeroen
Posted in *nix, *nix-tools, bash, Development, Power User, Scripting, Software Development, xxd | Leave a Comment »
Posted by jpluimers on 2023/04/14
Some notes, as in 2021, I started to see a lot of LED lights (often even LED string lights) being able to automatically do 6 hour on and 18 hour off in a 24 hour cycle to conserve battery usage and improve convenience.
Below are some links, as I might want to create such a circuit myself, maybe even with some solar charging. I’m especially interested to power these off 18650 Li-Ion batteries of which I wrote before (especially as you can easily salvage them from laptop or even e-bike battery packs).
Links via [Wayback/Archive] chip timer 6 hour per 24 hours – Google Search and [Wayback/Archive] microcontroller 6 hour on 18 off timer – Google Search:
–jeroen
Read the rest of this entry »
Posted in 18650, Batteries, Hardware, Li-Ion, LifeHacker, Power User | Leave a Comment »
Posted by jpluimers on 2023/04/13
MikroTik switches and routers are very flexible to configure, as everything is done through [Wayback/Archive] RouterOS settings.
This means that given enough ports, you can split a physical switch into logical switches. This can be very convenient when you run multiple networks without VLAN.
Earlier this week, I already wrote about Torching a specific port on a MikroTik switch or router running RouterOS which involved turning off hardware acceleration off for specific ports in order to have the flow through the underlying switch chip prohibiting torch and filter features.
For splitting noticing which ports are connected to which switch chip is also important: splitting works best if you can configure each logical switch to exclusively use network ports on one switch chip.
This post was to both research how to configure this, and if my MikroTik devices would allow for hardware acelleration.
Here are some links that should help me with configuring (via [Wayback/Archive] mikrotik split switch in two – Google Search):
–jeroen
Read the rest of this entry »
Posted in Development, Hardware, MikroTik, Network-and-equipment, Power User, RouterOS, routers, Scripting, Software Development | Leave a Comment »
Posted by jpluimers on 2023/04/12
Based on my series of tweets about the below disinformation posters (unrolled via [Archive] Jeroen Wiert Pluimers on Twitter: “@threadreaderapp unroll @UnrollThread”).
At first, I got the order wrong, but I was quickly corrected:
I wrote that series because at 20210102, the Dutch version got reposted a lot without attribution, for instance by [Archive] Michiel Noordzij on Twitter: “…” / Twitter (via [Archive] Farmahond on Twitter: “Aanvulling: de verzonnen verhalen a.k.a. leugens. Kan onder kopje “Anekdote”. #2januariTwitterdemonstratie” / Twitter).
So here the posters go in the right chronological order:
- klimafakten.de/plurv; German translated PLURV poster “Grundkurs Desinformation” – [Wayback/Archive] P-L-U-R-V: Dies sind die häufigsten Desinformations-Tricks von Wissenschafts-Leugnern | klimafakten.de
- Pseudo-Experten,
- Logik-Fehler,
- Unerfüllbare Erwartungen,
- Rosinenpickerei,
- Verschwörungsmythen.
- klimafakten.de/flicc; Original English FLICC poster “Disinformation 101” -[Wayback/Archive] F-L-I-C-C: The most common disinformation tricks of science deniers | klimafakten.de
- Fake experts,
- Logical fallacies,
- Impossible expectations,
- Cherry-picking,
- Conspiracy theories.
- klimafakten.de/ploks; Dutch translated PLOKS poster “Basiscursus Desinformatie” at [Wayback/Archive] P-L-O-K-S: Unser Info-Poster zu Strategien der Desinformation jetzt auch auf Niederländisch | klimafakten.de
- Pseudo experts,
- Logische dwalingen,
- Onmogelijke verwachtingen,
- Krenten uit de pap halen,
- Samenzweringstheorieën.
And the tweets from Klimafakten in the chronological order:
- [Archive] klimafakten.de. Sprechen wir darüber on Twitter: “Disinformation101 – How to distort scientific facts One of the main methods: presenting fake experts We explain this and the other four techniques of #FLICC in our brand-new info poster: … By the way, in German it’s #PLURV: …” / Twitter
- [Archive] klimafakten.de. Sprechen wir darüber on Twitter: “Be it #Corona, #ClimateChange or #Evolution – the science gets regularly distorted in political debates In a large-format infographic, we explain the five most common #disinformation ploys. Aka #FLICC (or #PLURV in German) … @johnfocook @skepticscience …” / Twitter
- [Archive] klimafakten.de. Sprechen wir darüber on Twitter: “Disinformation is a global plague. For those of you who might yet have missed out on it – here is our Dutch-language infographic explaining the five key disinformation techniques used in the climate debate 🧡🇳🇱#PLOKS … @peterteffer @whoebert @erikwesselius ….” / Twitter
The unrolls with the posters in the wrong chronological order:
–jeroen
Read the rest of this entry »
Posted in Awareness | Leave a Comment »
Posted by jpluimers on 2023/04/11
On most recent [Wayback/Archive] RouterOS configurations of MikroTik Routers and Switches, running [Wayback/Archive] Torch a port will show zero traffic when they are part of a bridge configuration. The same holds for the Packet Sniffer.
The reason is that these bridges have hardware acceleration turned on, which makes all traffic go through the switch chip instead of the device CPU. Torch works on the CPU level, so won’t show hardly any traffic except for some configuration stuff (depending on the combination of switch chip and CPU type).
This is not documented in the Torch documentation, but it is documented in the Packet Sniffer documentation.
Further reading:
- [Wayback/Archive] Manual:Troubleshooting tools – Torch – MikroTik Wiki
- [Wayback/Archive] Manual:Tools/Packet Sniffer – MikroTik Wiki
Note: Unicast traffic between Wireless clients with client-to-client forwarding enabled will not be visible to sniffer tool. Packets that are processed with hardware offloading enabled bridge will also not be visible (unknown unicast, broadcast and some multicast traffic will be visible to sniffer tool).
- [Wayback/Archive] mikrotik nonhardware bridge – Google Search (yes that was a typo, but Google still got good results)
- [Wayback/Archive] Can not see trafic in TORCH – MikroTik
As the ethernet ports are marked as S(laves) in the tables, I would assume that they are member ports of bridges and “hardware acceleration” is enabled (the value of hw in the respective rows of /interface bridge port is set to yes). So any frames which pass through these ports to other ports of the same switch chip are counted by the switch chip counters, but as they never get to the CPU, the torch cannot see them.
- [Wayback/Archive] mikrotik torch ip ports of bridge – Google Search
- [Wayback/Archive] Manual:Layer2 misconfiguration; Packet flow with hardware offloading and MAC learning – MikroTik Wiki
Consider the following scenario, you setup a bridge and have enabled hardware offloading in order to maximize the throughput for your device, as a result your device is working as a switch, but you want to use Sniffer or Torch tools for debugging purposes, or maybe you want to implement packet logging.
- [Wayback/Archive] Manual:Layer2 misconfiguration; Packet flow with hardware offloading and MAC learning; Configuration – MikroTik Wiki
/interface bridge
add name=bridge1
/interface bridge port
add bridge=bridge1 hw=yes interface=ether1 learn=yes
add bridge=bridge1 hw=yes interface=ether2 learn=yes
- [Wayback/Archive] Manual:Layer2 misconfiguration; Packet flow with hardware offloading and MAC learning; Problem – MikroTik Wiki
When running
Sniffer or
Torch tool to capture packets you might notice that barely any packets are visible, only some unicast packets, but mostly broadcast/multicast packets are captured, while the interfaces report that much larger traffic is flowing through certain interfaces than the traffic that was captured.
Since RouterOS v6.41 if you add two or more Ethernet interfaces to a bridge and enable Hardware Offloading, then the switch chip will be used to forward packets between ports. To understand why only some packets are captured, we must first examine how the switch chip is interconnected with the CPU, in this example we can use a block diagram from a generic 5-Port Ethernet router:
For this device each Ethernet port is connected to the switch chip and the switch chip is connected to the CPU using the CPU port (sometimes called the
switch-cpu port).
For packets to be visible in Sniffer tools, the packet must be sent from an Ethernet port to the CPU port, this means that the packet must be destined to the CPU port (destination MAC address of the packet matches the bridge’s MAC address) or the packet’s MAC address has not be learnt (packet is flooded to all ports), this behavior is because of
MAC learning·
The switch chip keeps a list of MAC addresses and ports called the
Hosts table· Whenever a packet needs to be forwarded, the switch chip checks the packet’s destination MAC address against the hosts table to find which port should it use to forward the packet.
If the switch chip cannot find the destination MAC address, then the packet is flooded to all ports (including the CPU port). In situations where packet is supposed to be forwarded from, for example, ether1 to ether2 and the MAC address for the device behind ether2 is in the hosts table, then the packet is never sent to the CPU and therefore will not be visible to
Sniffer or
Torch tool..
- [Wayback/Archive] Manual:Layer2 misconfiguration; Packet flow with hardware offloading and MAC learning – MikroTik Wiki
Packets with a destination MAC address that has been learned will not be sent to the CPU since the packets are not not being flooded to all ports. If you do need to send certain packets to the CPU for packet analyser or for Firewall, then it is possible to copy or redirect the packet to the CPU by using ACL rules. Below is an example how to send a copy of packets that are meant for 4C:5E:0C:4D:12:4B:
/interface ethernet switch ruleadd copy-to-cpu=yes dst-mac-address=4C:5E:0C:4D:12:4B/FF:FF:FF:FF:FF:FF ports=ether1 switch=switch1
Note: If the packet is sent to the CPU, then the packet must be processed by the CPU, this increases the CPU load.
- [Wayback/Archive] mikrotik torch mac address – Google Search
–jeroen
Posted in Development, Hardware, MikroTik, Power User, RouterOS, routers, Scripting, Software Development | 1 Comment »
Posted by jpluimers on 2023/04/11
https://techcrunch.com/2023/04/10/twitter-circle-bug-not-private/
Ian found out the hard way:
Curious to see what GDPR implications this has and how it relates to the up to EUR ~30 billion fine risk twitter has in Germany for not really moderating hate speech reports:
https://twitter.com/SethAbramson/status/1645276980730896385
Related:
Via
––jeroen
Posted in Uncategorized | Leave a Comment »
The Wiert Corner - irregular stream of stuff 