Git Product home page Git Product logo

globalping-hwprobe's Introduction

jsDelivr - Open Source CDN

jsdelivr-logo
A global super-fast and production-focused CDN, tightly integrated with NPM and GitHub
with support for on-the-fly optimizations, ES modules, detailed download stats and more

www.jsdelivr.com

Website Repo · Public API · Blog · @jsDelivr · Discord


We are looking for contributors. Please check open issues in the above repos if you think you could help, or open a new one if you have an idea you'd like to discuss.

jsDelivr is a free CDN for open-source files. We are tightly integrated with Github and npm, allowing us to automatically provide a reliable CDN service to almost every open-source project out there.

We offer a stable CDN that can be used in production on popular websites with huge amounts of traffic. There are no bandwidth limits or premium features, and it's completely free to use.

Why jsDelivr?

Ready for production

Our public CDN is built to be used in production by even the largest websites. Everything is optimized and constantly improved to offer all users maximum speed and uptime. Performance is monitored at all times, and we are always looking into new technologies and providers that may further improve our CDN. Downtime, timeouts, or slow responses are simply unacceptable.

We do everything possible to ensure our CDN will NEVER break any websites, regardless of the use case. If a file is available via our CDN, we assume it's used in production and ensure it will continue to work no matter what.

This includes dynamic endpoints such as /npm/, /gh/ and /combine/. When a file is first accessed, it gets permanently stored in a reliable file system. This means that even if a npm package gets deleted or an existing file gets removed by a developer, jsDelivr will continue to serve the stored copy forever without breaking any websites or causing any issues.

On top of that, we also do version fallback. This means that if a file used in version 1.0.1 is no longer available in 1.0.2 and a user requests the non-existent file, we will fall back to the previous 1.0.1 version and serve it instead of failing with a 404 error.

Multi-CDN

Unlike the competition, jsDelivr uses multiple CDN providers, resulting in the best possible uptime and performance. We currently use CloudFlare, and Fastly.

If a CDN goes down, websites that use jsDelivr won't have any issues because all traffic will be instantly redirected to remaining operational providers.

Smart Load Balancing

jsDelivr uses real user performance data (also known as RUM) to make its routing decisions. These metrics are gathered from hundreds of websites and are used in our load-balancing algorithm to make accurate decisions for serving content.

All providers (CDNs and custom servers) are tested millions of times per day by real users from all over the world. Based on this information, jsDelivr knows what provider is the fastest for each user. Each user gets a unique response based on his or her location, ISP, and the providers' uptime in real-time.

This system also responds immediately to performance degradation and downtime of providers. If a CDN is under a DDoS attack, and its performance drops in some locations, in a matter of seconds, the algorithm will pick up the change and start serving a different provider to all affected users.

Failover

We have multiple layers of failover to protect our users from any downtime.

We use 2 DNS providers at the same time. For jsDelivr to go down, both of these companies would have to go down at the same time.

Both of our DNS providers monitor our load-balanced endpoint, and if they detect problems, they will automatically switch all traffic to a single CDN provider.

Our load balancer monitors the uptime of all CDN providers using both RUM and synthetic data. If any of those detect downtime or performance degradation, that CDN provider will be removed immediately without any impact on our users.

Our origin consists of multiple servers in different data centers. If a server goes down, the CDNs will automatically switch to using the remaining healthy servers.

In total, we have one of the most resilient systems out there, ready to be used in production by even the biggest companies.

China

jsDelivr has multiple locations close to Chinese urban centers to ensure low latency and high performance for all Chinese users.

Usage Documentation

jsDelivr provides mirrors for npm, GitHub, WordPress plugins, and custom endpoints for several other projects with special requirements. If our regular endpoints don't work for your use case, let us know and we'll figure something out!

If you are a package author, check our tips for package authors to make using your package as easy as possible.

Root endpoint is always https://cdn.jsdelivr.net

npm

jsDelivr can instantly serve any file from any npm package in the public registry. New versions pushed to npm are instantly available via our CDN as well. No maintenance is required.

If a package, version, or file gets removed from npm, then jsDelivr will continue to serve that file from our permanent storage without breaking any websites using it.

We use a permanent S3 storage to ensure all files remain available even if npm goes down or a package is deleted by its author. Files are fetched directly from npm only the first time or when S3 goes down.

Load any project hosted on npm:
/npm/package@version/file
Load exact version:
/npm/[email protected]/dist/jquery.min.js
Use a version range instead of an exact version:
/npm/jquery@3/dist/jquery.min.js
/npm/[email protected]/dist/jquery.min.js

NOTE

If you use this feature and a file you requested is not available in the newest version of the package, the link will keep working thanks to our version-fallback feature. We'll continue to serve the file from the older version of the package instead of failing with a 404 error.


Load by tag (Not recommended for production usage):
/npm/jquery@beta/dist/jquery.min.js
Omit the version completely or use "latest" to load the latest one (not recommended for production usage):
/npm/jquery@latest/dist/jquery.min.js
/npm/jquery/dist/jquery.min.js

NOTE Requesting the latest version (as opposed to "latest major" or "latest minor") is dangerous because major versions usually come with breaking changes. Only do this if you really know what you are doing.


Add ".min" to any JS/CSS/SVG file to get a minified version - if one doesn't exist, we'll generate it for you. All generated files come with source maps and can be easily used during development:
/npm/[email protected]/github-markdown.min.css

NOTE Minifying a large file can take several seconds. However, we store all generated files in our permanent storage, so this delay only applies to the first few requests.


Omit the file path to get the default file. This file is always minified:
/npm/[email protected]
/npm/jquery@3
/npm/jquery
Get a directory listing:

GitHub

We recommend using npm for projects that support it for better UX - npm packages are searchable on our website, and package pages show additional useful information, such as descriptions and links to homepages.

We use a permanent S3 storage to ensure all files remain available even if GitHub goes down or a repository or a release is deleted by its author. Files are fetched directly from GitHub only the first time or when S3 goes down.

Load any GitHub release, commit, or branch:
/gh/user/repo@version/file
Load exact version:
/gh/jquery/[email protected]/dist/jquery.min.js
/gh/jquery/jquery@32b00373b3f42e5cdcb709df53f3b08b7184a944/dist/jquery.min.js
Use a version range instead of an exact version (only works with valid semver versions):
/gh/jquery/jquery@3/dist/jquery.min.js
/gh/jquery/[email protected]/dist/jquery.min.js

NOTE If you use this feature and a file you requested is not available in the newest release, the link will keep working thanks to our version-fallback feature. We'll continue to serve the file from older release instead of failing with a 404 error.


Omit the version completely or use "latest" to load the latest one (only works with valid semver versions): (not recommended for production usage)

Falls back to the master branch if there are no tagged releases.

/gh/jquery/jquery@latest/dist/jquery.min.js
/gh/jquery/jquery/dist/jquery.min.js

NOTE Requesting the latest version (as opposed to "latest major" or "latest minor") is dangerous because major versions usually come with breaking changes. Only do this if you really know what you are doing.


Add ".min" to any JS/CSS/SVG file to get a minified version - if one doesn't exist, we'll generate it for you. All generated files come with source maps and can be easily used during development:
/gh/jquery/[email protected]/src/core.min.js

NOTE Minifying a large file can take several seconds. However, we store all generated files in our permanent storage, so this delay only applies to the first few requests.


Get a directory listing:
/gh/jquery/[email protected]/
/gh/jquery/[email protected]/dist/

Combine multiple files

Our combine endpoint allows you to load several files from npm and GitHub endpoints in one request:

/combine/url1,url2,url3

All features that work for individual files (version ranges, minification, main modules) work here as well. All combined files come with source maps and can be easily used during development.

Examples:

/combine/gh/jquery/[email protected]/dist/jquery.min.js,gh/twbs/[email protected]/dist/js/bootstrap.min.js
/combine/npm/[email protected]/dist/css/bootstrap.min.css,npm/[email protected]/dist/css/bootstrap-theme.min.css

NOTE Combining large/many files can take several seconds. However, we store all generated files in our permanent storage, so this delay only applies to the first few requests.


Publishing packages

All packages hosted on npm and tagged releases on GitHub are automatically available on jsDelivr. If you are a package author, here are a few tips to make using your package as easy as possible:

  • Use semver for versioning (this is enforced by npm but not by GitHub)
  • If a file listed as main in package.json isn't meant to be used in a browser, set a browser or jsdelivr field
  • If you distribute minified JS/CSS files, also include source maps for those files
  • If you don't want to provide minified files, it's fine - we'll handle that for you

Configuring a default file in package.json

For packages hosted on npm, we support serving "default" files with shorter URLs. The default file can be configured by setting one of the following fields in package.json, with jsdelivr having the highest priority:

  1. jsdelivr
  2. browser
  3. main

We will first attempt to locate a minified version of the file provided here (by removing the extension and looking for the same file .min.js). If we can't find one, we will minify ourselves.

Be advised that you must include the file extension in the values, for example:

"main": "./index" // this will NOT work
"main": "./index.js" // this is the correct way

For projects having both a JS and a CSS file, use one the above fields for JS and a style field for the CSS file (example).

Restrictions

  • Packages larger than 150 MB or single files larger than 20 MB (in the case of GitHub) are not supported by default. We recommend removing files that are not needed from your package when possible. If you need to set a higher limit for your package, open an issue in this repo.
  • HTML files are served with Content-Type: text/plain for security reasons.

WordPress

Our WordPress endpoint works for plugins and themes hosted in the WordPress.org plugin directory and Wordpress.org theme directory, and mirrors the WordPress.org plugins SVN repo.

Load any plugin from the WordPress.org plugins SVN repo:
/wp/project/tags/version/file
Load exact version:
/wp/wp-slimstat/tags/4.6.5/wp-slimstat.js
Load the latest version (not recommended for production usage):
/wp/wp-slimstat/trunk/wp-slimstat.js
Load any theme from the WordPress.org themes SVN repo:
https://cdn.jsdelivr.net/wp/themes/project/version/file
Load an exact version of a file:
https://cdn.jsdelivr.net/wp/themes/twenty-eightteen/1.7/assets/js/html5.js
Add ".min" to any JS/CSS file to get a minified version - if one doesn't exist, we'll generate it for you. All generated files come with source maps and can be easily used during development:
https://cdn.jsdelivr.net/wp/themes/twenty-eightteen/1.7/assets/js/html5.min.js

Caching

Our caching logic and headers are optimized for production use and apply to all non-custom endpoints.

  • Static Versions and commit hashes - Effectively forever. The caching headers are set for 1 year but we also permanently cache the files in our S3 storage. So all future requests that bypass the CDN will hit our S3 storage with no option or way to update the contents of that file.
  • Version aliasing - 7 days. This also includes latest versions. They are cached on our CDN for 7 days with the option to purge the cache using our API to speed up the release of your project to your users.
  • Branches - 12 hours.

In certain cases, purgeable files can get updated faster due to low-cache hit ratio or forced CDN purge from our side for maintenance reasons.

We use permanent S3 caching even with dynamic URLs, such as version aliasing, meaning once we download your tagged files, there is no way for you to update them. If there is a critical issue in your latest release the best course of action is to tag a new semver valid release with the fix and purge the CDN URLs using our purge API.

Purge cache

jsDelivr has an easy-to-use API to purge files from the cache and force the files to update. This is useful when you release a new version and want to force the update of all version-aliased users.

Please note:

  • It will not work for static files as explained above.
  • Valid semver releases must be used for purge to work
  • Rate-limiting applies to all users

To avoid abuse, access to purge is given after an email request (for now - [email protected]).

Custom CDN Hosting

We can work together and set up a custom configuration for your project. This way, you can have full control over your files and the ability to utilize the full power of jsDelivr.

This kind of custom hosting can be suitable for:

  • Binary hosting. Windows executable files and zips.
  • Frequently updated files.
  • Projects that can't follow jsDelivr file structure.
  • Some other use that will blow all of our minds.

Simply send an email to [email protected] with a request for more information.

Current OSS projects using custom configs:

Privacy Policy

cdn.jsdelivr.net

jsDelivr might use information about downloaded files to build download stats per project and per file.

jsDelivr does not store any user data and does not track any users in any way.

Here are the relevant policies of our CDN providers:

globalping-hwprobe's People

Contributors

jimaek avatar kernelgurumeditation avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

globalping-hwprobe's Issues

Update container

We need the firmware to update the container without user interaction as it happens now. We need to find the most optimal way to do so.
Something to consider:

  • People dont like slow boots. So pulling the container on boot is probably not the best idea.
  • At some point the old container will stop working completely
  • SD Cards suck and we need to protect them
  • The device can lose power at any moment. This should never lead to corruption.

Can the firmware cache the docker container on card and then update it on a schedule? e.g.

  1. We compile the firmware with probe version 0.25.0, the device boots and starts the container.
  2. The old pre-baked container will update the code inside itself and start the probe. The container at this point is based on 0.25.0 but runs latest code v0.35.0
  3. The probe is online and works
  4. A parallel cron/schedule runs docker pull ghcr.io/jsdelivr/globalping-probe once per day and permanently writes it to the SD card. Only if there are changes.
  5. Scheduled reboot happens after 5 days.
  6. The firmware now boots the cached container from last pull, and not the one it came with. (the original container should probably be replaced completely. We dont need to store multiple versions of it. BUT need to handle cases when the probe reboots during container update)

restarts every 30 min or less

          Hey, the restarts are normal and they are there for security and stability reasons. The SSH connection is only there for rarely debugging, so no need to monitor it constantly.

Originally posted by @jimaek in #12 (comment)

Is it possible to change that behaviour through settings?
Is it normal that the restarts happening every 30 minutes, this arent the weekly updates/restarts.

how to check if hw-probe is working

Hi,
im using the hardware probe from my fiber internet at my home.
How can i check if my device is connected to the api and resolving requests?
I cant find any ID or something similair to check it on the web api site.

todo

  • Make the device detectable by name "globalping-probe" on LAN
  • Get IP via DHCP
  • Fallback to a DNS resolver if DHCP doesnt provide one
  • Show logs on SSH connection
  • Limit SSH port to LAN connections

restarts and connection losses

Hi,
i got my globalping device yesterday and installed it today.
Sometimes i can login with "ssh [email protected]
After some time im getting this error message:
Could not chdir to home directory /home/logs: No such file or directory
Error: No such container: globalping-probe

Also not shown on https://api.globalping.io/demo/

It needs some minutes to let me login again and shows up on the api website.

This is the "normal" output when its shown on https://api.globalping.io/demo/
Could not chdir to home directory /home/logs: No such file or directory
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
Checking for the latest version
Current version 0.10.1
Latest version 0.11.0
Start self-update process
Self-update finished
[2023-01-25 23:17:25] [INFO] [695] [general] Start probe version 0.11.0 in a production mode
[2023-01-25 23:17:26] [DEBUG] [695] [general] connection to API established

Update node.js on the existing probes

Since the existing probes don't have an automated container update mechanism (#28) and we have a similar issue with people who run the probes in VMs and don't update their docker containers, I've been exploring the option of adding an update mechanism for node.js directly into the docker container. The reason is that the node.js version used on the existing probes already reached EOL, which also prevents us from updating npm packages in our code base (since those usually stop supporting EOL versions quickly).

I have a repository hosting a modified version of the probe software, which includes this feature, with the main part being this file. It's based on a nvm script, which handles the whole process of downloading and verification.

I've also built a custom version of the FW to test this out on the HW probes. Unfortunately, while it works reliably in docker on my PC, it fails most of the time on the HW probe. I'm not 100% sure why since the failure results in a restart and loss of all logs, but my guess is that there is not enough RAM to handle the downloaded file combined with the update itself. Occasionally, though, it works - it just takes many reboots to succeed. The problem is it can often take 1 hour or more of retries, and since the update is in-memory only, it needs to happen again if the probe is shut down.

@kernelgurumeditation it would be great if you could take a look at this, verify the real cause of failures, and see if we can make any improvements/changes that would make the update work reliably (it is fine if it takes, let's say, 5 minutes after each startup). However, keep in mind that the goal is to make this work on the existing probes without user interaction, so we're limited to making changes to the update process itself; no FW changes will help here.

SSH Fingerprint changes on reboot

Hello! I had this problem, where every time I restart the probe, the SSH fingerprint changes, so I have to manually remove the old line from known_hosts to be able to connect.

also I cant select labels on issues

Detect hardware probes as such

We didn't think about it originally but its useful to know. We need a way to detect a probe as software or hardware.

I think passing an env var to the container is the best way to do that.

GP_HOST_HW=true
GP_HOST_DEVICE=v1

And need to make sure we dont forget to update the device value when we start using new hardware

7 packets transmitted, 6 received

from every other pc there are no packets dropped

[2023-06-10 13:37:48] [WARN] [696] [status-manager] ping test result don't match criterias:
{
  status: 'finished',
  resolvedAddress: '193.0.14.129',
  resolvedHostname: 'k.root-servers.net',
  timings: [
    { ttl: 57, rtt: 27 },
    { ttl: 57, rtt: 16.7 },
    { ttl: 57, rtt: 15.2 },
    { ttl: 57, rtt: 19.6 },
    { ttl: 57, rtt: 15.3 },
    { ttl: 57, rtt: 16.5 }
  ],
  stats: {
    min: 15.215,
    avg: 18.392,
    max: 26.984,
    total: 7,
    loss: 14.2857,
    rcv: 6,
    drop: 1
  },
  rawOutput: 'PING k.root-servers.net (193.0.14.129) 56(84) bytes of data.\n' +
    '64 bytes from k.root-servers.net (193.0.14.129): icmp_seq=1 ttl=57 time=27.0 ms\n' +
    '64 bytes from k.root-servers.net (193.0.14.129): icmp_seq=3 ttl=57 time=16.7 ms\n' +
    '64 bytes from k.root-servers.net (193.0.14.129): icmp_seq=4 ttl=57 time=15.2 ms\n' +
    '64 bytes from k.root-servers.net (193.0.14.129): icmp_seq=5 ttl=57 time=19.6 ms\n' +
    '64 bytes from k.root-servers.net (193.0.14.129): icmp_seq=6 ttl=57 time=15.3 ms\n' +
    '64 bytes from k.root-servers.net (193.0.14.129): icmp_seq=7 ttl=57 time=16.5 ms\n' +
    '\n' +
    '--- k.root-servers.net ping statistics ---\n' +
    '7 packets transmitted, 6 received, 14.2857% packet loss, time 1213ms\n' +
    'rtt min/avg/max/mdev = 15.215/18.392/26.984/4.101 ms'
}

Quality control ping test result is unsuccessful

[2023-07-21 14:10:31] [DEBUG] [general] 'http' request 3Yx2QcDSKzwFKhDz received.
[2023-07-21 16:31:41] [WARN] [status-manager] Quality control ping test result is unsuccessful: k.root-servers.net 14.2857% packet loss. Test pass.
[2023-07-21 17:07:09] [DEBUG] [general] 'http' request WMVQfaScKvz0dFVP received.
[2023-07-21 17:31:51] [WARN] [status-manager] Quality control ping test result is unsuccessful: ns1.registry.in 14.2857% packet loss. Test pass.
[2023-07-21 18:52:04] [WARN] [status-manager] Quality control ping test result is unsuccessful: ns1.registry.in 14.2857% packet loss. Test pass.
[2023-07-21 19:03:26] [DEBUG] [general] 'ping' request xCRY5PDyw1FRLfDI received.
[2023-07-21 19:32:16] [WARN] [status-manager] Quality control ping test result is unsuccessful: ns1.registry.in 14.2857% packet loss. Test pass.

Strange cause other devices in the same network dont have any problems pinging the domains

beta branch

Is there any beta branch to test?
I have 2 devices here so i could install one with the beta and one with the release version

Prevent SSH key changes

Every time the probe resets, its SSH key changes, which is super annoying when connecting to the logs account. Can we store the generated key on the SD card to avoid this?

Location not correct

[2023-02-03 17:46:58] [INFO] [688] [api:connect] connected from (Laakirchen, AT, EU) (lat: 47.9819 long: 13.8217)

Its not the correct location.
Its the nearest datacenter from my ISP (im using the hardware-probe from my home location)
Is there any way to change it to my exact home town?

Minor: /home/logs missing on hardware probes

Noticed /home/logs is missing when ssh'ing to the hardware probes logs account (first line after ssh command):

% ssh [email protected]
Could not chdir to home directory /home/logs: No such file or directory
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
Checking for the latest version
Current version 0.10.1
Latest version 0.11.0
Start self-update process
Self-update finished
[2023-01-13 22:32:48] [INFO] [695] [general] Start probe version 0.11.0 in a production mode
[2023-01-13 22:32:50] [DEBUG] [695] [general] connection to API established

Accessing non-container logs

I got to a state where the probe booted, started a container update, and that update failed. Connecting via SSH to get the logs was not helpful in this case because it only said Error: No such container: globalping-probe - I already found what's most likely the problem in this case, but:

  1. I can see there are some log messages like echo "Starting container update process" > /dev/tty4 in the code. Are those logs accessible in any way?
  2. If not, we can we collect the logs in one file and make that part of the SSH output?

errors after reboot

This is the output from the logs:

      _closeFrameSent: false,
      _closeMessage: <Buffer >,
      _closeTimer: null,
      _extensions: {},
      _protocol: '',
      _readyState: 2,
      _receiver: null,
      _sender: null,
      _socket: null,
      _bufferedAmount: 0,
      _isServer: false,
      _redirects: 0,
      _url: 'ws://api.globalping.io/socket.io/?version=0.14.0&EIO=4&transport=websocket',
      _req: null,
      [Symbol(kCapture)]: false
    },
    [Symbol(kType)]: 'error',
    [Symbol(kError)]: Error: getaddrinfo ENOTFOUND api.globalping.io
        at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:107:26) {
      errno: -3007,
      code: 'ENOTFOUND',
      syscall: 'getaddrinfo',
      hostname: 'api.globalping.io'
    },
    [Symbol(kMessage)]: 'getaddrinfo ENOTFOUND api.globalping.io'
  },
  context: undefined,
  type: 'TransportError'
}
Error: websocket error
    at WS.onError (file:///app/node_modules/engine.io-client/build/esm-debug/transport.js:40:37)
    at ws.onerror (file:///app/node_modules/engine.io-client/build/esm-debug/transports/websocket.js:82:37)
    at WebSocket.onError (/app/node_modules/ws/lib/event-target.js:220:18)
    at WebSocket.emit (node:events:513:28)
    at ClientRequest.<anonymous> (/app/node_modules/ws/lib/websocket.js:728:15)
    at ClientRequest.emit (node:events:513:28)
    at Socket.socketErrorListener (node:_http_client:496:9)
    at Socket.emit (node:events:513:28)
    at emitErrorNT (node:internal/streams/destroy:151:8)
    at emitErrorCloseNT (node:internal/streams/destroy:116:3)
[2021-11-20 19:39:29] [ERROR] [687] [general] connection to API failed: websocket error
{
  description: ErrorEvent {
    [Symbol(kTarget)]: WebSocket {
      _events: [Object: null prototype],
      _eventsCount: 4,
      _maxListeners: undefined,
      _binaryType: 'nodebuffer',
      _closeCode: 1006,
      _closeFrameReceived: false,
      _closeFrameSent: false,
      _closeMessage: <Buffer >,
      _closeTimer: null,
      _extensions: {},
      _protocol: '',
      _readyState: 2,
      _receiver: null,
      _sender: null,
      _socket: null,
      _bufferedAmount: 0,
      _isServer: false,
      _redirects: 0,
      _url: 'ws://api.globalping.io/socket.io/?version=0.14.0&EIO=4&transport=websocket',
      _req: null,
      [Symbol(kCapture)]: false
    },
    [Symbol(kType)]: 'error',
    [Symbol(kError)]: Error: getaddrinfo ENOTFOUND api.globalping.io
        at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:107:26) {
      errno: -3007,
      code: 'ENOTFOUND',
      syscall: 'getaddrinfo',
      hostname: 'api.globalping.io'
    },
    [Symbol(kMessage)]: 'getaddrinfo ENOTFOUND api.globalping.io'
  },
  context: undefined,
  type: 'TransportError'
}
Error: websocket error
    at WS.onError (file:///app/node_modules/engine.io-client/build/esm-debug/transport.js:40:37)
    at ws.onerror (file:///app/node_modules/engine.io-client/build/esm-debug/transports/websocket.js:82:37)
    at WebSocket.onError (/app/node_modules/ws/lib/event-target.js:220:18)
    at WebSocket.emit (node:events:513:28)
    at ClientRequest.<anonymous> (/app/node_modules/ws/lib/websocket.js:728:15)
    at ClientRequest.emit (node:events:513:28)
    at Socket.socketErrorListener (node:_http_client:496:9)
    at Socket.emit (node:events:513:28)
    at emitErrorNT (node:internal/streams/destroy:151:8)
    at emitErrorCloseNT (node:internal/streams/destroy:116:3)

ns1.registry.in 14.2857% packet loss

Ive tested it with a new pc and setup only hwprobe docker.
DNS same as all other devices and ive tested it with different dns (1.1.1.1 and 8.8.8.8).
New pc is working flawlessy and no dns package losses.
Probe still produces package losses:
[2023-08-20 09:14:19] [WARN] [status-manager] Quality control ping test result is unsuccessful: ns1.registry.in 14.2857% packet loss. Test pass.
[2023-08-20 09:34:22] [WARN] [status-manager] Quality control ping test result is unsuccessful: ns1.registry.in 14.2857% packet loss. Test pass.

          Its not something I can replicate on my probes, they pass all tests 100% of the time. So I dont think its a hardware issue.

If you want you could run a docker container probe on your PC and compare the results.

But its not even a failure, the log you sent is just a warning, you can see at the end that the probe was disconnected Test pass.

Originally posted by @jimaek in #23 (comment)

Probe not working / segfaulting

I wasn't sure where to report this, and I guess here is as good a place as any.

I've had one of the hardware probes since last year. It was working great, but now I don't see it on the Globalping site. When I ssh to logs@, it throws a segfault:

Could not chdir to home directory /home/logs: No such file or directory
unexpected fault address 0x284bf7c
fatal error: fault
[signal SIGSEGV: segmentation violation code=0x2 addr=0x284bf7c pc=0x284bf7c]

goroutine 1 [running, locked to thread]:
runtime.throw(0x1b9c5c5, 0x5)
        /usr/lib/go/src/runtime/panic.go:1117 +0x60 fp=0x329f63c sp=0x329f628 pc=0x816a78
runtime.sigpanic()
        /usr/lib/go/src/runtime/signal_unix.go:741 +0x1d0 fp=0x329f654 sp=0x329f63c pc=0x8300f8
github.com/docker/cli/vendor/k8s.io/api/apps/v1.init.0()
        /home/compiler/globalping-hwprobe/poky/build/tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/docker-ce/20.10.8-ce+gitd24c6dc5cf5e68dfb30027b2db454099566a9b9e-r0/git/src/import/.gopath/src/github.com/docker/cli/vendor/k8s.io/api/apps/v1/generated.pb.go:835 +0x4ec fp=0x329f658 sp=0x329f658 pc=0x177490c
github.com/docker/cli/vendor/k8s.io/api/apps/v1.init.0()
        /home/compiler/globalping-hwprobe/poky/build/tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/docker-ce/20.10.8-ce+gitd24c6dc5cf5e68dfb30027b2db454099566a9b9e-r0/git/src/import/.gopath/src/github.com/docker/cli/vendor/k8s.io/api/apps/v1/generated.pb.go:835 +0x4ec fp=0x329f658 sp=0x329f658 pc=0x177490c
runtime.doInit(0x2c83490)
        /usr/lib/go/src/runtime/proc.go:6292 +0x50 fp=0x329f784 sp=0x329f658 pc=0x828fec
runtime.doInit(0x2c88ab0)
        /usr/lib/go/src/runtime/proc.go:6292 +0x50 fp=0x329f8b0 sp=0x329f784 pc=0x828fec
runtime.doInit(0x2c85688)
        /usr/lib/go/src/runtime/proc.go:6292 +0x50 fp=0x329f9dc sp=0x329f8b0 pc=0x828fec
runtime.doInit(0x2c88280)
        /usr/lib/go/src/runtime/proc.go:6292 +0x50 fp=0x329fb08 sp=0x329f9dc pc=0x828fec
runtime.doInit(0x2c89d98)
        /usr/lib/go/src/runtime/proc.go:6292 +0x50 fp=0x329fc34 sp=0x329fb08 pc=0x828fec
runtime.doInit(0x2c85420)
        /usr/lib/go/src/runtime/proc.go:6292 +0x50 fp=0x329fd60 sp=0x329fc34 pc=0x828fec
runtime.doInit(0x2c85af8)
        /usr/lib/go/src/runtime/proc.go:6292 +0x50 fp=0x329fe8c sp=0x329fd60 pc=0x828fec
runtime.doInit(0x2c850b0)
        /usr/lib/go/src/runtime/proc.go:6292 +0x50 fp=0x329ffb8 sp=0x329fe8c pc=0x828fec
runtime.main()
        /usr/lib/go/src/runtime/proc.go:208 +0x278 fp=0x329ffe4 sp=0x329ffb8 pc=0x81978c
runtime.goexit()
        /usr/lib/go/src/runtime/asm_arm.s:841 +0x4 fp=0x329ffe4 sp=0x329ffe4 pc=0x84dcc0

goroutine 21 [chan receive]:
github.com/docker/cli/vendor/k8s.io/klog.(*loggingT).flushDaemon(0x2cef958)
        /home/compiler/globalping-hwprobe/poky/build/tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/docker-ce/20.10.8-ce+gitd24c6dc5cf5e68dfb30027b2db454099566a9b9e-r0/git/src/import/.gopath/src/github.com/docker/cli/vendor/k8s.io/klog/klog.go:1010 +0x70
created by github.com/docker/cli/vendor/k8s.io/klog.init.0
        /home/compiler/globalping-hwprobe/poky/build/tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/docker-ce/20.10.8-ce+gitd24c6dc5cf5e68dfb30027b2db454099566a9b9e-r0/git/src/import/.gopath/src/github.com/docker/cli/vendor/k8s.io/klog/klog.go:411 +0x13c
Connection to 10.30.2.2 closed.

Dev build flag

I currently had to build a custom FW to try out a new release of the probe software without releasing it to all users (changed the source for docker image to my repo). I'm wondering if we could have support for this in the official FW instead. E.g., if JSDELIVR-DEV.UPD file is present, pull ghcr.io/jsdelivr/globalping-probe:dev instead of ghcr.io/jsdelivr/globalping-probe:latest - security-wise, this should be fine, since it would still use the official repo, just a different tag.

v2 final testing

After everything is merged and no other features are planned need to make sure the final firmware is stable:

  1. Load it on multiple devices. From old batch and new batch for a few weeks.
  2. Build a firmware with 0.28 container and test the container update process
  3. Build a firmware with 0.29 container and test the container update process (after 0.30 is released)
  4. Monitor closely and check logs to ensure its not crashing or has update loops
  5. Ensure the weekly reboots don't break anything
  6. Ensure the sd card is protected from abuse
  7. Ensure RAM is enough to do all of the above, even if the container increases in size
  8. Measure time to start the container
  9. other?
  10. Start shipping

Hardware probe not getting correct time or updated to new version

Hi globalping team,

I recently received my hardware probe and had it running for a couple of weeks. I noticed in the API page that my probe was one of the few that were not updated to the latest version. Also, logs from ssh logs@[ip] show that it has a wrong system date, and has been consistently reporting error.

Could not chdir to home directory /home/logs: No such file or directory
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
Checking for the latest version
Current version 0.10.1
Latest version
[2021-11-19 17:22:47] [INFO] [688] [general] Start probe version 0.10.1 in a production mode
[2021-11-19 17:22:48] [DEBUG] [688] [general] connection to API established
[2021-11-19 17:22:49] [INFO] [688] [api:connect] connected from <redacted>
node:internal/process/promises:288
            triggerUncaughtException(err, true /* fromPromise */);
            ^

RequestError: certificate is not yet valid
    at ClientRequest.<anonymous> (file:///app/node_modules/got/dist/source/core/index.js:760:107)
    at Object.onceWrapper (node:events:628:26)
    at ClientRequest.emit (node:events:525:35)
    at TLSSocket.socketErrorListener (node:_http_client:481:9)
    at TLSSocket.emit (node:events:513:28)
    at emitErrorNT (node:internal/streams/destroy:151:8)
    at emitErrorCloseNT (node:internal/streams/destroy:116:3)
    at process.processTicksAndRejections (node:internal/process/task_queues:82:21)
    at TLSSocket.onConnectSecure (node:_tls_wrap:1534:34)
    at TLSSocket.emit (node:events:513:28)
    at TLSSocket._finishInit (node:_tls_wrap:948:8)
    at ssl.onhandshakedone (node:_tls_wrap:729:12) {
  input: undefined,
  code: 'CERT_NOT_YET_VALID',
  timings: {
    start: 1637343110967,
    socket: 1637343110992,
    lookup: 1637343110995,
    connect: 1637343111094,
    secureConnect: undefined,
    upload: undefined,
    response: undefined,
    end: undefined,
    error: 1637343111283,
    abort: undefined,
    phases: {
      wait: 25,
      dns: 3,
      tcp: 99,
      tls: undefined,
      request: undefined,
      firstByte: undefined,
      download: undefined,
      total: 316
    }
  },
  options: Options {
    _unixOptions: undefined,
    _internals: {
      request: undefined,
      agent: { http: undefined, https: undefined, http2: undefined },
      h2session: undefined,
      decompress: true,
      timeout: {
        connect: undefined,
        lookup: undefined,
        read: undefined,
        request: 15000,
        response: undefined,
        secureConnect: undefined,
        send: undefined,
        socket: undefined
      },
      prefixUrl: '',
      body: undefined,
      form: undefined,
      json: undefined,
      cookieJar: undefined,
      ignoreInvalidCookies: false,
      searchParams: undefined,
      dnsLookup: undefined,
      dnsCache: undefined,
      context: {},
      hooks: {
        init: [],
        beforeRequest: [],
        beforeError: [],
        beforeRedirect: [],
        beforeRetry: [],
        afterResponse: []
      },
      followRedirect: true,
      maxRedirects: 10,
      cache: undefined,
      throwHttpErrors: true,
      username: '',
      password: '',
      http2: false,
      allowGetBody: false,
      headers: {
        'user-agent': 'got (https://github.com/sindresorhus/got)',
        accept: 'application/json',
        'accept-encoding': 'gzip, deflate, br'
      },
      methodRewriting: false,
      dnsLookupIpVersion: undefined,
      parseJson: [Function: parse],
      stringifyJson: [Function: stringify],
      retry: {
        limit: 2,
        methods: [ 'GET', 'PUT', 'HEAD', 'DELETE', 'OPTIONS', 'TRACE' ],
        statusCodes: [
          408, 413, 429, 500,
          502, 503, 504, 521,
          522, 524
        ],
        errorCodes: [
          'ETIMEDOUT',
          'ECONNRESET',
          'EADDRINUSE',
          'ECONNREFUSED',
          'EPIPE',
          'ENOTFOUND',
          'ENETUNREACH',
          'EAI_AGAIN'
        ],
        maxRetryAfter: undefined,
        calculateDelay: [Function: calculateDelay],
        backoffLimit: Infinity,
        noise: 100
      },
      localAddress: undefined,
      method: 'GET',
      createConnection: undefined,
      cacheOptions: {
        shared: undefined,
        cacheHeuristic: undefined,
        immutableMinTimeToLive: undefined,
        ignoreCargoCult: undefined
      },
      https: {
        alpnProtocols: undefined,
        rejectUnauthorized: undefined,
        checkServerIdentity: undefined,
        certificateAuthority: undefined,
        key: undefined,
        certificate: undefined,
        passphrase: undefined,
        pfx: undefined,
        ciphers: undefined,
        honorCipherOrder: undefined,
        minVersion: undefined,
        maxVersion: undefined,
        signatureAlgorithms: undefined,
        tlsSessionLifetime: undefined,
        dhparam: undefined,
        ecdhCurve: undefined,
        certificateRevocationLists: undefined
      },
      encoding: undefined,
      resolveBodyOnly: false,
      isStream: false,
      responseType: 'text',
      url: <ref *1> URL {
        [Symbol(context)]: URLContext {
          flags: 400,
          scheme: 'https:',
          username: '',
          password: '',
          host: 'api.github.com',
          port: null,
          path: [
            'repos',
            'jsdelivr',
            'globalping-probe',
            'releases',
            'latest'
          ],
          query: null,
          fragment: null
        },
        [Symbol(query)]: URLSearchParams {
          [Symbol(query)]: [],
          [Symbol(context)]: [Circular *1]
        }
      },
      pagination: {
        transform: [Function: transform],
        paginate: [Function: paginate],
        filter: [Function: filter],
        shouldContinue: [Function: shouldContinue],
        countLimit: Infinity,
        backoff: 0,
        requestLimit: 10000,
        stackAllItems: false
      },
      setHost: true,
      maxHeaderSize: undefined
    },
    _merging: false,
    _init: [ { timeout: { request: 15000 } } ]
  }
}

Node.js v18.7.0
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
Checking for the latest version
Current version 0.10.1
Latest version
[2021-11-19 17:32:10] [INFO] [688] [general] Start probe version 0.10.1 in a production mode
[2021-11-19 17:32:11] [DEBUG] [688] [general] connection to API established
[2021-11-19 17:32:11] [INFO] [688] [api:connect] connected from <redacted>
node:internal/process/promises:288
            triggerUncaughtException(err, true /* fromPromise */);
            ^

... (more identical stack traces and error logs omitted)

It seems like the stack trace was also caused by the incorrect system date.

Also, I'm not sure whether the incorrect date was caused by missing NTP client or the NTP calls being blocked by the Chinese firewall.

What is the recommended action to be taken here? Thanks!

root-servers.net

Could not chdir to home directory /home/logs: No such file or directory
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
Checking for the latest version
Current version 0.14.0
Latest version 0.20.0
Start self-update process
Self-update finished
[2023-04-12 22:55:13] [INFO] [695] [general] Start probe version 0.20.0 in a production mode
[2023-04-12 22:55:14] [DEBUG] [695] [general] connection to API established
[2023-04-12 22:55:14] [INFO] [695] [api:connect] connected from (Laakirchen, AT, EU) (lat: 47.9849 long: 13.8183)
[2023-04-12 23:05:17] [WARN] [695] [status-manager] ping test result don't match criterias:
{
status: 'finished',
resolvedAddress: '199.7.83.42',
resolvedHostname: 'l.root-servers.net',
timings: [
{ ttl: 56, rtt: 37.3 },
{ ttl: 56, rtt: 30.9 },
{ ttl: 56, rtt: 31.1 },
{ ttl: 56, rtt: 30.9 },
{ ttl: 56, rtt: 30.1 },
{ ttl: 56, rtt: 34.5 }
],
stats: {
min: 30.106,
avg: 32.471,
max: 37.342,
total: 7,
loss: 14.2857,
rcv: 6,
drop: 1
},
rawOutput: 'PING l.root-servers.net (199.7.83.42) 56(84) bytes of data.\n' +
'64 bytes from l.root-servers.net (199.7.83.42): icmp_seq=1 ttl=56 time=37.3 ms\n' +
'64 bytes from l.root-servers.net (199.7.83.42): icmp_seq=3 ttl=56 time=30.9 ms\n' +
'64 bytes from l.root-servers.net (199.7.83.42): icmp_seq=4 ttl=56 time=31.1 ms\n' +
'64 bytes from l.root-servers.net (199.7.83.42): icmp_seq=5 ttl=56 time=30.9 ms\n' +
'64 bytes from l.root-servers.net (199.7.83.42): icmp_seq=6 ttl=56 time=30.1 ms\n' +
'64 bytes from l.root-servers.net (199.7.83.42): icmp_seq=7 ttl=56 time=34.5 ms\n' +
'\n' +
'--- l.root-servers.net ping statistics ---\n' +
'7 packets transmitted, 6 received, 14.2857% packet loss, time 1206ms\n' +
'rtt min/avg/max/mdev = 30.106/32.471/37.342/2.597 ms'
}
[2023-04-12 23:05:17] [WARN] [695] [status-manager] ping test result don't match criterias:
{
status: 'finished',
resolvedAddress: '193.0.14.129',
resolvedHostname: 'k.root-servers.net',
timings: [
{ ttl: 57, rtt: 18.7 },
{ ttl: 57, rtt: 14.2 },
{ ttl: 57, rtt: 14.4 },
{ ttl: 57, rtt: 14.9 },
{ ttl: 57, rtt: 15.1 },
{ ttl: 57, rtt: 15 }
],
stats: {
min: 14.189,
avg: 15.381,
max: 18.725,
total: 7,
loss: 14.2857,
rcv: 6,
drop: 1
},
rawOutput: 'PING k.root-servers.net (193.0.14.129) 56(84) bytes of data.\n' +
'64 bytes from k.root-servers.net (193.0.14.129): icmp_seq=1 ttl=57 time=18.7 ms\n' +
'64 bytes from k.root-servers.net (193.0.14.129): icmp_seq=3 ttl=57 time=14.2 ms\n' +
'64 bytes from k.root-servers.net (193.0.14.129): icmp_seq=4 ttl=57 time=14.4 ms\n' +
'64 bytes from k.root-servers.net (193.0.14.129): icmp_seq=5 ttl=57 time=14.9 ms\n' +
'64 bytes from k.root-servers.net (193.0.14.129): icmp_seq=6 ttl=57 time=15.1 ms\n' +
'64 bytes from k.root-servers.net (193.0.14.129): icmp_seq=7 ttl=57 time=15.0 ms\n' +
'\n' +
'--- k.root-servers.net ping statistics ---\n' +
'7 packets transmitted, 6 received, 14.2857% packet loss, time 1206ms\n' +
'rtt min/avg/max/mdev = 14.189/15.381/18.725/1.531 ms'
}
[2023-04-13 01:05:37] [WARN] [695] [status-manager] ping test result don't match criterias:
{
status: 'finished',
resolvedAddress: '193.0.14.129',
resolvedHostname: 'k.root-servers.net',
timings: [
{ ttl: 57, rtt: 21.5 },
{ ttl: 57, rtt: 12.8 },
{ ttl: 57, rtt: 12.7 },
{ ttl: 57, rtt: 12.6 },
{ ttl: 57, rtt: 12.8 },
{ ttl: 57, rtt: 12.9 }
],
stats: {
min: 12.609,
avg: 14.196,
max: 21.462,
total: 7,
loss: 14.2857,
rcv: 6,
drop: 1
},
rawOutput: 'PING k.root-servers.net (193.0.14.129) 56(84) bytes of data.\n' +
'64 bytes from k.root-servers.net (193.0.14.129): icmp_seq=1 ttl=57 time=21.5 ms\n' +
'64 bytes from k.root-servers.net (193.0.14.129): icmp_seq=3 ttl=57 time=12.8 ms\n' +
'64 bytes from k.root-servers.net (193.0.14.129): icmp_seq=4 ttl=57 time=12.7 ms\n' +
'64 bytes from k.root-servers.net (193.0.14.129): icmp_seq=5 ttl=57 time=12.6 ms\n' +
'64 bytes from k.root-servers.net (193.0.14.129): icmp_seq=6 ttl=57 time=12.8 ms\n' +
'64 bytes from k.root-servers.net (193.0.14.129): icmp_seq=7 ttl=57 time=12.9 ms\n' +
'\n' +
'--- k.root-servers.net ping statistics ---\n' +
'7 packets transmitted, 6 received, 14.2857% packet loss, time 1207ms\n' +
'rtt min/avg/max/mdev = 12.609/14.196/21.462/3.250 ms'
}
[2023-04-13 02:45:56] [WARN] [695] [status-manager] ping test result don't match criterias:
{
status: 'finished',
resolvedAddress: '192.58.128.30',
resolvedHostname: 'j.root-servers.net',
timings: [
{ ttl: 250, rtt: 15.2 },
{ ttl: 250, rtt: 12.9 },
{ ttl: 250, rtt: 12.4 },
{ ttl: 250, rtt: 12.6 },
{ ttl: 250, rtt: 13.6 },
{ ttl: 250, rtt: 12.4 }
],
stats: {
min: 12.428,
avg: 13.2,
max: 15.184,
total: 7,
loss: 14.2857,
rcv: 6,
drop: 1
},
rawOutput: 'PING j.root-servers.net (192.58.128.30) 56(84) bytes of data.\n' +
'64 bytes from j.root-servers.net (192.58.128.30): icmp_seq=1 ttl=250 time=15.2 ms\n' +
'64 bytes from j.root-servers.net (192.58.128.30): icmp_seq=3 ttl=250 time=12.9 ms\n' +
'64 bytes from j.root-servers.net (192.58.128.30): icmp_seq=4 ttl=250 time=12.4 ms\n' +
'64 bytes from j.root-servers.net (192.58.128.30): icmp_seq=5 ttl=250 time=12.6 ms\n' +
'64 bytes from j.root-servers.net (192.58.128.30): icmp_seq=6 ttl=250 time=13.6 ms\n' +
'64 bytes from j.root-servers.net (192.58.128.30): icmp_seq=7 ttl=250 time=12.4 ms\n' +
'\n' +
'--- j.root-servers.net ping statistics ---\n' +
'7 packets transmitted, 6 received, 14.2857% packet loss, time 1209ms\n' +
'rtt min/avg/max/mdev = 12.428/13.200/15.184/0.970 ms'
}
[2023-04-13 05:06:15] [WARN] [695] [status-manager] ping test result don't match criterias:
{
status: 'finished',
resolvedAddress: '193.0.14.129',
resolvedHostname: 'k.root-servers.net',
timings: [
{ ttl: 57, rtt: 23.6 },
{ ttl: 57, rtt: 12.9 },
{ ttl: 57, rtt: 12.6 },
{ ttl: 57, rtt: 12.8 },
{ ttl: 57, rtt: 12.8 },
{ ttl: 57, rtt: 12.5 }
],
stats: {
min: 12.542,
avg: 14.534,
max: 23.597,
total: 7,
loss: 14.2857,
rcv: 6,
drop: 1
},
rawOutput: 'PING k.root-servers.net (193.0.14.129) 56(84) bytes of data.\n' +
'64 bytes from k.root-servers.net (193.0.14.129): icmp_seq=1 ttl=57 time=23.6 ms\n' +
'64 bytes from k.root-servers.net (193.0.14.129): icmp_seq=3 ttl=57 time=12.9 ms\n' +
'64 bytes from k.root-servers.net (193.0.14.129): icmp_seq=4 ttl=57 time=12.6 ms\n' +
'64 bytes from k.root-servers.net (193.0.14.129): icmp_seq=5 ttl=57 time=12.8 ms\n' +
'64 bytes from k.root-servers.net (193.0.14.129): icmp_seq=6 ttl=57 time=12.8 ms\n' +
'64 bytes from k.root-servers.net (193.0.14.129): icmp_seq=7 ttl=57 time=12.5 ms\n' +
'\n' +
'--- k.root-servers.net ping statistics ---\n' +
'7 packets transmitted, 6 received, 14.2857% packet loss, time 1210ms\n' +
'rtt min/avg/max/mdev = 12.542/14.534/23.597/4.055 ms'
}
[2023-04-13 07:06:35] [WARN] [695] [status-manager] ping test result don't match criterias:
{
status: 'finished',
resolvedAddress: '192.58.128.30',
resolvedHostname: 'j.root-servers.net',
timings: [
{ ttl: 250, rtt: 22.7 },
{ ttl: 250, rtt: 12.1 },
{ ttl: 250, rtt: 12.1 },
{ ttl: 250, rtt: 13.1 },
{ ttl: 250, rtt: 12.7 },
{ ttl: 250, rtt: 16.2 }
],
stats: {
min: 12.078,
avg: 14.81,
max: 22.731,
total: 7,
loss: 14.2857,
rcv: 6,
drop: 1
},
rawOutput: 'PING j.root-servers.net (192.58.128.30) 56(84) bytes of data.\n' +
'64 bytes from j.root-servers.net (192.58.128.30): icmp_seq=1 ttl=250 time=22.7 ms\n' +
'64 bytes from j.root-servers.net (192.58.128.30): icmp_seq=3 ttl=250 time=12.1 ms\n' +
'64 bytes from j.root-servers.net (192.58.128.30): icmp_seq=4 ttl=250 time=12.1 ms\n' +
'64 bytes from j.root-servers.net (192.58.128.30): icmp_seq=5 ttl=250 time=13.1 ms\n' +
'64 bytes from j.root-servers.net (192.58.128.30): icmp_seq=6 ttl=250 time=12.7 ms\n' +
'64 bytes from j.root-servers.net (192.58.128.30): icmp_seq=7 ttl=250 time=16.2 ms\n' +
'\n' +
'--- j.root-servers.net ping statistics ---\n' +
'7 packets transmitted, 6 received, 14.2857% packet loss, time 1217ms\n' +
'rtt min/avg/max/mdev = 12.078/14.810/22.731/3.803 ms'
}
[2023-04-13 10:47:07] [WARN] [695] [status-manager] ping test result don't match criterias:
{
status: 'finished',
resolvedAddress: '193.0.14.129',
resolvedHostname: 'k.root-servers.net',
timings: [
{ ttl: 57, rtt: 23.4 },
{ ttl: 57, rtt: 13.1 },
{ ttl: 57, rtt: 13.6 },
{ ttl: 57, rtt: 13.5 },
{ ttl: 57, rtt: 12 },
{ ttl: 57, rtt: 13.5 }
],
stats: {
min: 12.024,
avg: 14.863,
max: 23.421,
total: 7,
loss: 14.2857,
rcv: 6,
drop: 1
},
rawOutput: 'PING k.root-servers.net (193.0.14.129) 56(84) bytes of data.\n' +
'64 bytes from k.root-servers.net (193.0.14.129): icmp_seq=1 ttl=57 time=23.4 ms\n' +
'64 bytes from k.root-servers.net (193.0.14.129): icmp_seq=3 ttl=57 time=13.1 ms\n' +
'64 bytes from k.root-servers.net (193.0.14.129): icmp_seq=4 ttl=57 time=13.6 ms\n' +
'64 bytes from k.root-servers.net (193.0.14.129): icmp_seq=5 ttl=57 time=13.5 ms\n' +
'64 bytes from k.root-servers.net (193.0.14.129): icmp_seq=6 ttl=57 time=12.0 ms\n' +
'64 bytes from k.root-servers.net (193.0.14.129): icmp_seq=7 ttl=57 time=13.5 ms\n' +
'\n' +
'--- k.root-servers.net ping statistics ---\n' +
'7 packets transmitted, 6 received, 14.2857% packet loss, time 1207ms\n' +
'rtt min/avg/max/mdev = 12.024/14.863/23.421/3.864 ms'
}
[2023-04-13 11:17:12] [WARN] [695] [status-manager] ping test result don't match criterias:
{
status: 'finished',
resolvedAddress: '192.58.128.30',
resolvedHostname: 'j.root-servers.net',
timings: [
{ ttl: 250, rtt: 21.5 },
{ ttl: 250, rtt: 16.7 },
{ ttl: 250, rtt: 18.5 },
{ ttl: 250, rtt: 17.2 },
{ ttl: 250, rtt: 16.9 },
{ ttl: 250, rtt: 12.1 }
],
stats: {
min: 12.142,
avg: 17.157,
max: 21.466,
total: 7,
loss: 14.2857,
rcv: 6,
drop: 1
},
rawOutput: 'PING j.root-servers.net (192.58.128.30) 56(84) bytes of data.\n' +
'64 bytes from j.root-servers.net (192.58.128.30): icmp_seq=1 ttl=250 time=21.5 ms\n' +
'64 bytes from j.root-servers.net (192.58.128.30): icmp_seq=3 ttl=250 time=16.7 ms\n' +
'64 bytes from j.root-servers.net (192.58.128.30): icmp_seq=4 ttl=250 time=18.5 ms\n' +
'64 bytes from j.root-servers.net (192.58.128.30): icmp_seq=5 ttl=250 time=17.2 ms\n' +
'64 bytes from j.root-servers.net (192.58.128.30): icmp_seq=6 ttl=250 time=16.9 ms\n' +
'64 bytes from j.root-servers.net (192.58.128.30): icmp_seq=7 ttl=250 time=12.1 ms\n' +
'\n' +
'--- j.root-servers.net ping statistics ---\n' +
'7 packets transmitted, 6 received, 14.2857% packet loss, time 1213ms\n' +
'rtt min/avg/max/mdev = 12.142/17.157/21.466/2.763 ms'
}
[2023-04-13 11:47:16] [WARN] [695] [status-manager] ping test result don't match criterias:
{
status: 'finished',
resolvedAddress: '192.58.128.30',
resolvedHostname: 'j.root-servers.net',
timings: [
{ ttl: 250, rtt: 16.9 },
{ ttl: 250, rtt: 15.7 },
{ ttl: 250, rtt: 15 },
{ ttl: 250, rtt: 12.8 },
{ ttl: 250, rtt: 13.6 },
{ ttl: 250, rtt: 12.8 }
],
stats: {
min: 12.75,
avg: 14.46,
max: 16.874,
total: 7,
loss: 14.2857,
rcv: 6,
drop: 1
},
rawOutput: 'PING j.root-servers.net (192.58.128.30) 56(84) bytes of data.\n' +
'64 bytes from j.root-servers.net (192.58.128.30): icmp_seq=1 ttl=250 time=16.9 ms\n' +
'64 bytes from j.root-servers.net (192.58.128.30): icmp_seq=3 ttl=250 time=15.7 ms\n' +
'64 bytes from j.root-servers.net (192.58.128.30): icmp_seq=4 ttl=250 time=15.0 ms\n' +
'64 bytes from j.root-servers.net (192.58.128.30): icmp_seq=5 ttl=250 time=12.8 ms\n' +
'64 bytes from j.root-servers.net (192.58.128.30): icmp_seq=6 ttl=250 time=13.6 ms\n' +
'64 bytes from j.root-servers.net (192.58.128.30): icmp_seq=7 ttl=250 time=12.8 ms\n' +
'\n' +
'--- j.root-servers.net ping statistics ---\n' +
'7 packets transmitted, 6 received, 14.2857% packet loss, time 1219ms\n' +
'rtt min/avg/max/mdev = 12.750/14.460/16.874/1.528 ms'
}
[2023-04-13 14:37:42] [WARN] [695] [status-manager] ping test result don't match criterias:
{
status: 'finished',
resolvedAddress: '199.7.83.42',
resolvedHostname: 'l.root-servers.net',
timings: [
{ ttl: 56, rtt: 34.2 },
{ ttl: 56, rtt: 33.8 },
{ ttl: 56, rtt: 29.2 },
{ ttl: 56, rtt: 30.1 },
{ ttl: 56, rtt: 29.1 },
{ ttl: 56, rtt: 32.6 }
],
stats: {
min: 29.116,
avg: 31.509,
max: 34.218,
total: 7,
loss: 14.2857,
rcv: 6,
drop: 1
},
rawOutput: 'PING l.root-servers.net (199.7.83.42) 56(84) bytes of data.\n' +
'64 bytes from l.root-servers.net (199.7.83.42): icmp_seq=1 ttl=56 time=34.2 ms\n' +
'64 bytes from l.root-servers.net (199.7.83.42): icmp_seq=3 ttl=56 time=33.8 ms\n' +
'64 bytes from l.root-servers.net (199.7.83.42): icmp_seq=4 ttl=56 time=29.2 ms\n' +
'64 bytes from l.root-servers.net (199.7.83.42): icmp_seq=5 ttl=56 time=30.1 ms\n' +
'64 bytes from l.root-servers.net (199.7.83.42): icmp_seq=6 ttl=56 time=29.1 ms\n' +
'64 bytes from l.root-servers.net (199.7.83.42): icmp_seq=7 ttl=56 time=32.6 ms\n' +
'\n' +
'--- l.root-servers.net ping statistics ---\n' +
'7 packets transmitted, 6 received, 14.2857% packet loss, time 1213ms\n' +
'rtt min/avg/max/mdev = 29.116/31.509/34.218/2.114 ms'
}
[2023-04-13 15:07:46] [WARN] [695] [status-manager] ping test result don't match criterias:
{
status: 'finished',
resolvedAddress: '199.7.83.42',
resolvedHostname: 'l.root-servers.net',
timings: [
{ ttl: 56, rtt: 35.7 },
{ ttl: 56, rtt: 29.2 },
{ ttl: 56, rtt: 32.2 },
{ ttl: 56, rtt: 28.9 },
{ ttl: 56, rtt: 29.1 },
{ ttl: 56, rtt: 30 }
],
stats: {
min: 28.869,
avg: 30.847,
max: 35.724,
total: 7,
loss: 14.2857,
rcv: 6,
drop: 1
},
rawOutput: 'PING l.root-servers.net (199.7.83.42) 56(84) bytes of data.\n' +
'64 bytes from l.root-servers.net (199.7.83.42): icmp_seq=1 ttl=56 time=35.7 ms\n' +
'64 bytes from l.root-servers.net (199.7.83.42): icmp_seq=3 ttl=56 time=29.2 ms\n' +
'64 bytes from l.root-servers.net (199.7.83.42): icmp_seq=4 ttl=56 time=32.2 ms\n' +
'64 bytes from l.root-servers.net (199.7.83.42): icmp_seq=5 ttl=56 time=28.9 ms\n' +
'64 bytes from l.root-servers.net (199.7.83.42): icmp_seq=6 ttl=56 time=29.1 ms\n' +
'64 bytes from l.root-servers.net (199.7.83.42): icmp_seq=7 ttl=56 time=30.0 ms\n' +
'\n' +
'--- l.root-servers.net ping statistics ---\n' +
'7 packets transmitted, 6 received, 14.2857% packet loss, time 1217ms\n' +
'rtt min/avg/max/mdev = 28.869/30.847/35.724/2.445 ms'
}
[2023-04-13 16:38:00] [WARN] [695] [status-manager] ping test result don't match criterias:
{
status: 'finished',
resolvedAddress: '193.0.14.129',
resolvedHostname: 'k.root-servers.net',
timings: [
{ ttl: 57, rtt: 22.5 },
{ ttl: 57, rtt: 13.5 },
{ ttl: 57, rtt: 13 },
{ ttl: 57, rtt: 12.3 },
{ ttl: 57, rtt: 17 },
{ ttl: 57, rtt: 17.1 }
],
stats: {
min: 12.256,
avg: 15.876,
max: 22.486,
total: 7,
loss: 14.2857,
rcv: 6,
drop: 1
},
rawOutput: 'PING k.root-servers.net (193.0.14.129) 56(84) bytes of data.\n' +
'64 bytes from k.root-servers.net (193.0.14.129): icmp_seq=1 ttl=57 time=22.5 ms\n' +
'64 bytes from k.root-servers.net (193.0.14.129): icmp_seq=3 ttl=57 time=13.5 ms\n' +
'64 bytes from k.root-servers.net (193.0.14.129): icmp_seq=4 ttl=57 time=13.0 ms\n' +
'64 bytes from k.root-servers.net (193.0.14.129): icmp_seq=5 ttl=57 time=12.3 ms\n' +
'64 bytes from k.root-servers.net (193.0.14.129): icmp_seq=6 ttl=57 time=17.0 ms\n' +
'64 bytes from k.root-servers.net (193.0.14.129): icmp_seq=7 ttl=57 time=17.1 ms\n' +
'\n' +
'--- k.root-servers.net ping statistics ---\n' +
'7 packets transmitted, 6 received, 14.2857% packet loss, time 1209ms\n' +
'rtt min/avg/max/mdev = 12.256/15.876/22.486/3.503 ms'
}

[2023-08-02 16:17:11] [WARN] [status-manager] Quality control ping test result is unsuccessful: ns1.dns.nl 14.2857% packet loss. Test pass.

hwprobe:
[2023-08-02 16:17:11] [WARN] [status-manager] Quality control ping test result is unsuccessful: ns1.dns.nl 14.2857% packet loss. Test pass.
This continues until probe gets disconnected.

from the same network and from different devices (not filtering activated) all ping commands run without any problem:

Ping-Statistik für 194.0.28.53: Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust), Ca. Zeitangaben in Millisek.: Minimum = 35ms, Maximum = 40ms, Mittelwert = 36ms

So its an hwprobe issue

Originally posted by @skapytek in #22 (comment)

Log/report firmware version

It seems we don't log the firmware version at all, so I have no idea which one my probe currently has. We should log that on startup and possibly also expose it to the API, same as #27?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.