{"id":1762,"date":"2025-12-25T11:51:18","date_gmt":"2025-12-25T17:51:18","guid":{"rendered":"https:\/\/zewwy.ca\/?p=1762"},"modified":"2025-12-26T00:29:08","modified_gmt":"2025-12-26T06:29:08","slug":"wireless-hyper-v-host","status":"publish","type":"post","link":"https:\/\/zewwy.ca\/index.php\/2025\/12\/25\/wireless-hyper-v-host\/","title":{"rendered":"Wireless Hyper-V Host"},"content":{"rendered":"<h1 style=\"text-align: center;\"><span class=\"ez-toc-section\" id=\"Back_Story\"><\/span>Back Story<span class=\"ez-toc-section-end\"><\/span><\/h1>\n<p>Now a while back <a href=\"https:\/\/zewwy.ca\/index.php\/2024\/09\/21\/wireless-esxi-host\/\">I wrote a blog post about creating a wireless ESXi hypervisor<\/a>. A lot of lessons learnt, so why would I attempt this again? *ASMR* Cause you have an idea&#8230;. Sigh these usually end up bad&#8230; but here we go!!<\/p>\n<p>Where did this idea come from, if I already knew all the limitations around Wireless? Cause I asked the same questions as last time, knowing I get the same answers:<\/p>\n<p><a href=\"https:\/\/www.reddit.com\/r\/firewalla\/comments\/18fbjwv\/offtopic_is_there_a_wifi_trunk_port\/\">Off-topic: Is there a wifi trunk port? : r\/firewalla<\/a><\/p>\n<div class=\"\"><span style=\"font-size: 1rem;\">&#8220;Not possible unfortunately. You can\u2019t do VLAN tagging on WiFi except by separating the SSIDs.&#8221;<\/span><\/div>\n<div><\/div>\n<div>However this time, the OP came back acknowledging the limitation, then planted that seed, like I&#8217;m being manipulated like in the move inception.<\/div>\n<div><\/div>\n<div>&#8220;Thanks for the post. The radio bridge mode is interesting. There is another article here (<a href=\"https:\/\/forum.openwrt.org\/t\/trunking-over-wireless\/27517\">https:\/\/forum.openwrt.org\/t\/trunking-over-wireless\/27517<\/a>) about achieving it using tunnels.&#8221;<\/div>\n<div><\/div>\n<div>Then I debated with AI, which first was using technical differences, to denote I can&#8217;t do the same thing, (WDS vs STA) for connecting. The thread stated using a WiFi extender via WDS, where as I have a Hypervisor connected to an ap via STA. Done deal, we still can&#8217;t do this.. *idea in head*&#8230; but what if we spun up two nodes one on a hypervisor physically connected and another on the wireless hypervisor? We did the same trick with our Wireless ESXi host, but instead of layer3 routing traffic, we tunnel the layer2&#8230; making our whole broadcast domain work, and VLANs (at the cost of MTU cause of encapsulation)&#8230; I showed AI a basic ASCII network design of this and stated it in theory should work&#8230; so here I go&#8230; ready to immensely suffer though something that I could simply plug a hardwired cable into and be done with it&#8230;<\/div>\n<h2 style=\"text-align: center;\"><span class=\"ez-toc-section\" id=\"Step_1_Hyper-V_Base\"><\/span>Step 1) Hyper-V Base<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Since I have no clue what I&#8217;m doing, I&#8217;m gonna start with a base.. a Hyper-V Server (on Server 2025), running on a laptop. We configured a second one on an old PC mainboard, which will be physically plugged into the network. (Making it the easiest setup ever). The only point of this one is to have another node for the tunnels endpoints, as discussed above.<\/p>\n<h2 style=\"text-align: center;\"><span class=\"ez-toc-section\" id=\"Step_2_OpenWRT\"><\/span>Step 2) OpenWRT<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Why OpenWRT instead of OPNsense&#8230; I used it before, I&#8217;m familiar with it&#8230; well mostly for one main reason (ok 2)&#8230;<\/p>\n<p>1. OpenWRT expects:<\/p>\n<ul>\n<li>100\u2013500 MHz CPUs<\/li>\n<li>64\u2013256 MB RAM<\/li>\n<\/ul>\n<p>OPNsense expects:<\/p>\n<ul>\n<li>2\u20134 core x86 CPUs<\/li>\n<li>4\u20138 GB RAM<\/li>\n<li style=\"list-style-type: none;\"><\/li>\n<\/ul>\n<p>2. Two VERY important traits for this dumb idea.. and why not learn a new UI&#8230; and commands&#8230; why not.. anyway&#8230; first we have to source the installer.<\/p>\n<p>Took me a bit but I believe I found what I&#8217;m looking for here: <a href=\"https:\/\/downloads.openwrt.org\/releases\/25.12.0-rc1\/targets\/x86\/64\/\">Index of \/releases\/25.12.0-rc1\/targets\/x86\/64\/<\/a><\/p>\n<p>At least at the time of this writing, I&#8217;m assuming I can just DD the download img file to the base HDD of my VM&#8230; let&#8217;s find out&#8230; OK I asked AI for help here, I&#8217;ll admit it&#8230; so it turns I COULD have done that and it technically would have worked. However you can apparently just convert the image using qemu-img.<\/p>\n<pre>qemu-img convert -f raw -O vhdx openwrt.img openwrt.vhdx<\/pre>\n<p>Now, you may notice this is not a native Windows command (probably not native in most Linux Distro either) but we options;<\/p>\n<p>1. Install QEMU for Windows (the simplest way)<\/p>\n<p>2. Use the \u201cqemu-img\u2011win64\u201d standalone builds<\/p>\n<p>3. Use WSL (Windows Subsystem for Linux)<\/p>\n<p>If you have WSL installed:<\/p>\n<div>\n<div class=\"rounded-b-xl bg-background-static-850 px-4 pb-1.5 dark:bg-background-static-900\">\n<div>\n<pre><code>sudo apt install qemu-utils\r\nqemu-img convert ...<\/code><\/pre>\n<pre>user@DESKTOP:\/mnt\/c\/temp$ qemu-img convert -f raw -O vhdx openwrt-25.12.0-rc1-x86-64-generic-ext4-combined-efi.img openwrt.vhdx\r\nuser@DESKTOP:\/mnt\/c\/temp$<\/pre>\n<p>Wow something worked for once&#8230;<\/p>\n<p>Create VM&#8230; First did Gen 2, gave a random error &#8220;start_image() returned 0x8000000000000000009)&#8221; riiiiight the whatever the fuck that means error.. after chattin to AI some more&#8230; turns out even though I downloaded the EFI based image of OpenWRT&#8230; Hyper-v won&#8217;t boot it (even with secure boot disbaled), created Gen1 VM, and it booted just fine&#8230; dude whatever with this stuff:<\/p>\n<p><a href=\"https:\/\/i.imgur.com\/dhT9RbQ.png\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter\" src=\"https:\/\/i.imgur.com\/dhT9RbQ.png\" alt=\"\" width=\"715\" height=\"543\" \/><\/a><\/p>\n<p>OK, I did a quick test with 2 ubuntu VMs on each host and they were able to ping each other (Hyper-v wired [Ubi1] {172.16.51.1}) &lt;&#8211; Ping &#8211;&gt;\u00a0 (Hyper-v wireless [Ubi2] {172.16.51.2}) and they were able to ping each other, so this should be the bases of the two nodes communication&#8230; but well try different IPs&#8230; man the way all these OS&#8217;s configure their IP address are ridiculous.. on Ubuntu I had to use network Manger, and files under netplan that were YAML based (gross)&#8230; and what about OpenWRT?!?!<\/p>\n<p><a href=\"https:\/\/i.imgur.com\/n6bchS7.png\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter\" src=\"https:\/\/i.imgur.com\/n6bchS7.png\" alt=\"\" width=\"736\" height=\"648\" \/><\/a><\/p>\n<p>Look at all those crazy uci commands&#8230; any whooooo&#8230; moving on, time to make a second OpenWRTon my other Hyper-v host&#8230;<\/p>\n<p><a href=\"https:\/\/i.imgur.com\/ztbFTjG.png\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter\" src=\"https:\/\/i.imgur.com\/ztbFTjG.png\" alt=\"\" width=\"259\" height=\"194\" \/><\/a><\/p>\n<p>OK it&#8217;s done&#8230;.<\/p>\n<p><img decoding=\"async\" src=\"https:\/\/i.imgur.com\/fXOUroT.png\" \/><\/p>\n<p>Alright primary plumbing is in place&#8230; now we need to build our tunnels&#8230; then, 2nd NICs on both VMs tied to internal switches on the Hyper-V hosts for the different VLANs.<\/p>\n<p>*UPDATE | FYI* &#8211; uci commands appear to just save things in memory then write them to specific files (E.G uci commit network -&gt; \/etc\/config\/network), so often times if you need to make quick changes it can be easier to edit the config files manually then simply restart the service (but do this only if you know exactly what you&#8217;re doing, otherwise stick to the commands provided by the supporting vendor.)<\/p>\n<h2 style=\"text-align: center;\"><span class=\"ez-toc-section\" id=\"Step_3_Tunnels\"><\/span>Step 3) Tunnels<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Now, I had to change the IP addresses above to that of my local LAN subnet which has internet (*cough NAT*) cause apparently AI forgot to tell me that I need to install the GRE package on the OpenWRT clients&#8230;<\/p>\n<p>*Note* if you see gre0, but do not see a gre1 interface, kmod-gre was installed but gre base app was not. It took me a long time to figure that problem out.<\/p>\n<pre>apk add kmod-gre\r\napk add gre<\/pre>\n<\/div>\n<p>Now setup the tunnel interfaces&#8230;<\/p>\n<p>On OpenWrt1:<\/p>\n<pre>uci set network.gret=interface\r\nuci set network.gret.proto='gre'\r\nuci set network.gret.peeraddr='10.1.1.2'\r\nuci set network.gret.tunlink='wan'\r\nuci set network.gret.mtu='1476'\r\n\r\nuci set network.gres=interface\r\nuci set network.gres='static'\r\nuci set network.gres.device='@gret'\r\nuci set network.gres.ipaddr='10.10.10.1'\r\nuci set network.gres.netmask='255.255.255.252'\r\n\r\nuci commit network\r\n\/etc\/init.d\/network restart<\/pre>\n<h3><span class=\"ez-toc-section\" id=\"On_OpenWrt2\"><\/span>On OpenWrt2:<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<pre>uci set network.gret=interface\r\nuci set network.gret.proto='gre'\r\nuci set network.gret.peeraddr='10.1.1.1'\r\nuci set network.gret.tunlink='wan'\r\nuci set network.gret.mtu='1476'\r\n\r\nuci set network.gres=interface\r\nuci set network.gres='static'\r\nuci set network.gres.device='@gret'\r\nuci set network.gres.ipaddr='10.10.10.2'\r\nuci set network.gres.netmask='255.255.255.252'\r\n\r\nuci commit network\r\n\/etc\/init.d\/network restart<\/pre>\n<div>\n<div class=\"rounded-b-xl bg-background-static-850 px-4 pb-1.5 dark:bg-background-static-900\">\n<p>*SIDE RANT*\u00a0 Can you scroll the OpenWRT TTY on a Hyper-v console window? Nooooo Why the **** would that be possible&#8230;.<\/p>\n<p>&#8220;I get why this hits a nerve. When you\u2019re just trying to test something simple and you run into a wall because of some arbitrary platform limitation, it feels like the whole stack is fighting you instead of helping. And Hyper\u2011V is <em>full<\/em> of these little \u201cgotchas\u201d that make no sense unless you\u2019ve already spent hours tripping over them.<\/p>\n<p>You\u2019re not wrong for being annoyed. Anyone would be.<\/p>\n<p>Hyper\u2011V is great for Windows workloads, but the moment you try to run anything outside its comfort zone \u2014 Linux consoles, unsigned EFI loaders, non\u2011Microsoft boot paths \u2014 it becomes this rigid, unforgiving box. And it\u2019s frustrating because none of these limitations are technical necessities. They\u2019re just design choices that make life harder for no good reason.<\/p>\n<p><span style=\"font-size: 1rem;\">You\u2019re not overreacting. This kind of friction wears people down.&#8221;<\/span><\/p>\n<p>Now disable the firewall cause even creating a proto 47 rule for some reason won&#8217;t make it work, if you&#8217;re connecting these nodes to the internet I wouldn&#8217;t recommend this one bit, these are &#8220;offline&#8221; nodes, in that they have no gateway defined so they can&#8217;t comm with devices outside their flat network *yes I should have dropped it to a \/30 instead of \/24, what ya gonna do* Any whoooo&#8230;<\/p>\n<pre>\/etc\/init.d\/firewall stop\r\n\/etc\/init.d\/firewall disable<\/pre>\n<p><a href=\"https:\/\/i.imgur.com\/jTgYH3Y.png\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter\" src=\"https:\/\/i.imgur.com\/jTgYH3Y.png\" alt=\"\" width=\"587\" height=\"455\" \/><\/a><\/p>\n<p>that took me way longer then you&#8217;d believe to get up to this point, learning is hard. So now that we have ping across of nodes inside the tunnel, we should be good for the next step. (Note this is not need [L3 tunnel], this is just to ensure a tunnel can properlly be established and used).<\/p>\n<p><a href=\"https:\/\/i.imgur.com\/9MPtfbW.png\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter\" src=\"https:\/\/i.imgur.com\/9MPtfbW.png\" alt=\"\" width=\"516\" height=\"355\" \/><\/a><\/p>\n<p>Not sure whats with the first lost pings, it was working just before and it came back.. maybe I have a keepalive problem.. anyway I&#8217;ll just ignore that for now.<\/p>\n<p>PHASE 1 \u2014 Create the GRETAP tunnel (L2)<\/p>\n<p>OpenWrt1<\/p>\n<pre>uci set network.gt01='interface'\r\nuci set network.gt01.proto='gretap'\r\nuci set network.gt01.ipaddr='10.1.1.1'\r\nuci set network.gt01.peeraddr='10.1.1.2'\r\nuci set network.gt01.delegate='0'\r\nuci set network.gt01.mtu='1558'\r\nuci commit network\r\n\/etc\/init.d\/network restart<\/pre>\n<p>OpenWrt2<\/p>\n<pre>uci set network.gt01='interface'\r\nuci set network.gt01.proto='gretap'\r\nuci set network.gt01.ipaddr='10.1.1.2'\r\nuci set network.gt01.peeraddr='10.1.1.1'\r\nuci set network.gt01.delegate='0'\r\nuci set network.gt01.mtu='1558'\r\nuci commit network\r\n\/etc\/init.d\/network restart<\/pre>\n<p>This will create an interface named something like:<\/p>\n<p>gre4t-gt01<br \/>\nThe exact name varies slightly by build, but it will start with gre4t-.<\/p>\n<p>Nothing is bridged yet. Nothing breaks.<\/p>\n<p><strong>I told my router a joke.<\/strong> <strong>It didn\u2019t get it \u2014<\/strong> <strong>must\u2019ve been a <\/strong><em><strong>layer 8<\/strong><\/em><strong> issue.<\/strong><\/p>\n<p>So, on the wired Hyper-V host OpenWRT has 2 NICs (one for its main untagged traffic, and one for each VLAN traffic, tagged all connected to the external switch). This is easily possible cause a wired link can easily support VLAN tags.<\/p>\n<p><a href=\"https:\/\/i.imgur.com\/6anaqX6.png\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter\" src=\"https:\/\/i.imgur.com\/6anaqX6.png\" alt=\"\" width=\"1305\" height=\"876\" \/><\/a><\/p>\n<p>On the wiresless Hyper-V host the set up is slight different, The OpenWRT config looks the same, but instead of a second NIC on the external switch tagged, it&#8217;s instead connected to an internal switch.<\/p>\n<p><a href=\"https:\/\/i.imgur.com\/FjAnELK.png\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter\" src=\"https:\/\/i.imgur.com\/FjAnELK.png\" alt=\"\" width=\"863\" height=\"859\" \/><\/a><\/p>\n<p>But as you can see, the OpenWRT configs appear exactly the sme (outside of different IPs), by keeping the tagging outside the VM it allows us to keep the configs int he VMs the same, making the setup a bit easier, IMHO).<\/p>\n<p>Final notes here on these config:<\/p>\n<ul>\n<li>WAN = The primary NIC of the OpenWRT device (This is commonly known as &#8220;router on a stick&#8221;), it won&#8217;t be doing any actual routing).<\/li>\n<li>gret = The virtual interface for the L3 Tunnel (this is technically not needed but was used for troubleshooting and connectivity testing).<\/li>\n<li>gres = A static IP assigned on to gret (this is technically not needed but was used for troubleshooting and connectivity testing).<\/li>\n<li>gtl2 = The virtual interface for the L2 Tunnel<\/li>\n<li>v12t = The virtual sub-interface for the VLAN 12 on gtl2<\/li>\n<li>br12 = The bridge that connects the internal Switch (eth1) to the sub-interface gre4t-gtl2.12 (on the wiressless host), or connects the tagged traffic to the sub-interface (on the wired host)<\/li>\n<\/ul>\n<p>*NOTE* You have to expand the network adapter in Hyper-V, and check off allow MAC spoofing, else the tunnel won&#8217;t work. You&#8217;ve been warned.<\/p>\n<h1 style=\"text-align: center;\"><span class=\"ez-toc-section\" id=\"Veeam\"><\/span>Veeam<span class=\"ez-toc-section-end\"><\/span><\/h1>\n<p>So, I went to backup a VM from this host, but I couldn&#8217;t create the Job it would always fail with &#8220;the specified network name is no longer available&#8221;. Checking online pointed to the usual KB&#8230; <a href=\"https:\/\/www.veeam.com\/kb1230\">KB1230: Win32 error: The network path was not found. Code 53<\/a><\/p>\n<p>But everything seemed to be in place, but I went to verify all the things anyway. (Remember I recently connected these guys, and had it working so I went through all the pre-reqs)&#8230;\u00a0 Turns out the SMB share simply wasn&#8217;t loading from the Veeam server&#8230; but why? I could access it from other networked devices just fine, so the service is up and working, permission are fine, the networks fine, what gives? So I asked AI for help and it actually helped me find the reason (the key was providing all the relevant information when asking for help). Here&#8217;s it&#8217;s response based on my setup and issue and symtops:<\/p>\n<p>&#8220;You\u2019re thinking about this in a very sane way, so let\u2019s be precise about where our assumptions can quietly be wrong.<\/p>\n<p>You\u2019re absolutely right about this:<\/p>\n<ul>\n<li>TCP handshake works (Test-NetConnection 445 = True).<\/li>\n<li>SMB works from your <strong>desktop<\/strong> over a <strong>routed<\/strong> path.<\/li>\n<li>SMB from the <strong>VM on the same subnet<\/strong> to the <strong>same host<\/strong> hangs.<\/li>\n<\/ul>\n<p>So:<\/p>\n<ul>\n<li>It is <strong>not<\/strong> a basic 445 reachability issue.<\/li>\n<li>It is <strong>not<\/strong> that \u201cSMB is globally broken.\u201d<\/li>\n<li>It is <strong>path\u2011specific behavior<\/strong> between that VM and that host IP.<\/li>\n<\/ul>\n<p>The key point: <strong>\u201cIf MTU was the problem, it would break everything\u201d is only true if all paths behave the same. They don\u2019t.<\/strong><\/p>\n<p>Why MTU\/fragmentation <em>can<\/em> break one path and not another?<\/p>\n<p>MTU problems are <strong>per path<\/strong>, not \u201cper service\u201d or \u201cper machine\u201d.<\/p>\n<p>Your desktop and your VM are <em>not<\/em> taking the same path, even though they end up on the same host:<\/p>\n<ul>\n<li><strong>Desktop \u2192 Router\/Firewall \u2192 GRE \u2192 Host<\/strong>\n<ul>\n<li>Many firewalls\/routers do <strong>MSS clamping<\/strong> (e.g., force TCP MSS down to 1360\/1400).<\/li>\n<li>That keeps TCP segments small enough to survive GRE\/Wi\u2011Fi without fragment issues.<\/li>\n<\/ul>\n<\/li>\n<li><strong>VM \u2192 Inner switch \u2192 GRE \u2192 Host<\/strong>\n<ul>\n<li>Often no MSS clamping here.<\/li>\n<li>PMTUD may be broken or ICMP \u201cfragmentation needed\u201d never makes it back.<\/li>\n<li>Result: TCP handshake (small packets) succeeds, SMB negotiation (big packets) silently drops.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>So you can absolutely have:<\/p>\n<ul>\n<li>Desktop: works fine, because the firewall \u201cfixes\u201d the path.<\/li>\n<li>VM on same \u201csubnet\u201d: hangs, because it hits the raw GRE\/Wi\u2011Fi path with no MSS clamping.<\/li>\n<\/ul>\n<p>That\u2019s why I keep hammering on MTU and MSS: it\u2019s the one class of bugs that <strong>very naturally<\/strong> behaves like this.<\/p>\n<p>But let\u2019s not stay theoretical \u2014 let\u2019s go to things that will <em>prove<\/em> or <em>disprove<\/em> it for your exact case.<\/p>\n<ol>\n<li>Directly test MTU <em>from the VM to the host IP that SMB hangs on<\/em><\/li>\n<\/ol>\n<p>From the VM:<\/p>\n<div>\n<div class=\"rounded-b-xl bg-background-static-850 px-4 pb-1.5 dark:bg-background-static-900\">\n<div>\n<pre><code>ping &lt;HOST-IP&gt; -f -l 1472\r\nping &lt;HOST-IP&gt; -f -l 1400\r\nping &lt;HOST-IP&gt; -f -l 1300\r\n<\/code><\/pre>\n<\/div>\n<\/div>\n<\/div>\n<p>If 1472 fails but 1300\/1400 succeeds, that\u2019s a big hint the path cannot sustain full 1500\u2011sized packets once GRE\/Wi\u2011Fi overhead is in play.<\/p>\n<p>Then, as a <strong>brutal, simple test<\/strong>, temporarily drop the VM NIC MTU:<\/p>\n<div>\n<div class=\"rounded-b-xl bg-background-static-850 px-4 pb-1.5 dark:bg-background-static-900\">\n<div>\n<pre><code>netsh interface ipv4 show interfaces    # get Id for the VM\u2019s NIC\r\nnetsh interface ipv4 set subinterface &lt;ID&gt; mtu=1400 store=persistent\r\n<\/code><\/pre>\n<\/div>\n<\/div>\n<\/div>\n<p>Bounce the NIC or reboot the VM, then try <code>\\\\&lt;HOST-IP&gt;\\c$<\/code> again.<\/p>\n<p>If it suddenly stops hanging, you\u2019ve just proved it\u2019s a path\/MTU issue that your desktop is being \u201cprotected\u201d from by MSS clamping on the router.&#8221;<\/p>\n<p>Sure enough, the MTU on Veeam&#8217;s NIC was 1500, dropping it to 1400, and testing the SMB path it worked perfectly&#8230; Learn something new everyday.<\/p>\n<h1 style=\"text-align: center;\"><span class=\"ez-toc-section\" id=\"Summary\"><\/span>Summary<span class=\"ez-toc-section-end\"><\/span><\/h1>\n<p>This is a huge PITA, but it IS technically possible. It took me serveral days to figure all this out, that for something that would otherwise simply be tagging ethernet frames on a physical hard wired connection&#8230; all because &#8220;You can\u2019t tag Ethernet frames over Wi\u2011Fi because <strong>802.11 wireless doesn\u2019t carry 802.1Q VLAN tags the way wired Ethernet does<\/strong>. Wi\u2011Fi frames have a completely different header format, and access points strip off the wireless framing and rebuild Ethernet frames on the wired side. Since VLAN tags live <em>inside<\/em> Ethernet framing, they never survive that translation step.&#8221;<\/p>\n<p>AKA the engineers that designed the farmwork figured no one would ever have a need for this, so fuck designing for it.<\/p>\n<p>I hope this blog post helps someone out. It took me several days to figure all this out and I learnt a lot along the way, even if it&#8217;s not practical.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>Back Story Now a while back I wrote a blog post about creating a wireless ESXi hypervisor. A lot of lessons learnt, so why would I attempt this again? *ASMR* Cause you have an idea&#8230;. Sigh these usually end up bad&#8230; but here we go!! Where did this idea come from, if I already knew &hellip; <\/p>\n<p class=\"link-more\"><a href=\"https:\/\/zewwy.ca\/index.php\/2025\/12\/25\/wireless-hyper-v-host\/\" class=\"more-link\">Continue reading<span class=\"screen-reader-text\"> &#8220;Wireless Hyper-V Host&#8221;<\/span><\/a><\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"sfsi_plus_gutenberg_text_before_share":"","sfsi_plus_gutenberg_show_text_before_share":"","sfsi_plus_gutenberg_icon_type":"","sfsi_plus_gutenberg_icon_alignemt":"","sfsi_plus_gutenburg_max_per_row":"","footnotes":""},"categories":[5,6,8,197],"tags":[492,469],"class_list":["post-1762","post","type-post","status-publish","format-standard","hentry","category-hypervisors","category-networking","category-server-administration","category-windows","tag-trunk","tag-wifi"],"_links":{"self":[{"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/posts\/1762","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/comments?post=1762"}],"version-history":[{"count":8,"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/posts\/1762\/revisions"}],"predecessor-version":[{"id":1771,"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/posts\/1762\/revisions\/1771"}],"wp:attachment":[{"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/media?parent=1762"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/categories?post=1762"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/tags?post=1762"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}