Re: [qubes-users] Error when trying to add a lot of firewall rules
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 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 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 add --before 0 accept proto=udp dsthost=
> >>> dstports=
> >>> 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'' 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 list, but I
> >>> think the new rule doesn't actually get applied.
> >>&g
Re: [qubes-users] Error when trying to add a lot of firewall rules
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.
Cheers,
Ralph
On Tue, Jan 1, 2019 at 9:42 PM unman 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 add --before 0 accept proto=udp dsthost=
> > dstports=
> > 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'' 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 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%3Dfwe3dafA%3DCe3avc%2BJaZtA%2BJgJO4QaDfObVADkswk%2BxyXA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
[qubes-users] Error when trying to add a lot of firewall rules
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 add --before 0 accept proto=udp dsthost=
dstports=
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'' 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 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
--
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%3Dfz_7U-GgCFP9_605PCsyVR0cjsO2viWT8_K%3DzwQD-SwKw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Screen dimension issue with qubes started before plugging in additional monitors
Issue fixed. In my fedora28 template I
changed /etc/X11/xorg-qubes.conf.template to have a hardcoded amount of RAM
for "Videocard0". So from:
VideoRam %MEM%
to
VideoRam 49576
49576 is just the amount of RAM which was calculated by the
`qubes-set-monitor-layout` script for a VM started after my external
monitors were plugged in. VMs started before extra monitors were plugged
in had about half that amount.
There appears to be a bug on github which may very well be the same thing,
and I'll try to circle back to that github issue and report what worked for
me when I get a moment tomorrow.
- Ralph
On Mon, Sep 10, 2018 at 2:01 PM, qubes-users-list - <
qubes-users-l...@ralphdouglass.com> wrote:
> I've been running into an issue where mouse events inside of a qube (i.e.
> clicking around inside of a window) aren't being recognized if I started a
> qube before plugging in additional monitors and the area I'm trying to
> click in is off-screen from the standpoint of the monitor layout I had when
> the qube was started.
>
> Moving windows 'off-screen' works just fine, not surprisingly, since I
> assume that's Dom0's job and it's not confused about my screens.
>
> xrandr in the problematic qube and dom0 match in terms of screen sizes,
> but it looks like all screens in the problematic qube are positioned at 0x0.
>
> Here's the output from xrandr in a problematic qube started before I
> plugged in more monitors, and a non-problematic qube I started afterwards
> plugging in more monitors. I left off the disconnected devices
> (DUMMY{3..15}).
>
> Started before I plugged in extra monitors:
>
> Screen 0: minimum 64 x 64, current 2560 x 1440, maximum 32767 x 32767
> DUMMY0 connected primary 2560x1440+0+0 325mm x 182mm
>QB2560x1440 34.61*+
> DUMMY1 connected 1920x1200+0+0 0mm x 0mm
>QB2560x1440 34.61 +
>QB1920x1200 59.88*
> DUMMY2 connected 1920x1200+0+0 0mm x 0mm
>QB2560x1440 34.61 +
>QB1920x1200 59.88*
>QB1200x1920 59.95
>
> Started after I plugged in extra monitors:
>
> Screen 0: minimum 64 x 64, current 3160 x 3360, maximum 32767 x 32767
> DUMMY0 connected primary 2560x1440+600+1920 0mm x 0mm
>QB3160x3360 14.85 +
>QB2560x1440 59.96*
> DUMMY1 connected 1920x1200+1200+300 0mm x 0mm
>QB3160x3360 14.85 +
>QB1920x1200 59.88*
> DUMMY2 connected 1200x1920+0+0 0mm x 0mm
>QB3160x3360 14.85 +
>QB1200x1920 59.95*
>
> I can move the problematic DUMMY0 screen around, but not all the way to
> 600x1920 as I want to match the actual layout of my monitors.
> Specifically, I can move DUMMY0 to the position 599x383 but no further on
> either the x or y dimension. If I do more, I get the following error:
>
> $ xrandr --output DUMMY0 --auto --pos 600x383
> X Error of failed request: BadMatch (invalid parameter attributes)
> Major opcode of failed request: 139 (RANDR)
> Minor opcode of failed request: 7 (RRSetScreenSize)
> Serial number of failed request: 100
> Current serial number in output stream: 101
>
> (Same is true for 599x384).
>
> 600x384 is obviously not a random number, but I haven't figured out where
> to take this further.
>
> Any thoughts on what to try next?
>
> Thanks in advance,
>
> Ralph
>
--
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%3Dfz8DgX5eVkguO-rimMQCwyf4fQDBeNW%3DbMfQF6wr3W4Lw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
[qubes-users] Screen dimension issue with qubes started before plugging in additional monitors
I've been running into an issue where mouse events inside of a qube (i.e.
clicking around inside of a window) aren't being recognized if I started a
qube before plugging in additional monitors and the area I'm trying to
click in is off-screen from the standpoint of the monitor layout I had when
the qube was started.
Moving windows 'off-screen' works just fine, not surprisingly, since I
assume that's Dom0's job and it's not confused about my screens.
xrandr in the problematic qube and dom0 match in terms of screen sizes, but
it looks like all screens in the problematic qube are positioned at 0x0.
Here's the output from xrandr in a problematic qube started before I
plugged in more monitors, and a non-problematic qube I started afterwards
plugging in more monitors. I left off the disconnected devices
(DUMMY{3..15}).
Started before I plugged in extra monitors:
Screen 0: minimum 64 x 64, current 2560 x 1440, maximum 32767 x 32767
DUMMY0 connected primary 2560x1440+0+0 325mm x 182mm
QB2560x1440 34.61*+
DUMMY1 connected 1920x1200+0+0 0mm x 0mm
QB2560x1440 34.61 +
QB1920x1200 59.88*
DUMMY2 connected 1920x1200+0+0 0mm x 0mm
QB2560x1440 34.61 +
QB1920x1200 59.88*
QB1200x1920 59.95
Started after I plugged in extra monitors:
Screen 0: minimum 64 x 64, current 3160 x 3360, maximum 32767 x 32767
DUMMY0 connected primary 2560x1440+600+1920 0mm x 0mm
QB3160x3360 14.85 +
QB2560x1440 59.96*
DUMMY1 connected 1920x1200+1200+300 0mm x 0mm
QB3160x3360 14.85 +
QB1920x1200 59.88*
DUMMY2 connected 1200x1920+0+0 0mm x 0mm
QB3160x3360 14.85 +
QB1200x1920 59.95*
I can move the problematic DUMMY0 screen around, but not all the way to
600x1920 as I want to match the actual layout of my monitors.
Specifically, I can move DUMMY0 to the position 599x383 but no further on
either the x or y dimension. If I do more, I get the following error:
$ xrandr --output DUMMY0 --auto --pos 600x383
X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 139 (RANDR)
Minor opcode of failed request: 7 (RRSetScreenSize)
Serial number of failed request: 100
Current serial number in output stream: 101
(Same is true for 599x384).
600x384 is obviously not a random number, but I haven't figured out where
to take this further.
Any thoughts on what to try next?
Thanks in advance,
Ralph
--
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%3DfwL9RfKEQ0ZMS5kQz2QVuspCGw1_cnPtJarrRRObA2SHw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: [Q4-rc5] Blank screen on boot after installation on Lenovo
On Sunday, April 1, 2018 at 2:02:15 PM UTC-4, Marek Marczykowski-Górecki wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Wed, Mar 28, 2018 at 11:25:18AM -, 'awokd' via qubes-users wrote: > > On Wed, March 28, 2018 2:09 am, berto0001 wrote: > > >> It's in a bit of an indeterminate state right now: > > >> https://github.com/QubesOS/qubes-issues/issues/2971. Did regenerating > > >> initramfs with host only fix it for you, or did you just leave the > > >> keyboard setting on US on the reinstall? > > > > > > Actually, I just pressed the keys as on an imaginary US keyboard after > > > realizing one key was in a different position. That's a quite common > > > method for non-US users -- you just need to be aware that you are dealing > > > with a moved key in the first place. And there is no feedback when typing > > > a password as first task on a new OS, obviously. > > > > Sounds like that linked issue's not resolved. If you have a Github > > account, mind commenting on it with your experience and pinging > > @andrewdavidwong? I can do it later too, if you don't. If you get a chance > > to regenerate with -H, I'm curious if that fixes it too. Shouldn't (TM) > > hurt anything. > > Have you tried final 4.0 image? There were some fixes that didn't > managed to get included in rc5. The issue appears to still present in the final 4.0 release based on the results of my reinstall this weekend. (I don't know if this is the source of the problem, but I watched the installer switch the the keyboard layout listed in the upper right hand corner from my chosen preference back to 'us' while installing packages. I think maybe somewhere between package number 700 and 800. By the end of the install the keyboard listed in the upper right hand corner was switched back to what I had previously selected. Post install rpm script doing this or something?!?) > > - -- > Best Regards, > Marek Marczykowski-Górecki > Invisible Things Lab > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > -BEGIN PGP SIGNATURE- > > iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlq3FxMACgkQ24/THMrX > 1yyY2gf/aMKU0Z5QePTIlSvlCv+w5Q+izB8ROYhVB2u924BN+cdJOpeucLV9BCJD > XjpxhT9jcmPa92VB8Y9ZYuuh0xHD2+2961/Gi84cgtyUhAeqPNwzixkQDFkQNDCk > LwjauR3+qR/ESQQjrnwEQj9wUSWdNaAeU3CKBbl2xyu7R1/mNQbiEKpN0hbaZ0S9 > ByZ3DzL5s2TC5Eulc134mCLba7W1Na6cUYeh4pC2caUztJOOIFWuqB8Jqyu0vEvp > l+SidbOeHoMdlTZEBx9VZzab/Xk1DqbuLHqkDU09XaSLlBzEahC/AW5Oz0Z1TJry > K/ZJNK6aVK74WDN/oBvfeswxas3UOg== > =uk26 > -END PGP SIGNATURE- -- 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/e57d6931-da3e-4bea-bd96-8311252b688e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Duplicate MAC address error
On Tuesday, December 26, 2017 at 10:30:45 AM UTC-5, Kushal Das wrote: > On Tue, Dec 26, 2017 at 8:18 PM, cooloutac wrote: > > > > wonder if your system runs low on ram? Could also try using system without > > iommu and see if it still happens. > > > I have 32GB here on a T470. I hope that is okay :) > > Kushal > -- > Staff, Freedom of the Press Foundation > CPython Core Developer > Director, Python Software Foundation > https://kushaldas.in I can recreate this error message consistently while running the latest R4 rc3. Inside of sys-net, just shut down the vm from the inside (e.g. sudo reboot) Afterwards sys-net fails to start: $ qvm-start sys-net Start failed: invalid argument: network device with mac XX:XX:XX:XX:XX:XX already exists To get back in a good state without rebooting the entire machine, I have to shut down (or kill) all dependent vms (AppVMs talking to my firewall-vm and my firewall vm). Then I can start sys-net again, followed by my firewall vm, followed by my regular app vms. I've managed to trigger this on two Lenovo laptops and one Dell laptop so far, all of which are running R4rc3. I'm pretty new to QubesOS and haven't figured out how to dig through the innards well enough yet to find anything useful. -- 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/32111085-5195-4ff1-b85e-dabbae3c3a43%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
