This is my first post on the mailing list, so if I'm wrong please let me know. I would like to discuss a number of improvements that I would like to implement on openwrt to better integrate this technology.
So I would like to understand with you what changes could be useful to the community and what is a patch only for my ISP. Since December 2021 my ISP offers IPv4 connectivity through MAP-T. The configuration arrives via DHCP and is now automatic on Openwrt. The share ratio which can be 1:16 or 1:1. The CPE provided automatically opts out from 1:16 to 1:1 if you activate: - DMZ - Port forwarding - UPNP Let's move on to the improvements I've made and would like to integrate: - The map.sh script of the "map" module now creates a json structure in the "data" field [1], in this structure there is all the information of the interface configuration: the type of map, the prefix of the BR, the various FMRs and the shared v4 address. For an example of the generated JSON: https://pastebin.com/raw/7WQ30LVy - Luci allows a protocol to generate the DOM for its state [2], so a protocol could override the general behavior of the "luci-mod-network" module. This is used together with the new JSON structure [3] to show the user the range of associated ports and other useful information. For the visual results: https://i.ibb.co/FB7FHVd/immagine.png https://i.ibb.co/PmGVNFg/immagine.png. As you may have noticed, the default overview behavior is overridden [4] and the "EDIT" key is changed to "Status" if the interface is "virtual" and does not have an associated UCI node. If the button is pressed, a modal is opened with the call to the new "renderStatus" function of the protocol. Alternatively, if the protocol has an associated UCI node, a "Status" TAB is populated in the classic modal. [5][6] - We have added to odhcp6c the possibility to prefix to send an IA_PREFIX [7], this can be useful as my ISP foresees this behavior. (The v6 prefix also determines the port range and v4, so being able to request the same prefix is very important to firewall rules). To date, this function can be configured in the "Request IPv6-prefix of length" in Luci with the format: "v6-pd\len:IADID". I would therefore like to discuss whether it might be worth splitting this option into several fields. For now it has not been done for reasons of backward compatibility. All this still needs to be tested, especially with MAP-E to see if there may be some kind of regression. For this we have a local lab where we do all the tests. Now we come to the sore keys: - miniupnp should be configured at runtime when the map interface goes UP. Specifically, the range of ports to whitelist, and the shared IPv4. Being MAP a "tunnel", it does not have an IPv4 assigned to the interface and therefore miniupnp thinks it is not active (miniupnp uses the IP to understand if an interface is up or down [8]). Passing an IPv4 address is also quite simple to implement, but it would be a specific implementation for this protocol so I don't know how to go about it. I'll have to add a parser in the init.d script to read the interface JSON described in the point above. Specifically unlike Luci, netifd does not have a method for extracting data resolved by a protocol. Netifd only takes care of configuring or deactivating an interface. It would therefore be necessary to define a standard JSON structure for the protocols so a single parser can be implemented for other protocols as well. This might be useful for DDNS and other packages that require access to the WAN IP. My idea was to implement ubus into miniupnp to get the device status and interface IP using the conventional JSON structure described above. - Due to the overhead the MAP-T process sometimes makes connections to hangs/stalls. My ISP supports mini jumbo frames, so in my case I can set WAN6 that way. It would therefore be necessary to make a firewall rule to do MSS clamping if the MTU of the uplink interface is set to 1500. So far I have not seen any way in fw3 to do this. The auto generated rule seems hard-coded. The ISP CPE has that rule set [9], and it seems that other users that have MAP have the MTU manually set [10]. - When Share ratio is 1:1 the port set is not necessary and the CPE has a full port range available. Non TCP/UDP protocols fail to work in 1:1 ratio; to make them work we assign the calculated IP address [11] to the MAP interface. I'm not sure if this is the correct way to go but it is working. (tested with GRE) I also wish the whole team a happy new year! Thanks in advance for any feedback, Nicolò References: [1]: https://github.com/hitech95/openwrt/commit/6ed00a53325008f586f36c6e136bf06b950ba419 [2]: https://github.com/hitech95/openwrt_luci/commit/a401a42d0d8023909abfe6c2c3a3db141f12178e [3]: https://github.com/hitech95/openwrt_luci/commit/6dd7beb3d244eb5370a9732dd5e4f675352a2be9 [4]: https://github.com/hitech95/openwrt_luci/commit/042a2ae0eb463649f9f170fa5a8f2eeb67acfdd7 [5]: https://github.com/hitech95/openwrt_luci/commit/080cacd6fb7c308f37c7f3a69473fb11f238786a [6]: https://github.com/hitech95/openwrt_luci/commit/087b954c3b70aa6b7c80125719edfb87192a00ff [7]: https://github.com/hitech95/openwrt_odhcp6c/commit/f2a9a2fd56935cce4bccf98d44f8697aadb22792 [8]: https://github.com/miniupnp/miniupnp/blob/master/miniupnpd/getconnstatus.c#L38 [9]: https://code.rdkcentral.com/r/c/rdkb/components/opensource/ccsp/Utopia/+/58220/1/source/firewall/firewall.c#1086 [10]: https://forum.openwrt.org/t/map-portsets-not-fully-utilized-and-only-16-ports-available-due-to-discrepancies-between-connlimit-and-nat/105020 [11]: https://github.com/hitech95/openwrt/commit/8651e72592095058f513ab2a54e7c18418e143fd _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel