>Perhaps I could set them up a Raspberry Pi as a print server? But that would make it not so cheap. And anyway, I’m not convinced they’d go for the extra plugs and wires.
$35 and it's yours, with tech support and CUPS/SANE development funding included, and all open source: https://printserver.ink
print spoolers typically consume space in /var/ for the files being printed and then stream them to the device through the output filters. The amount of data in play to render a page is not typically that big. Yes, there are corner cases analogous to a zip bomb which can make the print model explode. No, in practice this isn't very normal: printing is one of the spaces where compression of the data is entirely normal. "please print another row of black, where black is that thing I told you before, do that 2048 times and then come back"
Huh? I don't have any PDF files larger than 150 MB (2500+ pages long).
It won't be a problem. 512 MB is more than enough. The previous revision had 256 MB (that's a bit tight), and the newer PCB does not have RAM less than 1 GB.
Printing stack supports streaming, either per-band (part of a single page) or per-page. Even 1200 DPI CMYK color page is less than 50 MB.
You might think that such an important and long-standing feature as printing would undoubtedly be backed up by a large company. This was true until 2019, when it was backed by Apple. Currently, however, CUPS and all related projects are supported by volunteers, including myself.
All the current development runs in OpenPrinting github: https://github.com/OpenPrinting, and mostly focused on newer projects, such as CUPS v3, PAPPL, Printer Applications.
Recent versions of CUPS v2 are still used in Chrome OS and Chromebooks though (apart from all Linuxes).
Xerox just removed all the Linux drivers first for the majority of older models (even actual ones, which you can still buy), Windows and macOS drivers second for selected models (yet).
Canon, Pantum, Brother, Kyocera, HP, they all still produce new devices on older hardware base, which require driver and does not support AirPrint/Mopria even over USB. They just don't care, they reuse what they wrote 20 years ago and ship it. Xerox and HP use Samsung printing engine and drivers, Pantum uses Lexmark.
>but it's one of those projects that feels like it's going to end up being a rabbit hole.
I know your feelings. I've started https://printserver.ink because I wanted to buy a retail print server and could not find any. I was expecting half a year overall work for everything, but fixing all printer-related bugs for 3 years already.
Ah nice. If I supply my own raspi zero 2W, can I buy just a software license from you? Doing the software integration is the part I'm least looking forward to. :(
Unfortunately the firmware supports only Orange Pi Zero3. It's a hardware+software solution, because to make reliable print server, you have to control both and fix SoC/board specific bugs.
Greg does not accept my patch and does not reply to me, presumably because I'm Russian and he doesn't want legal consequences.
Raspberry Pi unfortunately have quite list of USB hub bugs and Wi-Fi module bugs (according to their GitHub and reports all over the Internet), and I'm not familiar with it and don't know how to fix. That's why I don't make generic firmware or container images, and stick only to my board which I know from start to end.
Well it's kind of possible to block it with routing tables+rules only, but you're right. This is also painful if iptables/nftables binaries are not installed.
The Linux box instantly turns into a router as soon as you run `sysctl net.ipv4.ip_forward=1`, because the default policy for FORWARD table is ACCEPT.
You need to explicitly reconfigure the iptables/nftables to prevent that from happening.
Some software, say LXD/Incus, enable forwarding automatically upon installation/startup, and do not configure firewall to block non-their traffic, making the machine an open router. I've reported that, the developers said that's by design (despite other virtualization/containerization systems block forwarding if they happen to enable the sysctl).
Respectfully- I don’t think this statement applies to the scenario I presented.
“The Linux box instantly turns into a router as soon as you run `sysctl net.ipv4.ip_forward=1`, because the default policy for FORWARD table is ACCEPT.”
In the setup I presented, we are bridging an Ethernet and a WiFi network. This would be desirable if you wanted to use an upstream dhcp server for your WiFi clients- or if you wanted to avoid double nat’ing.
In 802.11 infrastructure mode, a station can only send frames with its own MAC address. The AP won’t accept or forward frames from unknown MACs. So you can’t transparently bridge Ethernet devices’ MAC addresses through a WiFi client interface. This is why we need hostapd.
In every other circumstance- I think your statement holds.
I tried to do some weird alerting on new MAC addresses and ran into this weirdness. Bridging WiFi and Ethernet gets weird.
"So you can’t transparently bridge Ethernet devices’ MAC addresses through a WiFi client interface. This is why we need hostapd."
I think that is incorrect. hostapd handles the authentication side of things, but 4addr tuples are controlled by 'struct wireless_dev.use_4addr', and can be set by 'ip link set type bridge_slave ... proxy_arp_wifi on', `iw dev ... 4addr on', and if using systemd-networkd, with slave interface's
[Bridge]
ProxyARPWiFi=yes
(and networkd doesn't need hostapd's bridge= option since networkd handles that aspect.)
Kernel then uses NL80211_IFTYPE_AP_VLAN and handles the proxy operation.
It may be possible that this has changed. Last year I built a device and crashed into the bridging weirdness when I wanted to use upstream dhcp. There was/is some funkiness lurking with bridging wifi to Ethernet- in particular with broadcasts that traverse the bridge.
Respectfully the scenario you want to present seems to change. The title you submitted this under doesn’t have any mention of switching, firewalls, dhcp server or WiFi access point.
Then the actual title of the article mentions routing and switching but not a firewall, dhcp server or WiFi access point. Then at the end you seem to change the goal to being a WiFi router but really you have presented more steps than required for that. You have also setup switching, a firewall and a dhcp server which are not required to be a router with WiFi access point.
>> spectfully the scenario you want to present seems to change.
Man that is totally a fair point.
I feel like I’ve struggled with the tutorials on these configs so many times in my life that I’ve kind of munged several ideas together here. There’s so much subtlety to the iptables/nftables rules that I failed to understand for so long, that I forgot that some folks might not understand that WiFi has specific weirdness. You’re right- I open with routing as a topic, but I’m in a very specific nuance right away.
Could you share more details about this? Do you mean that e.g., if I run LXD/Incus on a machine with a public IP address, anyone on the internet could route traffic through it?
Anyone in "your lan" (L2 of the interface, sometimes L3 like VPN). Your containers/VMs will be fully accessible from other machines in "LAN" (hosting provider infrastructure, or ISP infrastructure), despite no port forwarding/publishing configured.
Your IP could also be used to run DoS attacks on the internet, although in this case (compared to containers/VM access) the attacker won't be able to receive replies (one-way communication only, like the address spoofing). But if you also happen to configure NAT (MASQUERADE) without additional limits, anyone in "LAN" could use your machine as a router (use your IP address to access websites).
Such misconfiguration is rarely told about in the how-tos and guides, and it's pretty common to have "additional free IPs" on your VPS/dedicated this way :D
This is also true in case of manually crafted home routers (such as in this article, and misconfigured advanced routers like Mikrotik, OpenWrt, Cisco, etc): if you happen to unconditionally enable forwarding without firewall, and think that NAT will somehow block the access to your home LAN, that's not true. Your neighbor, connected to the same ISP switch, could just add the routing record to 192.168.0.0/24 via your router's MAC address and access your 192.168.0.0/24 LAN devices without restrictions (unless ISP specifically blocks such access).
Thanks! It's always scary when container technology fiddles with your network... I wonder how they can be at peace with such defaults. Another reason to stick with good old containerd units, I guess.
The risk is minimal if you control or trust both networks. A network boundary is a natural choke point for access control, so that's where it's usually implemented. For an ipv4 boundary router (as is the topic of the post) you almost certainly need to configure Network Address Translation because your internal network addresses are non-routable on the Internet (at uni my dorm had public IP addresses for each student computer, fun times).
As for the GP's example, running VM's or containers* on your own machine? I'd say the default ACCEPT policy is fine. However, silently changing such a setting on software installation is a problem because if the machine is multi-homed (i.e. has more than one network interface), you've now created a network route outside of the network admin's control.
* The default for docker and podman is to use a private network, not a bridge anyway.
Basically you're introducing a hole. For example, if you have some devices in your network (like a dodgy TV box) that are not supposed to reach the internet or other parts of the network, the computer with net.ipv4.ip_forward=1 could be used as a pivot. Depending on the routing tables you probably would also need to enable IP masquerading (NAT) to allow bidirectional communication.
$35 and it's yours, with tech support and CUPS/SANE development funding included, and all open source: https://printserver.ink
Extra plugs could be eliminated with the help of "IEC320 3 pin C14 TO Male C13+2" cable: https://ae-pic-a1.aliexpress-media.com/kf/S4c8681fb1283499b8...
reply