https://lantian.pubLan Tian @ Blog2026-05-03T09:10:22.768ZAstro v6.2.1Lan Tianhttps://lantian.pubLan Tian @ Bloghttps://lantian.pub/favicon.icoCopyright 2012-2026 Lan Tian @ Blog<![CDATA[Modifying FileZilla to Workaround Bambu 3D Printer's FTP Issue]]>https://lantian.pub/en/article/modify-computer/modify-filezilla-workaround-bambu-3d-printer-ftp-issue.lantian/2026-04-13T23:28:02.000ZI recently bought a Bambu A1 Mini 3D printer to try out 3D printing. This printer offers a FTP server, allowing users to use FTP clients like FileZilla or WinSCP to upload model files for printing, and download timelapse videos.
However, when I tried connecting to the printer with FileZilla, I found that although the username and password were correct and login was successful, I couldn't retrieve the file list:
Some users on the Bambu official forum have also reported this issue, such as this reply and this reply.
Some users mentioned that WinSCP works, but I use Linux daily and don't want to switch to Windows just to connect to the printer's FTP service. So I investigated the cause of the problem and found a solution for Linux.
Introduction to FTP Protocol
To understand this problem, we first need to understand how the FTP protocol works. FTP (File Transfer Protocol) is an ancient file transfer protocol, born in 1971. It uses multiple TCP connections to separate control commands and data transfer:
Control connection: The client actively connects to the server (usually on port 21), establishing a persistent TCP connection. All commands (such as login, change directory, list files) and server responses are transmitted through this connection.
Data connection: Whenever file content needs to be transferred or file lists need to be retrieved, the client and server establish a new TCP connection. After the transfer is complete, this connection is closed.
Based on how the data connection is established, FTP can be divided into Active Mode and Passive Mode:
Active Mode
The client sends a PORT command on the control connection, telling the server the IP and port it's listening on.
The server actively connects from port 20 to the IP and port specified by the client.
After data transfer is complete, the connection is closed.
The format of the PORT command is PORT h1,h2,h3,h4,p1,p2, where h1-h4 are the four bytes of the IP address, and p1-p2 form the port number (p1*256+p2). For example:
PORT 192,168,1,100,4,1
This means the client is waiting for a connection at 192.168.1.100:1025 (4*256+1=1025).
The problem with active mode is that if the client is behind NAT or a firewall, the server cannot actively connect to the client. Therefore, modern FTP clients use passive mode by default. Bambu 3D printers also don't support active mode - attempting to use the PORT command will simply return an error.
Passive Mode
The client sends a PASV command on the control connection.
The server responds with a 227 status code, telling the client the IP and port it's listening on.
The client actively connects to the IP and port specified by the server.
After data transfer is complete, the connection is closed.
The format of the PASV response is the same as the PORT command, for example:
227 (192,168,1,1,7,232)
This means the server is listening for a connection at 192.168.1.1:2024 (7*256+232=2024).
Passive mode solves the problem of clients being behind NAT, since the connection is initiated by the client. However, if the IP address returned by the server is incorrect (for example, returning a private IP or invalid IP), the client won't be able to establish a data connection.
Bambu Printer Firmware Issue
If we take another look of FileZilla's output, we can find that Bambu's FTP server returned some weird response for the PASV command:
> PASV< 227 (0,0,0,0,7,232)
The first four segments of the return value are all 0, corresponding to the IP address 0.0.0.0, meaning Bambu's FTP server instructs the client to connect to this IP address instead of the printer's actual IP address.
0.0.0.0 is a special IP address, typically used to represent "all IP addresses on this machine". According to RFC 1122, 0.0.0.0 as a destination address is invalid, and can only be used as a special source address.
Different operating systems behave differently when connecting to 0.0.0.0:
On Windows, connecting to 0.0.0.0 will fail, returning a WSAEADDRNOTAVAIL error ("The remote address is not a valid address").
On macOS and Linux, connections to 0.0.0.0 are automatically redirected to the local machine, equivalent to 127.0.0.1.
Therefore, regardless of the operating system, when an FTP client receives 0.0.0.0 in a PASV response, it cannot correctly connect to the actual FTP server. In this reply on the Bambu forum, the user was using Windows and got the WSAEADDRNOTAVAIL error. But since I'm using Linux, the error returned was ECONNREFUSED (connection refused), because there's no FTP server on my local computer and no corresponding port is open.
On Windows, you can use WinSCP as an FTP client, and per this comment enable the Force IP address for passive connections setting in the options, which essentially ignores the IP address portion returned by the FTP server in the PASV command and only uses the port number.
This feature was designed to support some misconfigured FTP servers that return their private IP (e.g., 192.168.1.1) instead of their public IP in the PASV command. But coincidentally, it also solves the problem in Bambu's case.
However, as a Linux user, I don't have WinSCP available, so I have to figure out how to modify FileZilla.
Modifying FileZilla
FileZilla also has special handling logic for these misconfigured FTP servers. In the settings under Connection - FTP - Passive tab, you can configure what to do when the FTP server returns a private IP: either force using the server's public IP or switch to active mode.
This logic is implemented in the CFtpRawTransferOpData::ParsePasvResponse() function in src/engine/ftp/rawtransfer.cpp:
bool CFtpRawTransferOpData::ParsePasvResponse(){ // Omitted code for parsing PASV response content // The CFtpRawTransferOpData class defines a host_ variable that stores the IP address returned by the PASV command std::wstring host_; // peerIP is the server IP address used when FileZilla actively connects to the FTP server std::wstring const peerIP = fz::to_wstring(controlSocket_.socket_->peer_ip()); // The is_routable_address function is located in the libfilezilla library's lib/iputils.cpp file, // determining whether an IP address is a public IP (true) or a private IP (false). // Its logic is: if the IP is in 10.0.0.0/8, 127.0.0.0/8, 192.168.0.0/16, // 169.254.0.0/16, 172.16.0.0/12, it returns private IP, otherwise public IP. // Note that it judges 0.0.0.0 as a public IP. // // The logic here is: if the FTP server's IP is a public IP, but PASV returns a private IP, then enter special handling logic. // Special handling is only applied to public FTP servers because private FTP servers might intentionally return a different IP, // for load balancing at the network layer, or to use a second IP when the first IP's 65535 ports are exhausted. if (!fz::is_routable_address(host_) && fz::is_routable_address(peerIP)) { // If the setting to force using the server's public IP is enabled, use the server IP instead of the PASV-returned IP if (options_.get_int(OPTION_PASVREPLYFALLBACKMODE) != 1 || bTriedActive) { log(logmsg::status, _("Server sent passive reply with unroutable address. Using server address instead.")); log(logmsg::debug_info, L" Reply: %s, peer: %s", host_, peerIP); host_ = peerIP; } // Otherwise, return FTP passive mode failed, and FileZilla will switch to active mode and retry else { log(logmsg::status, _("Server sent passive reply with unroutable address. Passive mode failed.")); log(logmsg::debug_info, L" Reply: %s, peer: %s", host_, peerIP); return false; } } // This mode is hidden in the settings interface, users cannot switch to this mode else if (options_.get_int(OPTION_PASVREPLYFALLBACKMODE) == 2) { // Force using the IP when actively connecting to the FTP server regardless of any situation host_ = peerIP; } return true;}
As you can see, FileZilla doesn't treat 0.0.0.0 as a private IP, causing this logic to not work for Bambu's FTP server. The solution is to modify FileZilla's source code to add special handling for the 0.0.0.0 IP. Since 0.0.0.0 is an invalid IP, we can always use the special logic, regardless of whether the server is on a public or private network:
Index: src/engine/ftp/rawtransfer.cpp===================================================================--- a/src/engine/ftp/rawtransfer.cpp (revision 11406)+++ b/src/engine/ftp/rawtransfer.cpp (working copy)@@ -399,7 +399,11 @@ } std::wstring const peerIP = fz::to_wstring(controlSocket_.socket_->peer_ip());- if (!fz::is_routable_address(host_) && fz::is_routable_address(peerIP)) {+ std::wstring const zeroIP = fz::to_wstring(std::string("0.0.0.0"));+ if (+ std::wcscmp(host_.c_str(), zeroIP.c_str()) == 0+ || (!fz::is_routable_address(host_) && fz::is_routable_address(peerIP))+ ) { if (options_.get_int(OPTION_PASVREPLYFALLBACKMODE) != 1 || bTriedActive) { log(logmsg::status, _("Server sent passive reply with unroutable address. Using server address instead.")); log(logmsg::debug_info, L" Reply: %s, peer: %s", host_, peerIP);
After applying the above patch, recompile and install FileZilla, then try connecting to the printer again:
Now you can normally access the printer's FTP service to upload and download files.
Appendix: FTP Configuration for Connecting to Bambu 3D Printer
Host: ftps://192.168.12.34, replace with your printer's IP address
Username: bblp
Password: Can be found in the printer's settings - LAN page, it's an 8-digit access code. Note: You don't need to enable LAN mode to use FTP, enabling LAN mode will cause Bambu cloud features to stop working!
Port: 990
In FileZilla, you may need to select Require implicit FTP over TLS in the Encryption field.
]]>2026-04-13T23:28:02.000ZCopyright 2012-2026 Lan Tian @ Blog<![CDATA[魔改 FileZilla 解决拓竹 3D 打印机的 FTP 问题]]>https://lantian.pub/article/modify-computer/modify-filezilla-workaround-bambu-3d-printer-ftp-issue.lantian/2026-04-13T23:28:02.000Z我最近为了尝试 3D 打印，买了一台拓竹 A1 Mini 3D 打印机。这台打印机支持 FTP 连接，用户可以使用 FileZilla、WinSCP 等 FTP 客户端上传需要打印的模型文件，以及下载延时摄影录像。
如果在 Windows 上，可以用 WinSCP 作为 FTP 客户端，并且可以参照这个回复，开启设置中的 Force IP address for passive connections（对于被动模式连接强制使用 IP 地址），实际上就是忽略 FTP 服务器在 PASV 命令中返回的 IP 地址部分，只使用端口号。
在 FileZilla 中，可能需要在加密（Encryption）一栏中选择 Require implicit FTP over TLS。
]]>2026-04-13T23:28:02.000ZCopyright 2012-2026 Lan Tian @ Blog<![CDATA[Using FlapAlerted to Suppress flapping in DN42]]>https://lantian.pub/en/article/modify-website/dn42-flapalerted-reduce-flapping.lantian/2025-12-07T00:14:28.000ZDN42, aka Decentralized Network 42, is a large, decentralized VPN-based network. But unlike other traditional VPNs, DN42 itself doesn't provide any VPN exits, which means it doesn't allow you to bypass Internet censorships or unlock streaming services. On the contrary, the goal of DN42 is to simulate another Internet. It uses much of the technology running on modern Internet backbones (BGP, recursive DNS, etc), and is a great replica of a real network environment.
In the real internet, various operators use hardware routers from different manufacturers to exchange routing information with each other, such as Cisco, Juniper, Nokia, Arista, Huawei, etc. Similarly, in DN42, different participants will also choose different BGP software and hardware, with the most commonly used being Bird and FRRouting, but some also use Mikrotik, Ubiquiti EdgeRouter, or even real commercial routing hardware.
Because everyone chooses different BGP software and hardware, and even when using the same software, they configure their internal networks in different ways, when everyone's networks are connected together, sometimes strange problems may occur, such as BGP Flapping.
BGP Flapping in the Real Internet and DN42
BGP Flapping refers to a large number of path changes of the same route occurring in a short period of time, generally originating from a network repeatedly advertising and withdrawing the same route. Each time a route is advertised and/or withdrawn, this network will pass this route to all peers connected to it. These peers will calculate new best paths based on this route, and then pass the new paths to their peers, and so on.
In the real internet, the problem of BGP Flapping is not too significant, firstly because hardware routers purchased by various operators at great expense have sufficient computing resources to handle these route changes, or have built-in functions to suppress frequent route changes (BGP Dampening), and secondly because real operators use physical network connections, and the high cost of physical links means that except for the largest ISPs, operators that peer with each other are not too numerous, thus reducing the exponential amplification effect.
However, in DN42, the most commonly used Bird BGP daemon does not support BGP Dampening, which allows flapping routes to continue propagating. Even though FRRouting supports BGP Dampening, it doesn't mean everyone will enable it. At the same time, because DN42 participants use VPN connections, the cost of establishing peers is zero, so it's common for a network to connect to dozens or even hundreds of peers, and to spread flapping routes to dozens or hundreds of peers.
Moreover, because DN42 is an experimental network, different participants often change their network configurations from time to time. Since flapping generally switches between several valid paths and doesn't outright cause disconnection, the participant making changes may not immediately notice the problem.
This leads to frequent large-scale, multi-day flapping within DN42, for example:
The above chart shows the number of route updates received per second by several of my DN42 nodes. You can see that around November 7th, the number of route changes received increased, stepped up again around November 12th, and didn't decrease until November 13th.
Traditional Solutions
For DN42 participants, the biggest problem caused by flapping is the consumption of CPU resources and traffic. Many participants use VPS with limited computing resources and traffic, and flapping may lead to VPS being restricted in CPU usage, limited in network speed, or even suspended by provider.
However, within DN42, even if flapping is known to exist, it's not always possible to find the source of the flapping problem, let alone solve the root problem:
You can choose to manually disconnect problematic peers, which can immediately solve your CPU and traffic consumption problems, but this is only treating the symptoms, not the root cause. A peer that seems problematic to you might just be forwarding route updates from other peers. By doing this, you might need to disconnect your self from innocent peers, especially large networks connected to dozens or hundreds of peers. Moreover, as connections between different participants change, this flapping might be passed to you through other peers, which you need to disconnect again (and hopefully reconnect the former peers).
You can try to contact the problematic peer, but because DN42 participants are distributed worldwide, even if the other party is willing to troubleshoot immediately, it might take up to 24 hours to receive a response after they wake up/get off work. Moreover, the other party might not be the root cause of the problem, and they might need to repeat the same process to contact problematic peers, making the entire process very time-consuming.
In the real internet, large operators have a 24-hour on-duty NOC (Network Operation Center) that can immediately troubleshoot problems. But obviously, hobbyist networks like DN42 don't have such things.
Some people have proposed solutions to rate-limit port 179 of BGP. This can reduce the CPU usage of BGP daemon, but cannot reduce the total traffic consumed (and might even increase it), and will slow down the speed of exchanging a large number of routes when disconnected peers reconnect. The reason is that the BGP protocol is based on TCP. When BGP daemon receives a route update, it will immediately send the updated route to other peers through the TCP-based BGP connection. This route update message will immediately enter the OS-allocated buffer for this TCP connection. As long as the TCP connection remains connected, this message will eventually be sent. Even if the TCP connection is very slow, causing this updated route to change again, the BGP daemon cannot withdraw this instruction from the buffer. No common operating systems such as Linux/BSD/Windows provide this mechanism. Therefore, the actual number of route updates sent is still the same, just at a slower speed.
Depending on the rate-limiting method, it might just delay packets before handing them to the BGP daemon (generally called Traffic Shaping), or some might directly drop packets (called Traffic Policing). If packets are directly dropped, the peer needs to retransmit the packets, which causes greater traffic consumption.
In my opinion, it's easier and more effective to directly limiting the CPU usage of BGP daemon.
Implementing BGP Dampening Yourself on Bird
To suppress frequent route changes, BGP Dampening needs to do two things: detect routes that change frequently, and then prevent these changes from propagating to more peers by adjusting route/peer weights, thereby reducing the total amount of route changes in the entire network.
Although Bird completely does not support BGP Dampening and cannot implement either of the above functions alone, the step of "detecting routes that change frequently" can already be done by existing software. Another DN42 participant Kioubit developed FlapAlerted, which can peer with your own BGP daemon and then count the number of changes in each route, thereby finding routes whose changes exceeds a threshold. However, this software can only detect and cannot send these flapping network segments back to the BGP daemon, so it cannot achieve the interception effect.
Actually, FlapAlerted has a mod_roaFilter plugin, which can use the RPKI mechanism (to be introduced later) to filter an existing ROA record, and remove records for the flapping routes. However, this plugin is disabled by default, and you need to compile FlapAlerted yourself to use it. In addition, you need to have already set up RPKI based on DN42 Wiki, and filter all routes without corresponding RPKI records, which is a high standard to meet.
However, Bird has supported RPKI/ROA functionality since version 2.0. The ROA function in RPKI can be used to verify whether BGP-advertised routes come from the correct ASN. For example, the route 172.22.76.184/29 that I own in DN42 should come from my ASN 4242422547. Combined with Bird's filter functionality, you can intercept incorrect routes with methods similar to the following:
if (roa_check(roa_v4, net, bgp_path.last) = ROA_INVALID) then { # Route comes from incorrect ASN reject;} else if (roa_check(roa_v4, net, bgp_path.last) = ROA_UNKNOWN) then { # RPKI does not provide information about this route, so it's unknown whether the route comes from the correct ASN accept;} else if (roa_check(roa_v4, net, bgp_path.last) = ROA_VALID) then { # Route comes from correct ASN accept;}
So, to intercept routes that change frequently, we can generate fake ROA records based on the information collected by FlapAlerted, hijacking these frequently changing routes to invalid ASNs (such as AS0). This way, when routing software like Bird receives these routes, it will consider them to come from incorrect ASNs and intercept them.
However, FlapAlerted only provides an API to generate ROA record files and does not support the RPKI to Router protocol used by BGP daemon, so it cannot directly connect to Bird. For this, we need to use StayRTR, which can read and periodically update ROA record files of the same format from the real internet or generated by FlapAlerted, and then send them to Bird through the RPKI to Router protocol.
Installing FlapAlerted
We first need to install FlapAlerted and connect it to our own BGP daemon, so that FlapAlerted can obtain frequently changing routes.
Of course, you can also choose to directly use someone else's FlapAlerted instance, such as the one I set up at https://flapalerted.lantian.pub, or the one set up by Burble at https://flaps.collector.dn42 (needs to be accessed from within DN42).
If you use Docker, you can refer to the following Docker compose configuration:
services: flapalerted: image: ghcr.io/kioubit/flapalerted network_mode: host command: - "--asn" - "4242422547" # Change to your own ASN - "--bgpListenAddress" - "127.0.0.1:1790" # BGP session listening port, your BGP daemon needs to connect to this port later - "--httpAPIListenAddress" - "127.0.0.1:8080" # HTTP API listening port, StayRTR needs to connect to this port later - "-routeChangeCounter" - "120" # Number of times a route path needs to change within one minute to be included in the prefix list. Default is 600, but I think it's too high, I use 120 - "-overThresholdTarget" - "5" # How many consecutive minutes the rate reaches or exceeds routeChangeCounter to trigger an event. Default is 10, I changed it to a stricter 5 - "-underThresholdTarget" - "30" # How many consecutive minutes the rate is below routeChangeCounter to remove an event. Default is 15, I changed it to a stricter 30 restart: unless-stopped
Once FlapAlerted starts successfully, you can modify the BGP daemon configuration to forward routing information to FlapAlerted. If you use Bird, you can refer to the following configuration:
protocol bgp flapalerted { local as 4242422547; # Change to your own ASN # Change to the ASN and BGP IP/port set by FlapAlerted. # Here we use the same ASN as our own network, since BGP protocol does not forward routes from # iBGP (i.e., routes from your other nodes) to iBGP peers. Unless you enable the add paths option, # routes from your other nodes will only contain the optimal routes. If flapping occurs on # suboptimal routes, it will be hidden. Therefore, it is recommended that users with multiple # nodes establish separate connections with FlapAlerted on each node. neighbor 127.0.0.1 as 4242422547 port 1790; ipv4 { # Enable add paths option to send non-optimal routes to FlapAlerted as well, making suboptimal # route flapping visible. add paths on; export all; import none; # No need to receive any routes from FlapAlerted }; ipv6 { add paths on; export all; import none; };}
Confirm that Bird is properly connected to FlapAlerted, and confirm that FlapAlerted's ROA API is accessible, for example: curl http://127.0.0.1:8080/flaps/active/roa
Continue to the next step after confirming everything is correct.
Installing StayRTR
The next step is to install StayRTR to send the ROA information generated by FlapAlerted to Bird.
If you use Docker, you can refer to the following Docker compose configuration:
services: stayrtr: image: rpki/stayrtr network_mode: host command: - "--bind" - "127.0.0.1:8083" # Listening address for RPKI-to-Router protocol - "--metrics.addr" - "127.0.0.1:8084" # Listening address for Prometheus format statistics API - "--cache" - "http://127.0.0.1:8080/flaps/active/roa" # Change to your FlapAlerted server address - "--rtr.expire" - "3600" # How long to retain existing information if FlapAlerted server is offline - "--rtr.refresh" - "300" # How often to refresh information from FlapAlerted server - "--rtr.retry" - "300" # How long to retry if FlapAlerted server is offline restart: unless-stopped depends_on: - flapalerted
After StayRTR starts successfully, you can modify the BGP daemon configuration to connect it to StayRTR. It should be noted here that if you already enabled RPKI referring to DN42 Wiki, you must store the ROA information sent by FlapAlerted in a separate ROA table and check routes based on this ROA table separately. The reason is that if a route has multiple corresponding ASNs according to ROA information, any of these ASNs can advertise this route. Since FlapAlerted only generates information to hijack routes to invalid ASN (AS0), if mixed with normal ROA information, effectively both the original ASN and AS0 can advertise this route, which fails to achieve the filtering effect.
If you use Bird, you can refer to the following configuration:
# Create new ROA tables dedicated to FlapAlertedroa4 table roa_flap_v4;roa6 table roa_flap_v6;protocol rpki rpki_flapalerted { roa4 { table roa_flap_v4; }; roa6 { table roa_flap_v6; }; remote 127.0.0.1 port 8083; # Change to the port monitored by StayRTR max version 1; retry keep 10; # If connection is interrupted, reconnect every 10 seconds};
Continue to the next step after confirming that Bird is properly connected to StayRTR. If your FlapAlerted has not yet detected flapping routes, the ROA information is empty, and Bird will display a Cache-Error-No-Data-Available error, which is normal and can be ignored.
When FlapAlerted detects flapping routes, you can use the birdc show route table roa_flap_v4 command to check whether ROA information has actually been received.
Intercepting Routes in Bird Filters
With ROA information, we can add instructions to check ROA information in the filters of the corresponding protocols in Bird.
If you want to minimize CPU consumption, you can choose to filter out these routes at the Import Filter stage when receiving routes, but you won't be able to access these routes either. In addition, your FlapAlerted instance will also stop receiving these routes, and repeat the process of unblocking them after some time - seeing the flapping routes again - filtering them again.
If you just want to reduce the impact on the DN42 network, you can choose to filter them out at the Export Filter stage when sending routes, with the side effect that your peers won't be able to access these routes through you.
Add to your Filter filter:
# Change roa_flap_v4 to the corresponding ROA table name above, use roa_flap_v6 for IPv6if (roa_check(roa_flap_v4, net, bgp_path.last) = ROA_INVALID) then { # Route changes frequently, hijacked by FlapAlerted to AS0, Bird considers the route to # come from incorrect ASN reject;}# In other cases, roa_check will return ROA_UNKNOWN, because FlapAlerted does not provide# information about other routes, and Bird does not know whether the route source is correct
After reloading Bird, you will no longer spread these frequently changing routes to your peers, reducing the traffic consumption of you and your peers.
Summary
This chart shows the effect after I configured BGP Dampening in my network. Around 18:00, although flapping occurred within the DN42 network and my nodes received these route changes through multiple peers, FlapAlerted subsequently detected these flapping and blocked these routes through the above process. Therefore, although flapping continued until around 23:00, the routes sent by my network quickly declined after a brief spike, successfully suppressing flapping for my peers.
As you can see, BGP Dampening cannot prevent you from receiving flapping routes, but it can help you save CPU resources, or save some network traffic for you and your peers. Therefore, in addition to configuring BGP Dampening in your network, if other networks send you flapping routes, you can also suggest these networks take similar measures, thereby suppressing flapping on a larger scale and saving traffic for all DN42 participants.
]]>2025-12-07T00:14:28.000ZCopyright 2012-2026 Lan Tian @ Blog<![CDATA[Legal LTE Network at Home with Open5GS]]>https://lantian.pub/en/article/modify-computer/legal-lte-network-at-home-with-open5gs.lantian/2025-07-20T12:38:31.000ZIn my previous post, I built a legal LTE network using the US CBRS band and Magma LTE core network software.
Regarding "legal": I am not a lawyer or a wireless expert. Based on my research into the relevant policies and regulations, my entire setup should be legal. However, I take no responsibility if you encounter any legal issues after following the instructions in this post.
I chose Magma at the time because the CBRS LTE base station I bought was originally used for the Helium Mobile network, and Nova Labs/Helium Mobile uses Magma for its CBRS core network. This ensured that Magma was compatible with my base station. However, from the perspective of building a self-hosted core network in a Homelab, Magma has these issues:
Magma's core network relies on Docker or Kubernetes for deployment, making it difficult to deploy outside of containers using conventional methods (e.g., systemd services). As a NixOS user, I prefer to avoid bloated Docker containers and manage services on the system using systemd.
Magma's Access Gateway can only be installed on Ubuntu 20.04, which has a completely different system management approach from my usual NixOS. This means I would need to manually manage the Access Gateway machine's configuration and system upgrades, without being able to reuse my existing NixOS configuration.
Magma sometimes has strange issues, such as:
Android phones always failing to connect to the base station while iPhones work fine;
Phones unable to properly obtain the network name, always displaying MCC/MNC 315 010 instead of the actual configured network name Lan Tian Mobile;
The Access Gateway connected to the core network and synchronized configurations normally, but the core network management interface showed that the Access Gateway had not been connected for a long time.
Therefore, after finishing the previous post and confirming the feasibility of building a self-hosted LTE network, I began trying to replace Magma with another open-source LTE core network software, Open5GS.
Compared to Magma, Open5GS has these advantages:
Open5GS does not distinguish between core network and Access Gateway components; it can be fully deployed on a single machine.
Open5GS packages are already available in Nixpkgs (pkgs.open5gs), so I can install and use it directly on NixOS without needing to package it myself, and without Docker or Ubuntu.
Open5GS does not have the strange issues that Magma has; once set up, it is quite stable.
This post documents the process of setting up a core network with Open5GS on NixOS, and connecting a FreedomFi/Sercomm SCE4255W base station to the core network to transmit LTE signals.
Installing Open5GS
I referenced the following materials during the configuration process:
A set of Open5GS (and some add-ons) configurations packaged as ready-to-use Docker containers: herlesupreeth/docker_open5gs
Preparation
This post assumes you have prepared the following hardware or software configurations as described in my previous post. If you have not completed these configurations, you can refer to the corresponding sections in the previous post to configure the software or purchase the hardware:
A FreedomFi/Sercomm SCE4255W base station with the web management interface unlocked.
The base station is already registered with the CBRS SAS.
A SIM card programmedwith authentication information (KI, OPC, etc.), and you have recorded this authentication information (for later registration with Open5GS).
This post will use NixOS for all configurations, but I also provides some commands for Ubuntu, which users of other Linux distributions can use as a reference.
Understanding Open5GS Components
Open5GS, as its name suggests, is primarily a software that implements a 5G core network (as well as a LTE core network). Since the core network protocols and structure in the 5G era are significantly different from the 4G era, especially for standalone 5G SA networks, Open5GS can roughly be seen as a set of LTE/5G NSA core network software, plus a set of 5G SA core network software, with a small portion of components shared between them.
The LTE/5G NSA part of Open5GS consists of the following components:
MME - Mobility Management Entity
HSS - Home Subscriber Server
PCRF - Policy and Charging Rules Function
SGWC - Serving Gateway Control Plane
SGWU - Serving Gateway User Plane
SMF - Session Management Function
SMF itself is a 5G core network component, but Open5GS SMF also implements the Packet Gateway Control Plane in the 4G core network structure.
UPF - User Plane Function
UPF itself is a 5G core network component, but Open5GS UPF also implements the Packet Gateway User Plane in the 4G core network structure.
SCP - Secure, Contain, Protect Service Communication Proxy
SCP itself is a 5G core network component, but SMF depends on it.
NRF - NF Repository Function
NRF itself is a 5G core network component, but SCP depends on it.
And the 5G SA part consists of the following components:
NRF - NF Repository Function
SCP - Service Communication Proxy
SEPP - Security Edge Protection Proxy
AMF - Access and Mobility Management Function
SMF - Session Management Function
UPF - User Plane Function
AUSF - Authentication Server Function
UDM - Unified Data Management
UDR - Unified Data Repository
PCF - Policy and Charging Function
NSSF - Network Slice Selection Function
BSF - Binding Support Function
These components communicate with each other in the following structure:
The communication between various components of the 4G/5G core network uses the standardized Diameter protocol, which is based on TCP or SCTP protocol, exchanging data between various components of the 4G/5G core network. This also means that hardware and software from different vendors, as long as they support the Diameter protocol, can join the same core network and jointly provide services to mobile users.
However, in this post, I will only use Open5GS components, and will not add other components to the core network for now.
During this process, in addition to installing the Open5GS binaries, a set of systemd services corresponding to each Open5GS component is created, and the default Open5GS configuration is copied to /etc.
Since NixOS only has the Open5GS package (pkgs.open5gs) and no corresponding NixOS module, we need to manually create systemd services for Open5GS, mimicking the installation process on other systems like Ubuntu:
{ pkgs, lib, ... }:let # Since we are only building a 4G core network, only enable the services required for 4G core network services = [ "hss" "mme" "nrf" "pcrf" "scp" "sgwc" "sgwu" "smf" "upf" ];in{ # Enable MongoDB, HSS, PCF, PCRF components need MongoDB to save configurations services.mongodb = { enable = true; bind_ip = "127.0.0.1"; package = pkgs.mongodb-ce; }; # Create systemd services for each Open5GS component systemd.services = builtins.listToAttrs ( builtins.map (svc: { name = "open5gs-${svc}d"; value = { description = "Open5GS ${lib.toUpper svc} Daemon"; wantedBy = [ "multi-user.target" ]; after = [ "network.target" "mongodb.service" ]; requires = [ "network.target" "mongodb.service" ]; serviceConfig = { # The configuration file in the open5gs folder pointed to here will be created in the next step ExecStart = "${pkgs.open5gs}/bin/open5gs-${svc}d -c ${./open5gs}/${svc}.yaml"; ExecReload = "${pkgs.coreutils}/bin/kill -HUP $MAINPID"; LogsDirectory = "open5gs"; User = "open5gs"; Group = "open5gs"; Restart = "always"; RestartSec = "5"; RestartPreventExitStatus = "1"; }; }; }) services ); # Create a separate user and group for Open5GS users.users.open5gs = { group = "open5gs"; isSystemUser = true; }; users.groups.open5gs = { }; # Create a TUN interface named ogstun for communication with LTE devices systemd.network.netdevs.open5gs = { netdevConfig = { Kind = "tun"; Name = "ogstun"; }; }; systemd.network.networks.open5gs = { # The IP addresses used here are the same as in the default Open5GS configuration address = [ "10.45.0.1/16" "2001:db8:cafe::1/48" ]; linkConfig = { MTUBytes = 1400; RequiredForOnline = false; }; matchConfig.Name = "ogstun"; };}
Creating Open5GS Configuration Files
If you are using Ubuntu, the above installation process should have automatically installed the default configuration files to /etc/freeDiameter and /etc/open5gs. However, in NixOS, this process is not automatic, and we need to manually copy the configuration files or manually specify their paths.
Since the Nixpkgs Open5GS package already comes with a set of default configurations, we can directly copy the default configuration files from this package. First, build the package:
nix build nixpkgs#open5gs
If all goes well, Nix will download the pre-compiled Open5GS from the Binary Cache and symlink it to the result directory. At this point, we can see the default configuration files in the result/etc folder:
ls result/etc
Then we can copy them to our NixOS configuration for later modification:
cp -r result/etc/freeDiameter /path/to/your/nixos-config/freeDiametercp -r result/etc/open5gs /path/to/your/nixos-config/open5gs# Files copied from Nix store are read-only by default, add write permissions to themchmod -R +w /path/to/your/nixos-config/freeDiameter /path/to/your/nixos-config/open5gs
For files in the freeDiameter folder, we need to place them under /etc/freeDiameter:
Not placing them in /etc ensures that Open5GS services will automatically restart after modifying the configuration files.
Fixing Paths in Open5GS Configuration Files under NixOS
Since Open5GS packaged in Nixpkgs is installed by default under a path in /nix/store, its configuration files also references many paths under /nix/store by default.
First, get the actual installation path of Open5GS:
nix build nixpkgs#open5gs --print-out-paths --no-link# Output similar to:# /nix/store/vbb0aa2mkjbfay7gdgaw5r23g0ss6kyz-open5gs-v2.7.6/
Then search for this path in the copied configuration files. You will see many places containing the full path:
grep "/nix/store/vbb0aa2mkjbfay7gdgaw5r23g0ss6kyz-open5gs-v2.7.6/" freeDiameter/* open5gs/*# ...# Referencing TLS certificates generated by default during Open5GS build# freeDiameter/hss.conf:TLS_Cred = "/nix/store/vbb0aa2mkjbfay7gdgaw5r23g0ss6kyz-open5gs-v2.7.6/etc/open5gs/tls/hss.crt", "/nix/store/vbb0aa2mkjbfay7gdgaw5r23g0ss6kyz-open5gs-v2.7.6/etc/open5gs/tls/hss.key";# ...# Referencing freeDiameter Extension# freeDiameter/hss.conf:LoadExtension = "/nix/store/vbb0aa2mkjbfay7gdgaw5r23g0ss6kyz-open5gs-v2.7.6/lib/freeDiameter/dbg_msg_dumps.fdx" : "0x8888";# ...# Default log path is placed in Nix store# open5gs/hss.yaml: path: /nix/store/vbb0aa2mkjbfay7gdgaw5r23g0ss6kyz-open5gs-v2.7.6/var/log/open5gs/hss.log# ...# freeDiameter configuration file path is set in Nix store# open5gs/hss.yaml: freeDiameter: /nix/store/vbb0aa2mkjbfay7gdgaw5r23g0ss6kyz-open5gs-v2.7.6/etc/freeDiameter/hss.conf# ...
Once the Open5GS package or its dependencies are updated, the path of Open5GS in the Nix store will change, causing files specified by absolute paths to become invalid, and preventing Open5GS from starting. Therefore, we need to keep these paths synchronized with the Open5GS path, or point them outside the Nix store, to prevent future issues.
My workaround is to first link a copy of the pkgs.open5gs package to /etc:
# TLS certificates point to /etc/open5gs-pkg. Although this certificate is downloaded from Nixpkgs Binary Cache and the private key can be considered public, we are deploying on a single machine, and communication does not go through external networks, so proper encryption is not necessary.sed -i "s#/nix/store/vbb0aa2mkjbfay7gdgaw5r23g0ss6kyz-open5gs-v2.7.6/etc/open5gs/tls/#/etc/open5gs-pkg/etc/open5gs/tls/#g" freeDiameter/* open5gs/*# freeDiameter Extension points to /etc/open5gs-pkgsed -i "s#/nix/store/vbb0aa2mkjbfay7gdgaw5r23g0ss6kyz-open5gs-v2.7.6/lib/freeDiameter/#/etc/open5gs-pkg/lib/freeDiameter/#g" freeDiameter/* open5gs/*# Paths in /var point to the actual /varsed -i "s#/nix/store/vbb0aa2mkjbfay7gdgaw5r23g0ss6kyz-open5gs-v2.7.6/var/#/var/#g" freeDiameter/* open5gs/*# freeDiameter configuration file points to /etc/freeDiametersed -i "s#/nix/store/vbb0aa2mkjbfay7gdgaw5r23g0ss6kyz-open5gs-v2.7.6/etc/freeDiameter/#/etc/freeDiameter/#g" freeDiameter/* open5gs/*
After the modification, we will be able to upgrade Open5GS without issues in the future, and our configuration files placed in /etc will take effect normally.
(Optional) Regenerate Diameter TLS Certificates
Open5GS packaged in Nixpkgs comes with a TLS certificate generated during the build process. If your Open5GS is downloaded from the Binary Cache instead of being compiled locally, you will be using the same TLS key others can download from the Binary Cache.
If you deploy on a single machine according to this tutorial, since all communication is local and does not go through external networks, encryption and private key leakage have little impact on security.
However, if you plan to place some components on other machines, or if you do not want to use this leaked key, you can generate a new one using the following script:
{ pkgs, ...}:{ systemd.services.open5gs-certs = { wantedBy = [ "multi-user.target" ]; path = with pkgs; [ openssl ]; script = '' mkdir -p demoCA if [ ! -f "demoCA/serial" ]; then echo 01 > demoCA/serial fi touch demoCA/index.txt # CA self certificate if [ ! -f "ca.crt" ]; then openssl req -new -x509 -days 3650 -newkey rsa:2048 -nodes -keyout ca.key -out ca.crt \ -subj /CN=ca.epc.mnc010.mcc315.3gppnetwork.org/C=KO/ST=Seoul/O=NeoPlane fi for i in amf ausf bsf hss mme nrf scp sepp1 sepp2 sepp3 nssf pcf pcrf smf udm udr do if [ ! -f "$i.crt" ]; then openssl genpkey -algorithm rsa -pkeyopt rsa_keygen_bits:2048 \ -out $i.key openssl req -new -key $i.key -out $i.csr \ -subj /CN=$i.epc.mnc010.mcc315.3gppnetwork.org/C=KO/ST=Seoul/O=NeoPlane openssl ca -batch -notext -days 3650 \ -keyfile ca.key -cert ca.crt \ -in $i.csr -out $i.crt -outdir . fi done ''; serviceConfig = { Type = "oneshot"; User = "open5gs"; Group = "open5gs"; StateDirectory = "open5gs-certs"; WorkingDirectory = "/var/lib/open5gs-certs"; }; };}
When you run systemctl start open5gs-certs.service, this service will automatically generate missing keys in /var/lib/open5gs-certs.
Then you can modify the Open5GS configuration file to point the TLS key path to /var/lib/open5gs-certs:
# If you did not replace the TLS key path in the previous stepsed -i "s#/nix/store/vbb0aa2mkjbfay7gdgaw5r23g0ss6kyz-open5gs-v2.7.6/etc/open5gs/tls/#/var/lib/open5gs-certs/#g" freeDiameter/* open5gs/*# If you have already replaced the TLS key path in the previous stepsed -i "s#/etc/open5gs-pkg/etc/open5gs/tls/#/var/lib/open5gs-certs/#g" freeDiameter/* open5gs/*
You can also add open5gs-certs.service to the After and Requires of each Open5GS systemd service to ensure that the keys are generated before Open5GS starts.
The above steps configured the Open5GS core network itself, but we also need to install the web management UI to manage SIM card related information registered with Open5GS.
If you are using Ubuntu, you can use the official installation script:
Deploy the above configuration to your NixOS machine, and if everything goes well, these services should start normally without issues.
If you are using Ubuntu, all 4G/5G services should have automatically started when you installed the open5gs package. You can disable the 5G SA related services that we don't need, or you can ignore them; they will not affect subsequent configurations.
Creating Default Administrator for Management Panel
Open5GS does not automatically create a default administrator user when it starts, so after the deployment is complete and MongoDB has started, we need to manually run the following command to create an administrator:
The above command will create an administrator user with username admin and password 1423.
Open http://[Open5GS machine's IP address]:9999 in your browser, and log in to the management panel with the above username and password.
Modifying Open5GS Configuration Files
After Open5GS is installed, you will need to modify the configuration files to match the parameters of our CBRS LTE network. We only need to make the following changes:
Change MCC/MNC from the default 999/70 to CBRS's 315/010.
Simply search globally for mcc: 999 and mnc: 70, and replace them with mcc: 315 and mnc: 010 respectively:
Make the MME component listen on eth0 (or your actual network card name) interface instead of 127.0.0.2, otherwise the base station cannot connect to the core network.
Modify open5gs/mme.yaml, change the original configuration under s1ap:
mme: s1ap: server: - address: 127.0.0.2
To:
mme: s1ap: server: - dev: eth0 # Or your actual network card name
(Optional) Customize the network name broadcast by MME.
Modify open5gs/mme.yaml, find network_name:
network_name: full: Open5GS short: Next
Change it to your desired network name, for example:
network_name: full: Lan Tian Mobile short: LTMobile
Finally, restart all Open5GS related services:
systemctl restart open5gs-\*
Connecting FreedomFi/Sercomm Base Station to Open5GS
First, please ensure that you can log in to the FreedomFi/Sercomm SCE4255 base station's web management panel via IP address. If you cannot access the base station's web management panel, please refer to the section on enabling the management panel in my previous post.
Disabling TR-069 Remote Management
FreedomFi's Sercomm base stations by default connect to acs.freedomfi.com, a TR-069 server, to automatically obtain configurations. Although this remote management server was shut down when Helium Mobile discontinued its CBRS network, our base station will still continuously try to connect to this server. When using Magma to build the core network, since the Magma core network itself has TR-069 server functionality, we can keep remote management enabled and simply hijack remote management requests to our TR-069 server. However, Open5GS does not have TR-069 functionality, so we need to disable the base station's TR-069 remote management to avoid unnecessary requests, and prevent the base station's configuration from being accidentally overwritten.
Click TR098 at the top of the management interface, then switch to the MgntServer tab to switch to the base station's TR-069 remote management settings page:
Uncheck EnableCWMP, then click the Save button to save the settings.
Since the Sercomm base station management panel has some bugs, it is recommended to restart the base station here to ensure the settings take effect. The base station may automatically restart when saving settings, but if it does not, you can manually restart it by clicking the power button in the upper right corner of the management interface, or by manually power cycling it. After restarting, please return to this page and ensure EnableCWMP is unchecked.
At this point, the base station's TR-069 remote management function is disabled, and we can modify settings without fear of being overwritten by remote management.
Modifying Base Station CBRS SAS Connection Configuration
The next step is to connect the base station to the CBRS SAS server to obtain spectrum allocation, thereby avoiding conflicts with other base stations or operator signals, and preventing the FCC from SWATting you. When using the Magma core network, the CBRS SAS connection is automatically configured by Magma's TR-069 server, but since Open5GS does not have TR-069 functionality, this needs to be done manually.
Select A for Category, corresponding to indoor base stations.
Select GAA for ChannelType, corresponding to the lowest priority of the three types of CBRS users.
Enter /C=TW/O=Sercomm/OU=WInnForum CBSD Certificate/CN=P27-SCE4255W:%s for CertSubject.
Select indoor for Location, corresponding to indoor deployment.
If your base station's location has good GPS signal, Location Source can be set to GPS. However, if the GPS signal is poor, the base station will need to wait for GPS positioning to complete before connecting to CBRS SAS and starting to transmit signals after restarting. In this case, you can select Manual and manually enter the base station's latitude and longitude.
Latitude is latitude, with positive values for north of equator, and negative values for south of equator. Note that the unit for Sercomm base station's latitude and longitude is microdegrees (i.e., one millionth of a degree), so if you want to set 40 degrees north of equator, please enter 40000000.
Longitude is longitude, with positive values for east of meridian, and negative values for west of meridian. Note that the unit for Sercomm base station's latitude and longitude is microdegrees (i.e., one millionth of a degree), so if you want to set 80 degrees west of meridian, please enter -80000000.
Please obtain the latitude and longitude using your mobile phone or other devices for actual positioning. The base station's location needs to be relatively precise, otherwise it will affect the CBRS SAS spectrum allocation. This latitude and longitude should also be consistent with the latitude and longitude set on the CBRS SAS platform.
Select AMSL for HeightType, which means height above mean sea level.
Enter the base station's altitude for Elevation, in millimeters, so if you want to set 40 meters above sea level, please enter 40000.
Save the settings. You don't need to restart the base station yet; you can wait until configuring the base station's connection to the Open5GS core network in the next step.
Modifying Base Station Core Network Connection Configuration
The next step is to connect the base station to the Open5GS core network to transmit user information and data traffic.
Click Manage at the top of the base station management interface, then switch to the LTE Basic Setting tab:
Under Cell Configuration:
Check the AdminStats option, which means enabling signal transmission.
Select 1 for Carrier Number.
If you select 2 and adjust the settings below accordingly, you can enable carrier aggregation to double the bandwidth, but Sercomm's CBRS SAS implementation has some issues that may randomly cause signal transmission interruptions.
Do not check the Carrier Aggregation option.
If you want to enable carrier aggregation, check this box.
Select 20 for BandWidth to maximize bandwidth for highest speed.
Enter 0 for CellIDentity. If you have multiple base stations, you can enter 1, 2, etc., sequentially, ensuring no duplication between base stations.
If you want to enable carrier aggregation, enter 0,1, which means two different IDs separated by a comma.
Enter 100 for PCI. If you have multiple base stations, you can enter 101, 102, etc., sequentially, ensuring no duplication between base stations.
If you want to enable carrier aggregation, enter 100,101, which means two different IDs separated by a comma.
Enter 24 for TxPower.
Under S1 Configuration:
Select IPv4 for Tunnel Type. At this point, data between the base station and the core network is transmitted in plain text.
Since our base station and core network are on the same local area network and are physically controlled by us, the security risk here is small. However, if your base station needs to connect to the core network over Internet, you should try using the IPSEC option, but you will need to additionally configure IPSec tunnel related settings.
Enter the IP address of the Open5GS core network machine for MME IP Address.
If different components of your Open5GS core network are installed on different machines, enter the IP address of the machine running the MME component here.
Enter 315010 for PLMNID, corresponding to CBRS's MCC/MNC.
Enter 1 for TAC.
If your base station's location has good GPS signal, Sync Source can be set to GPS. However, if the GPS signal is poor, the base station will need to wait for GPS positioning to complete before starting to transmit signals after restarting. In this case, you can select FREE_RUNNING.
Save the settings. It is recommended to restart the base station once here to ensure the settings take effect. The base station may automatically restart when saving settings, but if it does not, you can manually restart it by clicking the power button in the upper right corner of the management interface, or by manually power cycling it.
After restarting, wait a moment and check the base station's indicator lights; the leftmost LTE status indicator light should be a steady blue, indicating that it's now transmitting LTE signals. This completes the base station configuration.
Take out your phone, select any SIM card, turn off the "Automatic Network Selection" option, and the phone will automatically search for nearby mobile networks. If your phone supports LTE band 48, you should see a network named Lan Tian Mobile (or your own configured network name), which is the signal transmitted by your base station.
The base station management panel should also display henb running, indicating that the base station is running normally:
Registering SIM Card Information with Open5GS
After the core network and base station are running normally, you can register SIM cards with the core network to allow phones and other devices using these SIM cards to connect to the LTE network.
Prepare a few programmable SIM cards and program authentication information to your SIM cards according to the SIM card programming tutorial in the previous post. Record the SIM card's IMSI/KI/OPC information.
Log in to Open5GS's web management panel, then click Add a subscriber:
Enter the SIM card's corresponding IMSI information for IMSI.
Enter the SIM card's KI for Subscriber Key.
Enter the SIM card's OPC for Operator Key.
Keep all other options at their defaults and click Save.
Insert the SIM card into your phone, wait a moment, and your phone should be able to connect to your mobile network.
Summary
This post mainly records the steps that differ from the Magma core network when setting up Open5GS, as well as some issues specific to setting it up on NixOS. Compared to Magma, Open5GS has a simpler installation process and does not rely on containerization management tools like Docker. If you are using Ubuntu, most of the above process is actually automatically completed during apt install.
From the perspective of LTE terminal devices (e.g., mobile phones), there is no difference in using these two core network software. Both have similar latency and network bandwidth, mainly limited by LTE communication itself. (Except for the strange bug I encountered with Magma where Android phones could not authenticate properly.)
I switched to Open5GS for the management convenience mentioned at the beginning. You can choose either Open5GS or Magma based on your preference.
]]>2025-07-20T12:38:31.000ZCopyright 2012-2026 Lan Tian @ Blog<![CDATA[用 Open5GS 搭建合法的 LTE 网络]]>https://lantian.pub/article/modify-computer/legal-lte-network-at-home-with-open5gs.lantian/2025-07-20T12:38:31.000Z在上一篇文章中，我用美国的 CBRS 频段和 Magma LTE 核心网软件搭建了一套合法的 LTE 网络。
下一步是让基站连接 CBRS SAS 服务器，获取频段分配，从而避免和其它基站或者运营商的信号发生冲突，以及避免 FCC 上门和你玩彩虹六号。在使用 Magma 核心网时，CBRS SAS 的连接配置由 Magma 的 TR-069 服务器自动下发，但由于 Open5GS 没有 TR-069 的功能，这部分就需要我们手动设置了。
从 LTE 终端设备（例如手机）的角度来看，使用这两款核心网软件并没有什么区别，两者的延迟、网络带宽都没有大的差别，主要还是受到 LTE 通信本身的限制。（除了我使用 Magma 时遇到的，Android 手机无法正常认证的奇怪 Bug）
我切换到 Open5GS，也是为了开头提到的管理上的便利。你可以根据自己的喜好，选择 Open5GS 或者 Magma 之一。
]]>2025-07-20T12:38:31.000ZCopyright 2012-2026 Lan Tian @ Blog<![CDATA[Using SideStore without StosVPN across your LAN]]>https://lantian.pub/en/article/modify-computer/sidestore-without-stosvpn-across-lan.lantian/2025-06-27T00:47:31.000Z2026-05-01 update: Added Nftables rule that apply to the entire network, provided by @KusakabeShi.
Foreword
SideStore is a commonly used iOS app sideloading tool that allows you to install third-party apps bypassing the App Store. It works by using your Apple ID to obtain a free Apple developer certificate, which is then used to sign the app you want to install, allowing it to run normally on your iOS device.
However, to maintain control over the iOS ecosystem, Apple prevents third-party app stores from using developer certificates to bypass restrictions on a large scale, setting a 7-day expiration period for developer certificates. Users need to regularly obtain new developer certificates and re-sign their apps to continue using the third-party apps they have installed.
Traditional sideloading tools, such as AltStore, rely on software like iTunes on a computer for the re-signing process. But unlike other sideloading tools, SideStore only requires computer assistance for the initial installation. After installation, SideStore can simulate a computer with iTunes installed, allowing the iOS system to communicate with it through a virtual network, thus achieving the effect of re-signing apps and even installing new third-party apps without a computer.
SideStore's virtual network can generally be implemented in the following two ways:
WireGuard: SideStore can create a WireGuard server on the device itself. Users can install a WireGuard client and connect to this server, allowing the iOS system to communicate with the simulated computer over the network.
The disadvantage of this method is that due to iOS system limitations, when the iPhone/iPad is using cellular data, the WireGuard client cannot connect to the WireGuard server created locally by SideStore. Therefore, SideStore only works properly when the device is connected to Wi-Fi.
Also, since the iOS system only supports connecting to one VPN at a time, if the user needs to use another VPN software, they have to manually switch between VPNs, which is quite troublesome.
StosVPN: A dedicated VPN client developed by the SideStore team that works exclusively for SideStore.
Compared to WireGuard, StosVPN is not affected by iOS restrictions and can work normally when the device is using cellular data. However, after trying it out, I found that StosVPN often disconnects automatically and cannot stay in the background for a long time. If the iOS device is not used for a while and StosVPN disconnects, and SideStore and other third-party apps fail to renew in time, you will have to find a computer to sign these apps again.
Also, since StosVPN is also a VPN, it is also subject to the iOS's limitation of only supporting one VPN connection at a time.
So I wanted to try to analyze the working principles of SideStore/StosVPN to see if I could integrate them into my home network or ZeroTier SDN network, allowing SideStore to refresh normally without extra VPN configuration.
Assigns IP address 10.7.0.0 to the iOS device, and configure iOS to send packets for 10.7.0.0/24 to StosVPN.
Defines an IP address 10.7.0.1, where StosVPN will simulate a computer with iTunes installed.
For each packet:
If the packet is sent from 10.7.0.0 to 10.7.0.1, swap the source and destination IP addresses, to send the packet back to the iOS device.
This logic is quite simple. SideStore essentially opens some ports locally on the iOS device, simulating a computer with iTunes installed. Suppose iOS creates a connection like this when trying to connect to the simulated computer:
TCP 10.7.0.0:12345 -> 10.7.0.1:54321
Then WireGuard or StosVPN will swap the source and destination IP addresses (but not the port numbers), rewrite the packet as follows, and send it back to the iOS device:
TCP 10.7.0.1:12345 -> 10.7.0.0:54321
From the iOS device's perspective, this is a new TCP connection from 10.7.0.1, unrelated to the previous connection sent to the computer. Since the port iOS is trying to connect to (54321 in this case) should be an iTunes port, and SideStore simulates iTunes locally, SideStore should be listening on port 54321 at this time and receiving the data.
After SideStore's simulated iTunes logic processes the data and generates a reply:
TCP 10.7.0.0:54321 -> 10.7.0.1:12345
WireGuard or StosVPN will again swap the source and destination IP addresses:
TCP 10.7.0.1:54321 -> 10.7.0.0:12345
This reply packet matches the initial connection sent to the simulated computer. iOS therefore believes it has received a reply from iTunes on the computer, and thus continues updating the developer certificate.
Simulating StosVPN's Working Logic with Nftables
Now understanding how StosVPN works, we just need to mimic its logic in our own network.
If you only have a few iOS devices, and they are all assigned static IP addresses, and you have a router running OpenWrt or another Linux system, you can simply use the following Nftables rules:
table inet sidestore { chain RAW_PREROUTING { type filter hook prerouting priority raw; policy accept; # Replace 192.168.0.xxx here with your iOS device's IP address ip saddr 192.168.0.123 ip daddr 10.7.0.1 ip saddr set 10.7.0.1 ip daddr set 192.168.0.123 notrack; ip saddr 192.168.0.234 ip daddr 10.7.0.1 ip saddr set 10.7.0.1 ip daddr set 192.168.0.234 notrack; # Add more rules as needed }}
The purpose of the above rules is that if a packet is received from your iOS device (192.168.0.123 or 192.168.0.234) destined for 10.7.0.1 (the virtual computer), it changes the packet's source IP to 10.7.0.1 (the virtual computer) and the destination IP to your iOS device (192.168.0.123 or 192.168.0.234), and then sends it out. The notrack here disables connection tracking, which prevents Linux from matching these packets to previously received packets and connection tracking entries, which could make the rules ineffective.
Since Nftables does not support using packet source/destination IP addresses as variables, it's not possible to achieve the purpose of "swapping source and destination addresses" with a single set of rules. Therefore, we need to add a rule for each iOS device. If you have a small number of iOS devices, you can write a separate rule for each device's IP address. However, if you have many devices, or if they don't have static IP addresses, you will need to write a rule for every IP address in your home network segment, which can be very troublesome. Also, if your router does not support Nftables or similar firewall functions and cannot rewrite packets in a similar way, you cannot achieve this functionality.
2026-05-01 update: Thanks to @KusakabeShi who provided the following rules, these Nftables rules can swap the source and destination addresses in one go. It will work for your entire network, and you don't need to create rules for each IP one by one:
table ip sidestore { chain NAT_PREROUTING { type nat hook prerouting priority -350; policy accept; ip daddr 10.7.0.1 ip daddr set ip saddr ip saddr set 10.7.0.1 notrack }}
SideStore VPN Tool
If you cannot use the above method, I have also written a small program that implements the above logic: SideStore VPN Tool. It can create a TUN interface on a Linux device, listen for packets destined for 10.7.0.1, and process these packets with the same logic as StosVPN.
To use this tool in your network, you need a device running Linux (such as a Raspberry Pi or a virtual machine), connect it to the same LAN as your iOS devices, and set a static IP address. Since the packets rewritten by the tool can be seen as a new connection from this Linux device to the iOS device, there should be no firewall or NAT between the iOS device and this Linux device, otherwise this new connection will be blocked, preventing SideStore's simulated computer from receiving requests normally.
Then, perform the following steps:
Enable IP Forwarding on the Linux device:
echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.confsudo sysctl -p
Install Rust and Cargo on the device.
Run the following commands to install and start the SideStore VPN Tool:
The SideStore VPN Tool will create a TUN device called sidestore and set up system routes to send all traffic destined for 10.7.0.1 to the tool for processing.
Add a static route on your main router:
Route: 10.7.0.1/32
Subnet Mask (if needed): 255.255.255.255
Gateway: The IP address of the Linux device mentioned earlier.
To minimize IP conflicts, this static route only affects a single IP address, 10.7.0.1. However, if your router does not support creating /32 routes, you can adjust the subnet mask to expand the scope of this routing rule, as long as it does not conflict with other devices:
Route: 10.7.0.0/24
Subnet Mask (if needed): 255.255.255.0
Gateway: The IP address of the Linux device mentioned earlier.
Ping 10.7.0.1 from any device on the LAN. It should now be reachable.
Disconnect WireGuard or StosVPN on your iOS device, and then try refreshing apps with SideStore. SideStore should now be able to refresh certificates normally even without a VPN.
如果你只有少量的 iOS 设备，并且给它们都分配了固定 IP，而且有一台运行 OpenWrt 或其它 Linux 系统的路由器，你直接用以下 Nftables 规则就可以了：
table inet sidestore { chain RAW_PREROUTING { type filter hook prerouting priority raw; policy accept; # 此处 192.168.0.xxx 改成你的 iOS 设备的 IP ip saddr 192.168.0.123 ip daddr 10.7.0.1 ip saddr set 10.7.0.1 ip daddr set 192.168.0.123 notrack; ip saddr 192.168.0.234 ip daddr 10.7.0.1 ip saddr set 10.7.0.1 ip daddr set 192.168.0.234 notrack; # 可以按需添加更多的规则 }}
上述规则的用途是，如果收到了来自你的 iOS 设备（192.168.0.123 或 192.168.0.234）发往 10.7.0.1（虚拟电脑）的数据包，就把数据包的源 IP 改成 10.7.0.1（虚拟电脑），目标 IP 改成你的 iOS 设备（192.168.0.123 或 192.168.0.234），然后发送出去。此处的 notrack 是关闭连接跟踪，防止 Linux 用这些数据包去匹配之前收到的数据包和连接跟踪条目，导致规则不生效。
由于 Nftables 不支持将数据包的来源/目标 IP 等信息用作变量，无法用一组规则实现「交换来源和目标地址」的目的，所以我们需要给每台 iOS 设备都添加一条规则。如果你的 iOS 设备比较少，可以给每个设备的 IP 都单独写一条规则。但如果你的设备很多，或者没有固定 IP，你就需要给家庭网段内的每一个 IP 都写一条规则，非常麻烦。同时，如果你的路由器不支持 Nftables 或类似的防火墙功能，无法用类似的方式改写数据包，也无法实现这样的功能。
table ip sidestore { chain NAT_PREROUTING { type nat hook prerouting priority -350; policy accept; ip daddr 10.7.0.1 ip daddr set ip saddr ip saddr set 10.7.0.1 notrack }}
SideStore VPN 工具
如果你无法使用上面的方法，我也写了一个实现上述逻辑的小工具：SideStore VPN 工具。它可以在 Linux 设备上创建一个 TUN 接口，监听发往 10.7.0.1 的数据包，并用和 StosVPN 相同的逻辑处理这些数据包。
要在你的网络内使用这个工具，你需要准备一台运行 Linux 的设备（例如树莓派或者虚拟机），将它连接到 iOS 设备所在的同一个内网中，并设置一个固定 IP。由于工具改写后的数据包可以看作是从这个 Linux 设备向 iOS 设备的一条新连接，所以 iOS 设备和这个 Linux 设备之间不能有防火墙或者 NAT，否则这条新连接会被拦截，导致 SideStore 的模拟电脑无法正常收到请求。
然后，执行以下操作：
在 Linux 设备上开启 IP 转发（IP Forwarding）：
echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.confsudo sysctl -p
]]>2025-06-27T00:47:31.000ZCopyright 2012-2026 Lan Tian @ Blog<![CDATA[Nix Logarithmic Math Library from Ground Zero]]>https://lantian.pub/en/article/modify-computer/nix-logarithmetic-math-library-from-zero.lantian/2025-05-19T23:02:28.000Z(Cover image from:
Wikipedia - Logarithm)
Since implementing these basic functions from scratch is also quite interesting,
I took some time to research it. Among these four functions, exp and ln are
somewhat difficult. pow and log can both be derived from the other two
functions:
lognxpow(x,n)=xn=lnnlnx=exp(n∗lnx)
Logarithmic Function ln
As we learned in math classes, when 0<x≤2, the natural logarithm
function lnx can be obtained using the following Taylor series:
When I implemented the trigonometric function last time, I wrote code to
calculate the result of the sin function based on the Taylor series.
Therefore, we only need to copy the code and change the formula for calculating
a term in the series.
{ # Precision limit, stop calculation when the Taylor expansion term is less than this value epsilon = pow (0.1) 10; # Absolute value function abs and alias fabs abs = x: if x < 0 then 0 - x else x; fabs = abs; # Helper function to calculate the product of all terms in a list multiply = builtins.foldl' builtins.mul 1; # Integer power calculation function, which is the `pow` function from the previous article, renamed to avoid conflict with the floating-point power function _pow_int = x: times: if times == 0 then 1 else if times < 0 then 1 / (_pow_int x (0 - times)) else multiply (lib.replicate times x); # Natural logarithm function, currently only handles 0 < x <= 2 ln = x: let # Calculate the i-th term in the series, where i starts from 1 step = i: (_pow_int (0 - 1) (i - 1)) * (_pow_int (1.0 * x - 1.0) i) / i; # Same as the `sin` function, calculate the Taylor series until the next term is less than epsilon (1e-10) helper = # tmp is used for accumulation, i is the index of the Taylor expansion term tmp: i: let value = step i; in # Stop calculation if the absolute value of the current term is less than epsilon, otherwise continue to the next step if (fabs value) < epsilon then tmp else helper (tmp + value) (i + 1); in helper 0 1;}
Although this Taylor series can handle the range 0<x≤2, after testing,
when x is close to the ends of the range, the number of terms to be calculated
becomes too large, causing Nix to report a stack overflow error:
Since the calculation method lnx=−lnx1 is applicable to the
entire 0<x<1 range, to maintain consistency in the calculation method, I
used this method for all inputs in this range.
Next, we only need to implement the logic to use different algorithms based on
the input range:
{ ln = x: let step = i: (_pow_int (0 - 1) (i - 1)) * (_pow_int (1.0 * x - 1.0) i) / i; helper = tmp: i: let value = step i; in if (fabs value) < epsilon then tmp else helper (tmp + value) (i + 1); in if x <= 0 then throw "ln(x<=0) returns invalid value" else if x < 1 then -ln (1 / x) else if x > 1.9 then 2 * (ln (sqrt x)) else helper 0 1;}
With the natural logarithm function ln, we can implement the generic
logarithm function logn with any base:
With the logarithm function in place, we still need another piece of the puzzle:
the natural exponential function expx=ex. The Taylor expansion of the
natural exponential function is:
expx=n=0∑∞nxn=1+x+2!x2+3!x3+...
Obviously, this Taylor expansion never converges, so we cannot calculate the
result term by term and then sum them up. Therefore, we can use the same method
as calculating arctan in the previous article, using polynomial regression to
fit the curve of the natural exponential function.
So which segment should we fit? When x≤0, we can directly calculate the
reciprocal of the absolute value exponent e−x1. And since we
already have the function _pow_int for calculating integer powers, when
x≥1, we can split x into integer and decimal parts and calculate them
separately:
x≤0,x>1,expx=exp−x1expx=(e⌊x⌋)(ex−⌊x⌋)
Therefore, we only need to fit the natural exponential function on [0,1).
Since we don't know how many terms to use in polynomial regression to get the
best result, I wrote a simple script using Python and Numpy to try from 1 term
to 100 terms and then select the fitting result with the smallest error:
import jsonfrom typing import Callable, Iterable, List, Optional, Tupleimport numpy as npfrom numpy.polynomial.polynomial import PolynomialEPSILON = 1e-10class Approximate: def __init__(self, fn: Callable[[Iterable[float]], Iterable[float]], linspace: Tuple[float, float, float], max_poly_degrees: Optional[int] = None): self.fn = fn # Range for polynomial regression, in np.linspace format self.linspace = linspace self.input = np.linspace(*linspace) # Calculate standard results using the standard function fn self.expected = fn(self.input) # Maximum number of terms to search self.max_poly_degrees = max_poly_degrees def _fit(self, deg: int) -> Tuple[float, Polynomial]: # Perform regression using Numpy's Polynomial regression class fit: Polynomial = Polynomial.fit(self.input, self.expected, deg, domain=(self.linspace[0], self.linspace[1]), window=(self.linspace[0], self.linspace[1])) # Calculate results using the regressed polynomial function result = fit(self.input) # Calculate error error_percent = np.fabs((result - self.expected) / self.expected) max_error_percent = np.max(error_percent[error_percent < 1e308] * 100) return max_error_percent, fit def run(self) -> Tuple[float, Polynomial]: # Search for the fitting result with the minimum error from 1 to max_poly_degrees terms error, poly = self._fit(1) for deg in range(2, self.max_poly_degrees+1): _error, _poly = self._fit(deg) if _error < error: error = _error poly = _poly return error, poly def explain(self) -> Polynomial: # Output results, where the JSON of Coefficients output can be directly copied into Nix code error, poly = self.run() print(f"Degree: {poly.degree()}") print(f"Error %: {error}") print(f"Coefficients: {json.dumps(json.dumps(list(poly.coef)))}") return polyApproximate(np.exp, (0, 1, 10000), max_poly_degrees=100).explain()
By comparing with the arctan function, which is also based on polynomial
regression, we can implement the exp function:
{ # Integer function int = x: if x < 0 then -int (0 - x) else builtins.floor x; exp = x: let # Extract the integer part of the input x_int = int x; # Extract the decimal part of the input x_decimal = x - x_int; # Polynomial coefficients calculated using Python and Numpy decimal_poly = builtins.fromJSON "[0.9999999999999997, 0.9999999999999494, 0.5000000000013429, 0.16666666664916754, 0.04166666680065545, 0.008333332669176907, 0.001388891142716621, 0.00019840730702746657, 2.481076351588151e-05, 2.744709498016379e-06, 2.846575263734758e-07, 2.0215584670370862e-08, 3.542885385105854e-09]"; in if x < 0 then # Calculate the reciprocal of the absolute value exponent 1 / (exp (0 - x)) else # Calculate the exponents of the integer and decimal parts separately, then multiply (_pow_int e x_int) * (polynomial x_decimal decimal_poly);}
Floating-Point Power Function pow
With the above functions, we can finally calculate floating-point powers using
xn=exp(n∗lnx). The only thing to note is various special cases:
{ pow = x: times: let # Check if the exponent is an integer is_int_times = abs (times - int times) < epsilon; in if is_int_times then # If it's an integer, use the existing integer power calculation function, which is faster and can handle the case when x < 0 _pow_int x (int times) else if x == 0 then # Base is 0, any power is 0 0 else if x < 0 then # Base is negative, cannot calculate floating-point power because we don't support imaginary numbers throw "Calculating power of negative base and decimal exponential is not supported" else # Calculate the result using the above formula exp (times * ln x);}
{ ln = x: let step = i: (_pow_int (0 - 1) (i - 1)) * (_pow_int (1.0 * x - 1.0) i) / i; helper = tmp: i: let value = step i; in if (fabs value) < epsilon then tmp else helper (tmp + value) (i + 1); in if x <= 0 then throw "ln(x<=0) returns invalid value" else if x < 1 then -ln (1 / x) else if x > 1.9 then 2 * (ln (sqrt x)) else helper 0 1;}
{ pow = x: times: let # 判断指数是否为整数 is_int_times = abs (times - int times) < epsilon; in if is_int_times then # 是整数时使用已有的整数幂运算函数，速度更快，并且可以处理 x < 0 时的情况 _pow_int x (int times) else if x == 0 then # 底数为 0，任意次幂都是 0 0 else if x < 0 then # 底数为负，无法计算浮点次幂，因为我们不支持虚数功能 throw "Calculating power of negative base and decimal exponential is not supported" else # 使用上述公式计算结果 exp (times * ln x);}
