Starting IPFS in Desktop or in Brave Browser Nightly 1.33.x Cycles Network Printer Power

[eDave56]

Enabling/updating Brave Nightly 1.33.x with IPFS enabled to local node or launching IPFS desktop application 0.17.0 causes network printer to reboot/restart/cycle power. It might just be my printer but it's weird. Sometimes the printer becomes unresponsive after the event.

OS: macOS 10.14.6 (Build 18G9323), macOS 11.6 (Build 20G165), Windows 10 Version 21H1 (Build 19043.1288)

Version of IPFS Desktop: 0.17.0
IPFS in Brave Browser Nightly 1.33.x at least as early as 1.33.7 for macOS, 1.33.34 for Windows 10

Printer: Canon Pixma 710 Series

And the Macs report this:
2012 13" MBP Mojave:
2015 13" MBA Big Sur:

Describe the bug
Starting IPFS Desktop application or enabling it in Brave Nightly 1.33.x causes printer to cycle power / reboot.

To Reproduce
Steps to reproduce the behavior:

Desktop:	Brave Nightly:
1. Open IPFS Desktop	1. Open Brave Nightly
2. If service not started, start it	2. Go to IPFS Settings and enable as local node
3. Wait 30-60 seconds	3. Wait 30-60 seconds
4. Printer restarts/cycles/reboots	4. Printer restarts/cycles/reboots

Expected behavior
Printer should be unaffected.

Additional context
First associated the printer cycling with updating Brave Browser Nightly to 1.33.7, narrowed it down to enabling/updating with IPFS enabled to local node in Brave Nightly, then confirmed it occurs with the IPFS desktop application.

Also initially thought it was macOS-only, but with at least Brave Nightly 1.33.34 and with Desktop 0.17.0, it's both macOS and Windows. On the Linux machine I have running (Lite Ubuntu 20.04) I have not yet been able to reproduce this effect.

I have captured network traffic during IPFS startup with WireShark and PacketPeeper if those would help.

I have a record of sorts in the issue I started on the Brave GitHub site:
brave/brave-browser#19007

Also my initial thread in the Brave Community:
https://community.brave.com/t/ipfs-cycles-network-printer-power-was-update-brave-nightly-cycles-network-printer-power/291260/2

[lidel]

@eDave56 thank you for taking the time to report this in such detail!

• Best guess DNS multicast packets responsible for local peer discovery (sent by go-ipfs and processed by devices in your LAN) trigger a bug in your printer's firmware.
  • @marten-seemann @mxinden did you ever see anything like this? My early suspicions are that either go-ipfs sends something out of the DNS spec, or there could be a bug in the DNS implementation used by the printer.
  • We have an old spec and a new spec for doing local discovery. The next step here is to confirm this is indeed the cause, and if it is due to the old deprecated spec, or the new one.

@eDave56Is it possible for you to capture local network traffic and share the WireShark dump? (attach a ZIP to a GitHub comment or share a CID).

[mxinden]

@marten-seemann @mxinden did you ever see anything like this? My early suspicions are that either go-ipfs sends something out of the DNS spec, or there could be a bug in the DNS implementation used by the printer.

Never seen something like this.

[eDave56]

@eDave56Is it possible for you to capture local network traffic and share the WireShark dump? (attach a ZIP to a GitHub comment or share a CID).

Here is one of the captures I did with WireShark. I can do more if need be. I also have captures using PacketPeeper.

Reset Capture 3.pcapng.zip

My machine in the capture is 192.168.1.14

If there's a download for a version of the IPFS Desktop application that uses the old spec I'm happy to download, install, and try it to see if it causes the same behavior as 0.17.0.

Actually, the Brave Release, Beta, and Dev versions I tested didn't produce the behavior. If they use the old spec, wouldn't that be pretty strong evidence that it's the new spec doing it?

[eDave56]

Still occurs on Brave Browser Nightly 1.33.57 Mac/Win:

Date:	03 November 2021	03 November 2021
Machine:	2012 13" MacBook Pro	Lenovo ideapad FLEX 4-1580, Intel® Core™ i7-7500U CPU @ 2.70GHz, 16 GB RAM
Network Connection:	Ethernet	Ethernet
Printer Reset?	Yes - when enabled IPFS local node	Yes - when enabled IPFS local node
Brave:	1.33.57	1.33.57
Chromium:	95.0.4638.69 (Official Build) nightly (x86_64)	95.0.4638.69 (Official Build) nightly (64-bit)
Revision:	6a1600ed572fedecd573b6c2b90a22fe6392a410-refs/branch-heads/4638@{#984}	6a1600ed572fedecd573b6c2b90a22fe6392a410-refs/branch-heads/4638@{#984}
OS:	macOS Version 10.14.6 (Build 18G9323)	Windows 10 Version 21H1 (Build 19043.1288)
JavaScript:	V8 9.5.172.25	V8 9.5.172.25
User Agent:	Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.69 Safari/537.36	Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.69 Safari/537.36

[dokterbob]

Just quickly glanced over this one and it rang a bell; unless configured not to do so, IPFS will try to connect to local nodes on LAN-addresses at whatever address and port other nodes advertise themselves as. It's quite possible some printers are set to wake up when a certain point is connected to and it's quite possible that this happens.

Normally, one would filter IPFS not to make LAN connections, as would be the case for the server profile.

But perhaps we should be even smarter and not try to make connections to not-routable subnets which we're not in.

[eDave56]

It's quite possible some printers are set to wake up when a certain point is connected to and it's quite possible that this happens.

Interesting, and that makes sense, but that's not what is happening with the printer here. The printer isn't waking up, but is actually rebooting and nagging me that it was not powered off properly afterwards. Or maybe it is waking up, but the Canon software gets carried away and wakes it up then reboots it?

[eDave56]

Still occurs with Brave Browser Nightly 1.33.62. Details here.

[eDave56]

I downloaded current and three old versions of IPFS Desktop for macOS and have tested them.
@lidel @marten-seemann @mxinden @dokterbob As was suggested, it appears to be go-ipfs v0.10.0 that does the reset (possibly the UI v2.13.0, but that seems unlikely).

I've downloaded the same for Windows, but don't have time to test tonight.

IPFS Desktop Version:	0.14.0	0.15.1 It tried to force upgrade but I locked in Finder, started daemon in Terminal	0.16.2 It tried to force upgrade but I locked in Finder, started daemon in Terminal	0.17.0 Locked in Finder as precaution
Agent:	go-ipfs v0.8.0	go-ipfs v0.8.0	go-ipfs v0.9.1	go-ipfs v0.10.0
UI:	v2.11.4	v2.12.3	v2.12.4	v2.13.0
Revision:	69cd414	04be933	e546203	44a46ba
Printer Reset?	No	No	No	YES

OS: macOS Version 10.14.6 (Build 18G9323)
Network Connection: Ethernet

[eDave56]

UPDATE AFTER POSTING THIS: The printer was in some weird state where it responded to scan request, but when I went to it and checked it it cycled power and nagged me, and now Nightly and IPFS Desktop reboot the printer when launched with IPFS local node enabled, again. Dev, Beta, and Release don't and I'm guessing it's only because they won't run go-ipfs.

---

A baffling new development in the Brave implementation: the current channel versions all use go-ipfs 0.10.0 and don't do the printer thing, now, though only Nightly actually has the local node running. Dev, Beta, and Release all report it offline and top in Terminal only lists go-ipfs when Nightly tries to run it. IPFS Companion had a notice in each case pointing me to the release notes for v2.19.1, but that was updated in June, so I don't know why that would have changed anything today [Note per update - it didn't]. So, strangely it seems things are working as they're supposed to with Nightly. And while local node isn't working with Dev, Beta, or Release, at least it's not rebooting my printer. I'll have to test IPFS Desktop, again, to see if somehow that's working right, now. [Note per update - it's not]

Here are screen shots of Terminal and the IPFS local node status page with Nightly running:

[lidel]

@eDave56 i think what matters now is the version of go-ipfs. (Brave/Desktop/webui do not seem relevant)

Could you try installing older versions of go-ipfs like 0.9.1 and 0.8.0 and run ipfs daemon on its own (without Brave and Desktop) to see if/when the issue appear? See https://docs.ipfs.io/install/command-line/ for os-specific steps.

[eDave56]

The printer was in some weird state where it responded to scan request, but when I went to it and checked it it cycled power and nagged me, and now Nightly and IPFS Desktop reboot the printer when launched with IPFS local node enabled, again.

I had installed IPFS Desktop 0.14, 0.15, 0.16, and 0.17 yesterday and found only 0.17 rebooted the printer. It still does.

[dokterbob]

Sounds like a buffer overflow in the printer or something other than that; unexpected input causing the printer to acutely crash, then some watchdog restarts it.

[eDave56]

Could you try installing older versions of go-ipfs like 0.9.1 and 0.8.0 and run ipfs daemon on its own (without Brave and Desktop) to see if/when the issue appear? See https://docs.ipfs.io/install/command-line/ for os-specific steps.

OK, I started with 0.8.0 - ran without rebooting printer
Uninstalled 0.8.0, installed 0.9.1 - ran without rebooting printer
Uninstalled 0.9.1, installed 0.10.0 - 0.10.0 rebooted printer
So it sure looks like it's go-ipfs 0.10.0 doing it

After I took that screenshot and after the printer was done rebooting, these messages appeared in Terminal:

[eDave56]

Sounds like a buffer overflow in the printer or something other than that; unexpected input causing the printer to acutely crash, then some watchdog restarts it.

From what I've read, it looks like Canon has been pretty unconcerned with such flaws in the past. Maybe that's all it is. And the firmware is kind of old.

I experimented with the different services the printer offers, and while the effect is cross platform, it looks like it's Canon's implementation of Bonjour that may be the issue. I have Bonjour installed on the Windows box, too, so it's a possibility. The Linux box not causing the effect might bolster this theory since as far as I know I don't have Bonjour installed in that distro.

Turning off WSD and LPR/D didn't stop the reboot. Turning off Bonjour, too, of course, rendered the printer unusable as a standalone, unless there's an option I missed.

I can just leave IPFS off until the damned printer breaks if it's too much hassle to continue working on this.

[lidel]

Thank you for narrowing this down to go-ipfs 0.10.0.
Eyeballed the wireshark dump you published and the new mdns (_p2p._udp) looks m̫͇̹̘̟̝͡a̝͞l̯͖͈̤͠f̢ọ̞̘͓r͏͍̺̩̜͈̩m̘̳̠͇e̶̦̩̯̫͔͙d̝̹͙̬̥:

@marten-seemann @aschmahmann my understanding is that this is caused by the new mdns implementation in go-libp2p:

• go-ipfs 0.10.0 shipped new libp2p which bumped the local discovery to use the new spec (implement the new mDNS spec, move the old mDNS implementation libp2p/go-libp2p#1161) and the DNS label it uses seems to cause an error in poorly written Canon firmware. 🙈
• The next version that we will ship with 0.11.0 will generate random DNS labels (use a random string for the mDNS peer-name libp2p/go-libp2p#1222) independent from peerid, that should fix the issue, but lmk if you see anything else at play here.

[eDave56]

Thank you, @lidel . Is there a timeline for the release of 0.11.0? I poked around and didn't see one, but my github skills are feeble.

[lidel]

It should land on the next few weeks, before December holidays.

[lidel]

@eDave56 are you able to see if go-ipfs v0.11.0-rc1 fixes this issue? We switched to go-libp2p 0.16, assuming it is fixed.

• https://dist.ipfs.io/go-ipfs/v0.11.0-rc1
• https://github.com/ipfs/go-ipfs/releases/tag/v0.11.0-rc1

[eDave56]

It looks like go-ipfs v0.11.0-rc1 has fixed the issue. It's been running for about 10 minutes and the printer hasn't made a peep. Thank you! Now I just need to wait for its integration into Brave.

[eDave56]

And as soon as I posted my comment the daemon produced this error. Printer's still fine, though.

[lidel]

This TCP error message is unrelated (printer issue was caused by UDP packets) :)
Thanks for confirming!