Archive for the ‘Network-and-equipment’ Category
Posted by jpluimers on 2023/09/08
Early spring 2023 I posted Reminder to self: check if FritzOS 7.50 has become available for Fritz!Box 7490 because it would (likely partially) introduce WireGuard support as I knew it had been available for other Fritz!Box devices since december 2022: [Wayback/Archive] Fritzbox: AVM startet die Verteilung von FritzOS 7.50 | heise online
Das Betriebssystem FritzOS 7.50 für Fritzbox-Router ist fertig. Mit dabei sind das Wireguard-VPN und Verbesserungen im Smart-Home-Funktionsumfang.
Finally, early september 2023 my Fritz!Box 7490 devices updated from firmware version 7.29 to 7.57 so apparently it took AVM quite a while to test and stabilise the new features on Fritz!Box 7490.
The final push for 7.57 might actually be a security issue in prior versions that already looks like being exploited according to [Wayback/Archive] AVM: Fritzbox-Firmware 7.57 und 7.31 stopfen Sicherheitsleck | heise online
Fritzbox-Update: Bereits angegriffene Sicherheitslücke wahrscheinlich
In Internetforen finden sich Hinweise darauf, dass die mit dem Update geschlossene Sicherheitslücke bereits angegriffen wird. Den Gerüchten zufolge können Angreifer Zugriff durch den HTTPS-Port 443 erlangen und hätten dann Zugangsdaten zur Fritzbox sowie PPP-Zugangsdaten verändert. Dadurch sei kein Internetzugang mehr möglich, und auch der Zugriff auf die Fritzbox werde verhindert. Einzig ein Werksreset helfe dann, um wieder Zugriff zu erlangen.
The odd thing of the upgrade logs is that the fiber connected 7490 mentioning a DSL settings reset, but the DSL connected 7490 didn’t:
Read the rest of this entry »
Posted in Ethernet, Fritz!, Fritz!Box, FritzOS/Fritz!OS, Hardware, Network-and-equipment, Power User | Leave a Comment »
Posted by jpluimers on 2023/09/01
I had to add the below to the firewall permission list of a Fritz!Box to allow watching NPO Start, the free Video on Demand service of the Dutch public broadcasting system:
npostart.nl
assets.npo-data.nl
www-assets.npo.nl
start-player.npo.nl
ccm.npo.nl
images.npo.nl
npo-drm-gateway.samgcloud.nepworldwide.nl
time.akamai.com
npo.prd.cdn.bcms.kpn.com
You can find the list on the page fritz.box/?lp=trafapp under Permitted websites edit.
–jeroen
Posted in Fritz!, Fritz!Box, Hardware, LifeHacker, Network-and-equipment, Power User | Leave a Comment »
Posted by jpluimers on 2023/08/28
Too bad that [Wayback/Archive] Cara (@Caramelia79) / Twitter deleted their tweet before it got archived, so this lone tweet does not really make sense now:
[Archive] Jeroen Wiert Pluimers on Twitter: “@Caramelia79 @unimanatee Heute neu gelernt: AEG Methode.” / Twitter
The joke however was this:
AEG Methode:
- Ausschalten
- Einschalten
- Geht
It is also known as “AEG-Prinzip” and refers back to the AEG brand that was (still is?) big in Germany for household appliances and industrial products.
The not so cool thing is that by now it seams to mean:
- Ausschalten
- Einschalten
- Geht nicht
as about a year ago some AEG microwave appliance models show errors F606 and F254 after a firmware update: they now think they are steam ovens but cannot find the correct steam hardware:
Read the rest of this entry »
Posted in Fun, Hardware, IoT Internet of Things, LifeHacker, Network-and-equipment, Power User | Leave a Comment »
Posted by jpluimers on 2023/07/12
Given my health uncertainty, I am looking for maintainers for the fritzcap project (it captures calls from a Fritz!Box modem/router and is written in Python).
History
The fritzcap project was originally started in2007 by [Wayback/Archive] spongebob | IP Phone Forum, first as a binary fritzcap.exe Windows executable (see his first post at [Wayback/Archive] FritzBox: Tool für Etherreal Trace und Audiodaten-Extraktion | IP Phone Forum). In 2010 it became an open source Python project at [Wayback/Archive] Google Code Archive – Long-term storage for Google Code Project Hosting.
Read the rest of this entry »
Posted in About, Audio, Cloud, Communications Development, Containers, Development, Docker, ffmpeg, Fritz!, Fritz!Box, fritzcap, Hardware, HTTP, Infrastructure, Internet protocol suite, Media, Network-and-equipment, Personal, Power User, Python, Scripting, Software Development, TCP | Leave a Comment »
Posted by jpluimers on 2023/05/22
From [Wayback/Archive] De Leukste Wifinaam van 2021 | NPO Radio 2:
- It hurts when IP
- Modem Talking
- Boogie WonderLAN
- AIVD afluisterplantenbak
- WiFinal Countdown
- Ichbinwifidu
- Michiel de Router
- Ziggo Stardust
- Drop it like it’s hotspot
- Draadlozing
- WhyTellMeFi
- Lekker Wifi
- Wifi Soerjadi
- Jodelawifi
My related blog posts:
–jeroen
Posted in Conventions, Development, Fun, Naming Conventions, Network-and-equipment, Power User, Software Development, WiFi | Leave a Comment »
Posted by jpluimers on 2023/04/24
It was great while it lasted, so be sure to order within the next 12 months as [Wayback/Archive] PC Engines apu platform EOL:
|
PC Engines apu platform EOL |
| The end is near ! |
After a long production run, AMD will accept last orders for the SOC used in our apu2/3/4/5/6 boards by end of June 2023. |
| apu phase-out |
We will do a life-time buy for a quantity of the AMD SOC and some other key components. We are willing to schedule customer shipments through end of June 2024. There is a 26 week lead time on the AMD SOC, expect limited supply until late 2023.
First ordered, first served. Binding orders may be required for large quantities.
|
| New products ? |
Despite having used considerable quantities of AMD processors and Intel NICs, we don’t get adequate design support for new projects. In addition, the x86 silicon currently offered is not very appealing for our niche of passively cooled boards. After about 20 years of WRAP, ALIX and APU, it is time for me to move on to different things. |
| Thank you ! |
I would like to thank all of our customers for their business, and sometimes patience. |
–jeroen
Posted in APU, Hardware, Network-and-equipment, pfSense, Power User, routers | 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/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/07
A while after I got a new smartphone, I noticed that when my MacBook was connected over Wi-Fi to the mobile hotspot of my Android phone, the Tunnelblick connections over OpenVPN to my family members would not work. A telnet from the Android phone to the OpenVPN TCP port 1194 woud succeed, but not from the MacBook. Connecting from the phone using JuiceSSH to the OpenSSH endpoints at those family members would work too, so I was a bit flabbergasted.
In the end this seems to be a set of coincidences that fails in this particular setup, but I am not totally aware why.
The solution was to both re-configure the APN (Access Point Name) the smartphone uses to connect to the internet from ipv4/ipv6 to ipv4, and to reboot the phone.
For Dutch provider KPN Mobile, the APN is named internet and apparently changed default to ipv4/ipv6 without properly supporting ipv4. Note the configuration parameters are all lowercase, although they should be written IPv4 and IPv6.
Here are a few posts that got me on the right track (all via [Wayback/Archive] openvpn fails over android hotspot – Google Search):
Note that sometimes the MTU can cause similar failures:
Note too: some links to check for OpenVPN responding are below.
Various sites with (often different) APNs that KPN mobile supports:
There are quite a few APNs, some with firewall and/or proxy and/or compression, some with external IP address (which means your smartphone really needs a firewall).
–jeroen
Posted in Android Devices, Hardware, Network-and-equipment, OpenVPN, Power User, VPN | Leave a Comment »
Posted by jpluimers on 2023/04/04
Wow, I wrote about Tailscale a few times before, and it is still on my research list, but this is a very compelling reason to use it. [Archive] Dave Anderson on Twitter: “Cool minor @Tailscale moment: I’m recommissioning a server that got moved from a different network, so all its network config was wrong, and generally I couldn’t get at it over the network, only IPKVM console. But then my ping over Tailscale started working?!” / Twitter
I archived the thread so it becomes easier to read: [Wayback/Archive] A readable Thread by @dave_universetf Says Cool minor @Tailscale moment: I’ – UnrollThread.com.
The core are these three tweets:
Turns out, IPv6 autoconfiguration is what happened. Sure, v4 configuration was entirely wrong (it was trying to connect to wifi, via a wifi dongle that was no longer installed, and wanted to talk to a DNS server that doesn’t exist any more), but eno1 had a cable plugged in!
The server noticed IPv6 router advertisements, went “I’ll have some of that”, and got global IPv6 connectivity automagically. IPv4 and DNS were still down though, so all it had at this point is the ability to send/receive IPv6 packets.
So, how did Tailscale get from there to a working setup? It still needs to contact
https://t.co/hEs4S8qvTw to get a network map, and still needs to talk to DERP servers to get p2p tunnels working outside the LAN. Enter bootstrap DNS!
It means I have to re-read Source: Some links on Tailscale / Wiregard, especially the [Wayback] How Tailscale works · Tailscale bit, then decide how I want to organise my infrastructure to run parts under Tailscale (I have the impression it is a peer based set-up, not router based).
Then I have to read [Wayback/Archive] IPv4, IPv6, and a sudden change in attitude – apenwarr of which the conclusion is this:
IP mobility is what we do, in a small way, with Tailscale’s WireGuard connections. We try all your Internet links, IPv4 and IPv6, UDP and TCP, relayed and peer-to-peer. We made mobile IP a real thing, if only on your private network for now. And what do you know, the math works. Tailscale’s use of WireGuard with two networks is more reliable than with one network.
Finally I need to not just read it, but understand all it (:
Or maybe I should ask Kris, as I got here through:
I saved Kris’ message thread here at [Wayback/Archive] Thread by @isotopp on Thread Reader App – Thread Reader App.
An OK translation is at [Wayback/Archive] Thread by @isotopp on Thread Reader App – Thread Reader App.
–jeroen
Posted in Hardware, Network-and-equipment, Power User, Scoop, Tailscale, VPN, Windows, Wireguard | 1 Comment »
The Wiert Corner - irregular stream of stuff 