Computer Old Farts Forum
 help / color / mirror / Atom feed
From: gtaylor at tnetconsulting.net (Grant Taylor)
Subject: [COFF] A little networking tool to reduce having to run emulators with privilege
Date: Tue, 22 Sep 2020 19:54:52 -0600	[thread overview]
Message-ID: <b94c3a89-b6ca-b7d4-dd24-ddf7c00283c9@spamtrap.tnetconsulting.net> (raw)
In-Reply-To: <20200922215309.a4ey9%steffen@sdaoden.eu>

On 9/22/20 3:53 PM, Steffen Nurpmeso wrote:
> Hello.

Hi,

> And that is fuzzy on my side, the best i have heard was on some 
> FreeBSD not too long ago, where the same problem exists.  ..Yes. 
> This is exactly the message i remembered:

Hum.

I've added an LACP Link Aggregation Group as a member to a bridge 
multiple times.

I would NEVER create an LACP Ling Aggregation Group between a wired and 
a wireless connection.  I would expect that to NOT work.

> Nothing.  I only set the route.

Hum....

> Ha.  That could very well be because i was desperately trying to 
> create a bridge all the time, but it just was not working at all. 
> So i turned to proxy_arp "pseudo-bridging", with just having routes and 
> the TAP devices for the VMs, nothing more.  A wild chaos universe thus.

Were you trying to bridge things to a wireless NIC?

> You know, to me this is just a programmatic problem, i just do 
> not understand.  Why does it matter whether you have eth0 or wlp1s0?

IMHO the name of the device doesn't matter.

But the name does imply what type of device it is.  eth0 is almost 
always wired (but there is no guarantee).  After looking it up, wlp1s0 
seems to imply Wi-Fi.

Wi-Fi tends to imply other problems specific to Wi-Fi.

> I can go into the internet with both,

Yes.

> why can i create a bridge on one but not the other?

Because some Wi-Fi cards have problems related to multiple MAC 
addresses.  Problems like they simply refuse to allow them.

So the problem that it sounds like you're running into is that the Wi-Fi 
is refusing to do anything useful with the Ethernet frames that are 
being bridged to it.

Aside:  EBTables may be able to help resolve this problem.  But that's 
another kettle of fish.

> That does not make sense.

Once you understand some of Wi-Fi's inherent limitations, it should also 
make sense to you.

> Just do it?

It (Wi-Fi) probably can't or won't do anything useful with an Ethernet 
frame that has a different source MAC address.

Ergo, bridging with Wi-Fi typically is problematic or simply doesn't 
work.  It's a limitation of Wi-Fi, not bridging technology.

> It works when i inject a VETH pair, so may it be like this.

/How/ are you injecting with a vEth pair?

You say you aren't bridging.  You indicate that you have used Proxy ARP 
in the past and that you aren't doing so now.

So I'm not entirely sure what you're doing currently.  I'd have to 
re-read and scrutinize emails in this thread again.

> Having the bridge now makes things easy, i just make it the master 
> of anything which is plugged into it.  Yes, so easy are things if 
> you never programmed a network hardware driver!

What all are you plugging into it?

Are you referring to plugging the single vEth in the network namespace?

> I do not use a bridge on the host.  This i cannot do.

I trust that you believe what you are saying.  I question the deep 
technical merits of it.  Including using things like EBTables to NAT* 
the source MAC address to that of thee Wi-Fi card.

*NAT typically applies to layer 3 IP addresses.  But the same concept is 
being done to layer 3 Ethernet addresses.

> But it makes things so easy now.  You have seen the scripts, and on 
> the host i see
> 
>    #?0|kent:tmp$ ip rou
>    default via 192.168.0.1 dev wlp1s0 proto dhcp src 192.168.0.153 metric 306
>    10.0.0.0/8 dev v_n proto kernel scope link src 10.0.0.1
>    10.0.0.1 dev v_n scope link
>    192.168.0.0/24 dev wlp1s0 proto dhcp scope link src 192.168.0.153 metric 306
>    #?0|kent:tmp$ ip a
>    ...
>    6: wlp1s0: ...
>        inet 192.168.0.153/24 brd 192.168.0.255 scope global dynamic noprefixroute wlp1s0
>           valid_lft 69766sec preferred_lft 58966sec
>    8: v_n at if7: ...
>        inet 10.0.0.1/8 scope global v_n
>           valid_lft forever preferred_lft forever

That's the first clear picture that I've had of the host side.  (Perhaps 
I mis-read something before.)

Do other things on your network have any access to what's running in the 
network namespace?  Or is it only accessible by your host?

> and in the namespace
> 
>    #?0|kent:~# ip netns exec v_ns ip rou
>    default via 10.0.0.1 dev v_br
>    10.0.0.0/8 dev v_br proto kernel scope link src 10.1.0.1
>    #?0|kent:~# ip netns exec v_ns ip a
>    ...
>    6: v_br: ..
>        inet 10.1.0.1/8 brd 10.255.255.255 scope global v_br
>           valid_lft forever preferred_lft forever
>        inet6 fe80::dc81:96ff:fe0b:a229/64 scope link
>           valid_lft forever preferred_lft forever
>    7: v_i at if8: ..
>        link/ether fe:7f:36:b0:04:97 brd ff:ff:ff:ff:ff:ff link-netnsid 0
>        inet6 fe80::fc7f:36ff:feb0:497/64 scope link
>           valid_lft forever preferred_lft forever
> 
> And i started a VM for you
> 
>    8: vm_ulinux-010204: ..
>        link/ether ce:4a:41:5c:d6:61 brd ff:ff:ff:ff:ff:ff
>        inet6 fe80::cc4a:41ff:fe5c:d661/64 scope link
>         valid_lft forever preferred_lft forever
> 
> No address no route setup,

Why not add an IP address to the vm_ulinux-010204 interface?  Much like 
you've added to the v_br interface above.

> and in the machine
> 
>    $ cat default/net
>    TYPE=static
>    DEV=eth0
>    ADDR=10.0.1.15
>    MASK=8
>    GW=10.0.0.1
> 
> Except for using a DHCP server in the namespace this is as short as it 
> can get.  Of course if i would use that it would be even less work to 
> do when setting up a VM.  And even more flexible and automatic.  But, 
> you know, this is so overkill given that i use this only for testing, 
> and dhcpcd is now privilege-separated:

I get the lack of motivation for DHCP inside of network namespaces.

Especially when the IP address(es) used in the network namespace can be 
derived from the name of the network namespace.

>    #?0|kent:src$ pla|grep dhcpc
>    dhcpcd     509     1 S     0.0  1748 dhcpcd /sbin/dhcpcd -h kent -z wlp1s0
>    root       510   509 S     0.0  2396 dhcpcd /sbin/dhcpcd -h kent -z wlp1s0
>    dhcpcd     511   509 S     0.0   268 dhcpcd /sbin/dhcpcd -h kent -z wlp1s0
>    dhcpcd     512   509 S     0.0   268 dhcpcd /sbin/dhcpcd -h kent -z wlp1s0
>    dhcpcd    7619   510 S     0.0   376 dhcpcd /sbin/dhcpcd -h kent -z wlp1s0

Why do you have as many things running dhcpcd against the same interface?

> And this twice all week long for in practice nothing?  Ah, no. 
> And what if i move along, i have to have dhcpcd, or configure dnsmasq 
> to serve it for the namespace.  And so i can use a simple hosts.txt 
> and have dnsmasq integrate it in its normal DNS service, this would 
> not be that easy if it would be dynamic, i had to look.

Hence why I prefer to not use DHCP inside of network namespaces.  ;-)

I think we're in agreement about how addresses are assigned.  Or at 
least that DHCP is an unnecessary complication.

> Anyhow, no network setup at all on in the namespace, i have the 
> hosts.txt that i need anyway, and i configure the machine once i 
> install it.  Done.
> 
> It is terrible.  Nothing HOWTO like, not "help the people to help 
> themselves", but everybody who understood a topic by himself is quick 
> in fooling others.  This makes the FreeBSD handbook and the BSDs and 
> their manual portfolio in general outstanding.

Ya.  I think that a lot of documentation for things that are post TLDP's 
heyday are lacking considerably.

I've had to dig through a lot of texts, scripts, watch a lot of videos, 
read man pages, and do lots of experimentation with network namespaces 
to get to where I am now.  I'm always happy to share what I know.

> Don't confuse me please, i am .. not a network expert.  Surely you 
> could do use firewall stuff, but i do not.  At least nothing special, 
> very restrictive indeed, but 10.0.0.0 is set free early, and other...

I'm not trying to confuse you.  I'm just pointing out that the host 
firewall /can/ mess with things in some situations.  So, I advise you to 
not assume that it can't.

> Ah yes, i have forgotten this line:
> 
>    if [ -n "$VM_NS" ]; then
>       ${iptables} -t nat -A POSTROUTING -o ${what} -j MASQUERADE
>       #echo 1 > /proc/sys/net/ipv4/conf/${what}/proxy_arp
>    fi
> 
> Here $what is the device, wlp1s0 for example.  True.

Okay.

That gives your network namespace access to the rest of the network (and 
probably the Internet).


> Of course.  The comment is a leftover.

;-)

> Actually yes.  In fact i have booted into 4.19 again today because 
> RTW88 is totally unusable here, at least after the first suspend/resume 
> and even though they added the rtw88_pci.disable_aspm=1 kernel command 
> line switch to work around power management problems.

Power management can be a nightmare for networking (and other things).

I now see that RTW88 is a Realtek /Wireless/ NIC.  That makes a lot of 
(if not all of) the problems that you're describing make a lot more sense.

> In fact the driver messed the hardware so much that Linux was no 
> longer capable to access it, even booting 4.19 and using R8822BE thus 
> did not do it.  By sheer luck the friendly salesman gave me a 512 GB 
> NVME SSD for the price of a 256 GB last year, so i kept the maximally 
> minimized 30 GB Windows partition just for win (imagine that: 30 GB of 
> space .. wasted!), and booted into it, because of despair!  Of course 
> i had forgotten my password (i just wanted to log into Windows to see 
> how it looks once i bought the laptop, my last Windows login before 
> that was Windows 95 B), but on the welcome screen you could select 
> the network, and once that dialog wanted the password of the network 
> (!) i rebooted into Linux 4.19 .. and was alive again.  Sheer luck, 
> dammit, otherwise i would have been just dead.  Terrible!

It sounds like you partially wedged the wireless chip set.  That's not 
unheard of.  Sometimes a reboot will unwedge it.  Sometimes it requires 
a full power off and back on.  Sometimes you need to remove the battery. 
  A few times you need another utility that will try to initialize it in 
a different way (Windows qualifies here).

> This at least seems to be avoidable by using the above command 
> line switch.  Today it could be accessed after reboot.

Good.

> No.

I see that now.

> But i do not?

But you do.

   #?0|kent:~# ip netns exec v_ns ip a
   ...
   6: v_br: ..
       inet 10.1.0.1/8 brd 10.255.255.255 scope global v_br
          valid_lft forever preferred_lft forever
       inet6 fe80::dc81:96ff:fe0b:a229/64 scope link
          valid_lft forever preferred_lft forever
   7: v_i at if8: ..
       link/ether fe:7f:36:b0:04:97 brd ff:ff:ff:ff:ff:ff link-netnsid 0
       inet6 fe80::fc7f:36ff:feb0:497/64 scope link
          valid_lft forever preferred_lft forever

"ip netns exec v_ns ip a" runs "ip address" inside of the "v_ns" network 
namespace.  "v_br" looks like a bridge.  Your IP is bound to the v_br 
(bridge) interface.  The "v_i" interface, which your previous email 
indicated was the vEth that is inside of the network namespace.

So it /really/ looks to me like you /do/ have a bridge /inside/ of the 
network namespace and that you /are/ using it as part of your 
communications path.

Please do an "ip link show" inside the network namespace.

    ip netns exec v_ns ip l

I half way expect that the v_i interface will have a master of v_br.

For giggles, why don't you add a "-d" between ip and link.

    ip netns exec v_ns ip -d l

> Yes i understood that.  I would need to assign addresses to the VMs 
> once the VM starts, whereas now i only do that inside the VM.  Hm?.

That overall concept would not change.  But you would assign it to the 
v_i interface instead of the v_br interface.

> There is only one network namespace here.  One for all VMs.

Ah.  I had thought there were multiple network namespaces.  One per VM / 
emulator.

> You cannot create bridge devices on wireless interfaces, unless you 
> have a driver which does support that, or, i guess, you create your 
> own host access point, i dimly recall this could be a solution too.

I don't know if the driver that balks at multiple MACs will support 
being an access point.

Though I do wonder if it would be possible to leverage EBTables to play 
with MAC addresses to sooth the Wi-Fi NIC's heartburn at multiple MACs. 
}:-)

> No no, only libgcrypt...

That's all that /you/ personally are using it for.

But I thought you indicated that something else was unhappy if there 
wasn't a (u)random device.

> Yes.  That i have to do some time.

I'll look into cgroups some day.  I've not had a need to do so yet.

> Unfortunately true.  The complexity of cgroups and the Linux kernel 
> as such is however very, very much intensed compared to a FreeBSD 
> jail.  At least once jails appeared it often was nothing more than a 
> "if(process->jailed)" at the beginning of some kernel functions.

*nod*

I think that Linux still has some things to learn from BSD jails and 
Solaris zones.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20200922/ec5d1c97/attachment-0001.bin>


  reply	other threads:[~2020-09-23  1:54 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-20 22:28 athornton
2020-09-21 21:38 ` steffen
2020-09-22  0:19   ` gtaylor
2020-09-22 14:54     ` steffen
2020-09-22 18:15       ` gtaylor
2020-09-22 21:53         ` steffen
2020-09-23  1:54           ` gtaylor [this message]
2020-09-23 23:50             ` steffen
2020-09-24  2:58               ` gtaylor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b94c3a89-b6ca-b7d4-dd24-ddf7c00283c9@spamtrap.tnetconsulting.net \
    --to=coff@minnie.tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).