Feature: UsbClient

[mackshot]

Hello everybody,

first of all thank you for this project.

Introductional words

I uses this project to set up a wlan access point for my parents who have a mobile home and are travelling through europe. That said, I am using the WLAN CLIENT option and ethernet is not used for now.
When there is no Wifi around an additional use case for my parents is to connect to 4G networks via a smartphone and then to share this connection to all wifi devices.

Using WLAN CLIENT option I noticed, when changing options in gui, settings sometimes get mixed up. It feels like some more if statements needs to be added to the source code to make sure that wlan0 and wlan1 get not mixed up.

What I did (so far)

1. I started(!) adding switches in the source code to better support WLAN CLIENT. This does not tackle all cases and problems but helps a bit on dashboard and should be taken as a starting point.

2. I added support to show status of an connected USB device sharing a network connection. So when you add a smartphone with USB Tethering turned on, you can now see on dashboard that there is an usb devices attached and you can see your ip address.

Final words

Would be happy to get some feedback. Thank you all
Markus

Preview (when USB Tethering is offline or no device is connected).

[billz]

@mackshot thanks for the PR. With the active discussion in #68, I think it's a popular enough use case to warrant building on this. Also related is @zbchristian's work in #582

I will make time and look at your PR although I don't have a USB modem on hand and test with a USB tethered phone.

[mackshot]

@billz Thank you for referencing the other issues/PRs.
Please keep in mind, that my work was focused on USB Devices registering themselves as network interfaces, like an Android Smartphone using USB-Tethering. All this "extra" work for real modems (which I really appreciate) are not needed there!

[billz]

@mackshot indeed, just thinking about how external interfaces might be more generally represented on the dashboard. I think your PR creates a good starting point for this.

For dev/testing I will replicate your setup by tethering an iPhone.

[Feni85]

Also related: there are quite a few Quectel-based Raspberry PI HATs on the market. These use a Broadcom chipset and can be connected via USB (fast) or UART (slow).

This chipset can dial via PPP (slow) or QMI (fast, but Broadcom closed source) and all variants present themselves as wwan0 in Raspbian with an optional ppp0 interface for the slower ppp dialer.

I've been using a Sixfab LTE HAT for some time now with RaspAP with great success, there is a tendency though to forget the default gateway when I change things in the GUI and I have to manually manipulate the interface every now and then if the connection dies.

Having a way in the gui to set a default gateway including wwan0 and manipulate the interface would be very useful.

https://github.com/sixfab
https://sixfab.com/ppp-installer-for-sixfab-shield-hat/
https://sixfab.com/qmi-interface-with-sixfab-shields-hats/

[billz]

@Feni85 good point. Ideally, support for USB client connections would be device agnostic such that a tethered phone, HAT, modem, etc. could be used interchangeably.

Re: default gateway, the Sixfab wwan0 interface should appear in the Networking UI where you can manipulate settings. Network interfaces are enumerated with ls /sys/class/net | grep -v lo and made available in the UI. See also this post by Sixfab.

[zbchristian]

I am running RaspAP either with a wifi adapter or a 4G modem as the client. For the ppp device the default gateway was actually one of the problems I had. Especially, because I wanted the device to do an automatic connection, when plugged in. I solved this with a script referenced in /etc/network/interfaces as soon as the device is up. So no need to do changes in the UI.
I did a hack to the dashboard in order to display the correct client device and to allow to stop/start the interface.

Setting the gateway in the UI under Networking might cause a problem, because in this case /etc/dhcpcd.conf is written without respecting the Hotspot settings (see #578 ). This leads to problems with the static IP of the access point, when dhcpcd is restarted or at the next boot of the raspi.

[billz]

@zbchristian I did some testing with a tethered iPhone and a USB multiplexing daemon (usbmuxd). This created an eth1 interface when connected to the Pi.

I did a hack to the dashboard in order to display the correct client device and to allow to stop/start the interface.

If the interface selected in the hostapd UI is used consistently, then the dashboard should simply display this as the active client interface. Your PR #582 addresses this. Is it meaningful to display/manage both the host and client interface? Need to think on this.

I solved this with a script referenced in /etc/network/interfaces as soon as the device is up. So no need to do changes in the UI.

Sounds good. This is obviously a goal of the project, ie. predictable actions that assist the user wherever possible.

[zbchristian]

@billz : a constistent handling of client devices would be very helpful. This requires to go from a pre-defined RASPI_WIFI_CLIENT_INTERFACE to a dynamically changing client interface and adapt the dashboard accordingly. Question is. what to do if multiple interfaces are present (e.g. wlan0, ppp0/wwan0)?

I did a hack to the dashboard in order to display the correct client device and to allow to stop/start the interface.

If the interface selected in the hostapd UI is used consistently, then the dashboard should simply display this as the active client interface. Your PR #582 addresses this. Is it meaningful to display/manage both the host and client interface? Need to think on this.

The PR #582 does only cover the switching of the access point interface. This includes the list of attached AP clients on the dashboard, but not the actual client interface. Currently the dashboard assumes, that RASPI_WIFI_CLIENT_INTERFACE is the client.

[zbchristian]

Just tried USB tethering with an Android phone and a usb0 network device is created and the default route is correctly set, so this works, as mackshot already mentioned, out of the box. So, only displaying the correct client(s) on the dashboard needs to be implemented.

[zbchristian]

@mackshot The mixup of the wifi interfaces is a problem, if two separate devices are used for the AP and the client. I solved this by fixing the device name to the MAC address via a udev rule and by assigning the AP to wlan1.
See #580 (comment) for details

[mackshot]

Well, from what I have read here so far, I have the feeling that we it might be a good idea to differentiate between the two different scenarios and that said handle them different and not at the same time:

Scenario 1: We have an external device, which registers in linux as network interface, like the iphone registering as ethX or an android phone registering as usbY: I feel that this scenario can be easily handled by a way (maybe similar to mine in the PR) to define an additional interface in the RaspAp config file and to show it like @billz or me (in the PR) did it.

Scenario 2: Modems or devices which need further configuration: Here way more work is todo, I guess (also rather non-technical) users understand, that he has to apply an additional configuration which would be nice to be supported via an GUI #68

That said, I suggest

1. first, to focus on Switching the interface of the access point not working properly  #580 first, to make sure that GUI and RaspAp works correctly when having multiple wlan devices.
2. second, that I hand in an updated PR (without my GUI modifications for topics related to Switching the interface of the access point not working properly  #580) addressing Scenario 1 (Wiki page needs some updates then as well).

The work on Scenario 2 / #68 can be continued in parallel. Unfortunately I have no device and cannot help there :-( .

[W9JYD]

I know this might be a little off topic but it's pretty relevant to this. It's kinda a "hackish" workaround but for me, it works.

It does require a paid app (Android only), though, called EasyTether Pro (US$9.99 on Google Play) and the developers (Mobile Stream) have been kind enough to include a .DEB file in an armhf binary on their website. I don't know if it's okay to include links to such here, but I will gladly provide them if asked!

just ssh it over from your computer or however you wanna (Mixplorer from XDA is the best, has SFTP, ftp, www and whatever servers you need) to the Pi, run sudo apt -y install ./easytether*.deb, open the app on the phone, tick the box to enable USB tethering, plug in the phone, and that's how I can do it.

I'm in the US, so carriers can be a bit shifty about how your data is used and sometimes you get a pittance for "hotspot data" yet unlimited data on the phone. (Cricket Wireless is my carrier, yeah an AT&T MVNO, but I like them)

This method works with my RaspAP setup: RPi 3 B+, and a very beefy USB power supply. (I bought it at a flea market but I checked its output before I bought it, and it puts out 5VDC@10A, and I checked it with a multimeter to be sure.)

I apologize if this isn't a workable solution but for me, it's sufficient and I just wanted to throw my working idea out to anyone who might be reading this.

And big applause to the RaspAP developer(s). I might be technically inclined (I'm a ham radio operator, dang it!), but sometimes just getting it done without much time (try setting up a hotspot for computers on Field Day!), and this does it. Use this method, the EasyTether app with RaspAP and it's supported.

Thanks for your time y'all. Peace Love and 73 de W9JYD