Ah! Thanks for pointing me at that bug. Yes, I'm running r4.0, but I am just completely wrong about being up to date. My qubes-core-dom0 package is only at 4.0.32-1, which is right before these fixes. It looks like I'm having some issues syncing with the qubes-dom0-current repo, and so hopefully once I figure that out I'll be all set.
Thanks for your help! - Ralph On Wed, Jan 2, 2019 at 1:28 AM David Hobach <trip...@hackingthe.net> wrote: > On 1/2/19 4:34 AM, qubes-users-list - wrote: > > Ah! I reread the docs, and it mentions a size limit 3k/~35-39 rules. > So I > > suspect that I'm hitting this limit. I was getting the error right in > that > > range. Thank you for pointing me at that. The docs point out rightly > that > > I can just put rules in the vm directly, so I'll go that route. > > > > For those curious, I'm running a fully up to date R4 > > > > The docs say "there is a 3 kB limit to the size of the iptables script". > > I'm curious as to where that limit comes from if anyone happens to know. > > Hmm yes unman wrote that doc part... > > But considering Marek's statement in > https://github.com/QubesOS/qubes-issues/issues/1570 : "This is already > fixed for Qubes 4.0. The fix is not feasible for backport (it's > incompatible change). The limitation is already documented." > > Are you running 4.0? Because if so, that is a bug and should cause #1570 > to be reopened. I cannot see the Qubes version from your post though. > > > > > > > On Tue, Jan 1, 2019 at 9:42 PM unman <un...@thirdeyesecurity.org> wrote: > > > >> On Tue, Jan 01, 2019 at 09:09:48PM -0500, qubes-users-list - wrote: > >>> I'm trying to add a fair number (around 50?) firewall rules to a vm. > I'm > >>> reading a directory of wireguard configs and trying to create a > specific > >>> rule for each ip*port. > >>> > >>> After adding many rules, at a very consistent point, I get the > following > >>> error: > >>> > >>> $ qvm-firewall <VMNAME> add --before 0 accept proto=udp dsthost=<HOST> > >>> dstports=<PORT> > >>> Got empty response from qubesd. See journalctl in dom0 for details. > >>> > >>> journalctl in dom0 says: > >>> > >>> unhandled exception while calling src=b'dom0' > >> meth=b'admin.vm.firewall.Set' > >>> dest=b'<VMNAME>' arg=b'' len(untrusted_payload)=2417 > >>> Traceback (most recent call last): > >>> File "/usr/lib/python3.5/site-packages/qubes/api/__init__.py", line > >> 262, > >>> in respond > >>> untrusted_payload=untrusted_payload) > >>> File "/usr/lib64/python3.5/asyncio/futures.py", line 381, in > __iter__ > >>> yield self # This tells Task to wait for completion. > >>> File "/usr/lib64/python3.5/asyncio/tasks.py", line 310, in _wakeup > >>> future.result() > >>> File "/usr/lib64/python3.5/asyncio/futures.py", line 294, in result > >>> raise self._exception > >>> File "/usr/lib64/python3.5/asyncio/tasks.py", line 240, in _step > >>> result = coro.send(None) > >>> File "/usr/lib64/python3.5/asyncio/coroutines.py", line 210, in coro > >>> res = func(*args, **kw) > >>> File "/usr/lib/python3.5/site-packages/qubes/api/admin.py", line > 1303, > >> in > >>> vm_firewall_set > >>> self.dest.firewall.save() > >>> File "/usr/lib/python3.5/site-packages/qubes/firewall.py", line > 588, in > >>> save > >>> self.vm.fire_event('firewall-changed') > >>> File "/usr/lib/python3.5/site-packages/qubes/events.py", line 198, > in > >>> fire_event > >>> pre_event=pre_event) > >>> File "/usr/lib/python3.5/site-packages/qubes/events.py", line 166, > in > >>> _fire_event > >>> effect = func(self, event, **kwargs) > >>> File > "/usr/lib/python3.5/site-packages/qubes/ext/r3compatibility.py", > >>> line 79, in on_firewall_changed > >>> self.write_iptables_qubesdb_entry(vm.netvm) > >>> File > "/usr/lib/python3.5/site-packages/qubes/ext/r3compatibility.py", > >>> line 158, in write_iptables_qubesdb_entry > >>> iptables) > >>> qubesdb.Error: (0, 'Error') > >>> > >>> The rule in question does show up in qvm-firewall <VMNAME> list, but I > >>> think the new rule doesn't actually get applied. > >>> > >>> As soon as I delete enough rules to not get the error, it feels like > the > >>> rules are all properly applied again, but I didn't test this > >>> comprehensively yet. > >>> > >>> It feels like I've hit some size limit? From the backtrace it looks > like > >>> the argument was an empty string: arg=b''. That seems suspect. > >>> > >>> Any pointers on where I could look in order to understand the issue > >> better? > >>> > >>> Thanks in advance, > >>> > >>> Ralph > >>> > >> > >> Which Qubes version are you using? > >> How many rules are you able to apply? > >> Have you looked at the docs? > >> https://www.qubes-os.org/doc/firewall > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "qubes-users" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an > >> email to qubes-users+unsubscr...@googlegroups.com. > >> To post to this group, send email to qubes-users@googlegroups.com. > >> To view this discussion on the web visit > >> > https://groups.google.com/d/msgid/qubes-users/20190102024257.s2plx7ipmkydl3dk%40thirdeyesecurity.org > >> . > >> For more options, visit https://groups.google.com/d/optout. > >> > > > > -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CAMVV%3Dfz7f%2BD0yr8bHSj2A9fQ-iRW7%3Dy0jKW8DM1zzT%3DUL00E6A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
