sigh I see, I mean, at least I know what is coming when I fill this out

Grafana stop randomly logging me out challenge (impossible)

Doing a bit of aliexpress safari again, and while this motherboard looks incredibly silly if you added a load of PLX PCIe switch/failover chips you would basically have a motherboard+CPU that is functionally the same as most big carrier routers

Mildly interesting, got a alert of a box going mental on the load avg

 Tasks: 155, 243 thr; 2 running
 Load average: 5922.82 4616.68 2131.84
 Uptime: 151 days(!), 22:30:04

dmesg said

[12507760.522357] INFO: task kcompactd0:32 blocked for more than 1208 seconds.
[12507760.522411]       Not tainted 5.10.[redacted]
[12507760.522446] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[12507760.522491] task:kcompactd0      state:D stack:    0 pid:   32 ppid:     2 flags:0x00004000

It turned out that one sshfs PID had decided to become a slow moving fork bomb..? Sure I guess, that's a new one

LMAO, does OkCupid run on Excel now???

This just happened recently. I bet this was a botched database migration. Maybe that explains why chat messages are showing out of order too.

LOL, what a dumpster fire.

When stuff says "doing x 100% of the time", like surely that's not very efficient doing something for only 1 amount of time per thread/time

Over in bgptools land, im doing BGP and BGP related processing approximately 24000% of the time

Did you bgp.tools sessions go down ~1 hour ago? Here is the RFO:

It turns out the locking mechanism on one of the uplink ports on a satellite PoP doesn't work, and the RJ45 can move about ~5mm, enough to drop a link when you are fiddling doing something else

Google Earth now has a good web client! And the historical imagery feature is now easily hyperlinkable, I have already wasted a unreasonable amount of time playing with this.

And look! One of the days sat/aerial photos were taken was during Bristol Pride!

Link: https://earth.google.com/web/search/52%c2%b013%2747.4%22N+0%c2%b028%2715.4%22W/@51.45072737,-2.59511422,10.26995062a,367.21371602d,35y,0h,0t,0r/data=Cj4iJgokCYZBTcAdKUpAEVCfPOB9zklAGSzxY6OX8eU_IYzngvU-6fi_KhAIARIKMjAxMy0wNy0xMxgBQgIIAToDCgEwQgIIAEoNCP___________wEQAA

Super weird that for the past year+ you just can't transit TCP connections for port 646 (IE: ldp) towards AS6939/Hurricane Electric

Are they patching over some horrible bug in their stack? I mean I don't think anyone is doing multihop LDP, but it's still _weird_ for a carrier to ACL off a TCP/UDP port

Reminds me of the days (maybe still) of Virgin Media dropping all SMB connections at the edge

Even after the bombs hit and there are no humans left, there will be two things that live on:

1) Some perl scripts on running crontab

2) Updates to the Google Cloud Third-Party Subprocessors list

someone posted this to the drum and bass subreddit and it's unreasonably cool and I have to share

pretty sick dnb track, made in LSDJ, on an actual gameboy! https://www.youtube.com/watch?v=dFiwCy4cLu8

Friend sent this to me earlier,

Yell not into the abyss, lest you become recognised as an abyss domain expert, and they expect you keep yelling into the damn thing

(The old tweet)

In the continuing tradition of "everything is AI", Apparently DDoS attacks smarter than a cURL in a while(true){} loop is now AI according to this Nokia slide deck

The idea that botnets are a 2020 thing is a insane assertion to put on a slide deck that is trying to sell people who have DDoS problems mitigation appliances.

There is a conundrum with these kinds of talks, because they are almost always conference sponsor talks. I feel a weird obligation to not call out the insane stuff in their slides, but also. This is such a warped reality being presented. gah.

boost to scare nearby SDI video transcoders

CCC / #38C3 goers, Help the schedule team figure out what talks should not clash with each other by tagging (and pressing submit) the talks you would go to if you could: https://halfnarp.events.ccc.de/

(boots ok etc)

At some point I do feel a little sorry for the Iridium Satellite Network, it seems to be the punching bag of security research.

On the other hand, it is the most accessible and... vintage/accessible tech

I have a better thermal camera for a few days, one of the infiray sensors that does not have the 9hz ITAR limits!

Little USB-C thing, and only requires a little bit of messing with to give some kind of output in Linux.

sudo rmmod uvcvideo
sudo modprobe uvcvideo quirks=0x02

Is needed, and then the UVC interface "works" (obviously without any of the post processing that is offered by the smart phone apps)

near 30FPS thermal performance is soooo nice, the extra resolution also is welcome

Hmmmm. "cool" feature of some IX's combined with some IX participants.

First, find a IX address that is not in use:

root@linx-ns:~# ping 195.66.231.230
PING 195.66.231.230 (195.66.231.230) 56(84) bytes of data.
^C
--- 195.66.231.230 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

Then hard set it's neighbour mac address to something that is not on the IXP

root@linx-ns:~# ip neigh replace 195.66.231.230 lladdr de:ad:ad:dd:dd:dd dev enp129s0f0.700

Then set a destination route to go via the mac-address-that-does-not-exist

root@linx-ns:~# ip route add 9.9.9.9/32 via 195.66.231.230

and then ping it

root@linx-ns:~# ping 9.9.9.9
PING 9.9.9.9 (9.9.9.9) 56(84) bytes of data.
From 195.66.226.119: icmp_seq=1 Redirect Host(New nexthop: 195.66.225.238)
64 bytes from 9.9.9.9: icmp_seq=1 ttl=63 time=0.720 ms
64 bytes from 9.9.9.9: icmp_seq=1 ttl=63 time=0.756 ms (DUP!)
64 bytes from 9.9.9.9: icmp_seq=1 ttl=63 time=1.47 ms (DUP!)
^C
--- 9.9.9.9 ping statistics ---
1 packets transmitted, 1 received, +2 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.720/0.981/1.468/0.344 ms

Cool right??

What is happening here is nuts on many different levels. To start, the non existent MAC address forces this IX (LINX) to treat any packets send to as "BUM" traffic, LINX could have prevented this by using static MAC like quite a lot of the other big ones do.

That however does not explain why we got ping responses... It turns out some routers on the peering LAN don't check if the destination MAC address for a packet is their own before forwarding the traffic! in this case 3 different LINX member routers saw my unknown unicast packet and was like "sure, why not, I'll route that!", and the packet routed all the way through to 9.9.9.9, and a response came back to me.

Mental!