Your message?
Notice: To avoid posts by spam, a message body without the word '#FuguIta' is rejected.
Please include the word in your message text.
m3th (2021-11-07 (Sun) 05:41:01)
FuguIta-7.0-amd64-202111011.img.gz
$ ls -l /bin/[
- r-xr-xr-x 2 root bin 123320 Oct 17 13:25 /bin/[
$ /bin/[
[: missing ]
#FuguIta
kaw (2021-11-02 (Tue) 15:43:48)
The plan
I received a request to send video and audio from a studio to a venue using IP transmission equipment for an event.
And there were two limitations to this job as follows.
1. a pair of IP transmission devices work well when directly connected, however, due to a problem with the web UI, we cannot change some of the settings, such as the IP address, which means that transmission over the Internet is impossible as it is.
2. We can change the settings of the edge router in the studio, but we don't know about the router in the venue. In other words, we cannot confirm whether we can set up port forwarding so that the Internet can communicate with hosts in the venue's network.
To solve this problem, we decided to build a VPN between the studio and the venue, and connect the IP encoder in the studio to the IP decoder in the venue using Layer 2. Once the VPN line is established, communication is possible from either direction. And the two ends of the VPN can be thought of as being pseudo-directly connected by LAN cables.
#img(): File not found:
Of course, we use OpenBSD and FuguIta to solve this kind of problem.
To build a VPN, WireGuard, or wg(4), which appeared in OpenBSD 6.8, seemed to be useful.
Using WireGuard in practice, we found that it was very easy to build a VPN circuit.Settings for WireGuard at the studio site is as follows:
---- hostname.wg1 -------------------- wgkey PRIVKEY-OF-THIS-PEER wgport 7501 wgpeer PUBKEY-OF-HIS-PEER wgaip 172.16.54.1/32 wgpka 0 inet 172.16.54.254 255.255.255.0 mtu 1380 upThe reason the wg number is 1 is to account for the possibility that other peers may connect in the future.
The reason why wgpka is 0 is because the Nat router on the other side is not forwarding the port, so keep alives will not occur.
Next, we look at the venue.---- hostname.wg0 -------------------- wgkey PRIVKEY-OF-THIS-PEER wgport 8501 wgpeer PUBKEY-OF-HIS-PEER wgendpoint 153.246.158.51 7501 wgaip 172.16.54.0/24 wgpka 5 mtu 1380 inet 172.16.54.1 255.255.255.0There was one more problem that we had to solve in using WireGuard.
#img(): File not found:
That is, WireGuard is a Layer 3-only VPN.
This time, we want to connect the IP encoder and the IP decoder pseudo-directly, so we need to connect them on Layer 2.
Therefore, I now decided to use etherip(4) to flow Ethernet frames into WireGuard VPN.
This seemed to achieve our goal.Here is the configuration of the physical devices on the studio side.
bge0 is connected to LAN, and axe0 to the video encoder.---- hostname.bge0 ------------------ inet 192.168.1.193 255.255.255.0 NONE up ---- hostname.axe0 ------------------ upAnd here is the endpoint of the etherip tunnel.
---- hostname.etherip1 -------------- tunnel 172.16.54.254 172.16.54.1 upThen we build a bridge(4) between the L2 endpoint and the physical device.
---- hostname.bridge1 --------------- add etherip1 add axe0 upFinally, we configure sysctls.
---- sysctl.conf -------------------- net.inet.ip.forwarding=1 net.inet.etherip.allow=1The configuration of the venue side is almost the same as the studio side. Overall, the configuration is symmetrical.
---- hostname.msk0 ------------------ inet 192.168.1.193 255.255.255.0 NONE ---- hostname.axe0 ------------------ up ---- hostname.etherip0 -------------- tunnel 172.16.54.1 172.16.54.254 up ---- hostname.bridge0 --------------- add etherip0 add axe0 up ---- sysctl.conf -------------------- net.inet.ip.forwarding=0 net.inet.etherip.allow=1
The Result
With the combination of WireGuard+EtherIP, we were able to transmit video and audio in good condition.
We transmitted a stream of about 25 Mbps on a line with a bandwidth of over 100 Mbps.
However, we found that the video and audio transmissions were very sensitive to fluctuations in the time axis.
In addition to the VPN line, we had an SSH connection for maintenance purposes, but when a certain amount of data was transmitted over this SSH line, the VPN packets would wait, causing the video to freeze for a short time.
In order to solve this problem, we will need to use pf(4) to control packet priority.
This will be an issue for next time.
Lastly, I would like to discuss the benefits of using FuguIta.
At each stage of designing, building, and deploying a VPN, we had multiple network configurations and needed to quickly switch between them or migrate the configurations between devices. FuguIta's usbfadm and gennetconfs/chnetconf tools made it possible for us to do these tasks quickly.
kaw (2021-11-02 (Tue) 11:41:34)
English translation of #FuguIta Guide is now available.
This was made possible by the generous effort of Alfredo Vogel.
I would like to express my gratitude to him for his great contribution.
vanitarium (2021-10-27 (Wed) 20:54:43)
#FuguIta I had a kernel panic because it did not find the wifi firmware: it returned that firmware folder was empty. Maybe it is the wrong URL? #FuguIta
Correct URL is firmware.openbsd.org/
kaw (2021-10-19 (Tue) 23:30:02)
#FuguIta-7.0-{i386,amd64} are currently under testing. They are available in the test directory of the download mirror.
We look forward to your trial reports.
Vanitarium (2021-09-13 (Mon) 18:46:22)
#FuguIta I am offering you to translate and edit the Japanese version into English and host it on my server. I can set it up as a wiki or a website. If you are happy with that let me know so I can let you proofread it and ok it.
m3th (2021-08-10 (Tue) 03:32:55)
Without typing anything, can I see the login prompt like OpenBSD?
This is my request. Without my help, mum can use Fuguita.
#FuguIta
-- kaw 2021-08-12 (Thu) 06:04:43
kaw (2021-05-25 (Tue) 12:41:15)
Now, I will try to describe the file layout structure of #FuguIta.
The first figure shows the file layout in boot mode 0 (Click the figure to enlarge).
As examples, the paths /bin/ed, /usr/bin/vi, and pkg_added /usr/local/bin/emacs are shown.
The root file system is rd(4). This rd(ram disk) device is attached to the kernel and has been already mounted from the system boot time. Under the root, there is an unfamiliar directory called "boottmp". This is where you will find the commands needed at the very beginning of the system boot, and utilities specific to FuguIta.
The FuguIta device itself, a DVD or USB flash drive, which holds the boot loader, OS kernel, and file system images. It is mounted read-only on /sysmedia.
The filesystem image in /sysmedia is mapped to /dev/vnd4 and mounted on /fuguita. This is the OpenBSD file tree. This is pretty much as it should be, except for a few modifications to fit to the live system. Also, this is read-only. So no files can be created, modified, or deleted under it.
/ram is a memory file system called TMPFS (temporary file system), which is both readable and writable. Files that need to be modified, such as /etc/*.conf, your own data under /home/YOU, and the pkg_added program, are located on this. In addition, files that are rarely modified are replaced by symbolic links towards equivalent files in /fuguita. This will reduce the memory usage of TMPFS.
#img(): File not found:Next is boot mode 1. This is the same as mode 0, but /usr is symbolically linked to /fuguita/usr. This makes the boot faster and uses less memory than mode 0 by not copying/linking /usr to /ram. However, /usr/local is not writable, so pkg_add is not possible.
#img(): File not found:Finally, there is boot mode 2. This is much simpler than modes 0 and 1. Only / and /ram are mounted, and all external devices are unmounted. Of course, all files can be modified.
#img(): File not found:
Note that usbfadm sync will only save the data that exists in /ram TMPFS at boot mode 0, 1, or 2.
m3th (2021-05-21 (Fri) 04:40:05)
Can I change password ?
Should I use newdrive command again?
I might lose data, if I mistake.#FuguIta
-- kaw 2021-05-21 (Fri) 14:19:05
Former articles are at FuguIta/BBS/10.
Return to Top