OpenWRT Tethering
This is the first article written about the Linksys AC Series of Routers that is independent of the main article, but is also included in the main Linksys AC Series Router Configuration Tips for OpenWRT.
Why? The original article was getting way too big. 40,000 plus words. The limitations of the Visual Editor in terms of opening and saving were becoming a drag. This isn't a criticism of the Visual Editor, just a fact.
Even though this article / section is titled in a somewhat open fashion, as if it applied to any OpenWRT device (which it sort of does), it was only tested and intended to be used on the Linksys AC Series of Routers. If you've stumbled upon this page / article, it is also included on the main Linksys_AC_Series_Router_Configuration_Tips_for_OpenWRT article.
Rough Notes
https://openwrt.org/docs/guide-user/network/wan/smartphone.usb.tethering
https://openwrt.org/docs/guide-user/network/wifi/connect_client_wifi
For USB "Mobile Hotspot" (Lumia / Microsoft Terminology) / "Tethering" (somewhat classic terminology): opkg install kmod-usb-net kmod-usb-net-rndis
Additional Packages: opkg install kmod-nls-base kmod-usb-core kmod-usb-net kmod-usb-net-cdc-ether kmod-usb2
IOS: opkg install kmod-usb-net-ipheth usbmuxd libimobiledevice usbutils (plus additional configuration)
When connecting to a Mobile Hotspot or Tethering via Wireless, a reboot of the router may be necessary for the router to connect to the device, perhaps a KMOD thing.
And of course, thankfully a Google search for specifics on specific / granular settings for MWAN3 don't show up in a search, so here's the link: https://openwrt.org/docs/guide-user/network/wan/multiwan/mwan3?s%5B%5D=mwan3
Using the same Wireless Radio for both connecting to Hot Spot and as an Access Point: "Host unreachable. This might indicate that you are not connected to the network, or might indicate a problem exists on the network between your ISP and the destination host."
Commands: IW, WIFI
There are issues if using a single radio to connect to a hotspot via (Client / STA / Station) virtual interface AND also having an access point (AP) mode operating for wireless clients. Solution: Travelmate;
https://forum.openwrt.org/t/travelmate-support-thread/5155
https://github.com/openwrt/packages/blob/master/net/travelmate/files/README.md
...attempted different start / stop sequences also of the radios and virtual interfaces, but that didn't work.
Commands: mwan3 interfaces, etc.
Issues: When "resetting" the radio, using Travelmate, wireless clients are disconnected and have to reconnect, not a big issue if they're set to reconnect automatically. Also in some instances, until network is restart, MWAN3 and / or travelmate do not allow the local router to ping out successfully when interfaces go up and down, but client machines can.
Also be aware there are some built in delays to all of this, so it doesn't happen automatically.
An alternative would be to purchase a WRT3200ACM or 32X as it has 3 separate radios that don't require the need for Travelmate. Additionally, for under $20, one could also purchase an additional USB Wireless interface such as: https://www.newegg.com/p/0XM-00HB-00005?Item=9SIACMW5833298 for a WRT1900ACS to give it three radios.
Also noticed that for the router, not clients, the routing table is messed up to the point where even when MWAN3 shows an active connection on one of the WANs, the routing table is such that there is no default gatewa configured.
Whatever route table the router uses, it doesn't use the correct one for itself after losing a tethered connection with MWAN3. A service network restart fixes the issue. ip ro and netstat -rn show all of the correct default routes, but the plain route command only shows the wwan route, even if a different one is being used. The following is a workaround for the /etc/mwan3.user file (Network, Load Balancing, Notification);
if [ "${ACTION}" = "disconnected" ] && [ "${INTERFACE}" = "wwan" ] ; then
# Do something on an ifup event for the wan interface only
ip route add default via 192.168.1.1
fi
The above script adds the correct default route back in...
Conntrack doesn't need to be installed for any of this stuff to work. Might be a good idea if MWAN noted that in the GUI.
And for those of you wondering about what the fork "Firewall Mask" (AKA mmx_mask in the configuration file for MWAN3), it defines the "mark mask" value in IPTABLES, which in turn allows for changes to be made in the Mangle Table for IPTABLES (https://serverfault.com/questions/425835/what-is-the-match-mark-field-in-iptables), and of course Mangle Tables allow for modifications of IP Packet Headers (https://serverfault.com/questions/467756/what-is-the-mangle-table-in-iptables). There is ZERO documentation about this on the OpenWRT site and Google returns about as many useful links to information about what "Firewall Mask" means. This paragraph is almost worth a dedicated page, except it won't rank as high as this one, so here it will stay. OK, what about the OpenWRT documentation that says this value is used in regards to number of WAN connections. https://openwrt.org/docs/guide-user/network/wan/multiwan/mwan3 Really? So what are the different values to set for 1 WAN (err, that would be stupid for MWAN as it is for 2 plus WANs), so what about 3 WANs, 4 WANs, what the fork are the different values for those?!?!?!?
defaultroute in /etc/config/network has nothing to do with anything other than defining a default route in IPTABLES, and it is enabled by default, essentially it is equivalent to not configuring a default gateway for a WAN interface.