New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Feedback: you really need to fix this. We need IPv6. It's free and it's the future. IPv4 is getting more and more expensive every year, being held by corporations for profits in artificial shortage.
If the operating system is read-only, and it can't be accessed remotely for security reasons (respect for this), how can it be upgraded to the latest open-source software which gets released? I am guessing it has some kind of microSD card which is overwritten manually by the "sysadmin" volunteer?
Don't get me wrong, I highly appreciate you for designing this. There needs to be some initiative in open-source area for better and safer internet and so far you seem to have the balls for it. Congratulations! But I also wonder what makes this device tick and how others can get involved in designing something that could also work (this is the nice part of brainstorming). Since this is similar to a Raspberry Pi, then a Pi Zero could also do it with a small microSD and your open-source operating system installed on it as read-only. Problem would be the WiFi slowing things down... I'm thinking.
I know, but we are limited in resources and ipv6 adds too many edge-cases and problems. So we need to set priorities, and obviously ipv4 has priority due to market share. And doing things in parallel with no resources only results in dilution and even more problems.
So once all the tools are built, sites designed, docs written and everyone is happy we can create an epic and completely dedicate ourselves to 100% support of Ipv6.
Check out the firmware specific docs here https://github.com/jsdelivr/globalping-hwprobe
Under normal operation there is no need to update the firmware, but it is possible by flashing the SD card. The probe software itself runs in RAM. Its a Docker container that gets pulled during startup, and additionally after startup all probes, software and hardware, can upgrade instantly to latest version by pulling the latest GitHub release.
Its all open source as well.
If you want to run it on a Pi, all you have to do is install any kind of Pi OS and Docker. Then just run the container as normal, its a multi-arch container and will work on ARM CPUs by default
edit: PM me if you need help with anything
NICE
Awesome project. Basically to upgrade and pull the latest Docker image it just needs a simple reboot. One can simply add a smart plug behind it, and set it to cut power and reboot automatically once a month for peace of mind in pulling the latest image.
I am not a fan of docker myself; I actually hate it; but with this it seems somewhat useful. Another option would have been a recompile from scratch for more transparency, but i guess that would have caused quite some unnecessary overhead for such a low-end project to keep it under low-power. Good job mate.
As early as 2012, I built socket-based software that only knows IPv6.
It's possible to use it with IPv4, via kernel's "IPv4 mapped IPv6 addresses" feature.
Hence, "market share" is not a valid excuse.
It's not just about making connections, it's also about parsing of input and output, probes grouping, new edge cases, and more...
So it makes a lot of sense to start with something simpler and easier to implement, make it stable and fully featured and worry about less popular protocols later. Otherwise the project could enter development hell and die there.
Don't forget that this is an open source project with minimal resources, we're not Google or a VC funded startup to just hire a dedicated ipv6 team.
I am against releasing half broken features just to tick a box that we support something. It will either be 100% ipv6 support or nothing at all.
I guess let's agree to disagree for now
I have filled the form althrough I keep my opinion I just dare to try it
so your "IPv4 team" does not have knowledge about IPv6??
very concerning, since that means of limited networking knowledge and your whole product is based on networking related stuff.
Good luck when you run into a IPv6 only network.
I hope my identity will be safe
@xms thats not what I said. If I had the money I would build multiple dev teams working on different parts of the system. There are no resources to do that, so stability and new features will take priority until we're ready to switch to ipv6 as a team.
The more I think about it the more problems come to mind. e.g. geo detection, we rely on 3 geoip DBs with voting logic and an extra "smart" algorithm to come soon. geoip DBs are awful for ipv6, they barely work for ipv4.
Next we need to make sure that every single part of the system (API, WS server, software probes, hardware probes, every single test type) can correctly work with ipv6 without regression to ipv4 features.
Next we use IPs as unique IDs, if the system scales to 10k probes how do we index them when there is a mix of v4 and v6 IPs?
How do ARM devices handle ipv6? What about docker? What about different docker network types?
This is just an example of how many components would have to be considered when thinking about ipv6. It's not as simple as understanding how ipv6 works or making linux work with ipv6. I am trying to build a reliable production system that can scale to thousands of users and thousands of probes serving all kind of use-cases.
That's why I am trying to explain this would have to be a separate big epic where we would have to 100% dedicate ourselves to go through every single part of the system and ensure complete compatibility. Including writing a bunch of tests for every single edge-case imaginable.
You mean the post address? Of course, especially since I am in Poland and GDPR is a serious thing here. I hope you will keep my identity safe as well, as it will be on the package
No information you provide will ever be used for anything else.
An additional note, the post office returned packages destined to Bolivia saying they can no longer deliver there.
Can somebody explain what this is. i read up on it but still dont understand what this is. It does ping, traceroute etc. but cant I do the same using my PC or VPS?
Why do you need a hardware for that? May be I missing something.
It allows you to do ping, traceroute, mtr, curl... from other locations basically, not just your PC. So if you need to decide what CDN to use you could do traceroutes from different countries and cities around the world to decide which one performs best for your users.
The hardware is not to do pings, it's to allow others to do pings from your location. The community comes together to help each other to build this global network that everyone benefits from.
Thats the simple explanation
Well, we want fame and glory: a leaderboard of everyone running a probe, along with how many measurements have been completed on their probes.
RIPE ATLAS and ArchiveTeam have them, but Globalping doesn't.
That will come too
It will be part of the new jsDelivr dashboard. People will be able to "adopt" software and hardware probes by proving ownership and then get points and achievements.
Please be patient, there is a lot yet to build!
Nice
It's cool. Want to try.
Seems like this would open things up to supply chain attacks... If the Docker image gets compromised then all the devices could become a giant botnet
Having a way to view the release notes before upgrading, and the hash of the commit used, would be useful.
In theory a simple restart should pull latest version of Docker image. In practice this might be used as a huge botnet, or as a huge VPN network used to bypass GFW.
However, I must admit, with it's open-source aspect it does seem quite interesting.
The container is also public https://github.com/jsdelivr/globalping-probe/pkgs/container/globalping-probe with every part of the system open sourced. The jsDelivr GitHub organization also has 2FA enforced for all members and I am the only one who can push to production.
So a hacker pushing a bad container should be impossible, immediately visible and easily revertible.
And again, it's just too much work for someone to do in the open where everyone can review everything. Just to get access to a few low-powered devices when there are better targets like literally any smart device produced in China. I highly doubt the factories take security as seriously as we do, you might not even need to hack them, just pay them to include your "monetization" code in the firmware they ship.
but how do we prove that the devices are downloading from the public repo rather than some private one, unless we can flash the firmware ourselves? 👀
I'm just playing devil's advocate; I'm not too worried about this device.
A bit late, but I do exactly this. I have a separate VLAN for IoT devices on my wireless network.
On that note, my switch is fully managed so if I win the port is 1000% going to be tagged to that VLAN.
This is so awesome!
Is the ID public? Should the ID be the same all the time?
How about generating a UUID based on some internal hardware id (mac address) or just generate a random UUID when booting.
Hmm, I guess you cant prove it easily on the firmware level. But at this point its probably a question of trust. If you trust me to send you a clean device then just use it, and if you dont then compile the firmware yourself and flash it to the card after you get the device
On the probe software level it should be a lot simpler, since the current code pulls from the public repo, to switch to a private 'malicious' repo there would have to be at least 1 last public release that makes the switch. Which of course would immediately undermine the project.
We dont have any public IDs. They're only used internally, and we use IPs because the whole system is ephemeral. The probe dont register, they just connect and disconnect as they please.
But as always that was just an example, it's fixable of course, just requires time and tests. My point was that its not a networking task but a dev task to ensure every single line of code can handle ipv6 related data.
I LOVE PROBES
It would be really cool if people that got their probes would post here some pics!
Feel free show off your home network labs, no matter how low-end they are
short question here. does globalping probes also work behind NAT or it needs a dedicated IPv4 address?
It will work behind NAT. No incoming connections are allowed so no need for dedicated IP.
how about if my isp blocks outgoing icmp on the nat ipv4 ?