PfSense and Mobile Broadband
-
Hi Folks,
I have some information on my blog on how to add support for mobile broadband devices that are not detected by default in FreeBSD. Since pfSense is based on FreeBSD, the same information applies to pfSense as well.
The following document walks you through how to build a custom pfSense image with support for new mobile broadband devices:
http://technotation.com/2012/09/08/pfsense-and-mobile-broadband/Cheers, and good luck!
humand
http://technotation.com -
Nice write up. :)
I have a couple of questions.
You don't mention how you determined which switching method was necessary for your modem. In your example it appears no special switching was required but that wouldn't work for many (most?) modems.You could almost certainly load u3g as a kernel module at boot instead of having to recompile the kernel. This would make it much easier to update pfSense. However that wouldn't include the updated usbdevs list. Do you know if that can be loaded separately?
Steve
-
The article I wrote was targeted at mini pcie modules which do not have mass storage support hence no switching is required.
For the majority of the USB modems (including the ones who are not detected by default) switching is done automatically by the driver, so no manual switching should be necessary.
the switching function is called automatically upon detection
see this line inside u3g.c:
#define U3GINIT_SIERRA 2 /* Requires Sierra init command /
and also this line in usb_quirk.h:
UQ_MSC_EJECT_SIERRA, / ejects after Sierra USB command */
(other vendors have different init code)If your device is by a major vendor (sierra, novatel, option, huawei, zte) it should be supported as it's highly unlikely to have a different init from a model to another.
If the "modem" device is not turned on (u3g does not pick up anything on dmesg) is most likely because the idVendor and idProduct values are declared wrong. make sure the values are what they need to be prior to recompiling the kernel.As for the second question, pfSense has the u3g and usb modules statically linked into the kernel, which makes it impossible to have them updated with newly added device support without recompiling the whole kernel.
-
Of course! A minipci card would not have a mass storage mode. I didn't think that through. :-[
You would expect that manufacturers would have a few limited init codes however the huge list of codes over at the usb-modeswitch forums suggests otherwise.
Although I've never tried with u3g it is possible to use an updated kernel module by loading it at boot. It will overide the in kernel code. I've done this with network drivers.
Steve
-
All Sierra devices from that list use the same init sting: (SierraMode=1).
All Novatel devices from that list use the same init string: (MessageContent="5553424312345678000000000000061b000000020000000000000000000000").
All Option devices from that list minus 3 or 4 use the same init string as well: (MessageContent="55534243123456780000000000000601000000000000000000000000000000".
From those 3 or 4, the one actually has the Sierra init string (according to that document) which you should be able to get it to work fairly easily if that particular information is accurate.
The other 2 or 3 use a different Vendor ID value so it makes sense that the init string is different and it might or might not be supported.
Huawei has a couple of groups of init strings and so does ZTE. The most common ones are supported.Not EVERY device is supported but generally speaking most devices are, and a lot of them are not supported by the default install. This makes sense since new devices get released relatively often nowadays and its not easy to acquire them all for testing/developing purposes between FreeBSD releases. Not to mention the fact that you should also need an active plan with a matching provider to make sure that it connects too, not only that it's detected.
-
Although I've never tried with u3g it is possible to use an updated kernel module by loading it at boot. It will overide the in kernel code.
I suspect (don't know for certain) there might be trouble doing this IF the kernel module defines a global symbol (effectively attempting to redefine a symbol in the kernel). As best I recall, a device driver shouldn't generally need to define any global symbols.
-
I don't personally know Scott, but it would be much easier to insert a pause in the build process to give you a proper chance of modifying code. As it stands right now you will have to do everything in a hurry because the build process does not wait for you. Also, providing the build process for the stable source code for pfSense would probably be too much to ask.
-
If you load a KLD in /boot/loader.conf[.local] it can override the in-kernel drivers, we've done that with several network drivers in the past (at least fxp, em, igb) when someone needed support for a newer card on an older box. The same may work for u3g.
-
Keep in mind that the usb subsystem needs to be rebuilt as well and it's a dependency of u3g.
-
Hence my original question: is it possible to load the usbdevs as a module?
Somewhat uninformed speculation but…
Would it make any sense to not include u3g in the kernel but include it as a loadable module instead?Steve
-
We have discussed moving many things to modules, so it's possible.
-
It's possible to move both u3g and the whole usb subsystem (usb, uhci, ehci, usb_quirk, etc..) to dynamically loadable modules, but it's more of an architectural decision. The other option would be what I previously suggested, a pause in the build process to give you a proper chance of modifying code.
-
A pause in the build process is just asking for trouble, and would unnecessarily delay builds for everyone that doesn't need such a delay (most of them).
There are ways to setup the builder config to apply your own custom patches or overlay your own files as a part of the build process, a delay is not needed.
-
Actually no. What I meant by a "pause" is an option to continue with the build after user input. This is already implemented at different stages in the build process. The last stage includes fetching the kernel sources and compiling the kernel without giving you a proper chance of modifying it as this is all part of that last build_iso.sh script.
-
That's what the patches file and directives are for. You can also set in the build config that you want to build certain components as modules, and add extra device directives to the kernel. For modifying the source, the patches are what you'd want. ./apply_kernel_patches.sh would be your friend in that case.
-
That's more like it. I wrote a quick patch for the pfSense image build process:
–- ./sys/dev/usb/serial/u3g.c 2012-03-06 14:37:00.000000000 +0100
+++ ./sys/dev/usb/serial/u3g.c.new 2012-06-03 18:19:07.000000000 +0200
@@ -460,2 +460,3 @@
U3G_DEV(SIERRA, E6892, 0),- U3G_DEV(XXXXX, XXXXX, 0),
U3G_DEV(SIERRA, E6893, 0),
--- sys/dev/usb/usbdevs 2012-06-03 18:26:29.000000000 +0200
+++ sys/dev/usb/usbdevs.new 2012-06-03 18:26:22.000000000 +0200
@@ -2992,2 +2992,3 @@
product SIERRA E6892 0x6892 E6892
+product XXXXX XXXX XXXXX XXXXX
product SIERRA E6893 0x6893 E6893
Replace the XXXXX with your device information. Save as broadband.diff and place it under /home/pfsense/tools/patches/RELENG_8_3
Edit /home/pfsense/tools/builder_scripts/patches.RELENG_8_3 and add the following line:
~~broadband.diff
below ~~huawei_k4505.diff.
run ./build_iso.sh (the last stage) to build the images. (The build process will fail the first time, perform a cleanup and re-run ./build_iso.sh.)
That will re-fetch the kernel sources, re-apply the patches and build the images.
It should work for all Sierra and Novatel devices, and for the majrority of HUAWEI and ZTE.This applies to the pfSense build image process which is described at: http://devwiki.pfsense.org/DevelopersBootStrapAndDevIso
- U3G_DEV(XXXXX, XXXXX, 0),