Open CicadaCinema opened 3 years ago
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?
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.
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 thesend
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 thegithub.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 :)
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!
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.
I haven't been able to test quite as much as I would have liked to, but here are the conclusions I can draw:
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.
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.