Attempting to send a file kills the entire network

[CicadaCinema]

(c) 2020 Microsoft Corporation. All rights reserved.

C:\Users\\Downloads\pcp_0.3.3_windows_amd64>ping google.com

Pinging google.com [216.58.212.238] with 32 bytes of data:
Reply from 216.58.212.238: bytes=32 time=17ms TTL=116
Reply from 216.58.212.238: bytes=32 time=24ms TTL=116
Reply from 216.58.212.238: bytes=32 time=16ms TTL=116

Ping statistics for 216.58.212.238:
    Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 16ms, Maximum = 24ms, Average = 19ms
Control-C
^C
C:\Users\\Downloads\pcp_0.3.3_windows_amd64>pcp send test.txt
Code is:  tag-draw-absent-track
On the other machine run:
        pcp receive tag-draw-absent-track
Stopping...

C:\Users\\Downloads\pcp_0.3.3_windows_amd64>ping google.com

Pinging google.com [216.58.212.238] with 32 bytes of data:
Request timed out.
Request timed out.

Ping statistics for 216.58.212.238:
    Packets: Sent = 2, Received = 0, Lost = 2 (100% loss),
Control-C
^C
C:\Users\\Downloads\pcp_0.3.3_windows_amd64

The debug output above provides all the relevant version information, and the internet also goes down for all the other devices on my network (in fact, the SSID disappears for a while). I can provide a network diagram if necessary, but my router is an ISP-issued Virgin Media Hub 3.

[dennis-tra]

Hi @ColonisationCaptain

I'm sorry to hear that my tool seems to cause your entire network to go down :/ Right now I can't think of a plausible cause.

The only relevant communication from pcp with your router is done via NAT-PMP, UPnP and mDNS. For the first two protocols I'm using libp2p and for the latter one I'm using whyrusleeping/mdns - another contributor to libp2p. The mDNS packets are sent with a frequency of 1s - this shouldn't overwhelm the router...

I'm actually clueless right now - regarding the network diagram, do you think there are other relevant components that could interfere here?

[CicadaCinema]

I feel like this might be an unintentional DoS attack on the vulnerable Puma 6 chipset, which is used in the router, according to these articles simply because I have no clue what else it could be. Over the coming days I might test this out on a number of devices and platforms, but right now I just want to integrate the send functionality into my own go project. I initially tried this on an ethernet connection passing through an unmanaged Netgear switch, but I don't see how that would have changed things.

I'm actually pretty new to go and I was considering using your project to learn, but this seems like a much more interesting thing to investigate! I believe I should be calling Action() in the send package, but I haven't quite been able to get this running with go code (as opposed to calling pcp from the command line). Could you point me to some resources on this? It seems I might need to eliminate the 'Context' parameters, but I am also unsure as to how the github.com/urfave/cli package works in the context of your code.

[dennis-tra]

I feel like this might be an unintentional DoS attack on the vulnerable Puma 6 chipset, which is used in the router, according to these articles simply because I have no clue what else it could be.

Wow, this is a really unfortunate problem and the symptoms you're describing fit what is outlined in the articles :/ correlation != causation, but as the internet breakdown is reproducible with pcp I think it's the plausible cause.

In the articles you've linked the authors mention that someone from the outside of your local network could just bombard your gateway with packets on different ports, that fill up some look-up table and render the device unusable. The protocols I've mentioned above only operate within your local network and afaik don't address many ports.

In case of UPnP - source:

UPnP uses UDP port 1900 and all used TCP ports are derived from the SSDP alive and response messages.[6]

In case of NAT-PMP - source:

NAT-PMP runs over the User Datagram Protocol (UDP) and uses port number 5351

In case of mDNS - source

UDP port 5353

This is still a limited number of ports that are potentially in use by pcp and imo shouldn't cause the problem that is described in the articles.

Over the coming days I might test this out on a number of devices and platforms, but right now I just want to integrate the send functionality into my own go project. I initially tried this on an ethernet connection passing through an unmanaged Netgear switch, but I don't see how that would have changed things.

Awesome, let me know how the tests go!

I'm actually pretty new to go and I was considering using your project to learn, but this seems like a much more interesting thing to investigate! I believe I should be calling Action() in the send package, but I haven't quite been able to get this running with go code (as opposed to calling pcp from the command line). Could you point me to some resources on this? It seems I might need to eliminate the 'Context' parameters, but I am also unsure as to how the github.com/urfave/cli package works in the context of your code.

github.com/urfave/cli is the package for building command line interface and takes care of e.g. argument parsing, error handling etc.

Eliminating the context would look like this:

func ActionWithoutContext(filepath string, wordCount int) error {
	// Read config file and fill context with it.
	ctx, err := config.FillContext(context.Background())
	if err != nil {
		return err
	}

	// Try to open the file to check if we have access and fail early.
	if err = validateFile(filepath); err != nil {
		return err
	}

	if wordCount < 3 {
		return fmt.Errorf("the number of words must not be less than 3")
	}

	// Generate the random words
	_, wrds, err := words.Random("english", wordCount)
	if err != nil {
		return err
	}

	// Initialize node
	local, err := InitNode(ctx, filepath, wrds)
	if err != nil {
		return err
	}

	// Broadcast the code to be found by peers.
	log.Infoln("Code is: ", strings.Join(local.Words, "-"))
	log.Infoln("On the other machine run:\n\tpcp receive", strings.Join(local.Words, "-"))

	local.StartAdvertising()

	// Wait for the user to stop the tool or the transfer to finish.
	select {
	case <-ctx.Done():
		local.Shutdown()
		return nil
	case <-local.SigDone():
		return nil
	}
}

For testing purposes you could just copy this besides the existing Action method. I haven't tested the above code but I hope it helps :)

It's really cool that you considered learning Go with this project. I'm always open for helping hands so it may be a good learning opportunity to dive right in and try to do one of the tickets of the project board. A good first issue could be this one - or any other you'd like :)

[CicadaCinema]

In the articles you've linked the authors mention that someone from the outside of your local network could just bombard your gateway with packets on different ports, that fill up some look-up table and render the device unusable. The protocols I've mentioned above only operate within your local network and afaik don't address many ports.

I mean, I was just pointing to the fact that this is a poorly-designed chipset - not this specific issue. In fact, the symptoms are different here. Instead of slowing down network requests, the network SSID disappears (all devices are disconnected) and some of the router lights turn on - haven't gotten around to finding out what this means yet, but it is likely that the router has just been forced to reboot.

I'll try out that code, thanks!

[dennis-tra]

I mean, I was just pointing to the fact that this is a poorly-designed chipset - not this specific issue.

Ah alright 👍

In fact, the symptoms are different here. Instead of slowing down network requests, the network SSID disappears (all devices are disconnected) and some of the router lights turn on - haven't gotten around to finding out what this means yet, but it is likely that the router has just been forced to reboot.

Let me know if you've found the issue and to what mechanisms it relates in this tool.

[CicadaCinema]

I haven't been able to test quite as much as I would have liked to, but here are the conclusions I can draw:

• This bug occurs consistently when the computer is connected via ethernet (through a small Netgear switch configured to be unmanaged)
• The bug has not occurred so far when the computer is connected to the router via WiFi
• The network goes down in the loop starting

  pcp/pkg/send/node.go

  Line 83 in 95a0b2d

  for _, advertiser := range n.advertisers {

  and ending

  pcp/pkg/send/node.go

  Line 103 in 95a0b2d

  }

  .

Haven't been able to test on other networks or other computers unfortunately, but I would appreciate your comments on these conclusions, especially as to what goes on in this loop.