#networking

215 posts · Last used 3d

Back to Timeline
Peter N. M. Hansteen @pitrh@mastodon.social · 3d ago
0
0
0
st1nger :unverified: 🏴‍☠️ :linux: :freebsd: @st1nger@infosec.exchange · 3d ago
A use-after-free bug in #Linux's #SCTP #networking #code can be turned into full #root on a host, and #Tencent researchers say they used it to escape a #container and reach the machine underneath. The flaw has existed since 2008. The fix already shipped: stable kernels 7.1.6, 6.18.42, 6.12.101 and 6.6.148, released August 3, close it. Anyone running an older kernel with SCTP reachable should update. https://thehackernews.com/2026/08/18-year-old-linux-sctp-flaw-could-let.html?m=1
0
0
0
Klaus Frank @agowa338@chaos.social · 4d ago
Note to self: Just don't touch #ipsec. It's shit all way round and always breaks. Just use something else. Why? Every time I want an encrypted tunnel between two public IPs I think like "oh yea, using IPSec here would be easy and straight forward". And then it never fucking works reliably. And if it does work it stops to work the next time you try to apply the exact same config. And it fails with shit like this... What have I done wrong?!? Why work sometimes?? #networking #strongswan #ipv6
3
3
1
Larvitz :fedora: @Larvitz@burningboard.net · 5d ago
0
1
0
Michael Koerfer @OT_MacDonald@infosec.exchange · Aug 05, 2026

Powerful Hardware Turned into E-Waste

What you're looking at is another unfortunate example of perfectly capable hardware becoming electronic waste long before its technical lifespan is over.

This is the AirTies Air 4960, an AX5400 Wi-Fi 6 mesh extender/access point featuring impressive hardware:

  • Broadcom BCM6752 triple-core ARM Cortex-A7 SoC (up to 1.5 GHz)
  • Broadcom BCM43684 4x4 Wi-Fi 6 radio with 160 MHz channel support
  • Dual-band Wi-Fi 6 (802.11ax)
  • Two Gigabit Ethernet ports
  • Around 4.5 W power consumption

From a technical perspective, this device is still more than capable of delivering excellent performance in many home and enterprise networking scenarios.

  • The Real Issue

The hardware isn't obsolete, the software ecosystem is intentionally locked down.

Many devices like this are heavily restricted by manufacturers or Internet Service Providers (ISPs), preventing owners from repurposing them once official support ends or the service contract expires.

Meanwhile, open-source firmware projects such as OpenWrt, DD-WRT and Tomato have demonstrated for years that networking hardware can remain secure, functional, and useful far beyond its commercial lifecycle.

Unfortunately, locked bootloaders, proprietary firmware, missing documentation, and closed-source drivers often make that impossible.

Sustainability Is Also About Software Freedom

We regularly discuss sustainability, circular economy, and reducing electronic waste.

Yet perfectly functional networking equipment ends up in recycling bins, not because the hardware has failed, but because users are prevented from installing alternative software.

  • The hardware already exists.
  • The raw materials have already been mined.
  • The manufacturing energy has already been spent.

In many cases, all that's missing is the freedom to install an alternative operating system.

  • A Better Approach

I would like to see manufacturers embrace a more open ecosystem by providing:

  • Unlockable bootloaders
  • Public hardware documentation
  • Support or at least tolerance for open-source firmware
  • Longer software support lifecycles

This would benefit users, enterprises, developers, the open-source community, and ultimately the environment.

Not every retired device is obsolete, many are simply made obsolete through artificial restrictions.

#OpenSource #OpenWrt #DDWRT #WiFi6 #Networking #Sustainability #CircularEconomy #RightToRepair #EmbeddedLinux #Broadcom #eWaste #Technology

20
1
21
thecybersecguru @thecybersecguru@infosec.exchange · Aug 03, 2026
ARP is one of those protocols everyone can define, but far fewer can explain in detail. I put together a comprehensive guide covering protocol internals, operating system behavior, Wireshark analysis, security implications, and modern enterprise defenses. Feedback is welcome. https://thecybersecguru.com/networking/address-resolution-protocol-arp/ #Networking #CyberSecurity #IPv4 #Wireshark
0
0
0
Dima @dima@dol.social · Aug 02, 2026
Drew the whole OSI stack because I got tired of googling which layer TLS sits on. Many years in. Still counting on my fingers. In practice I touch three of them. Physical, when someone unplugged the thing. Network, when it is DNS. Application, when it is also DNS. Presentation I had to look up. Twice. The first result was a mnemonic about pizza so I closed the tab out of spite. Layer 5 is in there too. Doing something. Allegedly. #OSIModel #Networking #DevOps #SysAdmin #ItsAlwaysDNS #Blog #Thoughts
0
0
0
Jaap de Vos @jaap@mastodon.bsd.cafe · Jul 13, 2026
A new article at the RIPE blog explains the current state of running IPv4 services over IPv6-only networks. The three pieces are RFC 8950 (IPv6 next-hops for IPv4 prefixes), a draft about IPv6 next-hops for IPv4 routes, and a draft for solving the IPv4 gateway problem that systems running IPv4 services in these types of networks typically have. It’s cool to see this gateway thing in such an informed piece, I’ve been wondering about that bit for a while. You might have seen different service providers solving this in different ways, with a /32 on either a regular interface or a loopback, and a strange default route pointing to just an interface (with no destination IP), or a destination IP in a prefix that the given machine doesn’t know about. Linux seems to support a couple of different ways to go about this (of course), and FreeBSD and OpenBSD each support a single, different solution AFAIK. I don’t believe illumos even has a way to solve this problem at the moment, but I might have that one wrong. Anyway, do have a look at the article: https://labs.ripe.net/author/remco-van-mook/a-farewell-to-arps-ipv4-service-on-ipv6-only-networks/ #IPv6 #IPv6mostly #fuckdualstack #networking
12
2
6
Matt Organ @Slater450413@infosec.exchange · Oct 22, 2024
Anyone else notice or have issues where ping.exe on Windows 10/11 behavior appears to be buggy these days. If I ping an address known to be offline. On both Linux and Unix, I correctly get 100% packet loss. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data. From 192.168.0.101 icmp_seq=1 Destination Host Unreachable --- 192.168.0.2 ping statistics --- 1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms On Windows I get an utterly broken 0% packet loss ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Pinging 192.168.0.2 with 32 bytes of data: Reply from 192.168.0.100: Destination host unreachable. Ping statistics for 192.168.0.2: Packets: Sent = 1, Received = 1, Lost = 0 (0% loss), The impact is that you then can't accurately measure the commands exitstatus/errorlevel when used in a script. #infosec #Windows10 #Windows11 #networking #Linux
2
1
2
Matt Organ @Slater450413@infosec.exchange · Jul 30, 2026
Replying to @Slater450413@infosec.exchange
Whoa, just discovered this is now fixed. No idea when that happened. #infosec #Windows10 #Windows11 #Networking #Linux
0
0
1