Network RA injection, Networking, GDPR, PDE

• Made some RA injection tests and those worked just as expected. Next I'll try those on networks where you should honestly assume those would be properly filtered out. But let's see if this is the situation, or not. Sure, I'm using really short router lifetime so the info gets flushed quickly if I notice that the filtration isn't working as it's supposed. It's fun to follow network router solicitation messages flowing in, after injecting a few RA packets. I've tried several open and cafe and other WiFi networks, and every time when there's no existing IPv6 present (as usual), my injection has worked so far. Except for situations like large shopping centers and so on, where they do have competent out sourced wifi management. But any random small business with guest WiFi (WLAN), it's almost guaranteed to work. Then you can start observing traffic for popular sites providing IPv6 like Facebook, Google, and so on. I've got one network in mind which I want to check out. It's something where you should safely assume they're filtering the traffic, but I'm bit suspicious, because the network already leaks ARP requests for lots of IP addresses. So I'll do really short injection test with that network. Let's see what happens. If you want to make this fun, you could just inject the RA packet once a week, with spoofed MAC and of course without making DHCPv4 quest, so depending on their logging level / details, it could be really hard for them to know what the source is. Because they can't connect the MAC to DHCP logs. In a way, it would be interesting to see how long it would take them to find out where the packets are coming from. Single packet, once a week at random time, with unlimited valid and preferred lifetime of infinity and turning DeprecatePrefix off. Turning off the ling layer address, so that won't leak within the RA packets. How about sticking pi zero in full network cabinet with this config? If the network isn't authenticated using 802.1X it would be nearly impossible to locate these devices. Of course MAC addresses are snooped from existing network traffic and spoofed based on existing MACs and other little fun. If net network isn't small, it could be interesting to see, how long it takes before they figure out what's even happening, why they're seeing strange IPv6 addresses on their network, what's the source and where it is. For average network admin, this would be quite a challenge. - Done, only got about 4 router solicitation. So in that sense it didn't work, or if it did, I didn't see the solicitation so fail.
• Previous statement just reminded me that network issues are sometimes really challenging. We still don't have any clue why some parts of one network seem to fail at times. We know that something is very wrong, but don't know what, why and where. People debugging the issue haven't used analytical straddling approach. They just tried everything in random. So there's no hard data or knowledge when the problem exists and if any of the things tried, really changed anything. There are several people working on the issue, without consistent logging and so on. So it's mostly waste of time. I've heard what they've suggested to be done next, but as far as I know, those are way off guesses. Like replacing server disks, because there are issues with HTTP / SMB / Samba. Those are just poor troubleshooting guesses afaik. I would focus on the network itself, because it's clear there are issues. Not server disks, nor software. (This is related to the issues I've discussed under Clonezilla before.) There was so much disinformation from the team, that it even mislead me. They claimed it's GPT failing, when it's actually the network failing with storing / reading the image file. I just hated, that they didn't start with the obvious. Running the images on local sata or usb external disk. But instead claiming the software being faulty. One claim is that there isn't anything wrong with the network, because TFTP works. Well well, TFTP is quite different from those protocols running on TCP.
• Helped a friend to check a website, that how it functions according GDPR rules. How to prune data from backups, how long to retain backups, logs. Check all database tables, and allow easy deletion / unlinking when required and so on. This was quite an effort, but and took several days of discussions and checking table structures and data. But now I think it's pretty good.
• Something different: Pulse Detonation Engine (PDE) and Low-Boom Flight Demonstration @ NASA.

2019-08-18