diff mbox series

[2/2,v2] slirp: Add classless static routes support to DHCP server

Message ID 20180308185743.3408-1-benjamin.drung@profitbricks.com
State New
Headers show
Series None | expand

Commit Message

Benjamin Drung March 8, 2018, 6:57 p.m. UTC
This patch will allow the user to specify classless static routes for
the replies from the built-in DHCP server.

Signed-off-by: Benjamin Drung <benjamin.drung@profitbricks.com>
---
 net/slirp.c      | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++---
 qapi/net.json    |  4 ++++
 qemu-options.hx  | 14 +++++++++++-
 slirp/bootp.c    | 20 +++++++++++++++++
 slirp/bootp.h    |  2 ++
 slirp/libslirp.h |  9 +++++++-
 slirp/slirp.c    |  7 +++++-
 slirp/slirp.h    |  2 ++
 8 files changed, 120 insertions(+), 6 deletions(-)

Comments

Eric Blake March 8, 2018, 7:46 p.m. UTC | #1
On 03/08/2018 12:57 PM, Benjamin Drung wrote:
> This patch will allow the user to specify classless static routes for
> the replies from the built-in DHCP server.
> 
> Signed-off-by: Benjamin Drung <benjamin.drung@profitbricks.com>
> ---

For future patches, when sending a v2, it's best to document here (after 
the --- separator) what changed from v1.  It's also a good idea to send 
a fresh thread rather than tying your v2 in-reply-to your v1, so that it 
doesn't get buried in an old conversation.

More submission hints at https://wiki.qemu.org/Contribute/SubmitAPatch

>   net/slirp.c      | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++---
>   qapi/net.json    |  4 ++++
>   qemu-options.hx  | 14 +++++++++++-
>   slirp/bootp.c    | 20 +++++++++++++++++
>   slirp/bootp.h    |  2 ++
>   slirp/libslirp.h |  9 +++++++-
>   slirp/slirp.c    |  7 +++++-
>   slirp/slirp.h    |  2 ++
>   8 files changed, 120 insertions(+), 6 deletions(-)

Reviewing just the QMP interface:


> +++ b/qapi/net.json
> @@ -163,6 +163,9 @@
>   # @domainname: guest-visible domain name of the virtual nameserver
>   #              (since 2.12)
>   #
> +# @route: guest-visible static classless route of the virtual nameserver
> +#         (since 2.12)
> +#
>   # @ipv6-prefix: IPv6 network prefix (default is fec0::) (since
>   #               2.6). The network prefix is given in the usual
>   #               hexadecimal IPv6 address notation.
> @@ -201,6 +204,7 @@
>       '*dns':       'str',
>       '*dnssearch': ['String'],
>       '*domainname': 'str',
> +    '*route':     ['String'],

I know we've used ['String'] for previous members, but that's rather 
heavyweight - it transmits over QMP as:

"dnssearch": [ { "str": "foo" }, { "str": "bar" } ]

Nicer is ['str'], which transmits as:

"route": [ "foo", "bar" ]

so the question boils down to whether cross-member consistency is more 
important than making your additions concise.

> +++ b/qemu-options.hx
> @@ -1904,7 +1904,7 @@ DEF("netdev", HAS_ARG, QEMU_OPTION_netdev,
>       "         [,ipv6[=on|off]][,ipv6-net=addr[/int]][,ipv6-host=addr]\n"
>       "         [,restrict=on|off][,hostname=host][,dhcpstart=addr]\n"
>       "         [,dns=addr][,ipv6-dns=addr][,dnssearch=domain][,domainname=domain]\n"
> -    "         [,tftp=dir][,bootfile=f][,hostfwd=rule][,guestfwd=rule]"
> +    "         [,route=addr/mask[:gateway]][,tftp=dir][,bootfile=f][,hostfwd=rule][,guestfwd=rule]"

Urgh - your QMP interface HAS to be further parsed to get to the useful 
information.  While it's nice to have compact syntax on the command 
line, it is really worth thinking about making information easier to 
consume (that is, NO further parsing required once the information is in 
JSON format).  Would it be any better to send things over the wire as:

"route": [ { "addr": "...", "mask": 24, "gateway": "..." } ]

instead of cramming all the information into a single string?  But based 
on the way this also maps to the command line, you may not have a choice 
without a lot more code complexity.

>   #ifndef _WIN32
>                                                "[,smb=dir[,smbserver=addr]]\n"
>   #endif
> @@ -2137,6 +2137,18 @@ qemu -net user,dnssearch=mgmt.example.org,dnssearch=example.org [...]
>   @item domainname=@var{domain}
>   Specifies the client domain name reported by the built-in DHCP server.
>   
> +@item route=@var{addr}/@var{mask}[:@var{gateway}]
> +Provides an entry for the classless static routes list sent by the built-in
> +DHCP server. More than one route can be transmitted by specifying
> +this option multiple times. If supported, this will cause the guest to
> +automatically set the given static routes instead of the given default gateway.
> +If @var{gateway} is not specified, the default gateway will be used.
> +
> +Example:
> +@example
> +qemu -net user,route=10.0.2.0/24,route=192.168.0.0/16 [...]
> +@end example

Can we please spell that '--net', along the lines of 
https://wiki.qemu.org/BiteSizedTasks#Consistent_option_usage_in_documentation
Benjamin Drung March 8, 2018, 8:07 p.m. UTC | #2
Am Donnerstag, den 08.03.2018, 13:46 -0600 schrieb Eric Blake:
> On 03/08/2018 12:57 PM, Benjamin Drung wrote:
> > This patch will allow the user to specify classless static routes
> > for
> > the replies from the built-in DHCP server.
> > 
> > Signed-off-by: Benjamin Drung <benjamin.drung@profitbricks.com>
> > ---
> 
> For future patches, when sending a v2, it's best to document here
> (after 
> the --- separator) what changed from v1.  It's also a good idea to
> send 
> a fresh thread rather than tying your v2 in-reply-to your v1, so that
> it 
> doesn't get buried in an old conversation.
> 
> More submission hints at https://wiki.qemu.org/Contribute/SubmitAPatch

Thanks. I will do that with the next iteration. Patch v2 addressed all
remarks from Samuel Thibault.

> > +++ b/qapi/net.json
> > @@ -163,6 +163,9 @@
> >   # @domainname: guest-visible domain name of the virtual
> > nameserver
> >   #              (since 2.12)
> >   #
> > +# @route: guest-visible static classless route of the virtual
> > nameserver
> > +#         (since 2.12)
> > +#
> >   # @ipv6-prefix: IPv6 network prefix (default is fec0::) (since
> >   #               2.6). The network prefix is given in the usual
> >   #               hexadecimal IPv6 address notation.
> > @@ -201,6 +204,7 @@
> >       '*dns':       'str',
> >       '*dnssearch': ['String'],
> >       '*domainname': 'str',
> > +    '*route':     ['String'],
> 
> I know we've used ['String'] for previous members, but that's rather 
> heavyweight - it transmits over QMP as:
> 
> "dnssearch": [ { "str": "foo" }, { "str": "bar" } ]
> 
> Nicer is ['str'], which transmits as:
> 
> "route": [ "foo", "bar" ]
> 
> so the question boils down to whether cross-member consistency is
> more 
> important than making your additions concise.

Agreed that ['str'] is nicer. I will update the patch.

> > +++ b/qemu-options.hx
> > @@ -1904,7 +1904,7 @@ DEF("netdev", HAS_ARG, QEMU_OPTION_netdev,
> >       "         [,ipv6[=on|off]][,ipv6-net=addr[/int]][,ipv6-
> > host=addr]\n"
> >       "         [,restrict=on|off][,hostname=host][,dhcpstart=addr]
> > \n"
> >       "         [,dns=addr][,ipv6-
> > dns=addr][,dnssearch=domain][,domainname=domain]\n"
> > -    "         [,tftp=dir][,bootfile=f][,hostfwd=rule][,guestfwd=ru
> > le]"
> > +    "         [,route=addr/mask[:gateway]][,tftp=dir][,bootfile=f]
> > [,hostfwd=rule][,guestfwd=rule]"
> 
> Urgh - your QMP interface HAS to be further parsed to get to the
> useful 
> information.  While it's nice to have compact syntax on the command 
> line, it is really worth thinking about making information easier to 
> consume (that is, NO further parsing required once the information is
> in 
> JSON format).  Would it be any better to send things over the wire
> as:
> 
> "route": [ { "addr": "...", "mask": 24, "gateway": "..." } ]

That's looks good.

> instead of cramming all the information into a single string?  But
> based 
> on the way this also maps to the command line, you may not have a
> choice 
> without a lot more code complexity.

Can you point me to an example where similar parsing is done?

> >   #ifndef _WIN32
> >                                                "[,smb=dir[,smbserve
> > r=addr]]\n"
> >   #endif
> > @@ -2137,6 +2137,18 @@ qemu -net
> > user,dnssearch=mgmt.example.org,dnssearch=example.org [...]
> >   @item domainname=@var{domain}
> >   Specifies the client domain name reported by the built-in DHCP
> > server.
> >   
> > +@item route=@var{addr}/@var{mask}[:@var{gateway}]
> > +Provides an entry for the classless static routes list sent by the
> > built-in
> > +DHCP server. More than one route can be transmitted by specifying
> > +this option multiple times. If supported, this will cause the
> > guest to
> > +automatically set the given static routes instead of the given
> > default gateway.
> > +If @var{gateway} is not specified, the default gateway will be
> > used.
> > +
> > +Example:
> > +@example
> > +qemu -net user,route=10.0.2.0/24,route=192.168.0.0/16 [...]
> > +@end example
> 
> Can we please spell that '--net', along the lines of 
> https://wiki.qemu.org/BiteSizedTasks#Consistent_option_usage_in_docum
> entation

I can change it, but then the documentation is inconsistent. There
are 75 lines with '-net' in qemu-options.hx, but only two lines
with '--net'.
Eric Blake March 8, 2018, 8:21 p.m. UTC | #3
On 03/08/2018 02:07 PM, Benjamin Drung wrote:
> Am Donnerstag, den 08.03.2018, 13:46 -0600 schrieb Eric Blake:
>> On 03/08/2018 12:57 PM, Benjamin Drung wrote:
>>> This patch will allow the user to specify classless static routes
>>> for
>>> the replies from the built-in DHCP server.
>>>
>>> Signed-off-by: Benjamin Drung <benjamin.drung@profitbricks.com>
>>> ---
>>
>> For future patches, when sending a v2, it's best to document here
>> (after
>> the --- separator) what changed from v1.  It's also a good idea to
>> send
>> a fresh thread rather than tying your v2 in-reply-to your v1, so that
>> it
>> doesn't get buried in an old conversation.
>>
>> More submission hints at https://wiki.qemu.org/Contribute/SubmitAPatch
> 
> Thanks. I will do that with the next iteration. Patch v2 addressed all
> remarks from Samuel Thibault.

At this point, since Samuel is the net maintainer, I'll trust his 
judgment on what interface works best; my review is only trying to make 
sure we don't bake in a UI mistake at the last minute (although we can 
adjust things during soft freeze, if needed).


>>>        '*dnssearch': ['String'],
>>>        '*domainname': 'str',
>>> +    '*route':     ['String'],
>>
>> I know we've used ['String'] for previous members, but that's rather
>> heavyweight - it transmits over QMP as:
>>
>> "dnssearch": [ { "str": "foo" }, { "str": "bar" } ]
>>
>> Nicer is ['str'], which transmits as:
>>
>> "route": [ "foo", "bar" ]
>>
>> so the question boils down to whether cross-member consistency is
>> more
>> important than making your additions concise.
> 
> Agreed that ['str'] is nicer. I will update the patch.

The problem is that ['str'] might not work easily for the command line 
glue; I'm more familiar with how QMP exposes things than with the 
command line parsing, and Markus, who is trying to improve command line 
parsing to share more common infrastructure with QMP, might have better 
comments on the topic, except that he's on leave for a few weeks and 
won't respond until after 2.12 is frozen.  Using ['String'] for 
consistency is therefore okay, if you can't get ['str'] working quickly.


>>> @@ -1904,7 +1904,7 @@ DEF("netdev", HAS_ARG, QEMU_OPTION_netdev,
>>>        "         [,ipv6[=on|off]][,ipv6-net=addr[/int]][,ipv6-
>>> host=addr]\n"

Here's an example where we made the command line smart.  ipv6-net takes 
TWO pieces of information: addr/int; on the QMP side, we spelled it 
'*ipv6-prefix':'str' + 'ipv6-prefixlen':'int'.  So somewhere in the 
command line parsing code for --net (which I'm less familiar with), 
there is some glue code taking the compact representation and splitting 
it into the more verbose but more direct QMP representation - well, that 
is, if we are converting it into QMP form at all (part of the problem is 
that our command line and runtime control don't always share code, 
although we're trying to get better at that).

>>> +    "         [,route=addr/mask[:gateway]][,tftp=dir][,bootfile=f]
>>> [,hostfwd=rule][,guestfwd=rule]"
>>
>> Urgh - your QMP interface HAS to be further parsed to get to the
>> useful
>> information.  While it's nice to have compact syntax on the command
>> line, it is really worth thinking about making information easier to
>> consume (that is, NO further parsing required once the information is
>> in
>> JSON format).  Would it be any better to send things over the wire
>> as:
>>
>> "route": [ { "addr": "...", "mask": 24, "gateway": "..." } ]
> 
> That's looks good.

Okay, doing that would mean using something like:

{ 'struct': 'RouteEntry', 'data': { 'addr': 'str', '*mask': 'int', 
'*gateway': 'str' } }
...
'route': [ 'RouteEntry' ]

(but reuse, rather than inventing a new type, if one of the existing QMP 
types already resembles what I proposed for RouteEntry)

The command line can still use route=addr/mask:gateway syntax, parse it 
down into components, then compile the QMP array of already-parsed 
structs (rather than making QMP take a direct ['String'] that still 
needs further parsing).  It may take more glue code, but the idea is 
that all the glue code should live on the front end, so that the QMP 
backend should be easy to work with.

> 
>> instead of cramming all the information into a single string?  But
>> based
>> on the way this also maps to the command line, you may not have a
>> choice
>> without a lot more code complexity.
> 
> Can you point me to an example where similar parsing is done?

Hopefully my hint about command-line ipv6-net gets you started (as I 
said, I'm less familiar with the specifics of net code, so much as 
taking the interface point of view here).

>>> +@example
>>> +qemu -net user,route=10.0.2.0/24,route=192.168.0.0/16 [...]
>>> +@end example
>>
>> Can we please spell that '--net', along the lines of
>> https://wiki.qemu.org/BiteSizedTasks#Consistent_option_usage_in_docum
>> entation
> 
> I can change it, but then the documentation is inconsistent. There
> are 75 lines with '-net' in qemu-options.hx, but only two lines
> with '--net'.

Yeah, there's that.  But hopefully someone will tackle the bite-sized 
task to get things consistent, and once they do, leaving fewer places 
that still need to be switched is nice.  I can live with either spelling 
until the bite-sized task is tackled, and am not implying you have to 
take on that task yourself, so much as pointing it out so you can choose 
if it is worth the nicer spelling for new content, or leaving it as-is 
to feel more consistent in the short term.
Benjamin Drung March 14, 2018, 7:07 p.m. UTC | #4
Am Donnerstag, den 08.03.2018, 14:21 -0600 schrieb Eric Blake:
> On 03/08/2018 02:07 PM, Benjamin Drung wrote:
> > Am Donnerstag, den 08.03.2018, 13:46 -0600 schrieb Eric Blake:
> > > On 03/08/2018 12:57 PM, Benjamin Drung wrote:
> > > >        '*dnssearch': ['String'],
> > > >        '*domainname': 'str',
> > > > +    '*route':     ['String'],
> > > 
> > > I know we've used ['String'] for previous members, but that's
> > > rather
> > > heavyweight - it transmits over QMP as:
> > > 
> > > "dnssearch": [ { "str": "foo" }, { "str": "bar" } ]
> > > 
> > > Nicer is ['str'], which transmits as:
> > > 
> > > "route": [ "foo", "bar" ]
> > > 
> > > so the question boils down to whether cross-member consistency is
> > > more
> > > important than making your additions concise.
> > 
> > Agreed that ['str'] is nicer. I will update the patch.
> 
> The problem is that ['str'] might not work easily for the command
> line 
> glue; I'm more familiar with how QMP exposes things than with the 
> command line parsing, and Markus, who is trying to improve command
> line 
> parsing to share more common infrastructure with QMP, might have
> better 
> comments on the topic, except that he's on leave for a few weeks and 
> won't respond until after 2.12 is frozen.  Using ['String'] for 
> consistency is therefore okay, if you can't get ['str'] working
> quickly.

['str'] works and was easily changeable.

> > > > @@ -1904,7 +1904,7 @@ DEF("netdev", HAS_ARG,
> > > > QEMU_OPTION_netdev,
> > > >        "         [,ipv6[=on|off]][,ipv6-net=addr[/int]][,ipv6-
> > > > host=addr]\n"
> 
> Here's an example where we made the command line smart.  ipv6-net
> takes 
> TWO pieces of information: addr/int; on the QMP side, we spelled it 
> '*ipv6-prefix':'str' + 'ipv6-prefixlen':'int'.  So somewhere in the 
> command line parsing code for --net (which I'm less familiar with), 
> there is some glue code taking the compact representation and
> splitting 
> it into the more verbose but more direct QMP representation - well,
> that 
> is, if we are converting it into QMP form at all (part of the problem
> is 
> that our command line and runtime control don't always share code, 
> although we're trying to get better at that).

The split is done net_client_init() before iterating over the options.
This is equivalent to having following command line parameter:

  [,ipv6-prefix=addr][,ipv6-prefixlen=int]

instead of

  [,ipv6-net=addr[/int]]

> > > > +    "         [,route=addr/mask[:gateway]][,tftp=dir][,bootfil
> > > > e=f]
> > > > [,hostfwd=rule][,guestfwd=rule]"
> > > 
> > > Urgh - your QMP interface HAS to be further parsed to get to the
> > > useful
> > > information.  While it's nice to have compact syntax on the
> > > command
> > > line, it is really worth thinking about making information easier
> > > to
> > > consume (that is, NO further parsing required once the
> > > information is
> > > in
> > > JSON format).  Would it be any better to send things over the
> > > wire
> > > as:
> > > 
> > > "route": [ { "addr": "...", "mask": 24, "gateway": "..." } ]
> > 
> > That's looks good.
> 
> Okay, doing that would mean using something like:
> 
> { 'struct': 'RouteEntry', 'data': { 'addr': 'str', '*mask': 'int', 
> '*gateway': 'str' } }
> ...
> 'route': [ 'RouteEntry' ]
> 
> (but reuse, rather than inventing a new type, if one of the existing
> QMP 
> types already resembles what I proposed for RouteEntry)
> 
> The command line can still use route=addr/mask:gateway syntax, parse
> it 
> down into components, then compile the QMP array of already-parsed 
> structs (rather than making QMP take a direct ['String'] that still 
> needs further parsing).  It may take more glue code, but the idea is 
> that all the glue code should live on the front end, so that the QMP 
> backend should be easy to work with.

The problem is that the opts visitor code only supports lists with a
single mandatory scalar member. Bigger changes are needed to support
splitting 'route'. I have looked into the code for several hours, but
found no simple and non-ugly way to add the splitting without major
changes to the code. I am willing to adapt the patch if someone changes
the opts visitor to support lists with multiple members.
diff mbox series

Patch

diff --git a/net/slirp.c b/net/slirp.c
index 8c08e5644f..237ca1f3c9 100644
--- a/net/slirp.c
+++ b/net/slirp.c
@@ -158,7 +158,7 @@  static int net_slirp_init(NetClientState *peer, const char *model,
                           const char *vnameserver, const char *vnameserver6,
                           const char *smb_export, const char *vsmbserver,
                           const char **dnssearch, const char *vdomainname,
-                          Error **errp)
+                          const StringList *vroutes, Error **errp)
 {
     /* default settings according to historic slirp */
     struct in_addr net  = { .s_addr = htonl(0x0a000200) }; /* 10.0.2.0 */
@@ -177,8 +177,12 @@  static int net_slirp_init(NetClientState *peer, const char *model,
     char buf[20];
     uint32_t addr;
     int shift;
+    unsigned int i;
     char *end;
+    unsigned int route_count;
     struct slirp_config_str *config;
+    struct StaticRoute *routes = NULL;
+    const StringList *iter;
 
     if (!ipv4 && (vnetwork || vhost || vnameserver)) {
         error_setg(errp, "IPv4 disabled but netmask/host/dns provided");
@@ -365,6 +369,61 @@  static int net_slirp_init(NetClientState *peer, const char *model,
         return -1;
     }
 
+    iter = vroutes;
+    route_count = 0;
+    while (iter) {
+        route_count++;
+        iter = iter->next;
+    }
+    routes = g_malloc(route_count * sizeof(StaticRoute));
+
+    i = 0;
+    iter = vroutes;
+    while(iter != NULL) {
+        char buf2[20];
+        const char *gateway = iter->value->str;
+        const char *mask;
+        char *end;
+        long mask_width;
+
+        // Split "subnet/mask[:gateway]" into its components
+        if (get_str_sep(buf2, sizeof(buf2), &gateway, ':') < 0) {
+            // Fallback to default gateway
+            routes[i].gateway.s_addr = host.s_addr;
+            mask = gateway;
+        } else {
+            if (!inet_aton(gateway, &routes[i].gateway)) {
+                error_setg(errp, "Failed to parse route gateway '%s'", gateway);
+                return -1;
+            }
+            mask = buf2;
+        }
+
+        if (get_str_sep(buf, sizeof(buf), &mask, '/') < 0) {
+            error_setg(errp, "Failed to parse route: No slash found in '%s'",
+                       mask);
+            return -1;
+        }
+        if (!inet_aton(buf, &routes[i].subnet)) {
+            error_setg(errp, "Failed to parse route subnet '%s'", buf);
+            return -1;
+        }
+
+        mask_width = strtol(mask, &end, 10);
+        if (*end != '\0') {
+            error_setg(errp,
+                       "Failed to parse netmask '%s' (trailing chars)", mask);
+            return -1;
+        } else if (mask_width < 0 || mask_width > 32) {
+            error_setg(errp,
+                       "Invalid netmask provided (must be in range 0-32)");
+            return -1;
+        }
+        routes[i].mask_width = (uint8_t)mask_width;
+
+        iter = iter->next;
+        i++;
+    }
 
     nc = qemu_new_net_client(&net_slirp_info, peer, model, name);
 
@@ -377,7 +436,8 @@  static int net_slirp_init(NetClientState *peer, const char *model,
     s->slirp = slirp_init(restricted, ipv4, net, mask, host,
                           ipv6, ip6_prefix, vprefix6_len, ip6_host,
                           vhostname, tftp_export, bootfile, dhcp,
-                          dns, ip6_dns, dnssearch, vdomainname, s);
+                          dns, ip6_dns, dnssearch, vdomainname,
+                          route_count, routes, s);
     QTAILQ_INSERT_TAIL(&slirp_stacks, s, entry);
 
     for (config = slirp_configs; config; config = config->next) {
@@ -409,6 +469,7 @@  static int net_slirp_init(NetClientState *peer, const char *model,
     return 0;
 
 error:
+    g_free(routes);
     qemu_del_net_client(nc);
     return -1;
 }
@@ -964,7 +1025,8 @@  int net_init_slirp(const Netdev *netdev, const char *name,
                          user->ipv6_host, user->hostname, user->tftp,
                          user->bootfile, user->dhcpstart,
                          user->dns, user->ipv6_dns, user->smb,
-                         user->smbserver, dnssearch, user->domainname, errp);
+                         user->smbserver, dnssearch, user->domainname,
+                         user->route, errp);
 
     while (slirp_configs) {
         config = slirp_configs;
diff --git a/qapi/net.json b/qapi/net.json
index 36589857f4..29118a2f01 100644
--- a/qapi/net.json
+++ b/qapi/net.json
@@ -163,6 +163,9 @@ 
 # @domainname: guest-visible domain name of the virtual nameserver
 #              (since 2.12)
 #
+# @route: guest-visible static classless route of the virtual nameserver
+#         (since 2.12)
+#
 # @ipv6-prefix: IPv6 network prefix (default is fec0::) (since
 #               2.6). The network prefix is given in the usual
 #               hexadecimal IPv6 address notation.
@@ -201,6 +204,7 @@ 
     '*dns':       'str',
     '*dnssearch': ['String'],
     '*domainname': 'str',
+    '*route':     ['String'],
     '*ipv6-prefix':      'str',
     '*ipv6-prefixlen':   'int',
     '*ipv6-host':        'str',
diff --git a/qemu-options.hx b/qemu-options.hx
index 8e88ba6b36..6025f64dfd 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1904,7 +1904,7 @@  DEF("netdev", HAS_ARG, QEMU_OPTION_netdev,
     "         [,ipv6[=on|off]][,ipv6-net=addr[/int]][,ipv6-host=addr]\n"
     "         [,restrict=on|off][,hostname=host][,dhcpstart=addr]\n"
     "         [,dns=addr][,ipv6-dns=addr][,dnssearch=domain][,domainname=domain]\n"
-    "         [,tftp=dir][,bootfile=f][,hostfwd=rule][,guestfwd=rule]"
+    "         [,route=addr/mask[:gateway]][,tftp=dir][,bootfile=f][,hostfwd=rule][,guestfwd=rule]"
 #ifndef _WIN32
                                              "[,smb=dir[,smbserver=addr]]\n"
 #endif
@@ -2137,6 +2137,18 @@  qemu -net user,dnssearch=mgmt.example.org,dnssearch=example.org [...]
 @item domainname=@var{domain}
 Specifies the client domain name reported by the built-in DHCP server.
 
+@item route=@var{addr}/@var{mask}[:@var{gateway}]
+Provides an entry for the classless static routes list sent by the built-in
+DHCP server. More than one route can be transmitted by specifying
+this option multiple times. If supported, this will cause the guest to
+automatically set the given static routes instead of the given default gateway.
+If @var{gateway} is not specified, the default gateway will be used.
+
+Example:
+@example
+qemu -net user,route=10.0.2.0/24,route=192.168.0.0/16 [...]
+@end example
+
 @item tftp=@var{dir}
 When using the user mode network stack, activate a built-in TFTP
 server. The files in @var{dir} will be exposed as the root of a TFTP server.
diff --git a/slirp/bootp.c b/slirp/bootp.c
index 9e7b53ba94..5ca3b74e3b 100644
--- a/slirp/bootp.c
+++ b/slirp/bootp.c
@@ -160,6 +160,7 @@  static void bootp_reply(Slirp *slirp, const struct bootp_t *bp)
     int dhcp_msg_type, val;
     uint8_t *q;
     uint8_t client_ethaddr[ETH_ALEN];
+    uint8_t significant_octets[slirp->route_count];
 
     /* extract exact DHCP msg type */
     dhcp_decode(bp, &dhcp_msg_type, &preq_addr);
@@ -306,6 +307,25 @@  static void bootp_reply(Slirp *slirp, const struct bootp_t *bp)
             q += val;
         }
 
+        if (slirp->route_count > 0) {
+            uint8_t option_length = 0;
+
+            for (int i = 0; i < slirp->route_count; i++) {
+                significant_octets[i] = (slirp->routes[i].mask_width + 7) / 8;
+                option_length += significant_octets[i] + 5;
+            }
+
+            *q++ = RFC3442_CLASSLESS_STATIC_ROUTE;
+            *q++ = option_length;
+            for (int i = 0; i < slirp->route_count; i++) {
+                *q++ = slirp->routes[i].mask_width;
+                memcpy(q, &slirp->routes[i].subnet.s_addr, significant_octets[i]);
+                q += significant_octets[i];
+                memcpy(q, &slirp->routes[i].gateway.s_addr, 4);
+                q += 4;
+            }
+        }
+
         if (slirp->vdnssearch) {
             size_t spaceleft = sizeof(rbp->bp_vend) - (q - rbp->bp_vend);
             val = slirp->vdnssearch_len;
diff --git a/slirp/bootp.h b/slirp/bootp.h
index 394525733e..60bef4e80d 100644
--- a/slirp/bootp.h
+++ b/slirp/bootp.h
@@ -71,6 +71,8 @@ 
 #define RFC2132_RENEWAL_TIME    58
 #define RFC2132_REBIND_TIME     59
 
+#define RFC3442_CLASSLESS_STATIC_ROUTE	121
+
 #define DHCPDISCOVER		1
 #define DHCPOFFER		2
 #define DHCPREQUEST		3
diff --git a/slirp/libslirp.h b/slirp/libslirp.h
index 740408a96e..3d2e395b08 100644
--- a/slirp/libslirp.h
+++ b/slirp/libslirp.h
@@ -5,6 +5,12 @@ 
 
 typedef struct Slirp Slirp;
 
+typedef struct StaticRoute {
+    struct in_addr subnet;
+    uint8_t mask_width;
+    struct in_addr gateway;
+} StaticRoute;
+
 int get_dns_addr(struct in_addr *pdns_addr);
 int get_dns6_addr(struct in6_addr *pdns6_addr, uint32_t *scope_id);
 
@@ -16,7 +22,8 @@  Slirp *slirp_init(int restricted, bool in_enabled, struct in_addr vnetwork,
                   const char *tftp_path, const char *bootfile,
                   struct in_addr vdhcp_start, struct in_addr vnameserver,
                   struct in6_addr vnameserver6, const char **vdnssearch,
-                  const char *vdomainname, void *opaque);
+                  const char *vdomainname, unsigned int routes_count,
+                  const StaticRoute *vroutes, void *opaque);
 void slirp_cleanup(Slirp *slirp);
 
 void slirp_pollfds_fill(GArray *pollfds, uint32_t *timeout);
diff --git a/slirp/slirp.c b/slirp/slirp.c
index 4f29753444..4e5f249eeb 100644
--- a/slirp/slirp.c
+++ b/slirp/slirp.c
@@ -286,7 +286,8 @@  Slirp *slirp_init(int restricted, bool in_enabled, struct in_addr vnetwork,
                   const char *tftp_path, const char *bootfile,
                   struct in_addr vdhcp_start, struct in_addr vnameserver,
                   struct in6_addr vnameserver6, const char **vdnssearch,
-                  const char *vdomainname, void *opaque)
+                  const char *vdomainname, unsigned int route_count,
+                  const StaticRoute *vroutes, void *opaque)
 {
     Slirp *slirp = g_malloc0(sizeof(Slirp));
 
@@ -321,6 +322,9 @@  Slirp *slirp_init(int restricted, bool in_enabled, struct in_addr vnetwork,
     slirp->vdhcp_startaddr = vdhcp_start;
     slirp->vnameserver_addr = vnameserver;
     slirp->vnameserver_addr6 = vnameserver6;
+    slirp->route_count = route_count;
+    slirp->routes = g_malloc(route_count * sizeof(StaticRoute));
+    memcpy(slirp->routes, vroutes, route_count * sizeof(StaticRoute));
 
     if (vdnssearch) {
         translate_dnssearch(slirp, vdnssearch);
@@ -351,6 +355,7 @@  void slirp_cleanup(Slirp *slirp)
     g_free(slirp->tftp_prefix);
     g_free(slirp->bootp_filename);
     g_free(slirp->vdomainname);
+    g_free(slirp->routes);
     g_free(slirp);
 }
 
diff --git a/slirp/slirp.h b/slirp/slirp.h
index 10b410898a..3c81b7f7cc 100644
--- a/slirp/slirp.h
+++ b/slirp/slirp.h
@@ -194,6 +194,8 @@  struct Slirp {
     size_t vdnssearch_len;
     uint8_t *vdnssearch;
     char *vdomainname;
+    unsigned int route_count;
+    struct StaticRoute *routes;
 
     /* tcp states */
     struct socket tcb;