That really complicates matters, because it involves a different set of "networking" functions for wireless/wifi. 
If both your computer and your printer are on a private LAN on your side of the firewall-router modem, then you are secure, as long as you have "blocked appropriate" WAN ports by your modem (assuming they have some built-in default protective settings).
Normally, "proper" firewall on the modem means no real need for a firewall on your internal devices, as long as the exposed LAN ports are blocked on the WAN side, you are covered.
HOWEVER, if LAN-attached servers block all non-LAN traffic for those services intended for LAN-only, again, you should be covered. 
That command gave me an error. What happens when you try:
netstat -ano | grep '/i' | grep "631"
$telnet <IP address or hostname> 631
Being able to open a telnet session without error gives you confirmation that your computer does has open port access to/from that port.
nmap -p 631 --script ipp-info <target-ip>
In that command, target-ip would be you computer's LAN address, i.e. 192.168.1.###, not the printer's .
... and once you reach that, more modern printers would have a function to define a security password to prevent inappropriate manipulation of settings.
If you go here
download the manual for MacOS (first on list) and go down to "page 177", where info for networking begins. That will provide some much needed details.
IF POSSIBLE, you may wish to try configuring with "cable-attached" internet, giving the printer a fixed IP address, before unplugging the cable and going wireless.
To see what your computer is dealing with during a power-up of your printer,
- unplug your printer,
- enter the cli command
tail -f /var/log/syslog, and - plug the printer back into the power outlet and turn on.
That will reveal the sequence of events involved in handling your printer.
For debugging, you will need to get into the system logs for CUPS. Before your next attempt at accessing the printer, you should do the following:
cupsctl --debug-logging ### activation of debug logging
cupsctl LogLevel=debug2 ### specifying verbosity of debug info
Once debugging is over, you should minimize CUPS logging by entering
cupsctl --no-debug-logging
Then view the errolog using the command:
tail -n 100 -f /var/log/cups/error_log | more
You may wish to scan the following URL for some insights:
If all else fails, you may be forced to perform the printer configuration using an Android, Mac, or Windows computer, using Canon's "IJ Network Tool", before re-attempting to perform the "hook-up" for your Linux-based wireless connection.
That software would be available from here:
I found the reference to the "IJ Network Tool" for Linux.
Alternate software sources: