DDoS is an abbreviation for "Distributed Denial of Service". It is a label given to what happens when a "rouge actor" sets up a system where a large number of computers "hammers" a service with incessant networking, and the service gets bogged down so that it fails to provide service.

That is what git.devuan.org is suffering of; a constant such hammering is happening that is a magnitude or more larger than how it was just a year ago.

The Anubis front-end feature makes it possible for git.devuan.org to provide service.

Your input is without value unless you can provide an alternative solution.

"Brought no result" is perhaps not too expressive.

Does this mean that you copied the ISO file onto the device as suggested? Could you please show the exact command you used when doing that?

Did you try booting in legacy mode as well as UEFI, and in both cases the console display stayed off?

It is quite peculiar (and unusual) that your system has such a hard time booting. You never told which CPU it is. And the machine assembly as a whole, is that a certain "brand" or is it your own assembly? What's the brand of the USB stick?

Thanks. Peculiar. Which brand of computer is it? I mean, which hardware, especially which CPU.

How did you copy the Devuan installer image to the USB stick?

What does "and loads" mean?

Is "secure boot" is turned off?

mmm a bit peculiar how you identify with the browser

Perhaps you have a good alternative of a means to stop the DDoS attacks from spiders and AI? It's a delicate balance to allowing such people that identify with their browsers whilst disallowing bot traffic.

Thanks @igorzwx.

Your technical prowess is quite impressive. Though I'd say your attitude and due respect for colleagues and present audience has significant room for improvement.

Last millennium we talked like this:
https://en.wikipedia.org/wiki/Control-Alt-Delete

please use code tag.

Right. One reason for that kind of effect is when different devices happen to share macaddress. But, does your latop invent new macaddress when it reboots? (I know that some people regard macaddresses to be part of the user's "online fingerprint" and therefore invent obfuscations that involve changing macaddress especially of their uplink interfaces)

Did you check whether arp messages are received on the laptop (from any problem device)? As you probably know the IP level messaging (such as icmp) involves prior "arp" messaging where devices "learn" the relationships between IP addresses and MAC addresses. The ping requestor and responder both need to fill their arp tables with such associations, though separately and individually, before being able to send their icmp messages.

If there is holdup at that level (or any kind of interference by the router in that messaging) then the effect is the one typically voiced as "machine A cannot ping machine B".

In the phone+frame cases you can only check the arp messaging on the laptop, and then focus on arp requests (about the laptop IP) from those devices. The laptop should receive them and should reply to them. Receiving and not replying puts the problem firmly at the laptop, whereas "not receiving" as well as "receiving and replying" puts the problem back onto the network.

ok. I believe netbsd uses pf (maybe short for packet filter?) for firewalling... it's the same as iptables but totally different In particular, its commands are different, and as I remember pf are set up in a certain order, and the later rules override the earlier ones.

I'll have to browse a bit to be able to say things about it. However, it looks to me like the server (192.168.1.4) has firewall rules that blocks its traffic to the laptop (192.168.1.17). Unless it has some kernel flag(s) to stop it responding to icmp requests. I would guess netbsd has different commands for sysctl too(?)

no that's not ping reqeust or response; that's ssh packets. Try using

tcpdump -n -i wlan0 icmp

to focus on icmp packets only. And please copy the exact responses rather than "like this" copying.

By this it indicates that the ping requests don't arrive at the server.

How about ping -n 9.9.9.9 from the laptop; does that get proper response? This test is only for verifying that packets from the laptop can go to and from the router. If that is the case, you will need to reconsider the router configuration.

Presumably it does have some isolation between LAN devices or device groups.

As you may know all (almost) network messaging comes in pairs with outbound packets getting inbound responses. I use tcpdump to look at that to show what happens on an interface, like:

tcpdump -n -i wlan0

to see packets in to and out from wlan0 without attempting "reverse dns" on them (i.e. see IP addresses rather than domain names).

You do that in one terminal while using an other terminal for trying things like ping. The best is if you can do the same on the target host, to see where the messages hold-up may be. Note that for ipv4 it is essential that "arp" messaging move freely; the hosts use that so as to learn the ethernet addresses of LAN devices. All networking is carried by the link-level LAN connectivity, which uses the ethernet addresses or broadcasts (i.e. address ff:ff:ff:ff:ff:ff plus the broadcast flag bit set). 

In your case, I do suspect your router. I think that most routers have "broadcast groups" where they only forward broadcast messages to interfaces within the group of the interface where the messages come in. Which router do you have -- brand and version "number"? (with that we can probably find its instruction book on the Internet)

Routers may also have limitations on number of connected devices.