If the firewall is restarted while AppVMs are connected, qubesd tries to
reconnect them before starting the GUI agent. However, the firewall was
waiting for the GUI agent to connect before handling the connections.
This led to a 10s delay on restart for each client VM.
Reported by xaki23.
Had stopped working:
Err http://security.debian.org/ jessie/updates/main libxenstore3.0 amd64 4.4.1-9+deb8u10
404 Not Found [IP: 128.61.240.73 80]
Updated from Debian 8 to Debian 9, and from opam to opam2.
With lots of VMs updating, the firewall quit with:
2017-04-23 20:47:52 -00:00: INF [frameQ] Queue length for 10.137.3.11: incr to 474
2017-04-23 20:47:52 -00:00: INF [memory_pressure] Writing meminfo: free 2648 / 17504 kB (15.13 %)
[...]
Fatal error: out of memory.
The firewall will now drop frames when more than 10 are queued (note
that queuing only starts once the network driver's transmit buffer is
already full).
Fedora 24 doesn't work with opam (because the current binary release of
aspcud's clasp binary segfaults, which opam reports as `External solver
failed with inconsistent return value.`).
In particular, this:
- Adds support for ICMP queries and errors.
- Uses an LRU cache to avoid running out of memory and needing to reset
the table.
- Passes around parsed packets rather than raw ethernet frames.
Qubes does not remove the client directory itself when the domain exits.
Combined with 63cbb4bed0, this prevented clients from reconnecting.
This may also make it possible to connect clients to the firewall via
multiple interfaces, although this doesn't seem useful.
We previously assumed that Qubes would always give clients IP addresses
on a particular network. However, it is not required to do this and in
fact uses a different network for disposable VMs.
With this change:
- We no longer reject clients with unknown IP addresses
- The `Unknown_client` classification is gone; we have no way to tell
the difference between a client that isn't connected and an external
address.
- We now consider every client to be on a point-to-point link and do not
answer ARP requests on behalf of other clients. Clients should assume
their netmask is 255.255.255.255 (and ignore /qubes-netmask).
This is a partial fix for #9. It allows disposable VMs to connect to the
firewall but for some reason they don't process any frames we send them
(we get their ARP requests but they don't get our replies). Taking eth0
down in the disp VM, then bringing it back up (and re-adding the routes)
allows it to work.
