[Qemu-devel] Request - How to compile change User Mode Networking address space?

[Tony Su]

Hello,
Posting here because it seems that this problem requires ability to
understand the source and how to modify it which means it's likely
above the head of any User forums and mail lists. I have no experience
coding C although that likely should not be an issue here except for
the questions I ask at the end.

Problem:
Physical Network is configured with Class A Private Address space
using the default subnet mask. Although this would usually be
considered a stupid Admin mistake because it invalidates routing
from/to any network also using any part of the Class A Private Network
space, it's an easily anticipated mistake. Admins who don't know or
don't think when configuring their networks almost always use default
subnet masks and if more than one NetworkID is possible, usually the
first possible. Currently User Mode Networking is configured to use
part of the Class A Private Network space.

Possible contributing problem:
I haven't been able to find anyone who can confirm that the following
command <should> modify the User Mode Networking default address
space, but in any case does not work for my distro. I have yet to
determine if this problem is specific to my distro or not. See my
comment below relating to the second code block which is my most
recent gues as to why this command does not work.

qemu-kvm -net user,net=176.27.0.0/12,host=176.27.2.2,dhcpstart=176.27.0.20



Current Discovery:
In every place I've posted to, solutions have always centered around
configuring bridged and NAT virtual networks but of course none of
those solutions relate to User Mode Networking because because unlike
the other virtual networks, it looks like User Mode Networking
settings are hard coded during compilation and unlike others is
persisted within QEMU. After not finding any configuration files in my
installation (which would have been nice and I really recommend), I
concluded by process of elimination that the settings had to be hard
coded during compilation, and subsequent search verifies this.

Believe I've found the essential code in slirp.c, lines 134-147

static int net_slirp_init(NetClientState *peer, const char *model,
                          const char *name, int restricted,
                          const char *vnetwork, const char *vhost,
                          const char *vhostname, const char *tftp_export,
                          const char *bootfile, const char *vdhcp_start,
                          const char *vnameserver, const char *smb_export,
                          const char *vsmbserver, const char **dnssearch)
{
    /* default settings according to historic slirp */
    struct in_addr net  = { .s_addr = htonl(0x0a000200) }; /* 10.0.2.0 */
    struct in_addr mask = { .s_addr = htonl(0xffffff00) }; /* 255.255.255.0 */
    struct in_addr host = { .s_addr = htonl(0x0a000202) }; /* 10.0.2.2 */
    struct in_addr dhcp = { .s_addr = htonl(0x0a00020f) }; /* 10.0.2.15 */
    struct in_addr dns  = { .s_addr = htonl(0x0a000203) }; /* 10.0.2.3 */



But, I was also surprised to find the following lines in slirp.c, lines 168-185

    if (vnetwork) {
        if (get_str_sep(buf, sizeof(buf), &vnetwork, '/') < 0) {
            if (!inet_aton(vnetwork, &net)) {
                return -1;
            }
            addr = ntohl(net.s_addr);
            if (!(addr & 0x80000000)) {
                mask.s_addr = htonl(0xff000000); /* class A */
            } else if ((addr & 0xfff00000) == 0xac100000) {
                mask.s_addr = htonl(0xfff00000); /* priv. 172.16.0.0/12 */
            } else if ((addr & 0xc0000000) == 0x80000000) {
                mask.s_addr = htonl(0xffff0000); /* class B */
            } else if ((addr & 0xffff0000) == 0xc0a80000) {
                mask.s_addr = htonl(0xffff0000); /* priv. 192.168.0.0/16 */
            } else if ((addr & 0xffff0000) == 0xc6120000) {
                mask.s_addr = htonl(0xfffe0000); /* tests 198.18.0.0/15 */
            } else if ((addr & 0xe0000000) == 0xe0000000) {
                mask.s_addr = htonl(0xffffff00); /* class C */
            } else {
                mask.s_addr = htonl(0xfffffff0); /* multicast/reserved */
            }

So, my specific questions:

1. I'm not familiar with the numerical method used to define the
address spaces, I'm guessing that it's hexadecimal formatted two
places correspond to an octet? Regardless any decisions on main branch
code modification, I think I need to modify these lines to address my
immediate needs until any changes are made to the main branch(Please
verify I'm correct).

2. I don't understand the second block of code (lines 168-185), (I
didn't copy the entire code, you'd have to look at the slirp.c file
for the entire code block), but I'm thinking that it suggests possibly
using other private address spaces. Perhaps my attempt to modify the
address space didn't work because the command has to exactly match one
of these pre-configured options? If that is the case then the current
way the code is written is likely faulty because there is still a
decent likelihood of address conflicts, eg a VM with User Mode
Networking connecting over a VPN to a remote private network could
utilize at least 2 and maybe 3 private network address spaces, and all
the current options in the existing code block have a better than
average likelihood of conflicts. Bottom line, IMO hard coded address
spaces are a bad idea, it's better to permit User configuration of the
address space which would decisively eliminate NetworkID conflicts.

TIA and IMO,
Tony

If someone considers relevant,
This is on
x64 openSUSE 12.2
QEMU emulator version 1.1.1 (kvm-1.1.1-1.8.1)

Currently using build distributed through the official distro repos