profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/zwhitchcox/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Zane Hitchcox zwhitchcox The Line, Llc Knoxville, TN http://zanehitchcox.com

zwhitchcox/babel-preset-mobx 23

All dependencies mobx depends on

zetup-sh/zetup-pkg 3

🔥 default zetup pkg 🔥

balena-io-modules/ah-trace 0

async hooks instrumentation for telemetry data

balena-io-modules/isomorphic-ws 0

Isomorphic implementation of WebSocket (https://www.npmjs.com/package/ws)

balena-io-modules/stream-adapters 0

utilities to convert to/from node streams and WHATWG streams

zetup-sh/zetup 0

Automate Your Development Setup

zwhitchcox/acorn 0

A small, fast, JavaScript-based JavaScript parser

fork zwhitchcox/node-fetch

A light-weight module that brings the Fetch API to Node.js

fork in 14 hours

push eventzwhitchcox/sarah-codes

Zane Hitchcox

commit sha addbcc81929f30e2f1d907986db28296d2c08b55

basic skills

view details

push time in 14 hours

issue commentnode-fetch/node-fetch

dns.lookup's should be done with `verbatim=true`

@jimmywarting

From the NodeJS docs

verbatim <boolean> When true, the Promise is resolved with IPv4 and IPv6 addresses in the order the DNS resolver returned them. When false, IPv4 addresses are placed before IPv6 addresses. Default: currently false (addresses are reordered) but this is expected to change in the not too distant future. Default value is configurable using dns.setDefaultResultOrder() or --dns-result-order. New code should use { verbatim: true }.

So, node actually encourages you to use verbatim=true.

Since v16.4.0, you can set the default result order to verbatim, but it's still not the default, and most people probably have no clue why they should do that anyway.

dns.lookup, the default dns resolution function resolves addresses using getaddrinfo. This algorithm follows rfc 6724. For full details, read the document, but basically, it governs the order of the IP addresses in the linked list provided by through a rather complex and sophisticated algorithm.

This really wasn't a big deal for most people, but with IoT devices becoming more and more common, non-smartphone hosts are being more commonly used over cellular networks which can drop IPv4 support sporadically, due to IPv4 address exhaustion.

Mobile developers use high level APIs which make decisions like which IP address to resolve for you, and both iOS and Android follow RFC 6724. They also implement Happy Eyeballs (see #1297), so failover is handled automatically.

So, really, it wasn't that big of a problem now, but with the rise of IoT, NodeJS environments are increasingly being deployed on mobile networks, making this more of a problem.

Particularly in less-developed countries, IPv6-only support is more common, and they may not have the resources to figure out what the problem actually is. I recently discovered a misconfiguration on a major cellular provider in India, which probably caused massive network latency issues and unneccessary failed connections.

zwhitchcox

comment created time in 14 hours

issue openednode-fetch/node-fetch

dns.lookup's should be done with `verbatim=true`

Is your feature request related to a problem? Please describe.

Currently, NodeJS ignores rfc 6724 which can cause problems when a network drops IPv6 support, which is increasingly common on 4G networks.

Describe the solution you'd like

Node should set verbatim=true on all requests.

Describe alternatives you've considered

This will eventually be the default in Node, but it's better if we can go ahead an implement it, because this is a stupid design decision and causes extremely confusing bugs.

created time in 15 hours

issue openednode-fetch/node-fetch

Happy Eyeballs

Is your feature request related to a problem? Please describe.

DNS misconfigurations or server down time can cause fetch requests not to be fulfilled. In the browser, this is handled for you using the Happy Eyeballs algorithm.

This functionality is also implemented in curl, iOS, Android, etc..

With IPv6-only network connectivity becoming increasingly common, misconfigurations in DNS servers can cause requests to fail, even when connectivity is available through alternative servers.

Browsers typically try to create a connection, wait 300ms, then try the next available server provided by getaddrinfo in the kernel.

Currently, node-fetch implements no failover for support for timed-out connections.

Describe the solution you'd like

I would propose node-fetch handle failover similarly to the browser. Or better yet, curl's implementation.

net.createConnection attempts to create a connection with the default dns.lookup server. Btw, semi-related, the DNS lookup should be returning results with verbatim=true. Currently, due to a poor design decision by NodeJS developers, IPv4 addresses are preferred, even when this contradicts RFC 6724. Note, that verbatim=true will probably become the default.

This can cause extremely confusing errors for developers using dual stack networks where IPv4 support periodically drops, because it's very hard to find what is causing the issue (I should know).

Ideally, fetch would send the first address first, wait 300ms, and if no connection was made, continue down the line of addresses returned by dns.lookup.

It could be a good idea to log a warning for the user that the first address sent by getaddrinfo was not available, as the 300ms timeout adds latency to every connection.

Still, this is better than dropping the request entirely.

In curl's implementation, which I prefer, its starts with the first address, then tries the next address of a different family.

So, if you're on a IPv6-only network, you don't have to try every single IPv4 address before you get to the IPv6 address.

Describe alternatives you've considered

It would be great if node could implement this natively, but there are currently no plans to do that.

Ultimately though, I think it would probably be better for the community to develop something like this and test it out before merging it into NodeJS anyway and see the response it gets. If it's extremely popular, NodeJS can merge it in, and the code can be removed from here.

created time in 15 hours

issue commentnodejs/node

Future of streams

Forgot to mention the repo is https://github.com/zwhitchcox/stream-adapters

This should also work on previous versions of node without web stream support.

ronag

comment created time in 15 hours

issue commentnodejs/node

Future of streams

So, for anyone reading this, I exported the code by @jasnell to its own module which contains the node internal code for stream adapters.

This makes it easy to convert to/from node/web-streams in a platform-independent environment.

I haven't tested it on the browser, but it should work...will test later. PRs welcome.

Note, that all node web-streams can be converted to/from web streams by calling toWeb or toNode on the stream.

cc @pimterry and @sam-stanford because I remember seeing them asking for this.

ronag

comment created time in 15 hours

push eventzwhitchcox/stream-adapters

Zane Hitchcox

commit sha 26fb53a3bf67f3de1a9136dd9001f5aa376ca263

update rpo

view details

Zane Hitchcox

commit sha b9654de9497108869ea60ebde10e022dcf0463e4

update rpo

view details

push time in 15 hours

push eventzwhitchcox/stream-adapters

Zane Hitchcox

commit sha 6bb8338bf74e9654f38eff8283913a7e97c89bf4

publish to npm Change-type: major

view details

Zane Hitchcox

commit sha 44eb2fa4f16d6c05be0610d4c727e02d75a2af98

change name

view details

push time in 15 hours

create barnchzwhitchcox/stream-adapters

branch : master

created branch time in 15 hours

created repositoryzwhitchcox/stream-adapters

created time in 15 hours

pull request commentbalena-io-modules/stream-adapters

publish to npm

@Resin-Hubot I self-certify

zwhitchcox

comment created time in 15 hours

PR opened balena-io-modules/stream-adapters

publish to npm

Change-type: major

+7 -2

0 comment

2 changed files

pr created time in 15 hours

create barnchbalena-io-modules/stream-adapters

branch : dummy-branch

created branch time in 15 hours

PublicEvent

PR opened balena-io-modules/device-diagnostics

Reviewers
Check for IPv6 DNS's without matching dates

skip first line and first 3 columns to avoid matching date instead of IPv6 addresses

In order to avoid matching dates when matching IPv6 addresses, I only matched the last field.

Unfortunately, dnsmasq doesn't always print the DNS as the last field per https://github.com/balena-io-modules/device-diagnostics/pull/286#issuecomment-918132277

Instead, simply skip the first line and the first 3 columns which contain the log date.

Change-type: patch

+1 -1

0 comment

1 changed file

pr created time in 4 days

create barnchbalena-io-modules/device-diagnostics

branch : skip-dates

created branch time in 4 days

issue closedbalenablocks/fbcp

The touch screen is rotated but the image on the screen is not.

Hi, I have a little problem. The screen has the axis of the touch reversed when I have it in "display_rotate = 0" but when I have "display_rotate = 1" it doesn't happen but I want it in "display_rotate = 0".

I have given permission to support for accesing my device.

I'm sorry if my English is not very good but it is because I live in Spain and I don't know much English and I am using google translator

closed time in 8 days

gameme10

issue commentbalenablocks/fbcp

The touch screen is rotated but the image on the screen is not.

Hey, so this is more of a support issue...the support agents won't see this unless you post on the forums.

Would you mind reposting this to https://forums.balena.io/ ?

gameme10

comment created time in 8 days

pull request commentbalena-io-modules/balena-image-manager

Update balena sdk

@klutchell I tried, but I couldn't get either of my raspberry pi 3s to come up...even with raspbian....I guess I could try just installing Rasbpian one of my rpi4s...it might not be till next week till I have a chance to do that though.

zwhitchcox

comment created time in 10 days

issue openedbalena-os/balena-supervisor

Try both IPv4 and IPv6 addresses for api.balena-cloud.com

There was an issue where the supervisor wasn't sending a heartbeat. This was because the network had dropped IPv4 support and was only serving IPv6.

Furthermore, the network wasn't sending an ICMP Host Unreachable packet, because when the request was failing, a traceroute to api.balena-cloud.com would get to the 192.168.1.1 and then just hang.

This caused getaddrinfo to return the wrong address. It was still returning the IPv4 address, because it had never gotten any indication that that address no longer worked.

According to RFC 3484, rule 1 is Avoid unusable destinations, and the kernel was never informed the destination was unusable.

But it also says

Well-behaved applications SHOULD iterate through the list of addresses returned from getaddrinfo() until they find a working address.

curl responses were working because it tried both IPv6 and IPv4 in parallel:

root@fc09813:~# curl -vv https://api.balena-cloud.com/ping
*   Trying 54.164.146.95:443...
*   Trying fd00:0:b:33::3693:e3ac:443...

Then, it dropped the connection if one wasn't working properly, preferring IPv6 if both were working.

But that functionality is not built into the supervisor. It just tries the first IP address returns by getaddrinfo, and fails if it can't connect. I checked when it wasn't getting a heart beat, and it returned the IPv4 address still, even when IPv6 only was working.

So, that means the supervisor devs SHOULD try different IP addresses if the first one fails. That will involve creating our own custom Agent that extends the createConnection method OR just do like is currently done with the dns.lookup function and monkey patch the net.createConnection globally, which I don't think is a terrible idea, in fact this functionality should probably be built into Node really. Maybe I should open an issue in nodejs/node.

But really, the ideal solution would probably be extending the Agent class and use that over all http connections to be more explicit and avoid future conflicts, although, the supervisor is so well maintained and only used by us and version controlled, it probably doesn't really matter.

The algorithm should probably try both IPv4 and IPv6 connections in parallel, just like curl and drop the non-responsive one.

This wouldn't be the final code, but it could be something like:

import net from 'net';

const {createConnection} = net;
net.createConnection = async (path, cb) => {
  const addresses = await dnsPromises.lookup(path, {verbatim: true});
  const ipv6 = addresses.find(({family}) => family === 6);
  const ipv4 = addresses.find(({family}) => family === 4);
  return await Promise.race([
    new Promise((res) => createConnection(ipv6, res),
    new Promise((res) => createConnection(ipv4, res),
  ]);
}

created time in 11 days

PR opened balena-io-modules/device-diagnostics

Reviewers
Check for IPv6 addresses

the upstream dns diagnostics check does not currently check for IPv6 addresses

Change-type: patch

+1 -1

0 comment

1 changed file

pr created time in 11 days

create barnchbalena-io-modules/device-diagnostics

branch : check-ipv6

created branch time in 11 days

pull request commentbalena-io-modules/balena-image-manager

Update balena sdk

Oh, nvmd, I guess you were probably using raspbian 32-bit

zwhitchcox

comment created time in 13 days

pull request commentbalena-io-modules/balena-image-manager

Update balena sdk

@klutchell Hmm, that's weird, I just tried with the current version on my rpi4 (aarch64), and the. md5 sums were the same as on my mac. Do I need to use a rpi3?

zwhitchcox

comment created time in 13 days

push eventbalena-io-modules/balena-image-manager

Zane Hitchcox

commit sha 19bbb7fdc13d0ac3344b5cd42d56490a06861f38

Update balena sdk Fixes [EOF zlib issue](https://github.com/balena-io/balena-cli/issues/2152 ) per [@klutchell 's balena-request fix](https://github.com/balena-io-modules/balena-request/pull/156). See https://github.com/madler/zlib/blob/master/FAQ#L33 Change-type: minor

view details

push time in 13 days

pull request commentbalena-io-modules/balena-image-manager

Update balena sdk

Once this is merged, we can merge this into the cli

zwhitchcox

comment created time in 13 days

PR opened balena-io-modules/balena-image-manager

Update balena sdk

Fixes EOF zlib issue per @klutchell 's balena-request fix.

See: https://github.com/madler/zlib/blob/master/FAQ#L33

Change-type: minor

+1 -1

0 comment

1 changed file

pr created time in 13 days

create barnchbalena-io-modules/balena-image-manager

branch : update-sdk

created branch time in 13 days

pull request commentbalena-io-modules/balena-image-manager

Clone the incoming image stream before writing to disk

@klutchell I think you can just update the balena-sdk version, because your finishFlush flags in balena-request should fix the problem.

klutchell

comment created time in 13 days